[MPlayer-dev-eng] [PATCH] Fix for libmad audio/video sync problems (on variable bitrate audio)

[Siarhei Siamashka]

On 3 January 2008, Compn wrote:
> On Thu, 3 Jan 2008 02:52:30 +0200, Siarhei Siamashka wrote:
> >Hello,
> >Unfortunately, you could not confirm the audio/video sync problem with
> >the sample I submitted earlier:
> >http://lists.mplayerhq.hu/pipermail/mplayer-dev-eng/2007-September/053923.
> >html
>
> i've heard one or two people on #mplayer say that libmad has a small
> desync (47ms ?)

There are not too many '-ac mad' users, otherwise there would be a lot more
bugreports for sure :) Desync can vary depending on how much estimated audio
bitrate (taken from the first mp3 frame) differs from the real average bitrate
in the soundtrack.

> >I can try to reencode and upload a different sample to show the
> >problem if you provide me with any video clip for which you are able
> >to notice audio/video sync issues.
>
> any clear video of people talking (news report) would do.

Actually I'm not very good at searching for videos of news reports (lost
probably 20 minutes looking for them before giving up), direct link where 
some suitable video file could be downloaded would be very much welcome.


Anyway, please try the following:

$ wget 
ftp://upload.mplayerhq.hu/MPlayer/samples/benchmark/testsuite1/matrixbench_normdivx_vbrmp3.avi

$ mencoder -oac mp3lame -lameopts br=32 -ovc lavc -lavcopts 
vcodec=mpeg4 -endpos 35 -o test.avi matrixbench_normdivx_vbrmp3.avi

$ mplayer -ac mad test.avi

$ mplayer -ac mp3 test.avi

Look at the place where the policemen says "sh*t", followed by a hit sound 
in the next scene. Audio is a bit ahead of the picture when using libmad for
audio decoding without a patch. If the desync is too small to notice, just
increasing 'sh->audio_in_minsize' (from 4096 to 2*4096 for example or even to
10*4096) in 'preinit' function from 'ad_libmad.c' will make it larger.

When doing more testing with larger buffer sizes, found problems with the
previous patch revision (it was a quick port from a different audio decoder
and unfortunately bugs slipped in). So a new patch is attached, it should be
fine now. Also reformatted new code to be more consistent with the rest of 
the source file.

Though it wasn't a primary goal, patched libmad code is even a bit faster
as a side effect (older code excessively overused memmove function, shifting 
~4K of data in the buffer after decoding each mp3 frame).
-------------- next part --------------
A non-text attachment was scrubbed...
Name: libmad_av_sync_fix.try2.diff
Type: text/x-diff
Size: 4672 bytes
Desc: not available
URL: <http://lists.mplayerhq.hu/pipermail/mplayer-dev-eng/attachments/20080105/36a2fc73/attachment.diff>