Opened 12 years ago
Last modified 12 years ago
#2053 new defect
Audio sync bug caused by recent FFmpeg revision
Reported by: | Owned by: | reimar | |
---|---|---|---|
Priority: | normal | Component: | core |
Version: | HEAD | Severity: | normal |
Keywords: | Cc: | ||
Blocked By: | Blocking: | ||
Reproduced by developer: | no | Analyzed by developer: | no |
Description
Recently (on February 21st) there were some FFmpeg revisions made that use duration instead of frame_size.
This is causing audio sync problems with MEncoder.
To reproduce the bug, see this sample: http://www.filefactory.com/file/c463f90/n/sample-skipping_mkv
I used the following cmd:
mencoder sample-skipping.mkv -oac copy -of mpeg -mpegopts format=mpeg2:muxrate=500000:vbuf_size=1194:abuf_size=64 -ovc lavc -channels 6 -lavdopts debug=0:threads=2 -lavcopts autoaspect=1:vcodec=mpeg2video:acodec=ac3:abitrate=448:threads=4:keyint=5:vqscale=1:vqmin=2:vqmax=3 -aid 0 -ofps 24000/1001 -lavdopts fast -af lavcresample=48000 -srate 48000 -o out.mpg
The audio sync loss is most apparent when he opens the door, it has fallen far behind.
You can also see it in the cmd output which reports lots of "Skipping frame!" messages.
Since the audio we're using in this file is AC3, it is fixed by reverting FFmpeg 16e54ac7255d47e70ba9ba60d5ce5d0a0e44b223 (http://git.videolan.org/?p=ffmpeg.git;a=commit;h=16e54ac7255d47e70ba9ba60d5ce5d0a0e44b223), in other words by telling FFmpeg to report frame_size again instead of duration.
I have confirmed that reverting that FFmpeg revision fixes the audio sync on this sample.
Change History (2)
comment:1 by , 12 years ago
comment:2 by , 12 years ago
It's still happening with MPlayer r34913 and FFmpeg r40793 (ae1ab8265bad5481b5842ee3aff4872d1fe4d34d).
It seems that this is a change in FFmpeg that MPlayer needs to be adapted to support, not a bug in FFmpeg.
The download link for the file expired so I uploaded it to my server:
http://www.spirton.com/uploads/MPlayer/MPlayer-2053.mkv