Re: Arpi: we need to discuss MPlayer's A/V sync

Arpi <[email protected]> Sat, 6 Jul 2002 16:36:31 +0200
Newsgroups gmane.comp.video.mcf.mplayer
Message-ID <[email protected]>
Hi,

> Albeu said that MPlayer needs timestamp for every audio frame and that 
> it cannot just decode those frames and use the duration given by the 
> decoder for sync.
It's false.
Mpeg2 has not timestamps for all frames, and progresisve streams has no
constant duration but playback works well. same for realvideo.

Normally mplayer uses only the duration from the decoders to do teh timing,
and uses timestamps only to detect desync and slowly correct it by changing
video speed. Anyway, for variable speed video (no constant FPS but every
frame has duration or timestamp) it requires timestamps as duration is
calculated from that *if no FPS given).
> 
> So, how exactly does this thing work? How does it handle most current 
> containers (AVI, Ogg) that usually contain audio frames without timecodes?

avi is simple - it has either CBR audio, so you have a fixed compression
ratio (timestamp=bytepos*constant), or has VBR audio with constant
packets/sec rate. Byte size of packets varies, but each packet contains the
same amount of PCM samples.

Ogg is problematic, as for low bitrates (especially at black video frames or
silence sound) there are no timestamps for many seconds, so a-v may shift a
bit. Also, ogg files has no constant FPS, so you need timestamps to
calculate durations. Anyway, mplayer plays ogg files well, at least the
samples i tried.

> Adding timecode (or even time offset) for every frame makes overhead 
> significantly bigger.
you MUST have either fixed rate (bitrate or packet rate for audio, and
FPS for video) or duration for every video frame. Audio don't have to have
timestamps too often, but it should have timestamps for keyframes
for seeking (i mean if there is a video keyframe with timestamp X, there
should be an audio timestamp X (or close to X) too).

> Would it be possible to just handle frames of a single Block as one big 
> frame, when doing sync? This way you wouldn't need to quess timecodes 
> for frames which don't already have one.

No.
But if you don't have timestamps nor FPS, how should teh decoder know the
display time of the frames??? Or you mean fixed FPS for a block of frames?

MPlayer currently increases previous timestamp by previous frame duration if
no timestamp for the current frame, so it works even with zero timestamps,
but no av sync _correction_ then.

> In case you are not familiar with MCF, Block is an element that contains 
> timecode and data. With audio it normally contains several frames and 
> then you only have timecode for the first one. Of course a Block only 
> contains audio for around 50 ms, so there is no trouble with seek 
> accuracy nor sync drift.

audio is not problem while you have constant audio samplerate (constant
number of PCM samples per second - note that quicktime allows variable
samplerate too - but i haven't seen any file using this feature)

for constant FPS video or vidoe frames with duration value i don't need
timestamps.

the problem, again, with ogg files that no fixed FPS and no timestamp for
every video frame.


A'rpi / Astral & ESP-team

--
Developer of MPlayer, the Movie Player for Linux - http://www.MPlayerHQ.hu