Window and renderer seperating in MacOS build

[rudrabhoj]

I compiled clapper (latest, github) using libs downloaded from homebrew. First run had these warning messages:

 ~/Applications/clapper/bin
./clapper
objc[99690]: Class ResultReceiver is implemented in both /opt/homebrew/Cellar/gtk+3/3.24.43/lib/libgtk-3.0.dylib (0x103019e00) and /opt/homebrew/Cellar/gtk4/4.14.5/lib/libgtk-4.1.dylib (0x11f6c7230). One of the two will be used. Which one is undefined.
objc[99690]: Class GtkApplicationQuartzDelegate is implemented in both /opt/homebrew/Cellar/gtk+3/3.24.43/lib/libgtk-3.0.dylib (0x103019e28) and /opt/homebrew/Cellar/gtk4/4.14.5/lib/libgtk-4.1.dylib (0x11f6c7258). One of the two will be used. Which one is undefined.
objc[99690]: Class GNSMenuItem is implemented in both /opt/homebrew/Cellar/gtk+3/3.24.43/lib/libgtk-3.0.dylib (0x103019e78) and /opt/homebrew/Cellar/gtk4/4.14.5/lib/libgtk-4.1.dylib (0x11f6c72a8). One of the two will be used. Which one is undefined.
objc[99690]: Class GNSMenu is implemented in both /opt/homebrew/Cellar/gtk+3/3.24.43/lib/libgtk-3.0.dylib (0x103019ea0) and /opt/homebrew/Cellar/gtk4/4.14.5/lib/libgtk-4.1.dylib (0x11f6c72d0). One of the two will be used. Which one is undefined.
objc[99690]: Class FilterComboBox is implemented in both /opt/homebrew/Cellar/gtk+3/3.24.43/lib/libgtk-3.0.dylib (0x103019f18) and /opt/homebrew/Cellar/gtk4/4.14.5/lib/libgtk-4.1.dylib (0x11f6c7348). One of the two will be used. Which one is undefined.
objc[99690]: Class gdkCoreCursor is implemented in both /opt/homebrew/Cellar/gtk+3/3.24.43/lib/libgdk-3.0.dylib (0x102365628) and /opt/homebrew/Cellar/gtk4/4.14.5/lib/libgtk-4.1.dylib (0x11f6c7398). One of the two will be used. Which one is undefined.

(clapper:99686): GLib-GIO-ERROR **: 07:55:16.668: Settings schema 'com.github.rafostar.Clapper' is not installed
zsh: trace trap  ./clapper

Fair enough, changed command a bit to give it the schema.
 ~/Applications/clapper/bin GSETTINGS_SCHEMA_DIR=/Users/rudrabhoj/Applications/clapper/share/glib-2.0/schemas ./clapper

So it worked??? Well no:

It opened the window, but playback is very bad, rendering window separated from the program itself. Is there a way to fix it, like render in software, use vulkan?

Using Apple Silicon (sonoma).

[Rafostar]

Is there a way to fix it, like render in software, use vulkan?

While there is some macos specific (Cocoa and CGL) code put in here to render, it was never actually tried on a real Apple HW, since I do not own one 😄 .

What seems to happen here is that app cannot locate clappersink which must be compiled as part of the app. In such case app will fallback to rendering in another window (background is currently missing). So you should probably start with checking meson logs what was compiled and where installed. GStreamer provides a convenience utility to test plugins/elements presence on the system gst-inspect-1.0 clapper should give some output if it is found.

[rudrabhoj]

Gstreamer problem was spot on! As install was local, gstreamer didn't know about plugin location. I added this, and tried this:

GST_PLUGIN_PATH=~/Applications/clapper/lib/gstreamer-1.0/ GSETTINGS_SCHEMA_DIR=/Users/rudrabhoj/Applications/clapper/share/glib-2.0/schemas ~/Applications/clapper/bin/clapper ~/Desktop/output.mp4

The window does not detach anymore, but the play button will not work. It will stay at black screen and not show any movement.

Let's check the info for this video:

Could it be again because of missing library path?

[Rafostar]

Please add to your command GST_DEBUG=*clapperimporter*:7,clapper*handler:7,2 and share the debug output. It might show us some more info about not working display.

[rudrabhoj]

 ~
GST_DEBUG=*clapperimporter*:7,clapper*handler:7,2 GST_PLUGIN_PATH=~/Applications/clapper/lib/gstreamer-1.0/ GSETTINGS_SCHEMA_DIR=/Users/rudrabhoj/Applications/clapper/share/glib-2.0/schemas ~/Applications/clapper/bin/clapper ~/Desktop/output.mp4
0:00:00.274910708 47864 0x6000012689c0 DEBUG   clapperimporterloader gstclapperimporterloader.c:283:gst_clapper_importer_loader_make_sink_pad_template: Making sink pad template
0:00:00.274923083 47864 0x6000012689c0 DEBUG   clapperimporterloader gstclapperimporterloader.c:228:_obtain_importers: Checking available importers
0:00:00.274926250 47864 0x6000012689c0 INFO    clapperimporterloader gstclapperimporterloader.c:125:_obtain_available_modules_once: Preparing modules
0:00:00.275086167 47864 0x6000012689c0 DEBUG   clapperimporterloader gstclapperimporterloader.c:245:_obtain_importers: Found 0 available importers
0:00:00.275094125 47864 0x6000012689c0 TRACE   clapperimporterloader gstclapperimporterloader.c:295:gst_clapper_importer_loader_make_sink_pad_template: Created sink pad template
0:00:00.275514917 47864 0x6000012689c0 DEBUG   clapperimporterloader gstclapperimporterloader.c:228:_obtain_importers: Checking usable importers
0:00:00.275525667 47864 0x6000012689c0 DEBUG   clapperimporterloader gstclapperimporterloader.c:245:_obtain_importers: Found 0 usable importers
0:00:00.313763333 47864 0x6000012689c0 ERROR            glimagesink gstglsinkbin.c:293:_connect_sink_element:<glsinkbin0> Failed to link sink element into the pipeline

(clapper:47864): GLib-GIO-CRITICAL **: 18:36:30.519: g_dbus_connection_emit_signal: assertion 'G_IS_DBUS_CONNECTION (connection)' failed
0:00:00.600949583 47864 0x600003f3b070 ERROR            glimagesink gstglsinkbin.c:438:gst_gl_sink_bin_change_state:<glsinkbin0> Failed to retrieve element
0:00:00.600964375 47864 0x600003f3b070 ERROR                playbin gstplaybin2.c:5554:activate_group:<playbin0> failed to activate sinks

(clapper:47864): GLib-GIO-CRITICAL **: 18:36:30.519: g_dbus_connection_emit_signal: assertion 'G_IS_DBUS_CONNECTION (connection)' failed

Adding that to the command gives this information ^

[Rafostar]

0 available importers is no good. Probably the same library path issue as before. Try setting CLAPPER_SINK_IMPORTER_PATH env to a path where installed importers are.

[rudrabhoj]

Looks like /Users/rudrabhoj/Applications/clapper/lib/clapper-0.0/gst/plugin/importers had the required libraries. Verified by:

 ~
ls /Users/rudrabhoj/Applications/clapper/lib/clapper-0.0/gst/plugin/importers/
libgstclapperglimporter.dylib	libgstclappergluploader.dylib

Then I tried to run it again, the result was same, but here is the output on terminal:

 ~
GST_DEBUG=*clapperimporter*:7,clapper*handler:7,2 CLAPPER_SINK_IMPORTER_PATH=/Users/rudrabhoj/Applications/clapper/lib/clapper-0.0/gst/plugin/importers/ GST_PLUGIN_PATH=~/Applications/clapper/lib/gstreamer-1.0/ GSETTINGS_SCHEMA_DIR=/Users/rudrabhoj/Applications/clapper/share/glib-2.0/schemas ~/Applications/clapper/bin/clapper ~/Desktop/output.mp4
0:00:00.260286958 77103 0x600003640870 DEBUG   clapperimporterloader gstclapperimporterloader.c:283:gst_clapper_importer_loader_make_sink_pad_template: Making sink pad template
0:00:00.260299167 77103 0x600003640870 DEBUG   clapperimporterloader gstclapperimporterloader.c:228:_obtain_importers: Checking available importers
0:00:00.260301875 77103 0x600003640870 INFO    clapperimporterloader gstclapperimporterloader.c:125:_obtain_available_modules_once: Preparing modules
0:00:00.260459292 77103 0x600003640870 DEBUG   clapperimporterloader gstclapperimporterloader.c:245:_obtain_importers: Found 0 available importers
0:00:00.260467542 77103 0x600003640870 TRACE   clapperimporterloader gstclapperimporterloader.c:295:gst_clapper_importer_loader_make_sink_pad_template: Created sink pad template
0:00:00.260563875 77103 0x600003640870 DEBUG   clapperimporterloader gstclapperimporterloader.c:228:_obtain_importers: Checking usable importers
0:00:00.260566833 77103 0x600003640870 DEBUG   clapperimporterloader gstclapperimporterloader.c:245:_obtain_importers: Found 0 usable importers
0:00:00.266922875 77103 0x600003640870 ERROR            glimagesink gstglsinkbin.c:293:_connect_sink_element:<glsinkbin0> Failed to link sink element into the pipeline

(clapper:77103): GLib-GIO-CRITICAL **: 04:17:35.948: g_dbus_connection_emit_signal: assertion 'G_IS_DBUS_CONNECTION (connection)' failed
0:00:00.548906833 77103 0x600001b0bb60 ERROR            glimagesink gstglsinkbin.c:438:gst_gl_sink_bin_change_state:<glsinkbin0> Failed to retrieve element
0:00:00.548921083 77103 0x600001b0bb60 ERROR                playbin gstplaybin2.c:5554:activate_group:<playbin0> failed to activate sinks

(clapper:77103): GLib-GIO-CRITICAL **: 04:17:35.950: g_dbus_connection_emit_signal: assertion 'G_IS_DBUS_CONNECTION (connection)' failed
0:00:07.239569125 77103 0x600001b0bb60 TRACE   clapperimporterloader gstclapperimporterloader.c:400:gst_clapper_importer_loader_finalize: Finalize

[Rafostar]

Hmmm. Looking into it, seems to be currently a problem with with .dylib extension (https://gitlab.gnome.org/GNOME/glib/-/blob/c138b98e363df8b95c2ee3eac214649b2908ad68/NEWS#L19). I wonder if simply renaming these 2 files from .dylib => .so would make it work (with CLAPPER_SINK_IMPORTER_PATH set). 🤔

Currently problem seems to be that "so" are expected, thus these 2 are not loaded and we still get 0 importers available.

[rudrabhoj]

Yes, that was the reason exactly. It worked fine once that change was made. Should we change meson to rename to .so ?

[rudrabhoj]

Btw if you guys need binary packages for MacOS (.dmg files??) I would be glad to maintain them!

[Rafostar]

It worked fine once that change was made.

Awesome you got this to work!

@rudrabhoj

Since you are the first person to do so (at least that I know of), can you share some more info what it ended up using: GST_DEBUG=*clapperimporter*:7,clapper*handler:7,2 and a PLAYING pipeline dot file created by setting GST_DEBUG_DUMP_DOT_DIR to some existing dir, please?

Btw if you guys need binary packages for MacOS (.dmg files??) I would be glad to maintain them!

Thanks for the offer. If you (or anyone else interested) could contribute a GitHub actions workflow that builds for MacOS from git master on each commit (similarly like Linux and Windows workflows that are already present) that would be awesome.

[sp1ritCS]

a GitHub actions workflow that builds for MacOS from git master on each commit

be careful with using Homebrew w. GHA, its surprisingly slow and somewhat prone to breakage.

Ideally use meson subprojects with whatever you can statically linked, then bundle whatever meson install --tags runtime produces into the image.

Should we change meson to rename to .so ?

No need, given its incorrect and apparently fixed upstream.

[Rafostar]

No need, given its incorrect and apparently fixed upstream.

Correct fix would be moving away from building module path with G_MODULE_SUFFIX which is deprecated. As it is right now, it will not work. Well ideally I wish to just do a new and improved sink that moves away from this "importers" concept, since they were meant to work around some missing GStreamer features, but they were implemented for 1.24 thus are no longer needed (and nowadays give more problems than benefits).

Ehh, if only GTK4 could finally decide what is the standardized way of rendering picture within it, cause ATM every GTK4 minor release expects/works with something entirely different 🤷‍♂️

[sp1ritCS]

No need, given its incorrect and apparently fixed upstream.

Correct fix would be moving away from building module path with G_MODULE_SUFFIX which is deprecated. As it is right now, it will not work.

Oh I see. I've only read the first part of the line of the changelog you linked that mentioned it "fixed" something so I've figured that was just some resolved bug that just hadn't made it to homebrew yet.

While using so as extension for OS X seems rather dumb, its apparently for backward compatibility; I guess setting name_suffix in meson is the only real solution :/.

[Rafostar]

Oh I see. I've only read the first part of the line of the changelog you linked that mentioned it "fixed" something so I've figured that was just some resolved bug that just hadn't made it to homebrew yet.

I honesty dunno if latest change made it to homebrew yet. Just linked an older (2.58) GLib changelog that mentions a workaround that still works. In much more recent GLib this method of loading modules was deprecated in favor of a solution that supposedly makes it work with .dylib. It actually spits a deprecation warning during Clapper compilation, so best way probably would be to port this part of code to new non-deprecated method instead of meson tweaking... or just do a new sink which must be done sooner or later anyway in order to support DMABufs and HDR.