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

[Zoltan Hidvegi]

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

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

Zoli