[MPlayer-dev-eng] [PATCH] Fix for libmad audio/video sync problems (on variable bitrate audio)
tempn at twmi.rr.com
Sun Jan 6 03:17:46 CET 2008
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:
>> >Unfortunately, you could not confirm the audio/video sync problem
>> >with the sample I submitted earlier:
>> 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
>Anyway, please try the following:
>$ 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
i'll test out libmad if i can get it to build...
uoti, does this patch look correct?
More information about the MPlayer-dev-eng