[MPlayer-users] Bug: av sync, bframes, dwStart issues

[John Stebbins]

I've scanned over the mail list archives and found activity in this area
back in March 06 by John Koleszar and Corey Hickey.  Some fixes were
applied, but I believe the real problem is being masked, or worked
around rather than truly fixed.

The symptom is audio leading video by 1 or 2 video frame times
(depending on bframe settings) at start of playback.  Currently,
mencoder masks this by applying an audio delay through the use of
dwStart in the audio stream header of the avi file. I believe this to be
an incorrect fix because bframes are not guaranteed to be generated even
though you have enabled them in your encoding.  Some video sequences may
be generated that contain no bframes, so your av sync will jitter by as
much as 2 video frame periods between sequences that contain bframes and
sequences that do not.

This masking becomes more problematic when using encoder front-ends that
encode the audio and video separately and then mux them in a final step
using tools such as mkvmerge or ogmmerge.  OgmRip is a good example of
such a front-end. Because the streams are encoded separately and the
front-end knows little (nothing) about the delays that could be caused
by the various decoding processes, the front-end does not intelligently
insert compensating stream delays. And it shouldn't need to.

I believe a correct fix belongs in mplayer and would delay the
presentation of initial audio and video until the decoder has queued
enough decoded video frames to handle its worst case video delay due to
bframe processing.  This would be done entirely by the player with no
hints from the encoder (e.g. dwStart fudge factor).  The player knows if
it supports bframe processing and should be able to delay initial
presentation until sufficient buffering of decoded frames has occurred
to handle its worst case delay that can be caused by bframe processing.

Note that fixing this problem may dove-tail into some of the pts
processing issues that have been raised (Koleszar). AV sync and decoder
rate throttling should be handled at the stage in the pipeline where
presentation is about to occur, not where data is initially fed into the
decoder. I haven't looked at mplayers code enough to know how this is
handled, but it seems something must not be right here.

John