# Trying to fix broken ( for \> 4 years) cocoa implementation of glimagesink on macOS
**URL:** https://discourse.gstreamer.org/t/trying-to-fix-broken-for-4-years-cocoa-implementation-of-glimagesink-on-macos/4600
**Category:** Plugin and library development
**Created:** [May 12, 2025, 8:37pm UTC](https://discourse.gstreamer.org/t/trying-to-fix-broken-for-4-years-cocoa-implementation-of-glimagesink-on-macos/4600 "2025-05-12T20:37:43Z")
**Posts on this page:** 4
**Page:** 1
### Author:  [@fduncanh](https://discourse.gstreamer.org/u/fduncanh)
#### Post date: [May 12, 2025, 8:37pm UTC](https://discourse.gstreamer.org/t/trying-to-fix-broken-for-4-years-cocoa-implementation-of-glimagesink-on-macos/4600/1 "2025-05-12T20:37:43Z")
the macOS glimagesink implementation is broken in that when it is not given a video window context (so it creates one itself), the window does not close when the EOS is sent and the pipeline GST\_STATE is set to NULL. Furthermore, the black empty gl window that remains unclosed causes a segfault if it is closed by clicking its close button.
- This error has been around unfixed for at least 4 years. Other people gave up, and used workarounds (unfortunately osxvideosink has a similar problem). **I think it is time to fix this** , and will put some effort into it, but would like some guidance.
Here are some of the the older reports
> **[gl: Cocoa window is never closed (#560) · Issues · GStreamer /...](https://gitlab.freedesktop.org/gstreamer/gst-plugins-base/-/issues/560)**
>
> More technical description GstGLWindowCocoa fails to close the window it creates. Reproduction steps Create a bunch of pipelines outputting...
> **[glimagesink doesn't close the windows it created when going NULL =\>...](https://gitlab.freedesktop.org/gstreamer/gst-plugins-base/-/issues/815)**
>
> 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...
> **[glimagesink doesn't close the windows it created when pipeline state is set...](https://gitlab.freedesktop.org/gstreamer/gst-plugins-base/-/issues/938)**
>
> if the OpenGL window created by glimagesink is open, closing and freeing the pipeline causes a segfault, if the underlying application is still running. (on MacOS...
The issue can’t be demonstrated with gst-launch-1.0 because that de-initializes gstreamer when eos arrives, but I will eventually write a small demo, with a main\_loop and bus messages, that remains open after eos, and then reopen as a Issue. _EDIT: the earliest of the above reports has a demo:_
[https://gitlab.freedesktop.org/-/project/1352/uploads/ff39d4c1209ad7e130a5940cdbd50848/main.c](https://gitlab.freedesktop.org/-/project/1352/uploads/ff39d4c1209ad7e130a5940cdbd50848/main.c)
For our use case, it’s not practical to supply a window handle rather than let glimagesink create one itself because the macOS version of our app is a build of something that builds on linux/windows/\*BSD/macOS and can use all the different gstreamer videosinks, so relies on automatic window creation, and destruction, without closing the app before creating a new window.
Right now the initial exploration is comparing GST\_DEBUG=5 output differences of glimagesink between linux (working correctly) and macOS versions, and adding lots of printf statements in things like
> **[subprojects/gst-plugins-base/gst-libs/gst/gl/cocoa/gstglcontext\_cocoa.m · main...](https://gitlab.freedesktop.org/gstreamer/gstreamer/-/blob/main/subprojects/gst-plugins-base/gst-libs/gst/gl/cocoa/gstglcontext_cocoa.m?ref_type=heads)**
>
> GStreamer multimedia framework
- question for experts ( maybe @ystreet00 ): where exactly is the last place in GStreamer where the window-closing command gets (should get) sent to the macOS window manager if everything had been properly unreffed/destroyed ? (including the context) is it in:
`gst_gl_context_cocoa_destroy_context (GstGLContext *context)` ?
If this issue is something not being fully unref’d I could add refcount checks, but I am guessing it is a context left behind. somewhere? I’m assuming this is something fixable in gstreamer code?
---
### Author:  [@ystreet00](https://discourse.gstreamer.org/u/ystreet00)
#### Post date: [May 13, 2025, 2:17am UTC](https://discourse.gstreamer.org/t/trying-to-fix-broken-for-4-years-cocoa-implementation-of-glimagesink-on-macos/4600/2 "2025-05-13T02:17:11Z")
This issue is best discussed on gitlab in any of the relevant issues you have mentioned.
---
### Author:  [@fduncanh](https://discourse.gstreamer.org/u/fduncanh)
#### Post date: [May 13, 2025, 3:28am UTC](https://discourse.gstreamer.org/t/trying-to-fix-broken-for-4-years-cocoa-implementation-of-glimagesink-on-macos/4600/3 "2025-05-13T03:28:06Z")
These are all a single unresolved issue, and date from before the monorepo. So I presume it needs a new issue opened citing them. Unfortunately, nothing useful came from these earlier postings (at least for macOS cocoa, I see that there were fixes on other platforms).
Maybe some guidance on where to look for the bug might result this time.
---
### Author:  [@tpm](https://discourse.gstreamer.org/u/tpm)
#### Post date: [May 13, 2025, 10:43am UTC](https://discourse.gstreamer.org/t/trying-to-fix-broken-for-4-years-cocoa-implementation-of-glimagesink-on-macos/4600/4 "2025-05-13T10:43:52Z")
Issues can be moved to the monorepo if needed. (Have done so now.)
If they’re the same issue we can mark one as a dup of the other and continue discussion in whichever issue has the most useful info.