[MPlayer-dev-eng] making -mc 0 the default in mencoder

[D Richard Felker III]

On Sun, May 09, 2004 at 12:46:38PM -0500, Zoltan Hidvegi wrote:
> > > If you do not correct for the pts jump, the audio will be completely
> > > out of sync.  I've uploaded a short sample to mplayerhq, called
> > > badav2.ts.  Play with -tsprog 2.
> > 
> > Yes, I agree. IMO the correct method would be to reset all the sync
> > information when there's a pts discontinuity and behave the same as at
> > the beginning of a file...
> 
> But for broadcast streams there is really no beginning, and the audio
> usually lags behind.  The pts is correct in the sense that if you
> match the audio and video pts, they will be in sync.  The pts does
> give the right sync info, the jump in the audio pts reflects a real
> jump.

You're welcome to write working code and submit a patch. But there are
various obstacles to getting pts-based sync right:

- You have to compensate for audio preload (stupid avi thing).
- You need to compensate for any buffering in the audio encoder.
- The pts behavior of the various demuxers isn't reliable. Some always
  give correct pts, others only occasionally have it correct and you
  have to guess/interpolate the rest of the time.

It's also possible that when B frames are used, the 1-frame delay in
video encoding messes up the output a/v sync. I haven't tested this
and don't really care since B frames are evil... But if so, it should
be fixed.

In our next-gen movie player/encoder, all sync will be pts-based, but
it will be done _correctly_, with perfect pts for each packet from the
demuxer/framer. Then you'll have the best of both worlds. But you'll
have to wait... :)

> > > > This should never happen on an mpeg4 avi file (or any avi file, except
> > > > one recorded from a tv card with bad capture software). If it does
> > > > you're free to use -noskip too.
> > > 
> > > It can happen if you use mencoder -ss to cut some mid part of an avi.
> > > Unless the audio is pcm, the audio cannot be cut exactly.
> > 
> > It's close enough. The error will be much less than one frame (about
> > 1/44 second at 44100 hz), and thus not noticable.
> 
> I do not know much about audio compression. but you can try this on an
> avi, it happens all the time.  If it were only 1/44 mencoder should
> not skip, but it does.  Maybe that is a bug in mencoder.  But avidemux
> also messes up the A/V sync when you edit video with non-pcm audio.

MP3 frames are 1152 samples long, compared to 44100 samples per
second. So if you seek to the nearest frame, it's about 1/44 second
per frame. And if you pick well whether to seek to the previous or
next, the maximum error is only 1/88 second.

With -mc 0, I've never seen a/v desync when using -ss with avi files.
And no frames are skipped or duplicated either. IMO the error is
entirely in the broken mc!=0 code.

And as for avidemux, it's rather broken too...

> > No, sync is often wrong by up to 300 ms (very noticeable) and this is
> > often reported on -users. Also, the skips/duplicates are plain WRONG.
> > There should never be a single skip or duplicate when encoding from a
> > DVD, except of course with inverse telecine.
> 
> Do you have a sample?  I.e. a sample where A/V sync is bad, but
> mencoder thinks it's good (i.e. AV_delay is close to 0)?  I never seen
> such bad behavior in ATSC broadcast, and I encode a lot of that.

Quite the opposite: examples where sync is perfect (-mc 0 gives no
skips/dups and perfect sync) but where the default mc results in
desync of up to 300 ms. For me it's not as bad (probably more like 100
ms) because I use a very old version of lame with less buffering (I
decided not to upgrade after hearing the 300 ms reports on -users with
new lame, since I didn't know about -mc 0 then). But I also notice
frequent skip/dup pairs in rapid succession, which are of course
unnecessary and hurt the video quality (make it jerky)!

If you want examples I can -dumpstream from a DVD. But it seems to
happen with almost any DVD...

Rich