After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 354946 - Make playbin use glsink when compositing is on
Make playbin use glsink when compositing is on
Status: RESOLVED OBSOLETE
Product: totem
Classification: Core
Component: GStreamer backend
unspecified
Other Linux
: Normal normal
: ---
Assigned To: Maintainer alias for GStreamer component of Totem
Maintainer alias for GStreamer component of Totem
Depends on: 357212
Blocks:
 
 
Reported: 2006-09-08 10:51 UTC by Bastien Nocera
Modified: 2009-11-16 14:17 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description Bastien Nocera 2006-09-08 10:51:56 UTC
When the Composite extension is turned on, and a compositing manager used, Xv emulation is usually poor. See the details at:
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=200270

It would be nice for playbin to automatically use the OpenGL sink when the screen is using a compositing manager. It can be detected using GTK+ 2.10's gdk_screen_is_composited, or by checking for the EWMH hints, _NET_WM_CM_S0 (or _NET_WM_CM_S1, etc.).

This would also mean moving the GL sink to -good (is there another bug opened for that?).
Comment 1 René Stadler 2006-09-08 14:14:45 UTC
Such detection magic does not belong in playbin.  Note that it has a property named "video-sink".  If left on default, it uses the autovideosink element, which in turn usually prefers xvimagesink.

GTK+/GNOME apps seem to be supposed to set the video sink used by playbin to an instance of the gconfvideosink element, which will use the videosink configured by the system vendor (changeable using gstreamer-properties).
Comment 2 Bastien Nocera 2006-09-09 23:56:23 UTC
Good point, let me reassign this to Totem, so that the GStreamer backend of Totem can implement such magic.
Comment 3 René Stadler 2006-09-10 04:28:53 UTC
Examining the backend code, one finds out that it already implements this in the way I lined out.  This isn't surprising since the backend seems to have been written by GStreamer developers in its entirety.

Using gstreamer-properties to set the videosink to glimagesink should therefore work, as far as totem is concerned.
Comment 4 Bastien Nocera 2006-09-10 11:03:43 UTC
The problem is that the users shouldn't have to set this up themselves, it should be automatic. Right now, Totem is X specific (and might still be for a while), so hard-coding the Xv sink, the Xshm sink, or the OpenGL one is what should be done, and not having to rely on users doing this.
Comment 5 Tim-Philipp Müller 2006-09-10 12:10:31 UTC
I agree, this should be made to work automagically in totem/playbin/autovideosink via the plugin ranks. xvimagesink/glimagesink could set/adjust their own ranks according to their surroundings so that glimagesink has a slightly higher rank in a composited environment for example.

This would most certainly require getting glimagesink into shape and moved into -good first, the requirements/guidelines for that can be found here:

http://webcvs.freedesktop.org/gstreamer/gstreamer/docs/random/moving-plugins?view=markup

IIRC (and I may not), last time I tried glimagesink it took my X server down (standard Dapper Xorg with ancient ATI card), so that needs working on. Also, glimagesink doesn't seem to support navigation events, that needs fixing too.
Comment 6 René Stadler 2006-09-10 13:39:26 UTC
Tim: While you mention totem and playbin, note that they have nothing to do with it.  Applications are correct with using gconfvideosink and autovideosink as a fallback.  If the vendor doesn't know/care what sink to configure the system to, the gconf setting says autovideosink anyways.

I still blame system vendors: If XVideo is broken so badly in these environments that it should not be used, why is it provided anyways?

Bastien: How can hardcoding a fixed set of sinks into an application ever be right?  Even if this would be the case, it would needed to be done for every single gst-based video application.  And then again if something new comes up.

I never said users (should) need to manually adjust the used video sink with gstreamer-properties.  It's just the method for overriding the system's configured default sink.  If a user turns on compositing manually by editing a system configuration file, adjusting the video sink selection this way is really no big deal.  If the vendor provides compositing out of the box/an easy way to switch to it, changing the setting is no big deal either and should be done.

There is no promise that in the future, there can't be better Xvideo implementations together with compositing.  Otherwise, it should not be provided at all then, right?  Neither way justifies modifying xvimagesink (or single applications for that matter).  Tim's solution makes more sense.  Bug should go back to GStreamer and change summary to something like "[glimagesink] Increase rank in compositing environment".
Comment 7 David Schleef 2006-09-23 00:07:20 UTC
GStreamer doesn't do dynamic ranking (yet).  The main hurdle is that it requires loading a plugin and testing an element out in its environment.  In this case, it means testing the glimagesink element with a given value of DISPLAY and/or the display= property.
Comment 8 Michael Monreal 2008-07-25 13:35:49 UTC
I came here because of a bug¹ I filed against totem in openSUSE 11.0. Totem just crashes for me all the time. I don't really see how this is related to this upstream bug but is there a way for me to narrow down the bug?

[1] https://bugzilla.novell.com/show_bug.cgi?id=407921
Comment 9 Bastien Nocera 2009-11-16 14:17:36 UTC
Closing this. With a decent video driver, using the Xv video sink works just fine nowadays, even when using gnome-shell or compiz.