<html dir="ltr">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1">
<style id="owaParaStyle" type="text/css">P {margin-top:0;margin-bottom:0;}</style>
</head>
<body ocsi="0" fpstyle="1">
<div style="direction: ltr;font-family: Tahoma;color: #000000;font-size: 10pt;">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:<br>
<br>
- 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.<br>
<br>
- 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?<br>
<br>
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.<br>
<br>
Curious what your thoughts are; thanks for your time.<br>
- Pierre-Loup<br>
</div>
</body>
</html>