Skip to content

Get rid of Cocoa Event Loop patches to glib so we can update

The 0009-Implementation-of-Cocoa-event-loop-integration-in-GM.patch patch is blocking our glib update, which is now very out of date.

The basic issue is that for any UI-related macOS APIs to work (including GL), the main thread of the app needs to be running a Cocoa event loop. So, everyone needs to add code to their app to make this work, for example: https://gitlab.freedesktop.org/gstreamer/gstreamer-rs/-/blob/main/examples/src/examples-common.rs

We've been patching Glib in Cerbero to not require this, but this custom patch will never be accepted upstream, and it's a lot of work to make it work properly inside Glib (will likely require painful refactoring in Glib). It also causes confusion for people who try to use GStreamer using Homebrew and find that video output doesn't work.

So the best way forward is to get rid of the workaround. My proposal is:

  1. Add a flag to gst/gst.c that says "I have added the nsrunloop workaround" + some API to set it
  2. In gst_init() check if that flag is set, if not, emit warning that points to documentation on what to do to fix things
  3. Set that flag when running the nsrunloop in example code that people should copy into their apps (and in gst-play and gst-launch)
  4. Remove the warning in 2-3 releases

If there's a way to check that the nsrunloop is running, it would be even better, but it's not necessary. It's just a way to tell people "check your code, and tell me you've checked your code".

This code will only be patched into Cerbero, so we should probably use an env var to set it, so that we aren't adding a symbol that doesn't exist in gstreamer itself.

Upstream issue: https://gitlab.gnome.org/GNOME/glib/-/issues/971

Edited by Sebastian Dröge