[VDPAU] VDPAU future direction; reducing _and_ expanding its scope?

[Rémi Denis-Courmont]

    Hello,

Le 2014-04-22 01:35, Pierre-Loup Griffais a écrit :
> VDPAU has gained plenty of driver and application support in the past
> years and it seems to be on good track to become the de-facto
> standard. Talking with some people, IHVs and ISVs altogether, that do
> not yet support VDPAU but are considering it, two main concerns
> emerge:
>
>  - Presentation: implementing (or targeting) a VDPAU presentation
> queue is tricky,

What do you mean by that?

> and on some hardware implementing it might not
> provide any significant value over handing off the decoded buffer to
> OpenGL for presentation,

You can hand the VDPAU surfaces to OpenGL.with GL_NV_vdpau_interop:
ftp://download.nvidia.com/XFree86/vdpau/GL_NV_vdpau_interop.txt
(putting NVIDIA link as Khronos site seems dead at the moment)

> which is the model that VA-API happens to adopt.

VA-API renders surfaces to an X11 drawable with vaPutSurface(), similar 
to plain old XVideo. That works very much the same way as 
VdpPresentationQueueDisplay(), possibly with 
VdpOutputSurfaceRenderOutputSurface(), though VA lacks timestamps.

> Could VdpPresentationQueue (or a higher-level object) be
> extended to expose capabilities just like the decoder does today, and
> let the implementation convey to the client that it does not support
> presentation?

You mean VDPAU without X11, similar to VA-DRM? In my personal opinion, 
introducing a new vdp_device_create_foo() in <vdpau_foo.h> without a 
corresponding VdpPresentationQueueTargetCreateFOO() would make more 
sense that adding a new capability.

Besides, existing software would not know to check the new capability, 
and fail. Adding a new function would maintain backward compatibility.

> That, along with a reference presentation implementation
> based on OpenGL that applications can use as-is as a fallback, seems
> like it could greatly reduce friction for potential implementers.

-- 
Rémi Denis-Courmont