[MPlayer-dev-eng] Reverted patch of time-based PTS locking

[Reimar Döffinger]

On Tue, Aug 14, 2012 at 10:23:30AM +0200, Pásztor Szilárd wrote:
> Reimar Döffinger:
> > Did you try with -mc 100? Actually the sample I tried
> > (http://samples.mplayerhq.hu/V-codecs/h264/PAFF/Sat1PAFF.ts) seems
> > to work fine even without most of the time (though I admit it is a
> > bit hard to tell).
> 
> It is indifferent from the -mc parameter. This is not an issue of speed of
> catching A-V sync. Also, with -demuxer lavf this code is not in effect by
> default at H.264 streams as the PTS reordering code (-correct-pts) is enabled
> then. Without -demuxer-lavf, however, it is.
> 
> Here is what the code does:
> 1. wait for two subsequent frames at a PTS difference of "frametime" value,
> that is, a sequence of 2 frames in correct order
> 2. then start replacing video PTS by increments of "frametime"
> 3. constantly check for drifts: if the recalculated PTS is closer to the
> incoming PTS than frametime/10, use original PTS. This eliminates rounding
> errors. If recalculated PTS is farther away from incoming PTS than
> frametime*20, give up and stop replacing PTS until step 1 happens again
> 
> As this shows, this code should not have any effect on A-V sync, it merely
> corrects disordered video PTS with being on the safe side as much as possible.

First: I (partially) misread the code.
However seeing it summarized gives a likely explanation for the issues
with some NTSC DVDs: They were probably "upconverted" to 30 fps, so
you would end up with for example 3 normal frames, then a duplicated
one.
The duplicated one would be (depending on container) encoded as skip
frame or not encoded at all, resulting in a double frame time for one
of the frames.
So your could would "correct" that frame time to only be the normal
frame time, thus causing slowly increasing desync (with video playing
too slow) until it reaches the 20*frametime (around 0.6s).
Then it would let MPlayer slowly correct it back, just to re-enable
itself again and do the same thing over.

> Meanwhile, an error has been introduced that kind of wrecks lavc signing a
> first field correctly in libmpcodecs/vd_ffmpeg.c:
> 
>     if(!got_picture) {
>         if (avctx->codec->id == CODEC_ID_H264 &&
>             skip_frame > AVDISCARD_DEFAULT)
>             return &mpi_no_picture; // H.264 first field only
>         else
>             return NULL;    // skipped image
>     }

Well, that probably explains your issues. You are using an outdated
MPlayer version, that bug has been fixed (and did cause massive
sync issues with PAFF).