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

[Ross Finlayson]

> > 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.)

>btw it's depend on -ao used. some ao drivers can do real pause, ie. keep
>audio buffer contents but stop playback imemdiately, so it doens't have to
>re-fill buffer after unpause. some others can't do that, so the card plays
>teh rest of data from buffer _after_ pause, and after unpause the buffer has
>to be filled again.

I suppose this might explain a brief period of asynchrony after resuming 
from a pause, but I have found that the asychrony continues indefinitely 
after resuming.  Shouldn't MPlayer figure out that it needs to delay 
resuming video playback until the audio buffer has filled up once 
again?  In other words, if A/V were in sync before the pause, then 
shouldn't MPlayer eventually figure out how to get them back in sync after 
resuming from the pause?

>it's all demuxer problem, it doens't (shoudl not) happen when playback
>normal files or use demuxers written by me.

Again, I think you misinderstand.  My demuxers (audio and video) are merely 
delivering buffers to the rest of MPlayer in FIFO order, and they *are* 
setting "pts" correctly.  (I have confirmed this.  Note that the "pts" for 
a RTP stream comes from the RTP packet timestamp (calibrated by RTCP), and 
is completely independent of the time at which the packet arrived, or the 
time at which the demuxer read the packet.  So, I'm quite sure that they're 
accurate, and in fact the "A-V:" display at the bottom of the screen 
matches the actual asynchrony that I'm hearing/seeing.)

>the whole a-v works this way: (VERY simplified:)
>
>while(1){
>   if(a_pts-a_buffer_delay<v_pts)
>     play_audio_chunk
>   else
>     play_video_frame
>}

This does not explain the second situation that I observed, in which 
MPlayer sometimes reads from the video demuxer at a slower rate than it 
should - so that A-V becomes an increasingly large positive number over 
time.  (With your pseudo-code, the only way this could happen is if 
"a_buffer_delay" becomes increasingly large over time.)

>a_buffer_delay is usually 0.3..1.5 seconds, depending on card, driver,
>samplerate, filters, channels, format, sometimes audio codec too.

How is the "a_buffer_delay" value computed?  Can it change over time, and 
is there any way in which this computation could be getting messed up?

>the a-v core doesn't care if your steram sare independent or interleaved

That may be true, but the effects I'm seeing are very real, so I have to 
wonder why MPlayer is (sometimes) having A/V sync problems with incoming 
MPEG/RTP streams, and not when the file is being played directly.  I know 
that (i) each demuxer is delivering packets to the rest of MPlayer in FIFO 
order, and (ii) these packets are each being given a correct "pts" value, 
which is why I'm wondering if the problem might be related to the fact that 
- in my case - the audio and video demuxers are independent.

Next, I'll try playing around with "-autosync" and "-mc" to see if I they 
have any effect on the problem.  But it shouldn't be necessary to have to 
mess with funky command-line options like this...

         Ross.