[MPlayer-users] A-V-sync in mencoder
D Richard Felker III
dalias at aerifal.cx
Tue Mar 16 19:29:45 CET 2004
On Tue, Mar 16, 2004 at 01:15:55PM +0200, Ville Saari wrote:
> Mplayer adjusts the video speed to keep audio-sync, but mencoder
> has to resample the video to fixed output framerate and does it by
> skipping or duplicating frames. This causes ugly jumps in the video
> so I was wondering if it would be feasible to implement an option to
> resample the audio instead?
Agree, but this should rarely even be necessary. Most of the problem
is just bugs in mencoder.
> Sudden changes of the audio speed would of course be unacceptable,
> but if the acceleration or deceleration is kept low enough, then I
> believe it wouldn't be perceptible. Unlike the frame skips that are
> almost always clearly visible and have become kind of a trade mark
> of mencoder-generated files.
>
> This would have several advantages over the frame skipping/duplicating:
>
> - Video speed could be changed during the encoding. I could for example
> use -fps 25 -ofps 24 to slow PAL-movies down to their original film
> speed with no need to worry about audio sync.
No, this is total nonsense. It changes the meaning of the -fps and
-ofps options. Think of what would happen when encoding from NTSC
dvds!
On the other hand, with your proposal, -fps 24 would probably do what
you want.
> - Mplayer's -speed option could be made available for mencoder too.
> -speed 0.96 would then be equivalent to the previous example. As long
> as the used video codec accepts the resulting frame rate.
Yes, this should be added asap. Unfortunately the a/v sync code is so
hideous I couldn't figure out how to do it when I tried.
> - There would be no need to encode dummy audio on the first pass of a
> two pass encoding, because the audio would have no effect on video.
>
> - The number of frames in the mencoded file would match the original
> exactly so the frame numbers for -frames, vrc_override etc. would
> be unambiguous.
Not true! Telecine!!!!
> Mencoder also seems to be quite eager to rapidly skip several frames near
> the beginning on the encoding. This would suggest that the beginnings of
> the video and audio stream have different time stamps on most files.
> Is it so or is it a bug in mencoder?
It's a bug.
> If the input file is to blame, then it would be better to sync the
> beginning by prepending silence to the audio. If the audio starts earlier
> than video, then a question arises whether black frames should be prepended
> to the video instead of cutting the audio? However in most cases the
> beginning of the audio is quite silent anyway, so it could be safely cut.
> A command line option could then be used to force black frames if they are
> really needed. Perhaps -ss with negative offset.
Basically mencoder just sucks, but it vaguely works. IMO you should
always use -mc 0 -noskip, but this can easily break a/v sync if your
input file isn't perfect or if you want to do inverse telecine.
You can try overhauling mencoder if you think you can make it work.
Otherwise you'll have to wait for G2 I expect, since I doubt anyone
else wants to touch the mess in mencoder... :(
Rich
More information about the MPlayer-users
mailing list