[MPlayer-dev-eng] [PATCH] Fix av sync calculations during lagging video

[Uoti Urpala]

On Thu, 2006-04-06 at 14:50 +0200, Reimar Döffinger wrote:
> Okay, right, there really is no permanent desync in either case AFAICT.
> Can you explain what exactly my version of the patch would break? I

It would incorrectly try to adjust video timing during lagging video
with autosync (it would cause for autosync the problem it fixes for
non-autosync, just in the other adjustment direction).

> And one last thing, both patches causes A-V desync caused by a too slow
> computer not to be included in the ct value. This probably is correct
> behaviour, but I think some people might not like it. Any comments on
> that?

The ct value should not change; I think it _would_ change with your
version of the patch and autosync. The "ct" value is supposed to show
how much the av sync code has adjusted the "natural" rate of the video
(in units of seconds total time changed) to get video pts to match audio
pts. If video frames cannot be shown quickly enough that is no reason
for the av sync code to change the time when mplayer _tries_ to show
them, and so the "ct" value should not change.

As for "people who might not like it", the current ct value changes
shown during lagging video do not contain any meaningful information IMO
(besides showing how badly the current av sync code is broken). Knowing
how far behind the current target time the latest video frame was shown
(indicating performance problems) might be useful information when
investigating av sync issues, but I'm not sure whether there's room for
it on the status line.