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

[D Richard Felker III]

On Sun, May 09, 2004 at 05:32:39AM -0500, Zoltan Hidvegi wrote:
> > Hey guys, I propose we make -mc 0 the default in mencoder. I've
> > already recommended using it in my in-progress encoding guide, but IMO
> > lots of users are too lame to RTFM so they won't know to use it.
> 
> I agree, in most cases mc=0 is the best.  But there is a problem with
> US ATSC broadcast streams.  Somehow, the audio is usually about half a
> second behind the video, so when you start to play an HDTV stream, the
> A/V sync is initially broken until the mc correction synces up the
> audio and video.  But there is even worse, the main program and each
> ad are individual mpeg files which are cut together into a single
> stream.  It is quite common that the audio pts jumps forward by as
> much as 2 seconds at the cutpoints while the video pts just increases
> at the normal rate, which completely messes up A/V sync.  The audio
> pts jump is really a way to encode silence, but mplayer does not
> handle it.  As a workaround, I've patched mencoder so that if the A/V
> sync is off by more than a threshold, say 0.2s, then it will drop or
> insert as many frames as necessary at once to bring the A/V sync back
> to normal, instead of the normal gradual adjusting.  As a result, when
> the audio pts jumps ahead, it will drop a portion of the video to
> bring it in sync.  Since this happens at cutpoints, it hardly ever
> loses anything important.
> 
> 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.

> > With mc==0, mencoder will still correct a/v sync in the output with
> > frame skips and duplicates, but only based on the sample counts
> > (frames for video, samples for audio)! It won't try to compensate for
> 
> 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.

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

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

Rich