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

[Michael Niedermayer]

On Tue, Jan 07, 2014 at 02:22:06PM -0700, Roger Pack wrote:
> 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-

>  udp.c |    9 +++++++++
>  1 file changed, 9 insertions(+)
> de134ef36275227a2aa172ffa3d3f4a051829e53  0001-debug-log-udp-socket-size.patch
> From 1a86525dd466c1a0fef517536e83e12026c7c849 Mon Sep 17 00:00:00 2001
> From: rogerdpack <rogerpack2005 at gmail.com>
> Date: Mon, 6 Jan 2014 12:57:52 -0700
> Subject: [PATCH] debug log udp socket size
> 
> Signed-off-by: rogerdpack <rogerpack2005 at gmail.com>

applied

thanks

[...]

-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Frequently ignored answer#1 FFmpeg bugs should be sent to our bugtracker. User
questions about the command line tools should be sent to the ffmpeg-user ML.
And questions about how to use libav* should be sent to the libav-user ML.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: Digital signature
URL: <http://ffmpeg.org/pipermail/ffmpeg-devel/attachments/20140108/ca938140/attachment.asc>