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

[Compn]

On Sat, 5 Jan 2008 03:10:45 +0200, Siarhei Siamashka wrote:

>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).


i'll test out libmad if i can get it to build...

uoti, does this patch look correct?

-compn