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/[email protected]/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 _______________________________________________ Gnash-dev mailing list [email protected] http://lists.gnu.org/mailman/listinfo/gnash-dev
