[MPlayer-users] structure protection
ilab
ilab at freemail.hu
Mon Nov 7 22:59:10 CET 2005
Guillaume POIRIER wrote:
> You may wanna try to dump the audio track with -ao pcm and
> re-introduce it with -audiofile, or try to see if encoding the sound
> to mp3 on the fly can work around the "variable channel" problem.
Thanx, I will try, this idea is definitely worth a try.
>>And the most important thing: If mplayer CAN play a vob witout A/V
>>desync then mencoder SHOULD BE ABLE TO encode the same vob without
>>A/V desync. There is nothing mystic in this. I think something
>>is missed out from mencoder which mplayer already knows.
>
> Wrong. There are countless other things that work just fine with
> mplayer and are problematic with mencoder. Take for example the
> encoding of NTSC or variable framerate contents which require great
> deal of attention (which you may call workarounds) to be encoded
> correctly.
Hmm... I get it, you are right.
>>So I dont suggest to put this method in the documentation, I would
>>not even say that it is a workaround.
>
> Well, if you find a better solution, please share it with me. I still
> have a long way to go to get to the point where I can say I master
> mencoder, so...
Nah... the fact that I dont have a solution doesnt mean that I should
say 'cool' for anything someone else says.
BTW: someone mentioned a workaround with muxing the audio with delay.
That seems to work, though I experience something that is strange
for me: I ripped the audio with dvd2avi (wine) and muxed with
virtualdubmod (wine) because I needed to adjust positive audio delay
(it is negative delay for mencoder for some strange reason) which
mencoder doesnt allow.
When I play the result with mplayer, I see A/V desync in the output
which is equal with the delay I set, and this desync changes more and
more smaller and finally disappears after about a minute (it starts
4500 msec).
Is this the way mplayer decompensates the desync with? Woulndt it
be more logical if this kind of delay would be done in a hard jump?
I mean this delay is valid for the _whole_ audio track, so it would
be reasonable if mplayer simply started the audio playing later
instead of the smooth compensation.
Thanx,
ilab
More information about the MPlayer-users
mailing list