[MPlayer-users] yum4mpeg audio sync broken

[Fredrik Hubinette]

Thank you, but I'm not a complete idiot.

I have also created many videos without any lag.
However, I have this one troublesome AVI file where the sound lags
a constant two seconds after the picture from beginning to end. The
frame right *is* correct, the audio just starts earlier than the video.

When playing this AVI with mplayer, it works just fine. I also beleive
that encoding it with mencoder would work, but when using the yuv4mpeg
output, the audio offset never gets compensated for, and the lag show up.

In this particular case, I could probably use the audio offset parameter
to mplex to fix the problem, but there are some rare AVIs out there that
has irregular frame rates, and there is no way to fix those without dropping
or duplicating frames, which is exactly what I would like mplayer to do.

Anyways, I'm not going to argue about this anymore, I have an ugly workaround
in my program, so if anybody else is having this problem, I suggest that
they use my mkdvd.pike script instead of waiting for it to get fixed in
mlayer.

        /Hubbe

Juergen Hammelmann <juergen.hammelmann at gmx.de> writes:

> [Automatic answer: RTFM (read DOCS, FAQ), also read DOCS/bugreports.html]
> 
> I have created several video with no lag between syncronisation of audio and 
> video. Another problem is, if you convert ntsc videos you have 24 frames/sec
> instead of 25 frames/sec at pal videos. To recognice this, you have to give 
> some more parameters... If not set correctly, the gap is increasing...
> 
> Am Freitag, 2. Januar 2004 23:11 schrieb Fredrik Hubinette:
> > [Automatic answer: RTFM (read DOCS, FAQ), also read DOCS/bugreports.html]
> >
> > No, that's not the answer. Because in my particular case, I have a
> > movie where the sound is offsetted by ~2 seconds from the video.
> >
> > If I play the video to the screen, mplayer quickly adjust the video
> > to sync up with the audio, but when I use yuv4mpeg audio and the
> > -framedrop flag, the code below actually *prevents* mplayer from
> > syncing the audio to the video.
> >
> > I've read mencvcd, and I'm reasonably certain that mencvcd would
> > create a video with a 2 second lag between the audio and video,
> > just like my script does. (Unless you use --sync 2.0 or some other
> > manual fix.)
> >
> >         /Hubbe
> >
> > "Jürgen Hammelmann" <Juergen.Hammelmann at gmx.de> writes:
> > > [Automatic answer: RTFM (read DOCS, FAQ), also read DOCS/bugreports.html]
> > > Hi,
> > >
> > > for encoding with yuv4mpeg you have to disable frame dropping in
> > > mplayer!!! Look at my TOOLS/mencvcd script how to do it.
> > >
> > > Ciao, Jürgen Hammelmann
> > >
> > > > [Automatic answer: RTFM (read DOCS, FAQ), also read
> > > > DOCS/bugreports.html]
> > > >
> > > > I'm writing a script that uses mplayer as a first step in converting
> > > > movies of various formats to DVDs. However, I'm having various problems
> > > > with the audio sync, and while reading mplayer.c I came across this
> > > > code:
> > > >
> > > >
> > > >          } else {
> > > >              /*
> > > >              Well, no blitting is needed, but some devices (such as
> > > > yuv4mpeg) m\
> > > > ust output frame
> > > >              otherwise A/V desync will occur. -- Alvieboy
> > > >              */
> > > >             if (vo_config_count)
> > > >                 video_out->control(VOCTRL_DUPLICATE_FRAME, NULL);
> > > >          }
> > > >
> > > >
> > > > As far as I can tell, this code is wrong. Frame dropping is done
> > > > specifically
> > > > to *preserve* A/V sync, and the code above prevents that from working.
> > > > I also noticed that there doesn't seem to be any code that can generate
> > > > extra frames if the audio should fall behind the video.  The code for
> > > > this seems to exist in mencoder, but unfortunately mencoder cannot
> > > > output yuv4mpeg...
> > > >
> > > > In my script I currently have a workaround that reads the "ct:" part of
> > > > the mplayer output and drops frames if ct becomes too large, but it's
> > > > a really really really ugly workaround.
> > > >
> > > >   /Hubbe
> >
> > _______________________________________________
> > RTFM!!!  http://www.MPlayerHQ.hu/DOCS
> > Search:  http://www.MPlayerHQ.hu/cgi-bin/htsearch
> > http://mplayerhq.hu/mailman/listinfo/mplayer-users
> 
> -- 
> When the weight of the paperwork equals the weight of the plane, the
> plane will fly.
> 		-- Donald Douglas
> 
> system: 10:35am  an 4 Tage 16:46,  4 Benutzer,  Durchschnittslast: 0,02, 0,04, 
> 0,00
> --
> email:        juergen.hammelmann at gmx.de            | Dipl.-Inf. J. Hammelmann,
> mobile:       +49-7034-259041, +49-179-2178869     | Herrenberger Str. 42/5,
> home:         +49-7034-61578, fax: +49-7034-652189 | D-71157 Hildrizhausen,
> email mobile: 01792178869 at o2online.de              | Germany
> www:          http://hammelmann.gmxhome.de         | 
> 
> _______________________________________________
> RTFM!!!  http://www.MPlayerHQ.hu/DOCS
> Search:  http://www.MPlayerHQ.hu/cgi-bin/htsearch
> http://mplayerhq.hu/mailman/listinfo/mplayer-users