[MPlayer-dev-eng] [PATCH]: reduce vsync wait in VDPAU

[Stephen Warren]

Reimar Döffinger wrote:
> 
> On Wed, Feb 25, 2009 at 01:59:22PM +0100, Reimar Döffinger wrote:
> > On Wed, Feb 25, 2009 at 01:45:39PM +0100, Dan Oscarsson wrote:
> > > On 2009-02-25 at 13:05 +0100 Reimar Döffinger wrote:
> > > > According to my information, you are supposed to use the timestamps
> > > > feature of the flip queue to solve this issue. I have not yet
> > > > investigated that though, so I do not know if it is actually
> > > > appropriate for MPlayer.
> > >
> > > It can probably be used in the sync-to-vsync handling i mplayer, but
> > > will not solve this issue.
> >
> > As I understood it, it will automatically drop a frame if there is no
> > vsync between the requested display time of that and the next frame, so
> > it should solve the issue, but in a way that would allow VDPAU to have
> > full control and e.g. use strategies to minimize jitter (which are
> > easier to implement at driver level).
> 
> Tests reveal that you are right though. What concerns me is that in my
> own attempt, vdp_presentation_queue_query_surface_status would not work
> at all, surfaces would remain in queued state forever.
> Maybe someone else can find out why with attached patch.

I just tested vdp_presentation_queue_query_surface_status, and it seems to
work OK. I did see one problem with your patch; it was querying the surface
status for next_surface, which isn't the surface being rendered to. With
the original patch code, the status is always VISIBLE for me, which isn't
surprising, since the surface not being rendered too is expected to be
VISIBLE. If I fix the patch to query status for the surface being rendered
to (surface_num), then the status is always IDLE, which again makes sense,
since video_to_output_surface always blocks until the surface is IDLE.

I validated this with both the overlay-based and blit-based presentation
queue implementations.

Hope this helps...

-- 
nvpublic