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

[Reimar Döffinger]

On Wed, Aug 15, 2012 at 12:24:25AM +0200, Pásztor Szilárd wrote:
> Reimar Döffinger:
> >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.
> 
> Yes it is possible that this code starts working in situations when
> it shouldn't.
> An easy additional check could prevent this bug though.

Hm, I couldn't really think of a solution that is 100% sure to work
in any case imaginable.
Though something a bit less like that might be ok, but I'm not convinced
it's going to be easy still.

> >Hm, can you see anything in actual playback?
> >Because I'd consider that mostly a cosmetic issue...
> 
> There is a big difference. As the video PTS is constantly jerking
> around
> without the fix, the A-V sync code jerks around too to catch up.
> I'm watching HD broadcasts with my monitor refresh rate set to 50/60,
> depending on PAL or NTSC source, and with letting PTS to jerk around,
> PAFF HD videos are frankly unwatchable, and even more so with -mc 1.

I admit I'm not able to see the difference.
Though I don't understand why it should get _worse_ with -mc 1,
with -mc 100 yes, but with -mc 1 it should ignore those A-V sync
jumps.