[MPlayer-dev-eng] A/V sync problem with independent demuxers
Arpi
arpi at thot.banki.hu
Sun Mar 2 18:24:02 CET 2003
Hi,
> 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
> 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
> thing I noticed is that immediately after pressing the space bar to resume
> playback after the pause, MPlayer issues an unusual number of reads to the
> audio demuxer, before it resumes reading from the video demuxer.
of course. since audio card buffers up 0.3-1.5 sec (avg. values for avg.
soundcard) so the audio card's buffer has to be filled before we continue
playback. (the audio buffer is a FIFO-like thing, unless you fill it enough,
it won't start play at the right time)
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 have seen this problem happen when audio and video are MPEG-1 or 2
> elementary streams; I have not yet confirmed whether or not the same
> problem occurs with other codecs (but I suspect they probably do).
it's all demuxer problem, it doens't (shoudl not) happen when playback
normal files or use demuxers written by me.
> Could someone who's familiar with MPlayer's A/V synchronization mechanism
> take a look at how it deals with independent audio/video demuxers?
the a-v core doesn't care if your steram sare independent or interleaved -
it just requires accurate PTS values for both streams and all is right.
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
}
a_buffer_delay is usually 0.3..1.5 seconds, depending on card, driver,
samplerate, filters, channels, format, sometimes audio codec too.
A'rpi / Astral & ESP-team
--
Developer of MPlayer, the Movie Player for Linux - http://www.MPlayerHQ.hu
"However, many people beg for its inclusion in Debian. Why?" - Gabucino
"Because having new software in Debian is good." - Josselin Mouette
"Because having good software in Debian is new." - Gabucino
More information about the MPlayer-dev-eng
mailing list