Hi,
Thanks Rob for moving that to trunk.
Le 14 mars 10 à 06:14, Rob Savoye a écrit :
I see two issues initially, although none of these effect normal
operation. If vaapi is enabled, it works fine for all my testcases,
but
segfaults when going to YouTube. Obviously on the TODO list.
Some
On Sat, Mar 13, 2010 at 10:14:12PM -0700, Rob Savoye wrote:
Adrian Panasiuk wrote:
A single build for all GUIs is not implemented right now, right?
Actually that is how it builds now. On a non Haiku system, try
configuring with --enable-gui=all, and you'll get a whole bunch.
I tried
strk wrote:
configure: error: OpenGL renderer is not supported by FB gui. Use
--enable-renderer=AGG or --enable-gui=kde,gtk,sdl
Try --with-renderer=agg, which is still the runtime default.
- rob -
___
Gnash-dev mailing list
Gwenole Beauchesne wrote:
segfaults when going to YouTube. Obviously on the TODO list.
Some time ago, I tried HD content on Youtube and it worked (with the
right fmt= option). However, I read they recently switched their HD
player to some AS3 + more features... that Gnash probably doesn't
Le 14 mars 10 à 16:36, Rob Savoye a écrit :
The Cairo backend is also closer to correct rendering than the OpenGL
backend. Since we have to convert vectors to bitmaps for OpenGL
anyway,
we might as well use Cairo unless there is an appreciable performance
performance hit. I've never seen
On Sun, Mar 14, 2010 at 08:48:12AM -0600, Rob Savoye wrote:
strk wrote:
configure: error: OpenGL renderer is not supported by FB gui. Use
--enable-renderer=AGG or --enable-gui=kde,gtk,sdl
Try --with-renderer=agg, which is still the runtime default.
Eh, my intention was to try the new
On 03/14/10 13:42, strk wrote:
Eh, my intention was to try the new all renderers
kind of build...
It's the default. :-)
- rob -
___
Gnash-dev mailing list
Gnash-dev@gnu.org
http://lists.gnu.org/mailman/listinfo/gnash-dev
On Sun, Mar 14, 2010 at 01:53:01PM -0600, Rob Savoye wrote:
On 03/14/10 13:42, strk wrote:
Eh, my intention was to try the new all renderers
kind of build...
It's the default. :-)
That's how I got the error.
--strk;
() Free GIS Flash consultant/developer
/\
On Sun, Mar 14, 2010 at 08:54:53PM +0100, strk wrote:
On Sun, Mar 14, 2010 at 01:53:01PM -0600, Rob Savoye wrote:
On 03/14/10 13:42, strk wrote:
Eh, my intention was to try the new all renderers
kind of build...
It's the default. :-)
That's how I got the error.
I've
The guis are still trying to link against librender/libgnashagg.la,
librender/libgnashcairo.la and librender/libgnashogl.la - I've checked
that symlinking librender/libgnashrender.la to those names allows
building working binaries.
A single build for all GUIs is not implemented right now, right?
strk wrote:
Kde4Gui won't link because of multiple definitions (no idea why, but
it's not a problem in trunk).
Ah, I've been building with just gtk primarily in the branch, so
missed this.
I'd be happy to help fixing this if it doesn't get
in rob's way (ie: if he has uncommitted patches)
On Mon, Mar 01, 2010 at 07:08:08PM -0700, Rob Savoye wrote:
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, Mar 02, 2010 at 09:43:35AM +0100, Benjamin Wolsey wrote:
Kde4Gui won't link because of multiple definitions (no idea why, but
it's not a problem in trunk).
I could reproduce this. It's due to gui/am-frag/kde4.am
having something like this:
if BUILD_OGL_RENDERER
...
kde4_gnash_SOURCES
Hi,
On Tue, 2 Mar 2010, Rob Savoye 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
On Tue, 2 Mar 2010, John Gilmore wrote:
there was lots of concern among free software developers that it's an
Intel trojan horse to get proprietary drivers embedded in the free
ecosystem.
Please define lots of concern, who, what? Nobody said anything like
this.
Your link to Fedora is
On Mon, 1 Mar 2010, Rob Savoye wrote:
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),
Hi,
On Wed, 3 Mar 2010, Craig Kelley wrote:
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
Le 2 mars 10 à 03:08, Rob Savoye a écrit :
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)'.
After some use, even from a developer point of view, those options are
really nice since
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
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
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,
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
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
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
Very cool, well done!
Bastiaan
On Mon, 1 Mar 2010, Rob Savoye wrote:
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
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 Mon, Mar 01, 2010 at 07:08:08PM -0700, Rob Savoye wrote:
The original idea was to make them dynamically loadable plugins, but for
now the big render library works. (in the branch, that is).
For distributions it'll be best to split them, or 'gnash' package
will have dependencies of all
50 matches
Mail list logo
