[FFmpeg-devel] udp.c comments/thoughts

[Roger Pack]

On 1/6/14, Andrey Utkin <me at andrey-utkin.pp.ua> wrote:
> On 06.01.2014 21:37, Roger Pack wrote:
>> On 1/6/14, Roger Pack <rogerdpack2 at gmail.com> wrote:
>>> Hello.  I noticed that in udp.c sometimes (with pthread cancel
>>> enabled) it says "Part of datagram lost due to insufficient buffer
>>> size" (I think what it meant to say is due to insufficient read
>>> request size?)
>
> No principal difference. But we could somewhat improve log message with
> user-friendly advice, if possible. I haven't check deeply this at the
> moment.
>
>>> Also it's quite confusing that fifo_size is in multiples of 188.
>>> Unless you an MPEG engineer, nobody anticipates this.  I might suggest
>>> adding another setting of "fifo_size_bytes" or something so that
>>> people realize there's a difference.
>
> Yep, confusing. Historical issue.
> "fifo_size_bytes" sounds a sort of humiliating for this proper option,
> comparing to ugly "fifo_size" option taking multiples of 188. Maybe some
> more "respectful" name could be found?
>
>>> Also I've noticed that the default RECV buffer size is 64K by default
>>> for udp packets.  I might suggest increasing this substantially, as
>>> this is far too little for many streams, and the OS can typically
>>> handle far higher (1M-10MB at least).
>
> Are there any official documents regulating allowed UDP packet sizes? Or
> you tell us what happens to work with current Linux? Maximum which i
> have seen in nature was 0xffff bytes via IPv4 loopback interface.

The default reported by Ubuntu 12.10 is 212992 which I believe you
divide by 2 to get the "real" value, 106496.
This means that currently, by default, FFmpeg is actually changing the
buffer size to *lower* the default (since it sets it to 64KB).  Which
may not be desirable.

I could see changing the default to 128KB instead, or possibly adding
extra/more logic so that the default is MAX(current, 64KB), thought?

>> Also as a follow-up, perhaps overrun_nonfatal should be default, since
>> it's basically just dropping packets, which UDP by default can do and
>> does anyway (so currently it behaves slightly differently with pthread
>> cancel enabled than otherwise, which is somewhat confusing).
>
> Makes sense, but the default state of this option was chosen in a way
> not breaking previous behaviour.

I believe the default is to "die" on buffer overrun, which is
different than the behavior is PTHREAD_CANCEL is not available, so
currently if you specify nothing, it "might" or "might not" work...my
guess is that the old behavior was to not die as well, since the
kernel dropped the packets, or am I wrong there?

Thanks.
-roger-