[gst-devel] VA-API support

[Gwenole Beauchesne]

Hi,

On Tue, 11 May 2010, Edward Hervey wrote:

>>    * Fully Open Source solution
>>    * VA-API support from 0.29 to 0.31
>>    * OpenGL rendering through VA/GLX or GLX texture-from-pixmap + FBO
>
>  I wonder how we could integrate this with the existing GL plugins and
> the ongoing cairo work Benjamin has been doing. Carl-Anton has started
> doing cairo support for the VDPAU plugins, maybe you can check out his
> work or you guys can exchange tips.

The libs provide helpers for easy integration into an OpenGL environment. 
If you have an OpenGL texture & target around, you just create a 
GstVaapiTexture from it and transfer VA surfaces to it when you get one. 
The real data being transported will remain a VA surface though.

For Cairo, I currently have no idea. At some point, I would want cairo-gl 
to directly handle VA surfaces too. e.g. for a fully accelerated Flash 
implementation (with Gnash).

>>    * libgstreamer0.10-dev >= 0.10.0
>>    * libgstreamer-plugins-base0.10-dev >= 0.10.0
>
>  Hmm... You might want to make it require more recent versions, those
> are almost 5 years old and a lot has changed since. A core/base from a
> year ago should do it, while not forcing people to use just-released
> versions.

I have not properly checked, but the very minimal would indeed be 0.10.25. 
It's just that I was lazy and did not want to try earlier version.

>>    * libva-dev >= 0.31.0-1+sds9 (VA/GLX)
>
>  Is that version needed even if you have a intel GPU ? Or is it only if
> you want to use the other backends ? You mention above it has VA-API
> support from 0.29 to 0.31.

Yes, you can use any libVA. The wording is incomplete. If you want the 
VA/GLX extensions, you need the -sds packages. Otherwise, it will work 
with the various upstream libVA version too. Note however that I will only 
build xvba-video against the libVA we use. For vdpau-video, you can build 
it against the current libVA 0.31 (upstream) and it works as well.

VA/GLX is being worked on on the Intel side too, so this will be 
integrated in a way or another. Definitively, modern drivers don't (and 
won't) use GLX texture-from-pixmap to render to an OpenGL texture. So, if 
you want OpenGL support, it's better to use the VA/GLX extensions anyway.

>  * Do you have a code repository ? It would be nice for other
> developers to follow/contribute if you had a git repository somewhere
> (maybe even on github/gitorious).

Well, for now, I am more concerned about getting it to work through 
decodebin2 or playbin2. So, there currently is not much to see since I 
currently don't see much myself to fix this problem yet. :-/

>  * Would be nice to share code between the vdpau and the vaapi plugins
> (like the bitstream parsing parts that both (and other HW-accelerated
> plugins) require). This might be made easier if we integrated your
> plugins in -bad, and you'd get the bonus side-effect of having the rest
> of the GStreamer community maintaining/improving your code as well :)

Actually, the way I developed the GstVaapi* helper libs could be made a 
plain GstVa with interfaces to implement either VA-API or VDPAU. ;-) i.e. 
there are hardly VA bits directly exposed in this GstVaapi API. If there 
are, they should be made private.

Anyway, I don't mind if this is integrated into -bad, thus the indirection 
through a github repo becomes useless and things indeed get simpler. ;-)

>  * Your plugins are LGPL... but they depend on a library (in gst-libs/)
> which is GPL, making the plugins GPL. Any reason for that ?

If this is the case, then it's a bug. I have just checked again, the 
gst-libs/ library is LGPL and the plugins are GPL. What makes you think 
the plugins were LGPL and libs GPL? I probably mixed up some doc then.

Regards,
Gwenole.