[Gnash-dev] [PATCH] Fix build with older Boost versions
Hi,
This patch fixes build with older Boost version ( 1.36). In particular,
intrusive_ptr::reset(T *) appeared in 1.35 and intrusive_ptr::reset()
appeared in 1.36.
I have only copied the implementation from boost 1.36. Not tested.
Regards,
Gwenole.From 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(+), 2 deletions(-)
diff --git a/libcore/asobj/flash/display/BitmapData_as.cpp b/libcore/asobj/flash/display/BitmapData_as.cpp
index 2da403b..996abd4 100644
--- a/libcore/asobj/flash/display/BitmapData_as.cpp
+++ b/libcore/asobj/flash/display/BitmapData_as.cpp
@@ -79,6 +79,25 @@ namespace {
}
+static inline void reset(boost::intrusive_ptrCachedBitmap lhs,
+ CachedBitmap *rhs = 0)
+{
+if (rhs) {
+#if BOOST_VERSION 103500 /* 1.35.0 */
+boost::intrusive_ptrCachedBitmap(rhs).swap(lhs);
+#else
+lhs.reset(rhs);
+#endif
+}
+else {
+#if BOOST_VERSION 103600 /* 1.36.0 */
+boost::intrusive_ptrCachedBitmap().swap(lhs);
+#else
+lhs.reset();
+#endif
+}
+}
+
BitmapData_as::BitmapData_as(as_object* owner, std::auto_ptrGnashImage im,
boost::uint32_t fillColor)
:
@@ -92,7 +111,7 @@ BitmapData_as::BitmapData_as(as_object* owner, std::auto_ptrGnashImage im,
// If there is a renderer, cache the image there, otherwise we store it.
Renderer* r = getRunResources(*_owner).renderer();
-if (r) _cachedBitmap.reset(r-createCachedBitmap(im));
+if (r) reset(_cachedBitmap, r-createCachedBitmap(im));
else _image.reset(im.release());
}
@@ -194,7 +213,7 @@ void
BitmapData_as::dispose()
{
if (_cachedBitmap) _cachedBitmap-dispose();
-_cachedBitmap.reset();
+reset(_cachedBitmap);
_image.reset();
updateObjects();
}
--
1.5.4.3
___
Gnash-dev mailing list
Gnash-dev@gnu.org
http://lists.gnu.org/mailman/listinfo/gnash-dev
Re: [Gnash-dev] trunk is broken
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, form...@0x9189800) at ../../gui/gtk/gtk_glue_agg_xv.cpp:383 383 _mediaHandler-createVideoConverter(0x32424752 /* RGB */, format.id); (gdb) bt #0 0x08093b51 in gnash::GtkAggXvGlue::findPixelFormat (this=0x91730e0, form...@0x9189800) at ../../gui/gtk/gtk_glue_agg_xv.cpp:383 #1 0x08094022 in gnash::GtkAggXvGlue::findXvPort (this=0x91730e0, display=0x9154800) at ../../gui/gtk/gtk_glue_agg_xv.cpp:317 #2 0x08094f78 in gnash::GtkAggXvGlue::init (this=0x91730e0) at ../../gui/gtk/gtk_glue_agg_xv.cpp:94 #3 0x0808a072 in gnash_canvas_setup (canvas=0x912a400, hwacc...@0xffcddda8, render...@0xffcddda4, argc=4, argv=0xffcdde94) at ../../gui/gtk/gtk_canvas.cpp:278 #4 0x080908b0 in gnash::GtkGui::init (this=0x916f100, argc=4, argv=0xffcdde94) at ../../gui/gtk/gtk.cpp:261 #5 0x08080ed2 in gnash::Player::run (this=0xffcde714, argc=4, argv=0xffcde854, infi...@0x916d098, u...@0x80b3d74) at ../../gui/Player.cpp:356 #6 0x0806107c in main (argc=4, argv=0xffcde854) at ../../gui/gnash.cpp:587 Since vaapi is mostly only useful for developers at this time, as most of it's dependencies aren't in distributions yet, I think I'm gonna disable it in the release branch. The only dependencies are libva and FFmpeg new enough (e.g. 0.6). For the former, we can have ArchLinux, Debian, MeeGo, Gentoo. I'll leave it unchanged in trunk hoping the person that broke it fixes it. Chances are more long-term is I need to refactor the vaapi support to work with OpenVG/OpenGLES anyway. Is OpenVG support committed somewhere? I have some driver around that does both OpenVG and VA-API, so it could be interesting to test. Regards, Gwenole. ___ Gnash-dev mailing list Gnash-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnash-dev
Re: [Gnash-dev] trunk is broken
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 ‘gnash::BitmapData_as::BitmapData_as(gnash::as_object*, std::auto_ptrgnash::GnashImage, uint32_t)’: ../../libcore/asobj/flash/display/BitmapData_as.cpp:95: error: ‘class boost::intrusive_ptrgnash::CachedBitmap’ has no member named ‘reset’ ../../libcore/asobj/flash/display/BitmapData_as.cpp: In member function ‘void gnash::BitmapData_as::dispose()’: ../../libcore/asobj/flash/display/BitmapData_as.cpp:197: error: ‘class boost::intrusive_ptrgnash::CachedBitmap’ has no member named ‘reset’ Or probably raise the Boost version check in configure? Thanks, Gwenole.___ Gnash-dev mailing list Gnash-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnash-dev
[Gnash-dev] [PATCH] Drop shit messages
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 Beauchesne gbeauche...@splitted-desktop.com
Date: Thu, 5 Aug 2010 11:15:06 +0200
Subject: [PATCH] Drop shit messsages...
---
configure.ac |1 -
1 files changed, 0 insertions(+), 1 deletions(-)
diff --git a/configure.ac b/configure.ac
index 7ce907c..9bec522 100644
--- a/configure.ac
+++ b/configure.ac
@@ -1151,7 +1151,6 @@ if test x${build_vaapi} = xyes -a ( x${build_media_ffmpeg} != xyes -o
fi
if test x${have_ffmpeg_vaapi} = xyes -a x${build_vaapi} = xyes; then
- AC_MSG_CHECKING(some shit)
use_libva=no
use_libva_x11=no
use_libva_glx=no
--
1.5.4.3
___
Gnash-dev mailing list
Gnash-dev@gnu.org
http://lists.gnu.org/mailman/listinfo/gnash-dev
[Gnash-dev] [PATCH] Fix VA-API configure check
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...@splitted-desktop.com
Date: Thu, 5 Aug 2010 11:10:44 +0200
Subject: [PATCH] Fix check for VAAPI enabled without suitable FFmpeg/VAAPI.
---
configure.ac |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/configure.ac b/configure.ac
index 9a672f1..7ce907c 100644
--- a/configure.ac
+++ b/configure.ac
@@ -1146,7 +1146,7 @@ AC_ARG_ENABLE(hwaccel,
dnl Until the hwaccel patches in ffmpeg wind up in the ffmpeg-plugin,
dnl restrict using HW Accel to using ffmpeg directly.
-if test x${build_media_ffmpeg} = xno -a x${build_vaapi} = xyes -a x${have_ffmpeg_vaapi} = xyes; then
+if test x${build_vaapi} = xyes -a ( x${build_media_ffmpeg} != xyes -o x${have_ffmpeg_vaapi} != xyes ); then
AC_MSG_ERROR([Hardware acceleration currently not supported unless using ffmpeg.])
fi
--
1.5.4.3
___
Gnash-dev mailing list
Gnash-dev@gnu.org
http://lists.gnu.org/mailman/listinfo/gnash-dev
Re: [Gnash-dev] embedded graphics Gnash
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 path since there are also implementations for desktops. e.g. ShivaVG based on top of OpenGL. I think AmanithVG also provides GLES 1.x and 2.x backends but it's now a commercial product IIRC. However, I still think Cairo could serve a better purpose because there are both OpenVG and OpenGL backends and the newer OpenGL backend is promising. i.e. we can have HW accelerated rendering on Cairo supported platforms, which is plenty nowadays. Would it be possible to evaluate the performance of the current Cairo - OpenVG path vs. this dedicated OpenGL ES path on your OMAP board? Regards, Gwenole. ___ Gnash-dev mailing list Gnash-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnash-dev
Re: [Gnash-dev] vaapi update
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 modify my version check. Currently I look for ffmpeg revno
52.45.0, and it it's newer than that, vaapi configure support is enabled
when using ffmpeg.
Here is a patch to properly check for VA-API support in FFmpeg.
Regards,
Gwenole.From fcbbc86614c83ef1d6a455f6d51bf30eec908d4d Mon Sep 17 00:00:00 2001
From: Gwenole Beauchesne gbeauche...@splitted-desktop.com
Date: Wed, 19 May 2010 07:29:24 +
Subject: [PATCH 2/2] Fix check for VA-API support in FFmpeg.
---
macros/ffmpeg.m4 | 40 +++-
1 files changed, 15 insertions(+), 25 deletions(-)
diff --git a/macros/ffmpeg.m4 b/macros/ffmpeg.m4
index 25f453a..f65e3c1 100644
--- a/macros/ffmpeg.m4
+++ b/macros/ffmpeg.m4
@@ -22,7 +22,6 @@ AC_DEFUN([GNASH_PATH_FFMPEG],
backupCFLAGS=$CFLAGS
avcodec_h=
ffmpeg_top_incl=
- have_ffmpeg_vaapi=no
dnl If the user specify an path to include headers from, we assume it's the full
dnl path to the header file, and not the top level path without the 'ffmpeg' node
@@ -222,20 +221,10 @@ AC_DEFUN([GNASH_PATH_FFMPEG],
dnl AC_EGREP_HEADER(avcodec_decode_audio2, ${avcodec_h}, [avfound=yes], [avfound=no])
-dnl This makes sure the version of ffmpeg is new enough to contain
-dnl the libva support.
-if test x${enable_vaapi} = xyes; then
- if test -z $ffmpeg_num_version -o $ffmpeg_num_version -lt 52480; then
-AC_MSG_WARN([Wrong ffmpeg/libavcodec version! 52.48.0 or greater required to use libVA, $ffmpeg_version detected.])
- else
-ffmpeg_version_check=ok
- fi
+if test -z $ffmpeg_num_version -o $ffmpeg_num_version -lt 511100; then
+ AC_MSG_WARN([Wrong ffmpeg/libavcodec version! 51.11.0 or greater required, $ffmpeg_version detected.])
else
- if test -z $ffmpeg_num_version -o $ffmpeg_num_version -lt 511100; then
-AC_MSG_WARN([Wrong ffmpeg/libavcodec version! 51.11.0 or greater required, $ffmpeg_version detected.])
- else
-ffmpeg_version_check=ok
- fi
+ ffmpeg_version_check=ok
fi
if test ! -z $ffmpeg_num_version -a $ffmpeg_num_version -gt 512800; then
@@ -263,17 +252,6 @@ dnl AC_EGREP_HEADER(avcodec_decode_audio2, ${avcodec_h}, [avfound=yes], [avfou
else
AC_DEFINE(FFMPEG_NELLYMOSER, 1, [Define if ffmpeg can decode NELLYMOSER audio])
fi
-if test -z $ffmpeg_num_version -o $ffmpeg_num_version -gt 524800; then
- dnl 52.48.0 (r21285) or higher required for VAAPI support
- have_ffmpeg_vaapi=yes
- AC_DEFINE(FFMPEG_VAAPI, 1, [Define if ffmpeg supports VAAPI])
-else
- have_ffmpeg_vaapi=no
-fi
-if test -z $ffmpeg_num_version -o $ffmpeg_num_version -gt 52450; then
- dnl 52.45.0 (r20957) or higher required for VAAPI support
- AC_DEFINE(FFMPEG_VAAPI, 1, [Define if ffmpeg supports VAAPI.])
-fi
else
AC_MSG_WARN([Could not check ffmpeg version (can't find avcodec.h file)])
# ffmpeg_version_check=ok # this is NOT ok, why would it be ?!
@@ -311,6 +289,18 @@ dnl AC_EGREP_HEADER(avcodec_decode_audio2, ${avcodec_h}, [avfound=yes], [avfou
ffmpeg_version_check=
fi
+ AC_MSG_CHECKING([for libavcodec/vaapi.h])
+ have_ffmpeg_vaapi=no
+ if test -f ${ffmpeg_top_incl}/ffmpeg/vaapi.h; then
+have_ffmpeg_vaapi=yes
+AC_DEFINE(HAVE_FFMPEG_VAAPI_H, 1, [Defined if ffmpeg/vaapi.h is found])
+ fi
+ if test -f ${ffmpeg_top_incl}/libavcodec/vaapi.h; then
+have_ffmpeg_vaapi=yes
+AC_DEFINE(HAVE_LIBAVCODEC_VAAPI_H, 1, [Defined if libavcodec/vaapi.h is found])
+ fi
+ AC_MSG_RESULT($have_ffmpeg_vaapi)
+
dnl -
dnl
dnl FFMPEG libs checking
--
1.7.0.4
___
Gnash-dev mailing list
Gnash-dev@gnu.org
http://lists.gnu.org/mailman/listinfo/gnash-dev
[Gnash-dev] [PATCH] Fix warning for NPAPI check
Hi,
This patch fixes a wrong warning when only one GUI was selected.
Enabled NPAPI plugin, but it's not supported by the selected GUI
should not be displayed if only either GUI is selected. e.g. GTK only.
Regads,
Gwenole.From 12d79ae019ea5da98d039ecacfc8b6dd7392707b Mon Sep 17 00:00:00 2001
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/configure.ac
index b15eaee..d25e09a 100644
--- a/configure.ac
+++ b/configure.ac
@@ -2030,8 +2030,8 @@ fi
AM_CONDITIONAL(HAVE_GLIB, [ test x${has_glib} = xyes ])
-if test x$build_gtk = xno -o x$build_kde4 = xno; then
- if test x$npapi = xyes; then
+if test x$npapi = xyes; then
+ if ! test x$build_gtk = xyes -o x$build_kde4 = xyes; then
AC_MSG_WARN([Enabled NPAPI plugin, but it's not supported by the selected GUI])
fi
fi
--
1.7.0.4
___
Gnash-dev mailing list
Gnash-dev@gnu.org
http://lists.gnu.org/mailman/listinfo/gnash-dev
[Gnash-dev] [PATCH] Fix VA-API glue initialization
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 Date: Wed, 19 May 2010 08:24:54 + Subject: [PATCH 3/3] Fix VA-API initialization. --- gui/gtk_canvas.cpp |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/gui/gtk_canvas.cpp b/gui/gtk_canvas.cpp index 3d9efa3..42a57df 100644 --- a/gui/gtk_canvas.cpp +++ b/gui/gtk_canvas.cpp @@ -271,7 +271,7 @@ gnash_canvas_setup(GnashCanvas *canvas, std::string hwaccel, // Set the hardware acclerator to the next one to try // if initializing fails. next_hwaccel = xv; -} +} else #endif #ifdef RENDERER_AGG #ifdef HAVE_XV -- 1.7.0.4 ___ Gnash-dev mailing list Gnash-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnash-dev
Re: [Gnash-dev] vaapi update
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 modify my version check. Currently I look for ffmpeg revno 52.45.0, and it it's newer than that, vaapi configure support is enabled when using ffmpeg. Please check for the file, not for a specific FFmpeg version. ;-) ___ Gnash-dev mailing list Gnash-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnash-dev
[Gnash-dev] [PATCH] Drop wrong VA-API driver check
Hi,
This check is totally useless beyond being wrong. Never use driver
implementation details from an application. If you really want to query
the driver string, use vaQueryVendorString() after having initialized a
VA-API driver. Besides, this check just disabled any other driver (Intel,
ATI, 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 May 2010 08:36:33 +
Subject: [PATCH 4/4] Drop wrong VA driver name check/hack.
---
gui/gtk.cpp | 24 +++-
1 files changed, 3 insertions(+), 21 deletions(-)
diff --git a/gui/gtk.cpp b/gui/gtk.cpp
index 75640cf..e6bb6ba 100644
--- a/gui/gtk.cpp
+++ b/gui/gtk.cpp
@@ -37,14 +37,13 @@
#include gnash.h // Quality
#include iostream
+
#ifdef HAVE_VA_VA_H
-#include va/va.h
-#include va/va_backend.h
+#include va/va.h
#include vaapi_utils.h
#endif
-
#ifdef HAVE_VA_VA_X11_H
-#include va/va_x11.h
+#include va/va_x11.h
#endif
#ifdef HAVE_X11
@@ -259,23 +258,6 @@ GtkGui::init(int argc, char **argv[])
}
}
-#ifdef HAVE_VA_VA_X11_H
-if (hwaccel == vaapi) {
-char *driver_name;
-struct VADisplayContext *pDisplayContext = (struct VADisplayContext *)vaGetDisplay(GDK_DISPLAY());
-
-if (pDisplayContext-vaGetDriverName(pDisplayContext, driver_name) == 0) {
-if ((strcmp(driver_name, nvidia ) == 0) || (strcmp(driver_name, vdpau ) == 0) || (strcmp(driver_name, s3g ) == 0)) {
-log_debug(Found supported vaapi driver for %s, driver_name);
-} else {
-log_error(No vaapi driver found for %s!, driver_name);
-}
-} else {
-log_error(Couldn't get the VAAPI driver name!);
-}
-}
-#endif
-
#ifdef BUILD_CANVAS
_canvas = gnash_canvas_new();
gnash_canvas_setup(GNASH_CANVAS(_canvas), hwaccel, renderer, argc, argv);
--
1.7.0.4
___
Gnash-dev mailing list
Gnash-dev@gnu.org
http://lists.gnu.org/mailman/listinfo/gnash-dev
Re: [Gnash-dev] Hardware acceleration support
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 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 implement? Now that it's easy to use OpenGL as the renderer, I've noticed it's definitely far from correct when rendering animations. Some things never even appear at all. Actually, the changes I made for VA-API in the OGL renderer did fix some things for the generic case too. I think similar fixes are needed for the Bitmap_info* renderers. IIRC, this was related to the way textures were rendered. Hence, this now works correctly for video but it's still broken for usual animations. BTW, now that Cairo has a modern OpenGL renderer, I think I would favor work on the Cairo backend. There is also the YouTube issue with scaling when using Xv, but works without Xv fine. More details om this in: https://savannah.gnu.org/bugs/?25766. My assumption would be other video sites suffer from the same problem. You can reproduce that one stand-alone. I will dig a previous mail of mine in this thread and add it to the bug. Basically, you can use the - s and -j/-k options to get the same behaviour. If we are talking of the same bugs, this is a generic Gnash one (movie_root, Renderer_agg, gui), not Xv specific. Actually, the way the Xv backend intended to do things exposed the Gnash bugs. I see two possible fixes for the scaling bug but I am not satisfied and I more worried about the pointer coords translation problem. So anyway, sorry, I didn't test with your patch, things are different now in that code. :-) Does Haiku support vaapi ? They would need drivers first. ;-)___ Gnash-dev mailing list Gnash-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnash-dev
Re: [Gnash-dev] Hardware acceleration support
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 OpenGL really helping that much, so my guess is with Cairo on top of OpenGL, we won't notice any difference in performance. I have the opposite experience. CPU usage is pretty low with the OpenGL renderer (30%) vs. 60+% with AGG. What I implied is I will try to track the remaining problem with OpenGL but if this consumes me too much time, I would just stick to Cairo. ___ Gnash-dev mailing list Gnash-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnash-dev
Re: [Gnash-dev] feature enhancement
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 (or a one-liner). So Gnash virtually already supports the Crystal HD decoder if the plug-in is working. ;-) ___ Gnash-dev mailing list Gnash-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnash-dev
Re: [Gnash-dev] Hardware acceleration support
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 that result yet. The idea is that if somebody did have DRI and GLX enabled, we'd probably want to use it. There are two problems with this check: 1) NVIDIA does not implement DRI, so this won't be reported in the extensions list. 2) I don't understand your comment for not releasing memory returned by XListExtensions(). X provides XFreeExtensionList() and this should be used. Besides, why not use XQueryExtension()? BTW, the check for VA-API drivers below DRI/GLX check is also wrong but fortunately, the macro used to enable the check is wrong too, so this is not compiled in. ;-) Anyway, I will write a VaapiDriverInfo class instead since there are some things I want to check and optimize the rendering process based on the driver capabilities (and version). Regards, Gwenole. ___ Gnash-dev mailing list Gnash-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnash-dev
Re: [Gnash-dev] Hardware acceleration support
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 irrelevant. Their only fear for not including VA-API was because the G45 driver *is* *fully* Open Source and they don't want to ship implementations for non-free codecs. If the driver was proprietary, libva would probably be included already... This probably means they won't be shipping with Gnash either, anyway. Or any other media player or multimedia framework (e.g. GStreamer) because this is a trap to use non-free codecs, isn't it? Besides, why is Gnash supporting H.264 codecs then? Why not just remove H.264 support from Gnash since it's non-free? And why not even remove the whole code since the whole x86 architecture (x86 Alliance) is an Intel trojan horse to get proprietary software included in your free ecosystem? You wouldn't be left with many choices but probably some SPARC implementations. And that half the work was done by Gwenole, presumably under contract to Intel. Don't presume anything. There is no such thing. We don't even have *any* business with Intel, at all. We would have been pleased, though. But as a young company, it's not simple to get and see large companies and ask them for restricted secret information right away to implement our solutions more efficiently, especially since the company had no history. ;-) In the ideal world, we would have chosen Intel and NVIDIA solutions. Yeah, probably another trojan horse you would say. What progress (toward freedom and extensibility) has happened since then? Acceptable extensions for alternative codecs were proposed. They were positively received but not integrated since there is no implementation. We didn't see input from you though. You appear to know how to design an API suitable for any future codec the mankind could think of, your help would be much appreciated. Gwenole, you recommended that we wait through 2009 for more secret stuff to get released; did that happen? The GMA500 driver will remain closed source. The G45 driver is free. If you count the number of chips around, the G45 driver is to be considered the main driver available. i.e. the Intel IGP, even integrated to the CPU nowadays, is the dominant player now. And the VA-API driver for it is free. Hopefully, the H.264 decoder would be released soon. The new target is expected to be Q2, this year. If this was that simple, this would already be available and even available to other chips, isn't it? ___ Gnash-dev mailing list Gnash-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnash-dev
Re: [Gnash-dev] Hardware acceleration support
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 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... It depends on what you indend and what it actually does. What behavior are you seeing? Try e.g. the JW's player (flvplayer.swf). $ gnash -r agg --hwaccel xv -s 2 flvplayer.swf available here as a convenience: http://www.splitted-desktop.com/~gbeauchesne/gnash-vaapi/samples/ This causes two things: 1) setStageScaleMode() to noScale thus stage coords are wrong and not scaled down to the actual stage size. Check mouse coords with -vv. 2) Viewport is changed to 2x size (why not) but the renderer scale is still set to 1.0. Thus, we are rendering the upper left quarter only. Note however that for regular animations, like bloxorz.swf, we have the correct expected result in both cases. (2) looks simple to fix to me, I foresee two possible fixes. I don't understand (1) yet. Do you have any ideas? Since I found inspiration for VA-API in the Xv code, this means --hwaccel vaapi has the same problem. Thanks, Gwenole. ___ Gnash-dev mailing list Gnash-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnash-dev
Re: [Gnash-dev] Hardware acceleration support
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 you don't need to have RENDER x HWACCEL build trees. This saves compilation time of my poor system. Thanks. ;-) BTW, it's worth mentioning a remaining problem with --hwaccel vaapi. Some UI elements don't overlay correctly. e.g. pause/unpause a video with JW's player. The VA-API part is correctly implemented with VA subpictures. The problem is in the AGG part. Either my renderEmptyVideo() is wrong, or AGG doesn't get it right. In theory, I just want AGG to generate whatever RGBA pixel making sure the alpha component is zero. AGG decides otherwise and generates me a fully opaque pixel (0xff alpha and low R/G/B components, 0x11 or 0x08 IIRC). If someone has an idea... Thanks, Gwenole. ___ Gnash-dev mailing list Gnash-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnash-dev
Re: [Gnash-dev] Hardware acceleration support
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 libvaapi at the top-level because you would run into weird dependency problems otherwise. libmedia, libbase, librender all require libvaapi. Regards, Gwenole. ___ Gnash-dev mailing list Gnash-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnash-dev
Re: [Gnash-dev] Hardware acceleration support
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 only. I swore vengeance on anyone who reintroduces either a circular dependency or any sort of dependency for libbase when I removed this problem a few weeks ago, and I meant it! The 'hwaccel' branch was created many weeks ago so vengeance was not possible at this time. ;-) ___ Gnash-dev mailing list Gnash-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnash-dev
[Gnash-dev] [PATCH][hwaccel] Fix VA-API configure summary
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/configure.ac
index b11cb00..bb90489 100644
--- a/configure.ac
+++ b/configure.ac
@@ -2661,12 +2661,12 @@ echo Renderers supported: ${add_renderer}
echo Media handler: $media_handler
if test x${build_vaapi} = xyes; then
echo Video Acceleration via libVA API support: yes
- if test x$use_vaapi_x11 = xyes; then
+ if test x$use_libva_x11 = xyes; then
echo Video Acceleration via libVA X11 API support: yes
else
echo Video Acceleration via libVA X11 API support: no
fi
- if test x$use_vaapi_glx = xyes; then
+ if test x$use_libva_glx = xyes; then
echo Video Acceleration via libVA OpenGL API support: yes
else
echo Video Acceleration via libVA OpenGL API support: no
@@ -3474,7 +3474,7 @@ if test x${build_vaapi} = xyes; then
echo LIBVA flags are: $LIBVA_CFLAGS
echo LIBVA libraries are: $LIBVA_LIBS
fi
- if test x$use_vaapi_x11 = xyes; then
+ if test x$use_libva_x11 = xyes; then
if test x${LIBVA_X11_CFLAGS} = xyes; then
echo LIBVA X11 flags are: default
else
@@ -3482,7 +3482,7 @@ if test x${build_vaapi} = xyes; then
echo LIBVA X11 libraries are: $LIBVA_X11_LIBS
fi
fi
- if test x$use_vaapi_glx = xyes; then
+ if test x$use_libva_glx = xyes; then
if test x${LIBVA_GLX_CFLAGS} = xyes; then
echo LIBVA GLXflags are: default
else
___
Gnash-dev mailing list
Gnash-dev@gnu.org
http://lists.gnu.org/mailman/listinfo/gnash-dev
Re: [Gnash-dev] Hardware acceleration support
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 that means on a fast enough CPU, VAAPI doesn't buy anything, so we'd probably want to disable it. I guess I had just assumed that a hardware decoding would be faster than software decoding, even with a dual-core. 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. Please point me to your samples so that I can check where the bottleneck is. I believe the clip was poorly encoded. Besides using HW video decode acceleration reduces power used since the CPU can run at lower frequency: 1 - 1.8 GHz vs. 2.7 GHz without HW acceleration. ___ Gnash-dev mailing list Gnash-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnash-dev
Re: [Gnash-dev] Hardware acceleration support
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 should stay top level then, plus we should move the Vaapi file in libbase. Well, I changed my mind, more specifically I reminded about something: libvaapi is linked against libva-x11 and/or libva-glx, and thus libX11 et al. So, it's probably better to have it separate. Anyway, libvaapi/ is not Gnash specific and the gnash namespace was a bad heritage from the older code. Regards, Gwenole. ___ Gnash-dev mailing list Gnash-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnash-dev
Re: [Gnash-dev] Hardware acceleration support
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 could drop our OpenGL renderer and rely on Cairo for crisp OpenGL rendering instead. Interesting, is this a real OpenGL renderer and not a simple renderer that calls glTexImage2D() only? 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 will check it out later. Regards, Gwenole. ___ Gnash-dev mailing list Gnash-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnash-dev
Re: [Gnash-dev] Hardware acceleration support
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 // indent-tabs-mode: nil ___ Gnash-dev mailing list Gnash-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnash-dev
Re: [Gnash-dev] Hardware acceleration support
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 draw whenever we choose. OK, I git pull'ed my cairo tree. We will need a cairo_gl_surface_create_from_texture() to bind a (ours) GL texture o a Cairo/GL surface then make it possible to use Cairo drawing functions to draw that texture into another Cairo/GL FBO. For VA-API, we can transfer the decoded video surface to an OpenGL texture. This is fine, but how could we inject it into the current Cairo drawing pipeline? Reading pixels from the GL texture is not an option. So, we need a means to draw our own textures into the cairo_gl_surface FBO. My idea is to add a cairo_gl_surface_create_from_texture() to Cairo/GL or a cairo_gl_surface_draw_texture() function. It seems cairo-gl-surface.c already has the necessary code to draw foreign cairo_gl_surface into the current one. ___ Gnash-dev mailing list Gnash-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnash-dev
Re: [Gnash-dev] Hardware acceleration support
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, I obviously broke something. All I get now is a blank grey box. The changes for switching renderers is separate from the VAAPI code, even though they're in the same branch. 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. ** (lt-gtk-gnash:14386): WARNING **: This systms lacks a hardware OpenGL driver! (lt-gtk-gnash:14386): GtkGLExt-CRITICAL **: gtk_widget_set_gl_capability: assertion `!GTK_WIDGET_REALIZED (widget)' failed [...] ___ Gnash-dev mailing list Gnash-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnash-dev
[PATCH][hwaccel] Drop duplicates (Was: [Gnash-dev] Hardware acceleration support)
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 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 index 604ba77..5da63b7 100644 --- a/libvaapi/vaapi_utils.h +++ b/libvaapi/vaapi_utils.h @@ -30,12 +30,6 @@ void DSOEXPORT vaapi_set_is_enabled(bool enabled); /// Check whether video acceleration is enabled bool DSOEXPORT vaapi_is_enabled(); -/// Enable video acceleration (with VA API) -void DSOEXPORT vaapi_set_is_enabled(bool enabled); - -/// Check whether video acceleration is enabled -bool DSOEXPORT vaapi_is_enabled(); - /// Debug output void DSOEXPORT vaapi_dprintf(const char *format, ...); ___ Gnash-dev mailing list Gnash-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnash-dev
Re: [Gnash-dev] Hardware acceleration support
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 some reason, I assume it's in how Gnash uses Cairo more than Cairo itself. But one of the main ideas behind the Cairo backend was that it was going to support both framebuffers and OpenGL, thereby freeing us from maintaining multiple renders like we do now. Yes, I also believe the Cairo backend is the future. However, aside of the performance problems, there also is a correctness problem. Currently, we have AGG Cairo OpenGL in correctness. Though Cairo being close to AGG. I myself don't know AGG and very little of Cairo, so we'd need to find someone with good Cairo-fu! ;-) BTW, Cairo also has an OpenVG renderer, which should be interesting for handheld devices. It's also very well optimized, so performance issues in Gnash would indeed be in the way it's used there. Regards, Gwenole. ___ Gnash-dev mailing list Gnash-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnash-dev
[Gnash-dev] [PATCH][hwaccel] Disable HW scaling in VA-API
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 with notify set to false before begin_display() .. and restore the old values at the end in end_display(). i.e. in GtkAggVaapiGlue::beforeRendering() and GtkAggVaapiGlue::render(). However, the next problem would be that translation from window coords to stage coords is incorrect too and the overall result is scaling working too good. i.e. large control bars for example: imagine you are scaling a 320x240 stage to 1280x1024. gnash.hwaccel.vaapi.nohwscaling.patch Description: Binary data ___ Gnash-dev mailing list Gnash-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnash-dev
[Gnash-dev] [PATCH][hwaccel] Fix SW fallback on VA-API initialization error
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 earlier. Regards, Gwenole. gnash.hwaccel.vaapi.sw.fallback.patch Description: Binary data ___ Gnash-dev mailing list Gnash-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnash-dev
[Gnash-dev] [PATCH][hwaccel] Add --no-hwaccel option
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 ___ Gnash-dev mailing list Gnash-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnash-dev
[Gnash-dev] [PATCH] Fix OpenGL renderer initialization
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, Gwenole. gnash.fix.opengl.patch Description: Binary data ___ Gnash-dev mailing list Gnash-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnash-dev
Re: [Gnash-dev] Hardware acceleration support
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 only accelerate nonfree codecs, Just a quick reply: where do you see free codecs in Flash that can benefit from HW acceleration? Do you really think Flash would ever support free codecs...? Do you really think there are free codecs competitive enough with H.264 to be used as a replacement? Currently, I strongly believe the answers to all of those is 'no' and I doubt this would change for Flash. Longer answer later. ___ Gnash-dev mailing list Gnash-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnash-dev
Re: [Gnash-dev] [PATCH] Fix build with libtool2
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)/ It seems this was a stupid local problem, but the patch remains valid. ;-) but that patch doesn't cure the same problem on cygwin and libtool 2.2.7. I receive always the same error: libtool: link: (cd .libs/libgnashbase.lax/libltdlc.a ppc-amigaos- ar x /cygdrive/d/DevCon2009/gnash/libbase/../libltdl/.libs/ libltdlc.a) ppc-amigaos-ar: /cygdrive/d/DevCon2009/gnash/libbase/../ libltdl/.libs/libltdlc.a: No such file or directory make[2]: *** [libgnashbase.la] Error 9 Then, you'd probably have to move up the endif so that the libltdl_la_LDFLAGS += -static portion is used no matter that you have libtool1 or libtool2? e.g. as in the attached patch? Regards, Gwenole. gnash.ltdl2.v2.patch Description: Binary data ___ Gnash-dev mailing list Gnash-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnash-dev
Re: [Gnash-dev] [PATCH] Fix build with libtool2
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 noinst_HEADERS are only available in the libltdl1 path. Is this expected? This also means you can't generate a correct make dist with libtool2. To be clearer, all noinst_HEADERS are in the libtool1 conditionals only. So, a make dist on a libtool2 system will not have the requested files. BTW, it's no longer possible to run gnash within the build-dir on trunk either. gtk-gnash complains that: error while loading shared libraries: libgnashbase.so.0: cannot open shared object file: No such file or directory which is true, there is no libgnashbase.so.0. The resulting gnash works with a make install but it's not really convenient. I will try to understand that tomorrow unless someone beats me. This happens because I built gnash in a different builddir than $ (top_srcdir)/. e.g. objs.vaapi-agg/ in the $(top_srcdir)/ How to reproduce: $ extract/clone gnash sources from trunk $ mkdir objs.agg $ cd objs.agg $ CXXFLAGS=-Os -g -pipe ../configure --enable-media=ffmpeg --enable- gui=gtk --enable-renderer=agg # or whatever confflags $ make -jN Then, $ ./gui/gtk-gnash will fail as I reported. However, if you build from the top-level directory, there won't be any problem. It worked before (on 0.8.6), on the same Ubuntu 9.04 system. So, this indeed looks like libtool changes. Regards, Gwenole. ___ Gnash-dev mailing list Gnash-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnash-dev
Re: [Gnash-dev] [PATCH] Call XInitThreads() in GtkGui::init() for the plug-in
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 version indeed calls XInitThreads() before gtk_init(). Regards, Gwenole. ___ Gnash-dev mailing list Gnash-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnash-dev
[Gnash-dev] [PATCH][OGL] Fix scaled window mode
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 ___ Gnash-dev mailing list Gnash-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnash-dev
[Gnash-dev] [PATCH][OGL] Fix draw_subshape() to disable environment mapping
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 Description: Binary data ___ Gnash-dev mailing list Gnash-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnash-dev
[Gnash-dev] [PATCH] Call XInitThreads() in GtkGui::init() for the plug-in
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: Binary data ___ Gnash-dev mailing list Gnash-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnash-dev
[Gnash-dev] [PATCH][OGL] Disable accumulation buffer based anti-aliasing
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? Regards, Gwenole. 0005-Disable-slow-anti-aliasing-code-with-the-accumulat.patch Description: Binary data ___ Gnash-dev mailing list Gnash-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnash-dev
Re: [Gnash-dev] Flash HD (H.264) video decoding acceleration
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 actually an Open Source implementation of HW video decode acceleration for G45... It seems that if there weren't any Open Source VA driver, libVA would have been accepted already. Ultimately, they decided to allow VDPAU into Fedora, but not VA API: https://fedorahosted.org/fesco/ticket/238 Sure, it was simpler to allow a lib to proprietary drivers and when there was an Open Source one, they feared about patents and such. ___ Gnash-dev mailing list Gnash-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnash-dev
Re: [Gnash-dev] Flash HD (H.264) video decoding acceleration
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 constraint.
The only option left to the community for those chips is to use the saders
and I doubt this will be as effective as the dedicated ASIC. That is,
there are no specs for AMD's UVD neither for NVIDIA's PureVideo circuits.
Intel is still working on the H.264 codec for G45. This one is completely
Open Source. The driver that is currently available is only limited to
MPEG-2 VLD at this time, and this is not very useful here.
Thank you for your early comments. I will address them and submit the
individual hunks instead. The original patch was only generated with a
git diff origin master for a rough overview.
+GnashTexture::GnashTexture(unsigned int width, unsigned int height,
ImageType type)
+: _width(width), _height(height), _texture(0), _format(type),
_flags(0)
+{
+D(bug(GnashTexture::GnashTexture()\n));
+
+init();
+}
And what of init()'s return value?
The longer term was to throw exceptions but I have not yet reviewed the
current practises. e.g. who will/should catch the exception and how to
handle it.
+struct TextureState {
+ unsigned intold_texture;
+ unsigned intwas_enabled : 1;
+ unsigned intwas_bound : 1;
+} _texture_state;
Do performance numbers indicate that bitfields should be preferred over
clarity (i.e., using bool) here?
To be honest, this should not make any difference. Actually, this was a
raw copy of some other code I wrote.
For sending future patches, it would be nice to have the VA API patch
seperate from other bugfixes.
Yes, of course. Most of the VA API additions now even live in their
specific directory.
Regards,
Gwenole.
___
Gnash-dev mailing list
Gnash-dev@gnu.org
http://lists.gnu.org/mailman/listinfo/gnash-dev
Re: [Gnash-dev] Flash HD (H.264) video decoding acceleration
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 weren't thinking much about free
formats -- which is a red flag.
I had asked some Intel people about other formats. The main reason was
only broadly accepted and standard formats are available on silicon.
Even VP6 did not match their criteria. Besides, the people who
designed the API worked with existing HW implementations, not with
hypothetical and future implementations.
But Gwenole's adapter also doesn't support anything but full decoding,
and doesn't support any free video formats. He also has a VA API
to XvBA adapter, but it's proprietary (it sits behind a password-
wall).
I will implement MPEG-2 MoComp and iDCT paths when I understand how
this works and how I can manage to get this accepted through the
FFmpeg AVHWAccel infrastructure.
Younes Manton is doing generic GPU-accelerated video decoding, which
started as his Google Summer of Code project. He's using mplayer and
the XvMC interface. But he's doing it right -- he's accelerating the
low layers (motion compensation) first, then working up to the higher
layers (inverse DCT). He's been looking at VDPAU too. Gwenole, you
could probably slap a VA API front end onto his code, which would make
the first free VA API implementation that does the low layers
One of my plans was to actually write an XvMC backend to VA-API. ;-)
(and it
would speed up NVidia video playback all in free software, and give
you clues about how to do that for the Intel chips). If the mplayer
or gstreamer VA API interface would call these layers (the way the
mplayer XvMC interface currently does), this would provide
acceleration for codecs that aren't fully decoded -- like all the ones
Gnash cares about.
I am not sure to fully understand what you mean but I will think again
about it tomorrow or over this night. Isn't Gnash/Flash limited to VP6
and H.264? How would MPEG-2 MoComp/iDCT support help Gnash?
Gwenole, if you're interested in pushing VA API further into the free
software community, get Intel to explain why its main released VA API
driver is proprietary -- and how and when they're going to replace
that with free software.
Are you talking about the Poulsbo driver? If I were to do some
reasoning based on public information and thus without being tainted
by privileged information, I would say: there could have been
something available by Q4 2009. However, it's questionnable as to what
form this would take and what precise chipset (current or future) this
would be available for. I would also say GMA500, more precisely VXD370
in current or future chips, is not in-house Intel technology. However,
their recent raise in stocks in ImgTech was probably a sign to {,be
allowed to} do something but Apple also raised their stocks
significantly afterwards, thus probably inhibiting some actions?
Nobody can really know or talk about anything related to that, I am
afraid. Doing so would only feed bad or good rumors. Of course, my
interpretations of facts I exposed here are probably not the reality.
For sure, we can only wait for Q4 (the whole 3 months) and see what
actually happens.
BTW, the G45 VA driver is fully Open Source right now because this is
Intel technology in a whole, unlike US15W.
Regards,
Gwenole.
___
Gnash-dev mailing list
Gnash-dev@gnu.org
http://lists.gnu.org/mailman/listinfo/gnash-dev
[Gnash-dev] VA API support
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 only one Open Source implementation at this time. Another one, with more codecs, should emerge by Q4 2009. VA API, as other video decoding acceleration API on Linux (and on other proprietary OS), is actually a decode+display API. That is, decoded frames reside in GPU memory and are to be displayed from there. There are interfaces to get the pixels back (vaGetImage()) but it's suboptimal. To make things worse, Flash requires RGB24 format so an extra color space conversion is required. Shouldn't this conversion be necessary, the vaGetImage() approach can be bearable, as VLC devs shown. A 1080p H.264 video can be decoded+vaGetImage()'ed with 30% CPU load, whereas a direct display with vaPutSurface() would make it less than 1%. Pure SW decoding, with Xv output, leads to 80% CPU load. The CPU was a dual core Opteron. The current approach, HW decoding + reading pixels back + converting to RGB24, is obviously too slow to be profitable. A quick test with this video (720x576) http://samples.mplayerhq.hu/V-codecs/h264/NeroAVC.mp4 Gnash was built with Gtk GUI and AGG renderer. Average CPU load 35%. Of which, top players were: 9107 20.5645 (no location information) no-vmlinux no-vmlinux (no symbols) 8281 18.6993 (no location information) [vdso] (tgid:6492 range:0xe000-0xf000) gtk-gnash(no symbols) 6712 15.1564 agg_span_image_filter_rgb.h:122 gtk-gnashgtk-gnash agg::span_image_filter_rgb_bilinearagg::image_accessor_cloneagg::pixfmt_alpha_blend_rgbagg::blender_rgb_preagg::rgba8, agg::order_rgb, agg::row_accessorunsigned char , agg::span_interpolator_linearagg::trans_affine, 8u ::generate(agg::rgba8*, int, int, unsigned int) 5618 12.6860 (no location information) libswscale.so.0.7.1 gtk-gnash(no symbols) 1424 3.2155 agg_renderer_scanline.h:163 gtk-gnashgtk-gnashvoid agg::render_scanline_aaagg::scanline_u8_amagg::alpha_mask_u81u, 0u, agg::one_component_mask_u8 , agg::renderer_baseagg::pixfmt_alpha_blend_rgbaagg::blender_rgba_preagg::rgba8, agg::order_bgra, agg::row_accessorunsigned char, unsigned int , agg::span_allocatoragg::rgba8, agg::span_image_filter_rgb_bilinearagg::image_accessor_cloneagg::pixfmt_alpha_blend_rgbagg::blender_rgb_preagg::rgba8, agg::order_rgb, agg::row_accessorunsigned char , agg::span_interpolator_linearagg::trans_affine, 8u (agg::scanline_u8_amagg::alpha_mask_u81u, 0u, agg::one_component_mask_u8 const, agg::renderer_baseagg::pixfmt_alpha_blend_rgbaagg::blender_rgba_preagg::rgba8, agg::order_bgra, agg::row_accessorunsigned char, unsigned int , agg::span_allocatoragg::rgba8, agg::span_image_filter_rgb_bilinearagg::image_accessor_cloneagg::pixfmt_alpha_blend_rgbagg::blender_rgb_preagg::rgba8, agg::order_rgb, agg::row_accessorunsigned char , agg::span_interpolator_linearagg::trans_affine, 8u ) The first two are likely sleep functions. IMHO, the most efficient way to use HW video decode acceleration through an OpenGL renderer. It's possible to instruct the video decoder to render to an OpenGL texture, either indirectly through the texture-from-pixmap extension or directly. However, this would require more changes to Gnash. e.g. manipulating video objects with a GL texture id instead of transporting the decoded frames bytes (GnashImage). Regards, Gwenole.___ Gnash-dev mailing list Gnash-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnash-dev
Re: [Gnash-dev] VDPAU Support
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. ___ Gnash-dev mailing list Gnash-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnash-dev
