[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Gwenole Beauchesne
Subject: Re: [Gnash-dev] Flash HD (H.264) video decoding acceleration
Date: Thu, 24 Sep 2009 01:26:39 +0200


Le 23 sept. 09 à 23:37, John Gilmore a écrit :

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.

I had asked some Intel people about other formats. The main reason was only broadly accepted and standard formats are available on silicon. Even VP6 did not match their criteria. Besides, the people who designed the API worked with existing HW implementations, not with hypothetical and future implementations.

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

I will implement MPEG-2 MoComp and iDCT paths when I understand how this works and how I can manage to get this accepted through the FFmpeg AVHWAccel infrastructure.

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

One of my plans was to actually write an XvMC backend to VA-API. ;-)

(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.

I am not sure to fully understand what you mean but I will think again about it tomorrow or over this night. Isn't Gnash/Flash limited to VP6 and H.264? How would MPEG-2 MoComp/iDCT support help Gnash?

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.

Are you talking about the Poulsbo driver? If I were to do some reasoning based on public information and thus without being tainted by privileged information, I would say: there could have been something available by Q4 2009. However, it's questionnable as to what form this would take and what precise chipset (current or future) this would be available for. I would also say GMA500, more precisely VXD370 in current or future chips, is not in-house Intel technology. However, their recent raise in stocks in ImgTech was probably a sign to {,be allowed to} do something but Apple also raised their stocks significantly afterwards, thus probably inhibiting some actions?

Nobody can really know or talk about anything related to that, I am afraid. Doing so would only feed bad or good rumors. Of course, my interpretations of facts I exposed here are probably not the reality. For sure, we can only wait for Q4 (the whole 3 months) and see what actually happens.

BTW, the G45 VA driver is fully Open Source right now because this is Intel technology in a whole, unlike US15W.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]