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

Roger Pack rogerdpack2 at gmail.com
Sat Mar 8 01:00:28 CET 2014

On 2/18/14, Reimar Döffinger <Reimar.Doeffinger at gmx.de> wrote:
> On Tue, Feb 18, 2014 at 10:09:56AM -0700, Roger Pack wrote:
>> On 1/6/14, Roger Pack <rogerdpack2 at gmail.com> wrote:
>> > Hello.
>> > I noticed when playing
>> >
>> > ffmpeg://udp:// 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"?
> Already exists, it's called "sector_size", I am just not sure about
> 1) If it behaves quite the right way, it was really intended for DVDs etc.
> 2) I have some doubts setting it for all cases unconditionally is a good
> idea, and I don't know if libavformat exposes some recommended/minimum
> read size itself...
> I also have a slightly bad feeling I might be missing a thing or two
> here.

Interesting.  I know that using ffmpeg to receive from (its) udp.c it
seems to always call down with a 64KB buffer, fwiw.  I'll look into
sector_size when I have the time.

More information about the MPlayer-users mailing list