Hi,
Le 9 août 09 à 23:00, Bastiaan Jacques a écrit :
Is there a vendor-neutral library that could be used for this purpose?
You can target all 3 major vendors, and a few others, with VA API.
http://freedesktop.org/wiki/Software/vaapi
Regards,
Gwenole.
Hi,
Since support for VA API is not to be integrated at this time, in the
current state, I have placed the patches and instructions there:
http://www.splitted-desktop.com/~gbeauchesne/gnash-vaapi/
The patch applies against bzr rev 11404.
Some background. VA API is an open spec and there is
Hi,
On Wed, 23 Sep 2009, Bastiaan Jacques wrote:
I would be interested in merging the VA API integration if we have some
indication that the free GPU driver community (i.e., Nouveau or
AMD-free) will soon be supported by VA API.
I don't believe this will happen, especially under the soon
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
Hi,
On Wed, 23 Sep 2009, John Gilmore wrote:
The Fedora steering committee has concerns about VAAPI:
http://www.opensubscriber.com/message/fedora-devel-l...@redhat.com/12677631.html
Reading:
https://bugzilla.redhat.com/show_bug.cgi?id=518546
It appears the concerns are because there is
Hi,
This fixes OGL gnash when --fullscreen or -j/-k options are used. The
video frames did not scale correctly. However, the other bitmaps are
not fixed with this patch.
Regards,
Gwenole.
0001-Fix-scaled-window-mode.patch
Description: Binary data
Hi,
draw_subshape() was glEnable()'ing GL_TEXTURE_GEN_S and
GL_TEXTURE_GEN_T and never glDisable()'ing them. This causes problem
when you wan to render a GL texture afterwards. e.g. video frames.
Regards,
Gwenole.
0002-Fix-draw_subshape-to-disable-environment-mapping-w.patch
Hi,
This patch initializes X threading support. I noticed Xv was using
XLockDisplay() and XUnlockDisplay() but it never initialized them.
Besides, I also got problems with the OGL renderer and the plug-ins.
Regards,
Gwenole.
0003-Call-XInitThreads-in-GtkGui-init.patch
Description:
Hi,
This patch disables anti-aliasing with the accumulation buffer. This
kills all performance, a better approach would be to use multisampling
(FSAA). However, I don't know if the FSAA patch to gtkglext was
integrated upstream. So, we'd probably to do it manually with another
front-end?
Hi,
Le 18 oct. 09 à 16:42, Bastiaan Jacques a écrit :
I gave this patch a spin and it turned out to segfault on my machine.
According to GTK docs, thread initialization should be done before
gtk_init(), so that may point to the cause.
Yes, you are right. I hadn't updated the patch. The right
Hi,
Le 12 janv. 10 à 00:44, Gwenole Beauchesne a écrit :
Current trunk doesn't build on my Ubuntu 9.04 system with libtool
2.2.6a. Well, you don't strictly notice this problem with the
original trunk but manual inspection of libbase/Makefile.am reveals
that some variables like
Hi,
Le 13 janv. 10 à 11:39, Andrea Palmatè a écrit :
Il 13/01/2010 9.35, Gwenole Beauchesne ha scritto:
Hi,
Le 12 janv. 10 à 23:41, Gwenole Beauchesne a écrit :
This happens because I built gnash in a different builddir than $
(top_srcdir)/. e.g. objs.vaapi-agg/ in the $(top_srcdir
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
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 b
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
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, 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
a patch to fix the merge problem: duplicate decls.commit e1fca2a8189ea131cde34281ff3dede14219b885
Author: Gwenole Beauchesne gbeauche...@splitted-desktop.com
Date: Tue Mar 2 12:22:14 2010 +
Fix SW fallback if VA-API is built-in.
diff --git a/libvaapi/vaapi_utils.h b/libvaapi/vaapi_utils.h
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
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
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,
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
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
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
Le 7 mars 10 à 16:19, nate lust a écrit :
It would be great if gnash suppored the broadcom crystal hd decoder
nate lust
It would be great if someone could cleanup the GStreamer plug-in
supporting the Broadcom Crystal HD decoder. If you do that, then Gnash
would support it without change
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
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
Hi,
On Tue, 18 May 2010, Rob Savoye wrote:
On 05/18/2010 11:18 AM, Gwenole Beauchesne wrote:
IIRC, the exact date is 2010/01/18 with the commit of a patch to install
libavcodec/vaapi.h. i.e. you can check for that file, thus meaning
that the FFmpeg installation is VA-API capable.
Ah, I'll
From: Gwenole Beauchesne gbeauche...@splitted-desktop.com
Date: Wed, 19 May 2010 07:24:49 +
Subject: [PATCH 1/2] Fix warning for NPAPI support and compatibility with the selected GUI.
---
configure.ac |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/configure.ac b
Hi,
This patch fixes VA-API support when Gnash was built with Xv. It never
actually used VA-API since either GtkAggXvGlue or GtkAggGlue was forced.
Regards,
Gwenole.From ccb3b9996270712aa8060c7b4ff9074d1d403111 Mon Sep 17 00:00:00 2001
From: Gwenole Beauchesne gbeauche...@splitted-desktop.com
Hi,
On Tue, 18 May 2010, Rob Savoye wrote:
On 05/18/2010 11:18 AM, Gwenole Beauchesne wrote:
IIRC, the exact date is 2010/01/18 with the commit of a patch to install
libavcodec/vaapi.h. i.e. you can check for that file, thus meaning
that the FFmpeg installation is VA-API capable.
Ah, I'll
, etc.).
This awful hack is not guaranteed to work. Besides, the fallback mechanism
already takes place gracefully in gtk_canvas.cpp.
Regards,
Gwenole.From 1b69e8166f8732d5a276ff9d2a6697244a42b95a Mon Sep 17 00:00:00 2001
From: Gwenole Beauchesne gbeauche...@splitted-desktop.com
Date: Wed, 19
Hi,
Le 23 juin 10 à 18:23, Rob Savoye a écrit :
One nice thing and OpenVG is that we would only need one rendering
backend, as it would use hardware acceleration if it was present,
and if
not, drop back to software rendering with similar performance as AGG
has.
OpenVG is an interesting
1338de1ea21d84114dc89e853e1d674e9672ae67 Mon Sep 17 00:00:00 2001
From: Gwenole Beauchesne gbeauche...@splitted-desktop.com
Date: Thu, 5 Aug 2010 12:35:49 +0200
Subject: [PATCH] Fix build with older Boost version ( 1.36).
---
libcore/asobj/flash/display/BitmapData_as.cpp | 23 +--
1 files changed, 21 insertions
Hi,
On Wed, 4 Aug 2010, Rob Savoye wrote:
So trunk is now broken if you want to use vaapi.
Xv support is also broken:
$ libtool --mode=execute gdb --args ./gui/gtk-gnash --hwaccel xv
~/flash/bloxorz.swf
0x08093b51 in gnash::GtkAggXvGlue::findPixelFormat (this=0x91730e0,
On Wed, 4 Aug 2010, Rob Savoye wrote:
So trunk is now broken if you want to use vaapi.
I think it even fails to break without since the following error doesn't
seem to be related to VA-API or other GnashImage.
../../libcore/asobj/flash/display/BitmapData_as.cpp: In constructor
Hi,
This patch drops shit messages.
BTW, could the original people please elaborate or is it just because
there were some things they did not understand enough or was not
meaningful enough?
Thanks,
Gwenole.From dc86edf0896830cae5e57cbf30024a90e1163940 Mon Sep 17 00:00:00 2001
From: Gwenole
Hi,
This patch fixes the VA-API configure check. In particular, it now really
fails when user configure'd --enable-hwaccel=vaapi but without
--enable-media=ffmpeg.
Regards,
Gwenole.From 2a3dac86384b4d71e536910f5fb6b322f3072df7 Mon Sep 17 00:00:00 2001
From: Gwenole Beauchesne gbeauche
46 matches
Mail list logo
