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

[Jason Tackaberry]

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

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


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


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


> In the second case the following happens:

By "second case" are you referring to the case when double buffering is
enabled?

> 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
for a 5fps video would cause the video to be played back at 30fps?  I
ask because this isn't what I'm seeing, so I must misunderstand what you
mean.

Thanks,
Jason.