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

[Zoltan Hidvegi]

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

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

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

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.

Zoli