Am Montag, den 01.03.2010, 19:08 -0700 schrieb Rob Savoye:
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
On Tue, 2 Mar 2010, Benjamin Wolsey wrote:
+1 for librender. Not sure exactly what you mean by moving libvaapi. I
would prefer that libvaapi code is kept together, and separate from
other code, though whether it's under librender or at top level isn't so
important.
It's better to keep
It's better to keep libvaapi at the top-level because you would run into
weird dependency problems otherwise. libmedia, libbase, librender all
require libvaapi.
Libbase must not depend on any other library. It seems to me that the
vaapi files there could be moved to libvaapi.
I swore
On Tue, 2 Mar 2010, Benjamin Wolsey wrote:
Libbase must not depend on any other library. It seems to me that the
vaapi files there could be moved to libvaapi.
We can move libvaapi to libbase/ then. The reason why I initially split it
off was it was faster for me to fix/build/relink this part
Hi,
config vars were not fully replaced. Fixed as in attachment.
Regards,
Gwenole.commit 772f8db21d85d121e5923bf04fca608383bd5ac5
Author: Gwenole Beauchesne gbeauche...@splitted-desktop.com
Date: Tue Mar 2 11:07:46 2010 +
Fix VA-API configure summary.
diff --git a/configure.ac
Benjamin Wolsey wrote:
I'm also not sure it's currently really worth making them really
dynamically loadable (you mean dlopening them, I guess?). The only
advantages I can see is that they'd be switchable during runtime (which
the design currently doesn't allow) and that new renderers could
Benjamin Wolsey wrote:
On the other hand, gui/Player.h in the hwaccel branch is generally
better than in trunk because most tabs are replaced with 4 spaces.
But it now has some new 8-space tabs, so the indentation is also
messed up in places.
My problem... On my laptop I wasn't converting
Benjamin Wolsey wrote:
Am Montag, den 01.03.2010, 19:08 -0700 schrieb Rob Savoye:
I also don't think it's a good idea to use -r / --render-mode to select
a renderer. Why not add --renderer, even with a short -R option?
We're running out of letters for options. :-) I can change it, I'm not
Gwenole Beauchesne wrote:
Actually, this won't work for VAAPI at this time because you won't have
the right VaapiGlobalContext initialized for OGL. I will look into his
once the remaining bits are merged.
I noticed too that OpenGL doesn't work anyway, I obviously broke
something. All I get
Gwenole Beauchesne wrote:
I think you should also replace sources annotations like
// indent-tabs-mode: t
to
// indent-tabs-mode: nil
That was the problem, I started fixing them all. I cut pasted a
standard block for emacs, and grabbed the wrong one. :-) It does 4 space
indents correctly,
Gwenole Beauchesne wrote:
On Tue, 2 Mar 2010, Benjamin Wolsey wrote:
It's better to keep libvaapi at the top-level because you would run into
weird dependency problems otherwise. libmedia, libbase, librender all
require libvaapi.
Ah, I guess it should stay top level then, plus we should
On Tue, 2 Mar 2010, Rob Savoye wrote:
I noticed too that OpenGL doesn't work anyway, I obviously broke
something. All I get now is a blank grey box.
I wanted to mention that the latest Cairo prerelease has a working
OpenGL backend. This means we could drop our OpenGL renderer and rely on
On Tue, 2 Mar 2010, Rob Savoye wrote:
The performance improvement is really effective for H.264 videos
playback only. You probably should downgrade your system to an Atom. ;-)
You have a point. :-) I have no Atom hardware to test on, so yeah, on
a dual core it may make no difference. Course
On Tue, 2 Mar 2010, Rob Savoye wrote:
Gwenole Beauchesne wrote:
On Tue, 2 Mar 2010, Benjamin Wolsey wrote:
It's better to keep libvaapi at the top-level because you would run into
weird dependency problems otherwise. libmedia, libbase, librender all
require libvaapi.
Ah, I guess it
Gwenole Beauchesne wrote:
I have a Phenom X3 (triple core) and it does help. For example, the 2012
trailer I pointed to you doesn't decode in real time with the SW
decoder. So, this generally is a win for H.264 on all platforms.
Which is what I'd think.
Please point me to your samples so
On Tue, 2 Mar 2010, Bastiaan Jacques wrote:
On Tue, 2 Mar 2010, Rob Savoye wrote:
I noticed too that OpenGL doesn't work anyway, I obviously broke
something. All I get now is a blank grey box.
I wanted to mention that the latest Cairo prerelease has a working
OpenGL backend. This means we
On Tue, 2 Mar 2010, Rob Savoye wrote:
My problem... On my laptop I wasn't converting all the tabs to spaces,
just some unlike my main computer. I fixed my emacs config so this
shouldn't be a problem now.
I think you should also replace sources annotations like
// indent-tabs-mode: t
to
//
On Tue, 2 Mar 2010, Gwenole Beauchesne wrote:
Interesting, is this a real OpenGL renderer and not a simple renderer that
calls glTexImage2D() only?
Yeah, most of the operations are accelerated using shaders.
I mean, the advantage of the current OpenGL, if
you don't consider bugs, is that
Gwenole Beauchesne wrote:
I wanted to mention that the latest Cairo prerelease has a working
OpenGL backend. This means we could drop our OpenGL renderer and rely on
Cairo for crisp OpenGL rendering instead.
Course our Cairo renderer is quite slow for some reason, I assume it's
in how Gnash
On Tue, 2 Mar 2010, Bastiaan Jacques wrote:
I mean, the advantage of the current OpenGL, if you don't consider bugs, is
that you control the order of objects displayed. That way, we can render
the Video texture at the right layer.
I'm not sure what you mean, but obviously Cairo allows us to
On Tue, 2 Mar 2010, Rob Savoye wrote:
Gwenole Beauchesne wrote:
Actually, this won't work for VAAPI at this time because you won't have
the right VaapiGlobalContext initialized for OGL. I will look into his
once the remaining bits are merged.
I noticed too that OpenGL doesn't work anyway,
Gwenole Beauchesne wrote:
It seems OGL doesn't work at all, no matter VA-API is built-in or not.
Something is probably wrong with the DRI/GLX check.
There is a new check in the latest version that checks to see if DRI
or GLX extensions are enabled, but nothing is done with that result yet.
Hi,
On Tue, 2 Mar 2010, Rob Savoye wrote:
Anyway, I just checked in your patch to this branch as of revno
#11825. For some reason the git patches don't apply 100% correctly, so
although I went through this by hand, I could have missed something. It
does compile and run though.
Attached a
On Tue, 2 Mar 2010, Rob Savoye wrote:
Gwenole Beauchesne wrote:
I wanted to mention that the latest Cairo prerelease has a working
OpenGL backend. This means we could drop our OpenGL renderer and rely on
Cairo for crisp OpenGL rendering instead.
Course our Cairo renderer is quite slow for
On Tue, 2 Mar 2010, Gwenole Beauchesne wrote:
On Tue, 2 Mar 2010, Rob Savoye wrote:
Course our Cairo renderer is quite slow for some reason, I assume it's
in how Gnash uses Cairo more than Cairo itself.
I don't think we're using Cairo inefficiently. I think the difference
stems from that
I've been hacking on hardware video decoding support in an experimental
branch
Great! It's good to stir up some fun in gnash like this. I'm still
afraid that gnash will soon be irrelevant to most people, until it can
play the friggin' scripts that the most popular video sites surround
their
Hi,
This patch disables HW scaling in the AGG/VAAPI code for now. This
requires the previous remove tabs patch.
Note that Xv has the same problems. We may be able to workaround this
problem by adding a bool notify = true arg to
movie_root::set_display_viewport() and call that function
Hi,
This fixes SW fallback when VA-API initialization failed. e.g. no VA-
API driver available or vaCreateContext() caused an error. This means
that we can enable VA-API by default and the fallback to SW won't
SIGSEGV any longer. ;-)
This patch is against the previous two patches I sent
On 03/02/10 12:05, John Gilmore wrote:
Great! It's good to stir up some fun in gnash like this. I'm still
afraid that gnash will soon be irrelevant to most people, until it can
play the friggin' scripts that the most popular video sites surround
their videos with.
While I agree with you,
Hi,
This adds a --no-hwaccel option just in case we make hwaccels enabled
by default. ;-)
IMHO, this is simpler and more intuitive to type than --hwaccel none.
Regards,
Gwenole.
gnash.no.hwaccel.opt.patch
Description: Binary data
___
Hi,
The logic behind the try-loop was a bit wrong. Fixed in this patch. A
better patch would be to add a name() property to each glue and make
canvas-glue-name() == something instead of relying on compile-time
constants. i.e. look for RENDER_xxx ifdefs around the top in realize.
Regards,
What ever happened to the licensing issues discussion? I did a pretty
exhaustive analysis of VA API in September, and concluded that there
was virtually no free software support for it, the spec only specifies
nonfree codecs, the implementations only accelerate nonfree codecs, it
was not designed
I guess its feasible; all I need is dev-board, jTag and a TV(?) and
plenty of spare-time.
//Markus
On 28 Feb 2010, at 15:31, Mohammad Mahefooz wrote:
Hi,
We are manufacturing an IP Set top box based on Texas Instruments
DaVinci DM6446 SoC with Linux OS. We are planning to deploy Opera
Le 3 mars 10 à 03:16, John Gilmore a écrit :
What ever happened to the licensing issues discussion? I did a pretty
exhaustive analysis of VA API in September, and concluded that there
was virtually no free software support for it, the spec only specifies
nonfree codecs, the implementations
34 matches
Mail list logo