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

[Aaron Plattner]

Hi Pierre-Loup,

On 04/21/2014 03:35 PM, Pierre-Loup Griffais wrote:
> 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, and on some hardware implementing it might not provide any
> significant value over handing off the decoded buffer to OpenGL for
> presentation, which is the model that VA-API happens to adopt. 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? 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.

One of the advantages that VDPAU has over VA-API is that there are fewer 
stages in the pipeline that an implementation can just fail to 
implement, which means fewer fallbacks that applications have to 
implement (and test).  I'd like to keep it that way if possible.  I.e., 
rather than failing to support presentation, maybe libvdpau could just 
fall back to the reference OpenGL presentation layer if the driver 
back-end indicates that it doesn't support native presentation?  Maybe 
combine that with a query that lets applications know if that's 
happening in case they really do want to implement their own fallbacks?

>   - Encoding: VA-API and OpenMAX both have encoding infrastructures;
> would there be any value in leveraging some of the existing VDPAU
> mechanisms in order to expose hardware encoding capabilities, in order
> to minimize the implementation work needed? Just as VDPAU allows
> presentation compared to more traditional bitstream decodes API, its
> encoding sister API could potentially specify means of achieving
> screen-scraping, like NvFBC. VDEPCAU anyone?

We originally punted on encode support in order to get something working 
shipped.  I don't have a preference as to whether it becomes part of 
VDPAU or exists as its own separate project.

> I'm interested in hearing high-level opinions from various stakeholders
> to convince myself whether this is worth spending any effort on. It's
> possible the consensus is that the current situation is fine, but to me
> it seems we're still in a little bit of a wild west. VA-API, OpenMAX,
> nvcuvenc, nvcuvid, NvFBC, XvBA, XvMC, Xv are quite unfortunately still
> all paths viable to target as a SW vendor depending on what your usecase
> / HW combination is. It does seem like the full scope of all of the
> above could be captured by a "VDEPCAU" without necessarily becoming too
> bloated.
>
> Curious what your thoughts are; thanks for your time.
>   - Pierre-Loup