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

[D Richard Felker III]

On Sun, May 09, 2004 at 11:14:40AM -0500, Zoltan Hidvegi wrote:
> > > So what I mean is that the default mc behavior is certainly not very
> > > useful, but we need something to fix the really bad sync that happens
> > > on such sudden pts jumps.  I do not like my workaround, that's why
> > > I've never posted a patch about it, but I do not know what else can be
> > > done.
> > 
> > Hmm, I'm not arguing that an error like this doesn't happen, but I'm
> > very skeptical of your explaination. With -mc 0, the broken pts should
> > not come into play, only the sample counts. That still might give
> > desync with such horrible files, though.
> 
> 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...

Anyway it's impossible for the current mc!=0 code to work, because it
measures pts the wrong way. The measurement includes buffering in the
audio encoder as well as the audio preload in the output avi, and
although there seems to be code intended to compensate for these
factors, it simply doesn't work. Also there's the matter of pts from
the demuxers being bad to begin with...

> > > Actually, I do not like that either.  A most annoying effect of this
> > > happens using mencoder -ovc copy on an mpeg4 file, where mencoder will
> > > blindly drop frames, which messes up any subsequent frames predicted
> > > from the dropped frame.
> > 
> > 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.

> > Not sure, but there's really no way filters can hope to handle a/v
> > sync in G1. The demuxer architecture is very broken and gives very
> > poor approximations of the actual pts.
> 
> It is usually good enough, otherwise you would see constant
> skip/duplicate frames.

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.

Rich