Re: [Gnash-dev] vaapi update

[Rob Savoye]

On 05/13/2010 08:31 PM, John Gilmore wrote:
> I noticed the results of XOrg meeting about video support here:
> 
>   http://lists.freedesktop.org/archives/xorg/2009-November/048182.html

  I just read through that page, interesting... I do see they talk about
vaapi, and basically said it sucks... There is new vaapi support for
Gstreamer as of literally a few days ago, I just built it, but haven't
had much time to test it yet. (I'm at UDS this week) Both vlc and
mplayer support vaapi now too, so it has some adoption. Firefox is also
been adding vaapi support.

> I don't know how this is going, but it's April/May and have we heard
> any encouragement for our Flash player to make use of a new video 
> rendering API for gstreamer?

  Yes, from any manufacturer I've talked to. Performance is the one
place we can potentially beat Adobe on *now*, so it seems worth
perusing. It also seems the YUV to RGA conversion as we do it now limits
the benefits considerably, so I'm still debating how much time to put
into this. It still seemed worth investigating to make an educated
decision. I just want to drop our cpu load, and since nobody else seems
to care about Gnash performance at all, somebody has to...

> Is there a wiki page that tells relatively clueless people like me
> exactly how to run current snapshots on their production Linux system

  I don't think you'd want to try this much till I hack on it some more,
but initial documentation is at:
        http://wiki.gnashdev.org/Hardware_Video_decoding

  This is definitely a work in progress, and I have been thinking to
really support hardware video decoding well, we need a major refactoring
of our video handling subsystem. This would apply to using things like
OpenMax (which is what Adobe uses) instead of vaapi.

  Right now I'm not even building debs for our repositories, as it
depends on ffmpeg. Now that Gstreamer is slowly getting vaapi support,
it may be that we can use vaapi without direct support in Gnash.

        - rob -