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) |
_______________________________________________ Libav-user mailing list Libav-user@ffmpeg.org http://ffmpeg.org/mailman/listinfo/libav-user
