[MPlayer-users] ffmpeg://udp:// ... feedback

[Roger Pack]

On 1/6/14, Roger Pack <rogerdpack2 at gmail.com> wrote:
> Hello.
> I noticed when playing
>
> ffmpeg://udp://127.0.0.1:2000 type streams, I would frequently get
> messages like this:
>
> [udp @ 0x1a4487700]Part of datagram lost due to insufficient buffer size
>
> it appears from digging into the code that what this means is that the
> "udp_read" method for ffmpeg is called first with request size "2048"
> which works fine, and it returns out the first udp packet, typically
> size 1472.
>
> It is then called again with size 576.  However, this is smaller than
> the "next packet to give" so (if compiled with PTHREAD_CANCEL support)
> it will return half a packet and discard the rest.  If compiled
> without PTHREAD_CANCEL support, it will return half a packet and
> silently discard the rest.  Which causes lots of corruption since many
> bytes are lost.  Interestingly, in the normal stream/udp.c file, only
> request of size 2048 come through.  I'm not entirely sure what is the
> right way to go here.  My guess is that mplayer should not be
> requesting such small byte sizes though.  Any feedback here?

ok I suppose I can attempt a patch if there's no other interest.  What
should be the recommended behavior here, just "pretend like its done"
if it gets to less than 2048 bytes remaining in the buffer?
For "normal" streams/udp.c it always calls it with "2048 bytes at a
time" maybe there's some logic that could be shared there and it could
call ffmpeg with the same logic?
A new parameter setting called "minimum read size"?
Any thoughts here?
-roger-