[MEncoder-users] a/v desync with mencoder that doesn't happen with mplayer -dumpstream

[Brion Swanson]

On 11/7/11 10:23 PM, "Brion Swanson" <deadbeefb5 at gmail.com> wrote:
>> On 11/05/2011 08:14 PM, The Wanderer wrote:
>>> On 11/05/2011 01:37 PM, Brion Swanson wrote:
>>>
>>>> On 11/04/2011 09:33 AM, The Wanderer wrote:
>>>>> Is the size of the desync consistent within any given rip, or does
>>>>> it vary
>>>>> over time as you let the movie play?
>>>> It appears consistent but since it's so far off it's hard to tell for
>>>> sure if
>>>> it's getting farther apart or not.
>>> Yeah, that would be a bit tricky.
>>>
>>> Does the MPlayer status line report the difference (in the 'A-V:'
>>> value), or
>>> does that claim to be in sync? If it does show the difference there,
>>> then you
>>> could use that to judge whether the desync is varying or not.
>>>
>>>>> Do you get the same desync with e.g. ffplay?
>>>> I'm not sure how to use ffplay to play the DVD directly, but if I
>>>> play the
>>>> stream.dump file there is no desync (though there is no desync in
>>>> mplayer
>>>> with that file either).
>>> I meant, do you get the desync when you play the transcoded file using
>>> ffplay?
>>>
>>> You've answered this in another response. That rules out one
>>> possibility, or at
>>> least makes it less likely; I've seen at least one case where MPlayer
>>> got the
>>> frame rate wrong on a particular VFR file (which had apparently been
>>> created
>>> using MEncoder), but ffplay could handle it just fine.
>>>
>>> (I really should get around to putting together a formal report about
>>> that.)
>>>
>>> Unfortunately, off the top of my head I don't have anything else to
>>> suggest,
>>> aside from perhaps posting a full console log of at least a playback
>>> session and
>>> possibly even the actual encoding process. There's no guarantee anyone
>>> would be
>>> able to help based on that, but it could hardly hurt... though the
>>> encoding log
>>> would probably be excessively large.
>>>
>> Poking around some more on this I found out a few interesting facts:
>>
>> 1. specifying -ofps 24000/1001 caused the audio to out of sync behind
>> the video instead of in front of it
>> 2. specifying -ofps 30000/1001 caused the audio to be very much behind
>> the video
>> 3. Benchmarking the video without audio (-nosound) did not result in
>> errors although allowing the video gave a VC% of about 52% while -vo
>> null gave a VC% of about 92% -- I don't know if that's usual or expected
>> 4. Playing the video does not produce any significant errors (just a
>> couple changes from soft telecine (24000/1) to hard telecine
>> (30000/1001) and back
>> 5. I tried doing a normal transcoding (instead of -oac copy and -ovc
>> copy) and the audio delay was still there (though the video quality was
>> considerably lower) and with the same amount of delay
>> 6. There was nothing special in the encoding log that I haven't already
>> mentioned even when I let it complete.
>>
>> Any other ideas you guys might have is appreciated.  This is truly
>> baffling to me.
>>
I believe I found a solution to my problem.  I don't fully understand 
what's different about this DVD from others I've ripped and it's the 
first time I've had to play with these settings in this manner, but I 
found that if I introduced "-mc 0" and "-audio-delay -0.5" I could get 
the audio almost in perfect sync with the video.  I think it may still 
be off very slightly, but changing the -audio-delay value to -1 or 0 
makes it worse than -0.5.

When I'm in mplayer I can use + and - to increase and decrease the audio 
delay which seems to slap it back into better synchronization (at about 
-400ms) but providing that same decimal value to -audio-delay doesn't 
seem to have the same effect.

In any case.  Hopefully this trick will work with Thor and The Green 
Lantern as well (and any other movies that come out in the future such 
as The Avengers I imagine).

I appreciate the help and suggestions!  It got me trying different 
things at least. :)

Brion

P.S. If anyone can explain exactly what this combination of arguments is 
doing I'd appreciate it.  From what I understand from the man pages -mc 
0 tells mencoder to disallow any A/V sync correction more than 0 
seconds.  the -audio-delay with a negative value delays the video for 
0.5 seconds.  I did not use -noskip because that caused much larger 
delays and problems.