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

[Pierre-Loup A. Griffais]

On 04/22/2014 04:45 AM, Christian König wrote:
> 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.

It would make it easier for HW vendors to expose their decoding 
capabilities through VDPAU without having to worry about interfacing 
with platform-specific windowing systems. Without going as far as 
changing the standard, just having a reference implementation of the 
presentation layer available for reference somewhere would be nice.

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

It seems like a VdpEncoder object could interface with the existing GL 
interop extension without needing to modify its specification, in order 
to capture frames from a game or compositor drawable. Some of the spec 
language mentions 'decoding' and 'output' but the extension was meant to 
be bi-directional to begin with, so this is promising. Does the general 
idea of specifying a VdpEncoder extension and providing an initial 
sample implementation based on an existing encode API sound crazy to anyone?

Thanks,
  - Pierre-Loup

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