And here's the demonstration video to make things clearer:
http://jeff.ecchi.ca/public/gstreamer-721148.webm

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.

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.

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.

Created attachment 264977 [details] [review]
test case

Proves my point :)

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.

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)

(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 ?

(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

(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.

*** Bug 736130 has been marked as a duplicate of this bug. ***

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?

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"

Created attachment 290618 [details]
GTK Clutter - GST Clutter test-case

I have simplified the initialization calling just clutter_gst_init

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.

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)

-- 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.