[FFmpeg-devel] Network IO in FFmpeg (was: abstractable threading api)
michaelni at gmx.at
Mon Jan 6 21:34:11 CET 2014
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,
> 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
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
Concerning the gods, I have no means of knowing whether they exist or not
or of what sort they may be, because of the obscurity of the subject, and
the brevity of human life -- Protagoras
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 198 bytes
Desc: Digital signature
More information about the ffmpeg-devel