Mailing List Archive

New video acceleration API info
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)

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


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.
Re: New video acceleration API info [ In reply to ]
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

_______________________________________________
mythtv-dev mailing list
mythtv-dev@mythtv.org
http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-dev
Re: New video acceleration API info [ In reply to ]
On 8/3/07, Daniel Kristjansson <danielk@cuymedia.net> wrote:
>
> On Thu, 2007-08-02 at 18:27 -0400, Todd Ignasiak wrote:
>
> > 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.


His original announcement (
http://lists.freedesktop.org/archives/xorg/2007-March/022893.html ) says he
considered XvMC, but decided to start clean. I don't know who's right on
that, but after looking at xvmc wrappers and manual selection of which
version to use, VAAPI initialization looks quite nice. Also, it's intended
to be usable in any environment, not just X. But, I'm guessing that
wouldn't effect many MythTV users.

On the XvMC side.. another intel engineer recently announced XvMC work in
their i915 driver, and work in progress on newer cores. If they're doing
both, I would think that the VLD and non-MPEG2 stuff would be VAAPI
territory.
http://lists.freedesktop.org/archives/xorg/2007-July/026598.html
http://lists.freedesktop.org/archives/xorg/2007-July/026607.html

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. :)



Yeah, there were similar comments on the xorg mailing list. But, the Intel
guys said that fixed function video decode pipelines will still be around
( http://lists.freedesktop.org/archives/xorg/2007-March/022960.html ).
So, I guess the question is whether the low-end GPUs will also be capable of
GLSL video offload.

Obviously, GLSL would also be a nice solution for cross-platform (Mac OS X)
frontends too. Are there any open source efforts working towards this? I
haven't seem any yet.