gnash-dev
[Top][All Lists]
Advanced

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

[Gnash-dev] Hardware acceleration support


From: Rob Savoye
Subject: [Gnash-dev] Hardware acceleration support
Date: Mon, 01 Mar 2010 19:08:08 -0700
User-agent: Thunderbird 2.0.0.23 (X11/20090817)

I've been hacking on hardware video decoding support in an experimental
branch ('hwaccel'), and just added support for Gnash to load the
renderer at runtime. So that means one can change between Cairo,.
OpenGL, and AGG when gnash is started. It's also configurable by a
gnashrc setting. Currently I'm just putting all the backends in one big
library, and also all the GUI glue code. Luckily there were zero name
collisions on anything.

The original idea was to make them dynamically loadable plugins, but for
now the big render library works. (in the branch, that is). I'm also
considering renaming backend to librender, and in the branch, also
moving libvaapi under librender.

If anyone decides to play with this, run 'gnash --render-mode
(opengl|cairo|agg)'. The new option for HW video accelerators is
'--hwaccel (none, vaapi, xv)'. So far I've tested this on an Nvidia
(binary blob and libvdpau required), and Intel (965 required), and
supposedly ATI works with libxvba.

The last thing I need to fix before migrating this to trunk is currently
if vaapi is enabled, but you don't have supported hardware, it doesn't
handle this gracefully at all. (it segfaults, actually) it should also
be possible to find the best defaults for a platform, for example
testing for opengl/vaapi support, then dropping back to agg/vaapi, then
agg/xv, then agg/none. Unfortunately Gnash's Xv support has a major
scaling bug...

So far I actually haven't seen much performance improvement in my
testing, (mpeg4 n an FLV) but it looks like the bottleneck is in our
renderers.

        - rob -




reply via email to

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