[VDPAU] VDPAU future direction; reducing _and_ expanding its scope?
Pierre-Loup Griffais
pgriffais at valvesoftware.com
Mon Apr 21 15:35:49 PDT 2014
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.
- 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?
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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/vdpau/attachments/20140421/6dcb9639/attachment.html>
More information about the VDPAU
mailing list