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

[Stephen Warren]

Reimar Döffinger wrote:
> 
> On Mon, Mar 23, 2009 at 08:45:28AM -0700, Stephen Warren wrote:
> > Dan Oscarsson wrote:
> > > On 2009-03-18 at 10:34 +0100 Reimar Döffinger wrote:
> > > > You can try attached patch. There are some issues though: I only
> > > > tested with the blit engine, which behaves a bit weirdly, it
> > > > should be possible to disable it, and it should be possible to
> > > > adjust the number of output surfaces used.
> > > > It might also be nicer to allow skipping in the draw_image part for
> > > > cases where the GPU usage is the issue, but that has higher jitter.
> > >
> > > I have now built on your patch by adding knowledge on the vsync
> > > interval and vsync time so that it can better align display and
> > > dropping to get best showing of frames.
> >
> > The best way to handle this would be to use the VDPAU presentation
> > queue's timestamp mechanism; choose a timestamp for each frame to
> > be presented, give this to the presentation queue, then use the
> > "displayed at" time returned by the presentation queue status
> > commands to determine whether presentation is drifting to become
> > late or not.
> 
> As I understood your last comment on this, this feature does still not
> allow play videos with higher fps than the vsync rate, thus frames still
> need to be dropped "manually" and to decided whether to do this or not
> we still better estimate if a vsync will happen "soon" or not.

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

-- 
nvpublic