2011-11-22, 17:48
RockerC Wrote:Would it not be best to try to utilize existing API standard for video acceleration like VAAPI or OpenMAX as much as possible?
Doesn't XBMC already support both VAAPI and OpenMAX?
http://www.freedesktop.org/wiki/Software/vaapi
http://www.khronos.org/openmax/
If that is the case, could you perhaps not write your own VAAPI or OpenMAX backend drivers and headers whenever the hardware manufacturer does not supply official support for these but instead only offer their own non-standard video acceleration method?
It is, maybe, an option. We did used to support OpenMAX, but I'm not personally a big fan of the API.. and I expect it would turn into #ifdef city to support different OMX implementations without breaking existing platforms. And would be a bigger task that adding support for the native codec API.
VAAPI might be an option. I like the fact that it encompasses video mixing/rendering, although will have to take a closer look at how XBMC utilizes this. The big annoyance that I see so far with VAAPI is that it is just a VLD level decoder, but our decoders want the entire elementary bitstream (including things like SPS/PPS in h264, and equivalent in other formats). At least the advantage with VAAPI is it is more widely supported on linux than OMX.
In the end, the decoder is the easy part. And there is stuff like https://github.com/topfs2/xbmc/commits/gstreamer if we wanted to use a standard API. The bigger question is how to handle the rendering efficiently..
RockerC Wrote:If you could do that then way XBMC's video players would maybe only have to support a few of the existing API standards instead of having direct support for all different types of video acceleration hardware using their own unique methods?
Any such backend drivers and headers that you write could then also be used by other open source projects who already support VAAPI or OpenMAX?
In related news to this there is now a new VAAPI backend design that is primarily made for ARM devices. Haihao Xiang from Intel recently published a branch of VAAPI with a VA/EGL backend. This new vaapi-egl driver is a generic implementation for VAAPI with EGL and then there are backend drivers for Intel and PowerVR hardware support using an EGL display with OpenGL ES rather than GLX/OpenGL such as the normal VAAPI
http://lists.freedesktop.org/archives/li...00717.html
http://cgit.freedesktop.org/libva/log/?h=vaapi-egl
vaapi-egl could be interesting.. does XBMC support this already? I guess it shouldn't be too big a change. I'll look more closely at how rendering is handled in vaapi decode case..