On Fri, May 25, 2012 at 12:48 PM, Camera Man <i.like.privacy....@gmail.com> wrote: > On 05/24/2012 03:07 PM, Michael Bradshaw wrote: > > Is there a particular reason FFmpeg streams so slowly? > > > 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. > > 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. > > 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)
Great, thanks for that input. I'll check the transfer speeds going through localhost when I get the chance tomorrow. I wouldn't be surprised if that's it, and I hope it is because it sounds decently patchable. Thanks, Michael _______________________________________________ Libav-user mailing list Libav-user@ffmpeg.org http://ffmpeg.org/mailman/listinfo/libav-user