[MPlayer-users] A-V-sync in mencoder

[Aaron Peterson]

> 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

wow, that's discouraging. bummer :)