[MPlayer-dev-eng] Re: A/V sync problem with independent demuxers
Ross Finlayson
finlayson at live.com
Mon Mar 3 00:05:57 CET 2003
> > 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.
More information about the MPlayer-dev-eng
mailing list