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

[Gwenole Beauchesne]

Hi,

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.

Regards,
Gwenole.