Re: [Gnash-dev] Flash HD (H.264) video decoding acceleration

[John Gilmore]

Thank you for working on improving gnash.

> First off, I have to express some concern that apparently only
> proprietary GPU drivers are supported for use with VA API -- at least,
> for the codecs that are commonly used in Flash videos. The last
> thing we want to do is encourage people to use proprietary drivers for
> use with Gnash. I would be interested in merging the VA API integration
> if we have some indication that the free GPU driver community (i.e.,
> Nouveau or AMD-free) will soon be supported by VA API.

I have the same concern.  I don't think we should let Intel use Gnash
to slide proprietary licenses into the free ecosystem.  Instead, we
should support the best of the all-free acceleration APIs.

Here's the best index page I found for the VA API:

  http://www.freedesktop.org/wiki/Software/vaapi

Intel has published a truly free VA API driver here, for their G45 and
GM45 chips:

  git clone git://git.freedesktop.org/git/libva
  http://lists.freedesktop.org/archives/intel-gfx/2009-August/003708.html

It's a really early driver and it only includes full decoding of the
MPEG2 bitstream; it doesn't include any of the sub-stuff like the IDCT
or Motion Compensation interfaces (which would let applications or
libraries accelerate any software-rendered video format, other than
MPEG2).  They are working on supporting H.264 in that driver
eventually.  I don't think they've cut a release that includes even
the existing code, it's just a working repo so far.

It's unclear to me why there isn't an Ogg Theora video profile in the
VA API itself.  I find it unlikely that Theora decoding or encoding
can't be accelerated by a bunch of the hardware out there.  It seems
like the people who defined the API weren't thinking much about free
formats -- which is a red flag.

Corbin Simpson (free Radeon driver developer) says that the free
Radeon and free AMD developers have agreed to implement VDPAU (but
have been busy with other things):

  http://article.gmane.org/gmane.comp.freedesktop.xorg/40358

In theory, using Gwenole's GPLv2 adapter code, a free application that
calls VA API can end up using a free VDPAU driver, when one exists:

  http://www.splitted-desktop.com/~gbeauchesne/vdpau-video/

But Gwenole's adapter also doesn't support anything but full decoding,
and doesn't support any free video formats.  He also has a VA API
to XvBA adapter, but it's proprietary (it sits behind a password-wall).

There's a summary in Wikipedia, which I recommend that Gwenole (or
someone else who is clued in to the graphics-api-wars) add a section
comparing VA API, VDPAU, XvBA, and XvMC:

  http://en.wikipedia.org/wiki/Graphics_hardware_and_FOSS

LWN has an article on VA API that describes many of Gwenole's contributions:

  http://lwn.net/Articles/338581/

  "... a "wait and see" attitude was taken by most projects during the
  first year or so of VA API development. Some of that is, no doubt,
  caution that would be taken towards any entirely new API; perhaps
  some of it is attributable to the perception that VA API was an
  Intel-only project or at best fated to duke it out against VDPAU and
  XvBA until one of them becomes dominant."

The Fedora steering committee has concerns about VAAPI:

  http://www.opensubscriber.com/message/address@hidden/12677631.html

Ultimately, they decided to allow VDPAU into Fedora, but not VA API:

  https://fedorahosted.org/fesco/ticket/238

Younes Manton is doing generic GPU-accelerated video decoding, which
started as his Google Summer of Code project.  He's using mplayer and
the XvMC interface.  But he's doing it right -- he's accelerating the
low layers (motion compensation) first, then working up to the higher
layers (inverse DCT).  He's "been looking at VDPAU" too.  Gwenole, you
could probably slap a VA API front end onto his code, which would make
the first free VA API implementation that does the low layers (and it
would speed up NVidia video playback all in free software, and give
you clues about how to do that for the Intel chips).  If the mplayer
or gstreamer VA API interface would call these layers (the way the
mplayer XvMC interface currently does), this would provide
acceleration for codecs that aren't fully decoded -- like all the ones
Gnash cares about.  See:

  http://www.bitblit.org/gsoc/g3dvl/
  http://bitblitter.blogspot.com/

Gwenole, if you're interested in pushing VA API further into the free
software community, get Intel to explain why its main released VA API
driver is proprietary -- and how and when they're going to replace
that with free software.  If they're never going to replace it, the
free community will probably say "never mind VA API then, we'll go our
own way".  It would suck if AMD and NVidia hardware had an all-free
path, but most Intel hardware ended up using proprietary drivers.
Intel has been very good at making its drivers free in the past; this
departure from that policy makes VA API look like Intel's attempt to
find a path by which they can make lots more drivers proprietary.
Thus, the resistance among people who care about freedom.

Gwenole, once those Intel issues are resolved, I recommend raising
VA API inclusion with the Fedora steering committee again.  Having a
released all-free-software path from a high level application that
calls VA API, down to a hardware driver that actually accelerates,
should encourage them to adopt it.  Also having a free VDPAU adapter
would let high level apps have a free path to much more hardware.

>    I assume this would be a corporate copyright assignment or a personal 
> one ? I can send you the appropriate paperwork. On occasion I've had 
> corporations refuse to assign copyright to the FSF (we're a GNU 
> project), which has forced me to remove code I wish I didn't have to. I 
> can think of a few other projects (OLPC's new hardware is Via based) 
> that would benefit from this patch, so hopefully there is no problem.

Half the people at Splitted-Desktop come from Mandriva, so they know
a lot about free software.

        John Gilmore