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

[Zoltan Hidvegi]

> > 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.

> > 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.

> > And during re-encoding, it also messes up the
> > inverse telecine filters.  It would be better to have an options that
> > completely disables any dropping/duplicating in mencoder.c and make
> > the timer correction visible for the filters, so that filters can
> > handle it.
> 
> You need to RTFM the latest version. Look for -vf softskip. :)

Cool, I should have done cvs update.

> > One would try to use -mc 0 -noskip for this, but when
> > -noskip is in effect, the filter cannot drop frames, since if a filter
> > returns 0, mencoder will duplicate the previous frame (mencoder.c line
> > 1296).  I would think this is a bug, but it was quite deliberately
> > coded that way, so maybe there is some reason for this.
> 
> 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.

Zoli