Skip to content

glimagesink doesn't close the windows it created when going NULL => PLAYING => NULL

When a pipeline using glimagesink goes from NULL to PLAYING (or even READY I think) and then back to NULL, it doesn't free the window that has been automatically created (this doesn't apply when told to use an existing window obviously). This happens on both X and Wayland, using git master of gstreamer and gst-plugins-base. It exists since at least 1.12.

We've tried to fix the issue but were unable to do so after several days (and I don't think we're that bad). At first it looks like some objects are not unref'ed as they should but I've come to think that maybe this was on purpose.

I've looked for similar issues in the bug tracker and found several entries that seem to indicate that the amount of refs/unrefs in glimagesink might be problematic (both ways actually). This reinforces the feeling that the desired lifetime of some objects is not clear. In plugins-base: #560 , #533 , #502 , #308 . In plugins-bad: gst-plugins-bad#670 .

This leads to some questions:

  • can we get a confirmation that letting glimagesink automatically create a window is a usecase that is fully supported and expected to be used in real-world scenarios?
  • should that window be freed whengst_test.c the pipeline goes back to NULL or should it (and other resources) be kept for reuse?

I'm attaching a reproducer ( gst_test.c ) which can be compiled with gcc -Wall -Wextra -g3 -ggdb3 $(pkg-config --cflags gstreamer-1.0) gst_test.c $(pkg-config --libs gstreamer-1.0). It runs for two seconds and then sets the pipeline to NULL, at which point the window remains but is frozen (it doesn't even redraw upon expose or resize events).

PS: I've linked to #308 because I've found that when running under X, after the pipeline is back to NULL, calling XSync() (which merely flushes communication buffers and is called in one of the finalizers) is enough to get the window closed. Since the issue doesn't exist on 1.8, it occured to me that the transition from xlib to xcb might be related (without being the main issue).

Thanks.