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

[Christian König]

Hi Aaron & Pierre-Loup,

Am 22.04.2014 01:46, schrieb 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?

Agree completely on this. VDPAU is a very well designed interface for 
both the application as well as the driver side to work with.

I currently don't see much need for defining a presentation queue helper 
library that implements the VDPAU functionality on top of OpenGL.

On the other hand a proper define of VDPAU presentation queue over EGL 
would be indeed quite useful.

Christian.

>
>>   - 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
>
> _______________________________________________
> VDPAU mailing list
> VDPAU at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/vdpau