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

[Roger Pack]

On 1/6/14, Andrey Utkin <me at andrey-utkin.pp.ua> wrote:
> 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.

Appears you are correct.  In OS X you can set it to (at least) 1MB, in
windows 10MB (or more?) and in linux, I didn't notice but seemingly
has max 262142 (which is still higher than the default setting of
212992 on my side).  So...I guess that pthread cancel thread might be
more useful/necessary in Linux (setting it above the max 262142 does
seem to set it to the max allowable, which is an improvement though,
as you mentioned, attached patch might be useful/helpful there to
allow users to notice they are unable to set it higher--or should be
be INFO not DEBUG?).
Thank you.
-roger-
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-debug-log-udp-socket-size.patch
Type: application/octet-stream
Size: 1114 bytes
Desc: not available
URL: <http://ffmpeg.org/pipermail/ffmpeg-devel/attachments/20140107/826ca14a/attachment.obj>