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

[Roger Pack]

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...

# The cleanest way is to use asynchronous IO (overlapped IO in Microsoft
# slang). There are several variants, but in this case I would advise either
# to create an event object signaled when the read is finished and another
# to request the interruption and to do a WaitForMultipleObjects, or to use
# a completion port object (which is, in my opinion, the most elegant
# version of asynchronous IO for windows).

That would probably work well (WaitForMultipleObjects), though I don't
have the expertise to quite do it myself...

Thank you.
-roger-