VA-API support
Locked
 
|
Hi,
I have uploaded some experimental plugins with VA-API support: <http://www.splitted-desktop.com/~gbeauchesne/gstreamer-vaapi/> gstreamer-vaapi consists in a collection of VA-API based plugins for GStreamer and helper libraries. * `vaapidecode' is used to decode MPEG-2, MPEG-4, H.264, VC-1, WMV3 videos to video/x-vaapi-surfaces surfaces, depending on the underlying HW capabilities. * `vaapiconvert' is used to convert from video/x-raw-yuv pixels to video/x-vaapi-surface surfaces. * `vaapisink' is used to display video/x-vaapi-surface surfaces to screen. Features -------- * Fully Open Source solution * VA-API support from 0.29 to 0.31 * OpenGL rendering through VA/GLX or GLX texture-from-pixmap + FBO * Support for major HW video decoding solutions on Linux (AMD, Intel, NVIDIA) Requirements ------------ Software requirements * libgstreamer0.10-dev >= 0.10.0 * libgstreamer-plugins-base0.10-dev >= 0.10.0 * libva-dev >= 0.31.0-1+sds9 (VA/GLX) * libavcodec-dev >= 0.6 or with <libavcodec/vaapi.h> Hardware requirements * AMD platforms with UVD2 (XvBA supported) * Intel Eaglelake (G45) * Intel Ironlake (HD Graphics) * Intel Poulsbo (US15W) * NVIDIA platforms with PureVideo (VDPAU supported) Caveats ------- * No integration within decodebin2 or the playbin2 pipeline * No ad-hoc parser, vaapidecoder currently relies on FFmpeg * MPEG-4 Part-2 (DivX) has decoding bugs Regards, Gwenole. ------------------------------------------------------------------------------ _______________________________________________ gstreamer-devel mailing list [hidden email] https://lists.sourceforge.net/lists/listinfo/gstreamer-devel |
|
Administrator
|
On Mon, 2010-05-10 at 15:06 +0200, Gwenole Beauchesne wrote:
> Hi, > > I have uploaded some experimental plugins with VA-API support: > <http://www.splitted-desktop.com/~gbeauchesne/gstreamer-vaapi/> > > gstreamer-vaapi consists in a collection of VA-API based plugins for > GStreamer and helper libraries. > > * `vaapidecode' is used to decode MPEG-2, MPEG-4, H.264, VC-1, WMV3 > videos to video/x-vaapi-surfaces surfaces, depending on the > underlying HW capabilities. > > * `vaapiconvert' is used to convert from video/x-raw-yuv pixels to > video/x-vaapi-surface surfaces. > > * `vaapisink' is used to display video/x-vaapi-surface surfaces to > screen. Awesome ! > > Features > -------- > > * 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. > * Support for major HW video decoding solutions on Linux (AMD, Intel, NVIDIA) > > Requirements > ------------ > > Software requirements > > * 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. > * 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. > * libavcodec-dev >= 0.6 or with <libavcodec/vaapi.h> > > Hardware requirements > > * AMD platforms with UVD2 (XvBA supported) > * Intel Eaglelake (G45) > * Intel Ironlake (HD Graphics) > * Intel Poulsbo (US15W) > * NVIDIA platforms with PureVideo (VDPAU supported) > > Caveats > ------- > > * No integration within decodebin2 or the playbin2 pipeline > * No ad-hoc parser, vaapidecoder currently relies on FFmpeg This is also an area where Carl-Anton's work on gst-vdpau could help fix that, the mpeg1/2 part should be trivial to implement for ex (code already available in -bad/sys/vdpau/), and since he has to write such parsers for this Summer of Code, you could re-use them easily imho. > * MPEG-4 Part-2 (DivX) has decoding bugs > > Regards, > Gwenole. * 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). * 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 :) * Your plugins are LGPL... but they depend on a library (in gst-libs/) which is GPL, making the plugins GPL. Any reason for that ? Once again, Awesome work :) Edward > > ------------------------------------------------------------------------------ > > _______________________________________________ > gstreamer-devel mailing list > [hidden email] > https://lists.sourceforge.net/lists/listinfo/gstreamer-devel ------------------------------------------------------------------------------ _______________________________________________ gstreamer-devel mailing list [hidden email] https://lists.sourceforge.net/lists/listinfo/gstreamer-devel |
|
|
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. ------------------------------------------------------------------------------ _______________________________________________ gstreamer-devel mailing list [hidden email] https://lists.sourceforge.net/lists/listinfo/gstreamer-devel |
|
|
In reply to this post by Edward Hervey
On Tue, 2010-05-11 at 09:19 +0200, Edward Hervey wrote:
> 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. > I think what we want to do is move things out of vaapi as soon as possible and put them into something more capable (Cairo surfaces of course). I don't care if we use GL or xlib surfaces, as I expect to be able switch quickly between them anyway. What I'd still like to see is an element that takes as input raw H264/VC1/... frames and outputs Cairo surfaces. That should give us 100% of the performance, no need to duplicate sinks and converters yet again and give us the flexible to do everything we need. I should probably try to get this working on my i965, but never looked again because of the bad rep VAAPI got after some people tried to make it work half a year ago and failed. Benjamin ------------------------------------------------------------------------------ _______________________________________________ gstreamer-devel mailing list [hidden email] https://lists.sourceforge.net/lists/listinfo/gstreamer-devel |
|
|
Le 11 mai 10 à 18:45, Benjamin Otte a écrit :
> On Tue, 2010-05-11 at 09:19 +0200, Edward Hervey wrote: >> 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. >> > I think what we want to do is move things out of vaapi as soon as > possible and put them into something more capable (Cairo surfaces of > course). I don't care if we use GL or xlib surfaces, as I expect to be > able switch quickly between them anyway. You can't have xlib surfaces. > What I'd still like to see is an element that takes as input raw > H264/VC1/... frames and outputs Cairo surfaces. That should give us > 100% > of the performance, no need to duplicate sinks and converters yet > again > and give us the flexible to do everything we need. Examples? Your Cairo surfaces will have to be VA surfaces or GL texture as the outcome. If you want to get rid of the HW surface, you are left with OpenGL only. If you intend to have the decoded pixels back, you'd rather get 20% of the performance... Also note that for some drivers, you will be able to get Y/U/V textures, instead of a single RGBA texture. So, if you can plan Cairo/GL surfaces made up of 3 textures, that could be an interesting thing too. > I should probably try to get this working on my i965, but never looked > again because of the bad rep VAAPI got after some people tried to make > it work half a year ago and failed. How? ------------------------------------------------------------------------------ _______________________________________________ gstreamer-devel mailing list [hidden email] https://lists.sourceforge.net/lists/listinfo/gstreamer-devel |
|
|
On Tue, 2010-05-11 at 19:59 +0200, Gwenole Beauchesne wrote:
> You can't have xlib surfaces. > Doesn't matter. The way it currently looks is GL all the way. X (and of course Image) will be supported as a fallback so the apps that want it can make use of it. > Examples? Your Cairo surfaces will have to be VA surfaces or GL > texture as the outcome. If you want to get rid of the HW surface, you > are left with OpenGL only. > gst-plugins-cairo has a projectm plugin that I used as an example of something that's capable of nothing but OpenGL. http://blogs.gnome.org/otte/2010/04/21/hacking-spree/ has a demo video created with it. > Also note that for > some drivers, you will be able to get Y/U/V textures, instead of a > single RGBA texture. So, if you can plan Cairo/GL surfaces made up of > 3 textures, that could be an interesting thing too. > So far that has not been a consideration and it certainly will not be in the first version. But I'm not ruling this out as it might be interesting to support when people want to operate on YUV directly. Until then, I'll be happy with just running a shader that blends onto a single RGBA texture. > > I should probably try to get this working on my i965, but never looked > > again because of the bad rep VAAPI got after some people tried to make > > it work half a year ago and failed. > > How? > I don't remember the details. And I didn't have access to a VAAPI-capable GPU back then. It's also a bit of a turn-off that no distro ships any packages and even you advertise that one needs some patchset to make it work. It would be a lot simpler if there were regular releases and a master branch that one could follow. Benjamin ------------------------------------------------------------------------------ _______________________________________________ gstreamer-devel mailing list [hidden email] https://lists.sourceforge.net/lists/listinfo/gstreamer-devel |
«
Return to GStreamer-devel
|
1 view|%1 views
| Free forum by Nabble | Edit this page |