[MPlayer-dev-eng] Re: [PATCH] VFCTRL_PERIODIC_UPDATE

[Uoti Urpala]

On Sun, 2007-01-21 at 15:12 -0500, Jason Tackaberry wrote:
> On Sun, 2007-01-21 at 20:49 +0200, Uoti Urpala wrote:
> > First, it's disabled completely if double buffering is enabled, and
> > double buffering should be enabled in normal use. 
> 
> This is labeled as a bug, and my intention was to deal with it
> afterward, since I expected to need some help from mplayer-dev.  With
> double buffering enabled, flipping between frame draws causes
> significant jitter (as you might imagine).

Here the extra jitter compared to -nodouble is probably caused not by
the extra frame draw but by the effect of the "real" flip with the
particular vo when called without drawing a new frame in between.

> But even if it's not fundamentally fixable, it seems to me to be an
> acceptable tradeoff between double buffering and fps-independent
> overlay, which is a decision the user can make (by choosing to pass
> -nodouble or not).

I don't think so. The brokenness is bigger the lower the FPS is. It
might be an "acceptable tradeoff" when it's not needed, but if it's
really needed because of low FPS then it breaks much worse.

> > Now if you disable double buffering then the vo might really overwrite
> > the old frame as soon as a new one is drawn or it might work mostly
> > the same as with double buffering (changing contents at flip() only).
> 
> With double buffering disabled, all the behavior I've seen indicates it
> does overwrite the old frame when the new one is drawn.

Depends on the vo. If you mean behavior with the whole patch then that
calls flip() too, so just checking whether the picture changes doesn't
show anything.

> >  Since only flip() is timed and decoding is always done immediately
> > after the previous frame has been flipped, in the first case timing of
> > low-fps video is broken completely (not only broken overlay).
> 
> To clarify, by "first case" do you mean the case when double buffering
> is disabled?  If so, this isn't what I'm seeing.  If I play a video with
> -fps 5, I can update the overlay roughly 30 times a second while the
> video plays evenly at 5 fps.

Most likely a/v sync is off by about 1/5 seconds (assuming decoding time
per frame is low allowing 30 fps updates for overlay) and evenness even
with constant-fps video depends on decoding time for every frame being
near constant. With varying frame duration the effect would be much
worse.
 
> > In the second case the following happens:
> 
> By "second case" are you referring to the case when double buffering is
> enabled?

No I'm talking about 2 possible cases of vo behavior with double
buffering disabled.

> > frame A should appear at time 1, frame B at time 2. overlay is updated
> > at time 1.1.
> > 
> > time=0.01 draw frame A
> > time=1.00 flip frame A
> > time=1.01 draw frame B
> > time=1.10 overlay update and vo flip is done based on frame B, which
> >           thus appears 0.9 seconds too early.
> 
> Does this imply that after the overlay update at t=1.10 frame C will be
> drawn, and that if I update the overlay at t=1.11 frame C will then be
> flipped?  And if so, wouldn't that mean updating the overlay at 30fps

No, it does not imply an effect on the timing of frame C.