
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">

<html style="direction: ltr;">

  <head>

    <meta content="text/html; charset=ISO-8859-1"

      http-equiv="Content-Type">

    <title></title>

    <style>body p { margin-bottom: 0cm; margin-top: 0pt; } </style>

  </head>

  <body style="direction: ltr;"

    bidimailui-detected-decoding-type="latin-charset" bgcolor="#ffffff"

    text="#000000">

    On 05/24/2012 03:07 PM, Michael Bradshaw wrote:<br>

    <blockquote

cite="mid:CAJ29FNYtP7qxYScZKwaLqEBtBk9O7UTHExz=EU2QbzdPEcrRfg@mail.gmail.com"

      type="cite">Is there a particular reason FFmpeg streams so slowly?<br>

    </blockquote>

    <br>

    Speculation: Sounds like it might be a buffering problem: The easy

    way to test it is to time transfers from a nearby machine (localhost

    or anything with <1ms ping time), vs the internet. If  things

    become disproportionally faster (e.g., chrome goes *3 from 4MB/sec

    to 12MB/sec but ffmpeg goes *50 from 80KB/sec to 4MB/sec), then this

    is your problem.<br>

    <br>

    Browsers (and wget and curl and friends) set the socket buffers to a

    few megabytes. IIRC, ffmpeg leaves tcp connections at the 8KB

    default. Which means, after 8K-16K have been received and not yet

    processed (which takes all of ~5ms in your case), the local kernel

    tells the remote one "my buffer is full, stop sending", and only

    when this has been processed, it will tell the other side "ok, you

    can resume". Because of how TCP works, this is synchronous and

    inserts delays that depend on the ping time to the server.<br>

    <br>

    AFAIK, there's no way to set the http/tcp buffer size in ffmpeg;

    (udp connections have the ?buffer_size=xxxx option, but tcp doesn't)<br>

  </body>

</html>