[MPlayer-dev-eng] [PATCH] reduce flashing on resize with VDPAU

[Dan Oscarsson]

On 2009-03-23 at 10:26 -0700 Stephen Warren wrote:
> OK. I guess for certain frame-rate-conversion cases, it makes sense to
> make decisions based on actual VSYNC rate. I.e video v.s. display VSYNC
> rate should be used to make a decision regarding the cadence of which
> frames to drop in display.
> 
> However, given that, I still think the presentation queue timestamp
> mechanism should be used to ensure that they actually get presented at
> the intended time, since this may be a HW operation and subject to less
> jitter than SW timing. Also the PQ status feedback should be used to
> determine if display was actually late (due to PQ display call being too
> late to meet the timestamp, e.g. GPU overloaded, or MPlayer scheduled
> out for a very long time delaying stream parsing, bad stream timestamps,
> etc.)

I did think about using the timestamps and have in my code (not the
patches just posted) code that correlate timestamp time with system
time. But did not find a good way to use them without change a lot more
in mplayer outside the libvo.
Also I have found out that the vdpau time moves at a slightly different
speed then system time making timings get slowly out of sync. My code
that I use to align the speed of the movie with the speed of the vsyncs
will slowly get out of sync due to this time difference.

But you will find that in the patch I just posted, I use the timestamps
to find when surfaces have been displayed.

> 
> > > > I can also identify when the blitting engine is used so that it
> > > > can be handled differently from the other one.
> > >
> > > That's odd; the two mechanisms are designed to have the same
> > > semantics and be indistinguishable. If that's not the case, it's a
> > > bug we'd like to fix. Why do you feel the need to distinguish the
> > > two mechanisms, and how are you doing so?
> > 
> > Because the blit engine is not limited to the screen refresh (vsync)
> > rate, thus there is no (/not much) need to do frame dropping etc.
> > Assuming this hasn't changed, I have not tested the beta drivers, only
> > 180.37...
> 
> Ah yes. That is definitely a bug in the blit-based PQ. It will hopefully
> be fixed in the fairly near future, so this isn't something you should
> rely upon. That said, if you're simply detecting the behavior of whether
> the PQ syncs-to-VSYNC or not, and adjusting MPlayer's actions based on
> that, then eventually with some new driver release, that behavior will
> simply never happen, and MPlayer should always fall into the other path,
> which I guess will work OK.

Yes, and as you can see in my patch just posted, I queue up a few
surfaces and wait for them to be displayed to find the time between two
vsyncs (missing a simple call for that in vdpau).
When blitting is done the time between two surfaces is very small and
the length varies quite a lot. That is how I detect the blitting. When
it syncs to vsync, I will no loger detect it and do not need to as it
then works with my vsync handling code.

   Dan