[mythtv] New video acceleration API info

Daniel Kristjansson danielk at cuymedia.net
Fri Aug 3 13:41:00 UTC 2007


On Thu, 2007-08-02 at 18:27 -0400, Todd Ignasiak wrote:
> There was some discussion a couple months ago regarding the Intel
> video acceleration API.  They recently put up some information on the
> freedesktop.org www site.
>
> It would be good to get some input on this API, from the perspective
> of all the MythTV experience with XvMC and trying to improve on that.
> http://www.freedesktop.org/wiki/Software/vaapi
> 
> The major differences between this and XvMC are:
> - Support for VLD, iDCT, and MC (XvMC is only iDCT and MC. The
> OpenChrome XvMC was extended to do VLD for VIA Unichrome GPUs)

So XvMC-VLD showed it was fairly easy to add VLD acceleration.

> - Support for more codecs (MPEG2, MPEG4, H.264, VC-1)  XvMC only
> addresses MPEG2.

The XvMC API addresses MPEG-1, MPEG-2, H.263 and MPEG-4, adding
H.264 & VC-1 would have been trivial.

> It's being done completely open.  The open source drivers from Intel
> will presumably be the first to support this -- unlocking the video
> features of their X3*00 video cores.  That should offer some great
> possibilities for MythTV frontends.

We may code to it someday, but if they do implement this in
an open way we may just translate it into pure OpenGL fragment
programs and avoid implementing yet another API to do the
same thing as the numerous established APIs. The main problem
with XvMC isn't the API but poor implementation of it, for
instance only offering 8 buffers on the nVidia cards, and
only offering crappy 16 color OSD buffers. VIA OpenChrome
offers more buffers, but doesn't allocate memory according
to the XVideo spec so you have to have tell people to use
certain BIOS settings and then they still may need to hack
the source. The other problem with XvMC was that the old
X team refused extensions, but X.org is much more receptive
to improving X than the previous maintainers.

Since vaapi is just a wrapper for the 3-D engine in the Intel
video cards there really is no benefit to using it rather than
the more established OpenGL API, unless they plan to obfuscate
the fragment programs that do the decoding. Any card that supports
vaapi will support OpenGL, and most cards that support OpenGL
won't support vappi. If I were to talk to them I'd suggest 
dropping vappi and just implementing this in some video player
using OpenGL... That would make  porting it to MythTV easier. :)

-- Daniel



More information about the mythtv-dev mailing list