GNOME Bugzilla – Bug 674083
Use autocluttersink
Last modified: 2012-05-30 08:43:29 UTC
it would allow Totem to automatically use the VAAPI enabled cluttersink from Fluendo.
It should be noted that this is at best an issue for 0.10 and shouldn't be needed any more for 0.11/1.0
See also: http://thread.gmane.org/gmane.comp.video.gstreamer.devel/37805
(In reply to comment #1) > It should be noted that this is at best an issue for 0.10 and shouldn't be > needed any more for 0.11/1.0 How come?
Well, perhaps I'm missing something, but in an ideal world everyone would just use the recently-added API extensions for this stuff (GstVideoContext, GstSurfaceBuffer, GstSurfaceConverter), which clutter-gst supports now and which is still in gst-plugins-bad/gst-libs until at least some other implementation than gst-vaapi is using it as well (e.g. vdpau or Fluendo's plugins). I don't think there's a technical reason why third party plugin vendors couldn't move to that API if they were so inclined. The whole autocluttersink thing is just a stopgap solution to avoid all that. In 1.0 there should just be proper API for this from the start (-ish), and that's that then.
I can see that there are APIs to cover the sinks, but how would one select a sink (eg. what do I replace the gst_clutter_sink_new() with?).
In that case you wouldn't have to replace it with anything, it would just handle everything for everyone out of the box.
Well as you said this is useful for 0.10 which is still what is stable and being shipped for now. So I don't think it would hurt much to use an autoplugger for the clutter sink (as we always did in the past with autovideosink) and that would bring a lot of flexibility. I am not a big fan of the "being strict and force everyone to go my way" approach as GStreamer has always been intended to be a flexible framework. So as this autoplugger is now provided by Clutter and this will allow flexibility for 0.10/1.0 migration while allowing hardware vendors to provide their clutter accelerated plugins without being forced to migrate everything to 1.0, I think Totem should stop calling a clutter method instantiating a static GStreamer plugin and use the registry, at last. My 0.02 $ Julien
Either we have a Totem ported to GStreamer 1.0 by 3.6, or we'll used autocluttersink (provided the blocking bug gets fixed).
There was another problem. Josep mentioned that video balance needed to be disabled when we were testing. Is that still the case?
As far I know it needs to be removed from the custom bin (videobalance ! [auto]cluttersink) that Totem creates and provides to playbin2. If I'm not wrong there was recent changes on playbin2/playsink to autoplug the videobalance software element when needed. In any case I think that the right solution is to have videobalance interface exposed in cluttersink and have it implemented with a shader when uploading into the texture for video/x-raw-yuv caps and implemented in the converter for video/x-va caps, for example in VDPAU this can be achieved through the vdpVideoMixer. I'm not sure how to support it in VAAPI, maybe can also be handled in the converter or with a shader after conversion.
(In reply to comment #10) > As far I know it needs to be removed from the custom bin (videobalance ! > [auto]cluttersink) that Totem creates and provides to playbin2. > > If I'm not wrong there was recent changes on playbin2/playsink to autoplug the > videobalance software element when needed. I'm guessing that's the one: commit dfa508ffa1ec5031f62735372acf4e21c8c9cf86 Author: Sebastian Dröge <sebastian.droege@collabora.co.uk> Date: Wed Feb 22 11:56:59 2012 +0100 playsink: Add a software color-balance element before the sink if the sink doesn't support changing the color-balance > In any case I think that the right solution is to have videobalance interface > exposed in cluttersink and have it implemented with a shader when uploading > into the texture for video/x-raw-yuv caps and implemented in the converter for > video/x-va caps, for example in VDPAU this can be achieved through the > vdpVideoMixer. Certainly, but that doesn't mean that we have to regress right now.
commit fe0a1cdc7004e6d43590679808af806258c4ba71 Author: Bastien Nocera <hadess@hadess.net> Date: Fri Apr 27 17:25:44 2012 +0100 backend: Use autocluttersink And get free hardware decoding, using either gst-vaapi and Fluendo's hardware decoder plugins. https://bugzilla.gnome.org/show_bug.cgi?id=674083