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

[Reimar Döffinger]

On 06.01.2014, at 21:34, Michael Niedermayer <michaelni at gmx.at> wrote:
> On Mon, Jan 06, 2014 at 12:36:26PM -0700, Roger Pack wrote:
>> On 12/23/13, Roger Pack <rogerdpack2 at gmail.com> wrote:
>>>> The maximum size of the buffer seems to be around 300k, at least on Linux
>>>> (it could be higher with the help of root privileges, but we can not
>>>> count
>>>> on it). That is about half a second of digital TV, unless I am mistaken.
>>>> A
>>>> video processing application can easily be busy for that amount of time,
>>>> even if it is on average fast enough to work in real time.
>>>> Therefore, we need something whose task is to read from the socket as
>>>> fast
>>>> as possible, storing the data into a larger buffer.
>> 
>> 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...

No, they can't, not unless someone with root privileges changes the max size, in which case they could probably almost as well change the default size.
Also if I remember right trying to set a larger size can make things even worse on some OSs. Maybe I misremember, but at least read the commit log _very carefully_ before changing this, this was tried before and failed.

> 1mb is a much more reasonable default than a few kb for video
> when theres no thread around to pick up data quickly

I am fairly certain we tried that before deciding to require threads.
It might still be a reasonable fallback thing to try if threads are not available I guess...