[MPlayer-dev-eng] Re: A/V sync problem with independent demuxers

[D Richard Felker III]

On Sun, Mar 02, 2003 at 03:05:57PM -0800, Ross Finlayson wrote:
> 
> >> I have found that MPlayer's internal A/V synchronization mechanism often
> >> does not work well for situations (such as RTP streaming) in which the
> >> audio and video demuxers are independent (i.e., are each fed from a
> >> different input stream, rather than both being tied to a single input
> >> stream).  In this case, the packets read for each demuxer (using
> >> "demux_fill_buffer()") are given the correct "pts" (presentation
> >> timestamp), but the rest of MPlayer often (but not always) fails to
> >> maintain A/V synchronization.
> >
> >disagree
> 
> OK, but this is something that I have observed happening (often) :-)
> 
> >> I have seen two different situations occur.  The first situation occurs
> >> when the user presses the space bar to pause the playout.  At this point
> >> the audio and video playout both stop immediately, as they should.  But
> >> after the user presses the space bar again to resume playing, video gets
> >> several seconds ahead of audio (i.e., "A-V:" is negative).  The length of
> >> the gap seems to correlate to the duration of the pause.  Thus, it seems
> >> that MPlayer's internal buffering is not handling pauses correctly.  One
> >
> >wtf?
> >mplayer is not threaded. if your demuxer keep reading one steram under
> >pause, it's your problem
> 
> I think you misunderstand.  My demuxers are not reading anything during a 
> pause (nor is the rest of MPlayer reading from either of the demuxers 
> during a pause).  (The underlying OS *does* continue to buffer incoming RTP 
> packets - as part of its normal UDP socket receive buffering - but these 
> packets will later get delivered, in FIFO order, to the appropriate demuxer 
> the next time it's read.)

NO!! The OS does not have 50 meg udp buffers!!! After the (very small)
buffer fills up, old packets will simply get dropped. If you're
sending audio and video on separate ports, this would explain your
problem. Video is much bigger, so all but the latest video will be
dropped, whereas a few seconds of audio might get buffered.

Rich