[FFmpeg-devel] Network IO in FFmpeg (was: abstractable threading api)

[Andrey Utkin]

On 06.01.2014 22:34, Michael Niedermayer wrote:
> On Mon, Jan 06, 2014 at 12:36:26PM -0700, Roger Pack wrote:
>> Interestingly, I looked into the numbers for different OS's
>> SO_RECVBUF.  In OS X currently the code by default sets it to 65K from
>> a 42K default.  In windows it sets it to 64K from an 8K default.  In
>> linux it attempts to set it to 64K from about 100K default (it
>> actually sets it *down*) so...for at least those OS's, unless you
>> specify manually a high "buffer_size" then it is prone to packet loss,
>> especially when i-frames come "all at once" in several UDP packets,
>> etc.
>> 
>> Maybe it should set it higher by default, and this is expected?  It
>> appears all the OS's mentioned can handle 1MB SO_RECVBUF at least...
> 
> 1mb is a much more reasonable default than a few kb for video
> when theres no thread around to pick up data quickly

Yep but default sysctl settings in linux allow no more than ~200 KB, see 
/proc/sys/net/core/rmem_max (on my stations now i have 196608 and 212992 
set). With such default settings, UDP loss happens anyway, and sometimes 
changing sysctl settings is not possible. So changing default kernal 
buffer size doesn't fix everything automatically.
But still, raising ffmpeg default value is worthwhile, because AFAIK as 
a result of corresponding setsockopt() the kernal buffer size is raised 
to available maximum. Although growing kernal buffer should be taken 
seriously, because it affects available system resources. If there is a 
lot of ffmpeg UDP processing instances, kernal buffers can take quite 
big part of RAM.

-- 
Andrey Utkin