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 721148 - ximagesink/xvimagesink: Does not render on windows with RGBA visuals
ximagesink/xvimagesink: Does not render on windows with RGBA visuals
Status: RESOLVED OBSOLETE
Product: GStreamer
Classification: Platform
Component: gst-plugins-base
1.8.3
Other Linux
: Normal major
: git master
Assigned To: GStreamer Maintainers
GStreamer Maintainers
: 736130 (view as bug list)
Depends on:
Blocks: 708375
 
 
Reported: 2013-12-28 05:16 UTC by Jean-François Fortin Tam
Modified: 2018-11-03 11:27 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
test case (1.18 KB, patch)
2013-12-28 17:49 UTC, Jean-François Fortin Tam
none Details | Review
GTK Clutter - GST Clutter test-case (2.09 KB, application/octet-stream)
2014-11-13 08:48 UTC, Álvaro Peña
  Details
GTK Clutter - GST Clutter test-case (1.75 KB, application/octet-stream)
2014-11-13 09:49 UTC, Álvaro Peña
  Details

Description Jean-François Fortin Tam 2013-12-28 05:16:56 UTC
As part of bug #708375, I have a branch of Pitivi where I replace the menubar and toolbar by a unified set of client-side window decorations. If you're curious about that code, you can look at the last few commits here: https://github.com/nekohayo/pitivi/commits/headerbar

I'll spare you the trouble of figuring out why that commit, which has nothing to do with sinks or anything in Pitivi's "viewer.py", causes the internal Pitivi viewer to display a black image instead of the video frames, even though my window does give a proper xid to set as the handler for it etc.

Here is the line that causes video overlay to fail:

    self.set_titlebar(self._headerbar)

If you comment out that line (gtk_window_set_titlebar), everything works.
Comment 1 Jean-François Fortin Tam 2013-12-28 05:19:53 UTC
And here's the demonstration video to make things clearer:
http://jeff.ecchi.ca/public/gstreamer-721148.webm
Comment 2 Tim-Philipp Müller 2013-12-28 13:09:56 UTC
Can you make a small self-contained test program (python is fine)?

Likely you're not telling gtk to create a native window for one of your windows, or call _get_xid() too late. See GstVideoOverlay documentation.
Comment 3 Jean-François Fortin Tam 2013-12-28 15:29:02 UTC
Before I embark on basically rewriting a gui with a viewer widget,
I should point this out:

https://git.gnome.org/browse/pitivi/tree/pitivi/viewer.py#n500

Pitivi currently waits for the target widget's "realized" event callback before setting the xid and exposing the sink. The GstVideoOverlay documentation does not actually cover this (newer?) approach and still promotes the use of a sync bus message handler.

I trust the current code to be "correct" in this regard (given that it worked perfectly until now, until I changed *one* line of code that enables client-side decorations), and expect Nicolas to have known what he was doing with this:

https://git.gnome.org/browse/pitivi/commit/?id=a0a21e6
https://git.gnome.org/browse/pitivi/commit/?id=c07dc1b

And, well... "native" window? I'm not sure what you mean; everything is straight gtk here, the only difference is whether I tell the gtk window to set_titlebar or not.
Comment 4 Tim-Philipp Müller 2013-12-28 16:34:17 UTC
I prefer to just debug things instead of trusting code to be correct or that someone knew what they were doing, but suit yourself. Making a minimal test case is a good way to eliminate unexpected side-effects. Using your line of reasoning one could point out that seeing that not a single line was changed in GStreamer and it worked before, the bug must clearly be elsewhere ;) In any case, someone else with a pitivi checkout will have to debug this in absence of a test case.
Comment 5 Jean-François Fortin Tam 2013-12-28 17:49:24 UTC
Created attachment 264977 [details] [review]
test case

Proves my point :)
Comment 6 Paolo Bacchilega 2014-01-04 21:18:04 UTC
Hey, 

I just read about this bug on Planet GNOME :)  I had a similar problem when I added an GtkHeaderBar to gThumb and I fixed it setting the default visual for the drawing area (instead of using and RGBA visual, which is set automatically if a header bar is used).

Try to change the test case this way:

GdkVisual *visual;
visual = gdk_screen_get_system_visual (gtk_widget_get_screen (video_window);
if (visual != NULL)
  gtk_widget_set_visual (GTK_WIDGET (video_window), visual);

where video_window is the drawing area used to show the video.
Comment 7 Jean-François Fortin Tam 2014-01-11 18:44:17 UTC
My guess is that this situation should be handled automatically by gst/videooverlay, not sure applications should have to add this workaround*.

And if headerbar sets a RGBA visual, there must be a good reason no?



*: For what it's worth, I played a bit to try to translate your workaround
   in Python, but I probably did it incorrectly as it did not solve the issue
   on my end, the overlay stays black:

  system_visual = the_gtkdrawable_widget.get_screen().get_system_visual()
  if system_visual:
      the_gtkdrawable_widget.set_visual(system_visual)
Comment 8 Nicolas Dufresne (ndufresne) 2014-01-11 19:52:03 UTC
(In reply to comment #7)
> My guess is that this situation should be handled automatically by
> gst/videooverlay, not sure applications should have to add this workaround*.
> 
> And if headerbar sets a RGBA visual, there must be a good reason no?

Rounded corners. I'm surprise that video-overlay fails inside an RGBA visual, would need investigation about why. Maybe for PiTiVi it's time to switch to cluttersink ?
Comment 9 Paolo Bacchilega 2014-01-11 21:16:25 UTC
(In reply to comment #7)
> My guess is that this situation should be handled automatically by
> gst/videooverlay, not sure applications should have to add this workaround*.
> 
> And if headerbar sets a RGBA visual, there must be a good reason no?
> 
> 

I guess it is used for the window drop shadow effect
Comment 10 Sebastian Dröge (slomo) 2014-01-12 09:35:13 UTC
(In reply to comment #7)
> My guess is that this situation should be handled automatically by
> gst/videooverlay, not sure applications should have to add this workaround*.

Note that GstVideoOverlay is just a stupid interface without any actual logic ;)

Some more observations here: xvimagesink and ximagesink fail this way. But glimagesink and eglglessink don't. Although they require the exact same XID and just do the rendering differently. So the problem here is maybe that ximagesink/xvimagesink need some different code path for RGBA visuals than for RGB visuals.
Comment 11 Tim-Philipp Müller 2014-10-06 13:10:12 UTC
*** Bug 736130 has been marked as a duplicate of this bug. ***
Comment 12 Álvaro Peña 2014-11-13 08:47:26 UTC
I have experimented some similar issues with cluttersink when using more than one GtkClutterEmbed with client-side decorations.

Looking in depth I have found that the problem is not really in the cluttersink but in something that take place in the clutter_gst_init. I have created an example in C when you can play with the error (attached).

Do you think that it's the same "bug" or must I create a new one?
Comment 13 Álvaro Peña 2014-11-13 08:48:32 UTC
Created attachment 290610 [details]
GTK Clutter - GST Clutter test-case

You can compile with "gcc test-gtk-clutter.c `pkg-config --cflags --libs gtk+-3.0 clutter-gtk-1.0 clutter-gst-1.0` -o test-gtk-clutter"
Comment 14 Álvaro Peña 2014-11-13 09:49:57 UTC
Created attachment 290618 [details]
GTK Clutter - GST Clutter test-case

I have simplified the initialization calling just clutter_gst_init
Comment 15 Nicolas Dufresne (ndufresne) 2015-08-13 01:54:51 UTC
Clutter has no place in this bug obviously. Looking at this, I notice that we don't update the visual to what the window uses. I need to look what else need updating, but basically we keep the default visual, ignoring the window visual completely. That explains why it works when the default visual is RGBA.
Comment 16 Tobias Mueller 2017-01-07 20:13:37 UTC
FWIW: The workaround mentioned in comment 6 works for me:

        visual = Gdk.Screen.get_system_visual(self.get_screen())
        if visual:
            self.set_visual(visual)
Comment 17 GStreamer system administrator 2018-11-03 11:27:28 UTC
-- GitLab Migration Automatic Message --

This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity.

You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/gstreamer/gst-plugins-base/issues/100.