gstcefsrc
gstcefsrc copied to clipboard
centricular
Reland "Fix build on macosarm64 and pay attention to USE_SANDBOX flag"
The issue with the prior PR was USE_SANBOX was ON by default. I clearly did not pay attention enough to that. IMO the default should be OFF, and only be enabled if the arch is arm and the target is macos.
- This updates the CEF version to 122.1.13. The reason for this is on the M1 you will get a flood of linker errors due to incompatibilities with the older 103.0.9.
- I had to rename USE_SANBOX to SANDBOX as find_packages was resetting it to ON if set to OFF prior to the call
- Tested build/inspect on Mac M1 in Release and Linux 64 in Release
Additionally I had to add a few additional cmake options for the MacARM build otherwise I would get errors, and in one case lib_cef_dllwrapper was being compiled for i386. Let me know if there is something wrong there.
Apple clang version 15.0.0 (clang-1500.1.0.2.5) Target: arm64-apple-darwin23.2.0 cmake version 3.24.1
I compiled and did a gst-inspect-1.0 on it. I did not test but I can run one now... BUMMER. SIGSEGV. Changing to draft. I will work on it tomorrow. It's late for me.
GStreamer 1.22.4
0:00:00.789074000 57748 0x60000396f2a0 LOG aggregator gstaggregator.c:2194:gst_aggregator_query_latency_unlocked:<mix> Signaling src from thread 0x60000396f2a0
0:00:00.789077000 57748 0x60000396f2a0 DEBUG aggregator gstaggregator.c:2197:gst_aggregator_query_latency_unlocked:<mix> configured latency live:true min:33219954 max:-1
0:00:00.789096000 57748 0x60000396f2a0 LOG aggregator gstaggregator.c:488:gst_aggregator_check_pads_ready:<mix> checking pads
0:00:00.789099000 57748 0x60000396f2a0 LOG aggregator gstaggregator.c:532:gst_aggregator_check_pads_ready:<mix:sink_0> Have no buffer and not EOS yet
0:00:00.789101000 57748 0x60000396f2a0 LOG aggregator gstaggregator.c:532:gst_aggregator_check_pads_ready:<mix:sink_1> Have no buffer and not EOS yet
0:00:00.789103000 57748 0x60000396f2a0 LOG aggregator gstaggregator.c:587:gst_aggregator_check_pads_ready:<mix> pad not ready to be aggregated yet
0:00:00.789106000 57748 0x60000396f2a0 LOG aggregator gstaggregator.c:880:gst_aggregator_wait_and_check:<mix> Waiting for src on thread 0x60000396f2a0
thread 1 , stop reason = signal SIGSTOP
No such issue on Linux
You can see here https://github.com/centricular/gstcefsrc/pull/67 Plus I started on my branch to make it work. https://github.com/centricular/gstcefsrc/compare/master...reinismu:gstcefsrc:macos-support but I'm not familiar with cmake and so so with MacOS.
We might put a bounty on this thing. Running this plugin on MacOS would benefit us.
We had a discussion and we decided to reward 1000$ to someone who can make this plugin work on Apple Silicon MacOS :)
You are headed on the right path with what you have done in gstcefsubprocess. If If I were to do more work on this I would look to the CEF examples. Specifically the mac process helper. If I have time this evening I will see what I can come up with.
So over lunch I took another look at this. The segfault is coming from CefString. In static gpointer run_cef(GstCefSrc *src) { There is the line:
CefString(&settings.browser_subprocess_path)
.FromASCII(browser_subprocess_path);
That is where the segfault happens. I will look into it more later today if I have time.
At this point not sure what is going on here. From the code CefString str("LETS CRASH");.
* thread #17, name = 'cef-ui-thread', stop reason = EXC_BAD_ACCESS (code=1, address=0x0)
frame #0: 0x0000000000000000
error: memory read failed for 0x0
Target 0: (gst-launch-1.0) stopped.
(lldb) bt
* thread #17, name = 'cef-ui-thread', stop reason = EXC_BAD_ACCESS (code=1, address=0x0)
* frame #0: 0x0000000000000000
frame #1: 0x0000000104291d98 libgstcef.dylib`cef_string_utf8_to_utf16(src="LETS CRASH", src_len=10, output=0x00006000025189c0) at libcef_dll_dylib.cc:1583:10
frame #2: 0x00000001041a6f74 libgstcef.dylib`CefStringTraitsUTF16::from_string(data="LETS CRASH", length=10, s=0x00006000025189c0) at cef_string_wrappers.h:269:12
frame #3: 0x00000001041a6e4c libgstcef.dylib`CefStringBase<CefStringTraitsUTF16>::FromString(this=0x00000001706babe0, data="LETS CRASH", length=10) at cef_string_wrappers.h:684:12
frame #4: 0x00000001041a6d80 libgstcef.dylib`CefStringBase<CefStringTraitsUTF16>::CefStringBase(this=0x00000001706babe0, src="LETS CRASH", length=0) at cef_string_wrappers.h:385:7
frame #5: 0x00000001041a620c libgstcef.dylib`CefStringBase<CefStringTraitsUTF16>::CefStringBase(this=0x00000001706babe0, src="LETS CRASH", length=0) at cef_string_wrappers.h:383:38
frame #6: 0x00000001041ab13c libgstcef.dylib`run_cef(src=0x000000012d80eae0) at gstcefsrc.cc:477:13
frame #7: 0x00000001007101fc libglib-2.0.0.dylib`g_thread_proxy + 68
frame #8: 0x0000000188bb6034 libsystem_pthread.dylib`_pthread_start + 136
I thought maybe trying to load the library in gstcefsrc.c might be the issue, but as soon as I touch
// Initialize the macOS sandbox for this helper process.
CefScopedSandboxContext sandbox_context;
I will get a crash. I think this might be a mem allocator issue? CefString does an allocation, and so does CefScopedSandboxContext. I can do this
CefBrowserSettings browserSettings;
settings.no_sandbox = !src->sandbox;
settings.windowless_rendering_enabled = true;
settings.log_severity = src->log_severity;
which is fine given this is a simple structure on the stack. It has been a while since I have dealt with these types of issues. I guess if I were going to debug this further I would build CEF against my local tool chain.
@reinismu I would like to get this working at some point, but I simply do not have the time to dig into it. As I stated above the issue revolves around memory allocation AFAICT. There is a bad access at as you can see. I ran the CEF sample minimal without any issue, so I know CEF works on OS-X and the M series chips. At this point I don't know. I have a habit of closing PR's that I will not work on. However, given minimal amount of traffic here I will reopen in hopes someone will have an aha moment.
Maybe someone from Centricular will get interested in this as well.
I wonder if bad access is not caused by MacOS security stuff. The last I recall from my try was setting up process metadata
I am compiling CEF locally, so I can at least debug a bit better. I will continue to look into this when I have some free time.
We had a discussion and we decided to reward 1000$ to someone who can make this plugin work on Apple Silicon MacOS :)
Noted, I will check with our MacOS people :)
We had a discussion and we decided to reward 1000$ to someone who can make this plugin work on Apple Silicon MacOS :)
Noted, I will check with our MacOS people :)
Did any MacOS people seem interested? :) If price is too low, we can discuss it
We had a discussion and we decided to reward 1000$ to someone who can make this plugin work on Apple Silicon MacOS :)
Noted, I will check with our MacOS people :)
Did any MacOS people seem interested? :) If price is too low, we can discuss it
Hey, sorry for not following up, I mentioned this in our internal chat but no one picked up on it at the time. Maybe shoot us a mail at [email protected] to get the ball rolling :)
Hi! @nirbheek told me I could have a look at this. The issue you were facing is that, on macOS, what you're calling is in fact an interposer, lazy-loader dylib: https://github.com/chromiumembedded/cef/blob/00118ddcdbdd6f7a5ed6e131417e6fb222bb33b0/libcef_dll/wrapper/cef_library_loader_mac.mm#L63-L65
Since that library was never initialized in the gstcef side, all CEF calls were rendered null pointer dereferences. I believe these changes should be sufficient to get you going, feel free to include and rebase them : https://github.com/SteveMcFarlin/gstcefsrc/compare/cmake-macosarm64...amyspark:gstcefsrc:cmake-macosarm64
Bear in mind, however, that it seems CEF intends you to consume the library as an Apple framework -- the loader attempts to find the Framework relative to the executable's path, as when deployed into an app bundle.
Hi! @nirbheek told me I could have a look at this. The issue you were facing is that, on macOS, what you're calling is in fact an interposer, lazy-loader dylib: https://github.com/chromiumembedded/cef/blob/00118ddcdbdd6f7a5ed6e131417e6fb222bb33b0/libcef_dll/wrapper/cef_library_loader_mac.mm#L63-L65
Since that library was never initialized in the gstcef side, all CEF calls were rendered null pointer dereferences. I believe these changes should be sufficient to get you going, feel free to include and rebase them : SteveMcFarlin/[email protected]:gstcefsrc:cmake-macosarm64
Bear in mind, however, that it seems CEF intends you to consume the library as an Apple framework -- the loader attempts to find the Framework relative to the executable's path, as when deployed into an app bundle.
Thanks for looking into this :)
Currently trying it out on my M2 Mac Mini. Compiled and set up everything on it.
Sadly for me it segfaults :(
Command
GST_PLUGIN_PATH=Release:$GST_PLUGIN_PATH gst-launch-1.0 -e \
cefsrc url="https://soundcloud.com/platform/sama" ! \
video/x-raw, width=1920, height=1080, framerate=60/1 ! \
cefdemux name=demux ! queue ! videoconvert ! \
queue max-size-bytes=0 max-size-buffers=0 max-size-time=3000000000 ! x264enc ! queue ! \
mp4mux name=muxer ! filesink location='test.mp4' \
audiotestsrc do-timestamp=true is-live=true volume=0.0 ! audiomixer name=mix ! \
queue max-size-bytes=0 max-size-buffers=0 max-size-time=3000000000 ! audioconvert ! \
audiorate ! audioresample ! faac bitrate=128000 ! queue ! muxer. \
demux. ! queue ! mix.
Logs:
.... setting up pipeline
0:00:00.026971459 30738 0x600000391770 INFO structure gststructure.c:2957:gst_structure_get_valist: Expected field 'channel-mask' in structure: audio/x-raw, rate=(int)[ 1, 2147483647 ], channels=(int)[ 1, 2147483647 ];
0:00:00.026979917 30738 0x6000003ac370 INFO GST_STATES gstelement.c:2825:gst_element_continue_state:<queue5> completed state change to PAUSED
0:00:00.026985000 30738 0x6000003ac370 INFO GST_STATES gstelement.c:2728:_priv_gst_element_state_changed:<queue5> notifying about state-changed READY to PAUSED (VOID_PENDING pending)
0:00:00.026989375 30738 0x6000003ac370 INFO GST_STATES gstbin.c:2942:gst_bin_change_state_func:<pipeline0> child 'queue5' changed state to 3(PAUSED) successfully
0:00:00.026992834 30738 0x6000003ac370 INFO GST_STATES gstbin.c:2484:gst_bin_element_set_state:<demux> current READY pending VOID_PENDING, desired next PAUSED
0:00:00.026996125 30738 0x6000003ac370 INFO GST_STATES gstelement.c:2825:gst_element_continue_state:<demux> completed state change to PAUSED
0:00:00.026998625 30738 0x6000003ac370 INFO GST_STATES gstelement.c:2728:_priv_gst_element_state_changed:<demux> notifying about state-changed READY to PAUSED (VOID_PENDING pending)
0:00:00.027001792 30738 0x6000003ac370 INFO GST_STATES gstbin.c:2942:gst_bin_change_state_func:<pipeline0> child 'demux' changed state to 3(PAUSED) successfully
0:00:00.027004542 30738 0x6000003ac370 INFO GST_STATES gstbin.c:2484:gst_bin_element_set_state:<capsfilter0> current READY pending VOID_PENDING, desired next PAUSED
0:00:00.027007459 30738 0x6000003ac370 INFO GST_STATES gstelement.c:2825:gst_element_continue_state:<capsfilter0> completed state change to PAUSED
0:00:00.027009834 30738 0x6000003ac370 INFO GST_STATES gstelement.c:2728:_priv_gst_element_state_changed:<capsfilter0> notifying about state-changed READY to PAUSED (VOID_PENDING pending)
0:00:00.027012709 30738 0x6000003ac370 INFO GST_STATES gstbin.c:2942:gst_bin_change_state_func:<pipeline0> child 'capsfilter0' changed state to 3(PAUSED) successfully
0:00:00.027015250 30738 0x6000003ac370 INFO GST_STATES gstbin.c:2484:gst_bin_element_set_state:<cefsrc0> current READY pending VOID_PENDING, desired next PAUSED
0:00:00.027054750 30738 0x6000003a00a0 WARN aggregator gstaggregator.c:2283:gst_aggregator_query_latency_unlocked:<mix> Latency query failed
0:00:00.027065417 30738 0x6000003ae620 INFO cefsrc gstcefsrc.cc:481:run_cef: Initializing CEF
zsh: segmentation fault GST_PLUGIN_PATH=Release:$GST_PLUGIN_PATH gst-launch-1.0 -e cefsrc ! !
I tried running gstcefsubprocess manually and it segfaults as well.
sharehand@SH-MacMini-M2 Release % sudo lldb ./gstcefsubprocess
(lldb) target create "./gstcefsubprocess"
Current executable set to '/Users/sharehand/projects/gstcefsrc/build/Release/gstcefsubprocess' (arm64).
(lldb) run
Process 30799 launched: '/Users/sharehand/projects/gstcefsrc/build/Release/gstcefsubprocess' (arm64)
Process 30799 stopped
* thread #1, queue = 'com.apple.main-thread', stop reason = EXC_BAD_ACCESS (code=1, address=0x0)
frame #0: 0x0000000000000000
error: memory read failed for 0x0
Target 0: (gstcefsubprocess) stopped.
(lldb) bt
* thread #1, queue = 'com.apple.main-thread', stop reason = EXC_BAD_ACCESS (code=1, address=0x0)
* frame #0: 0x0000000000000000
frame #1: 0x0000000100036f50 gstcefsubprocess`CefExecuteProcess(CefMainArgs const&, scoped_refptr<CefApp>, void*) + 36
frame #2: 0x000000010000278c gstcefsubprocess`main + 120
frame #3: 0x000000019547bf28 dyld`start + 2236
(lldb)
Maybe I missed something?
~~I investigated a bit further and noticed that my gstcefsubprocess doesn't link to libgstcef.dylib~~
sharehand@SH-MacMini-M2 Release % otool -L gstcefsubprocess
gstcefsubprocess:
/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1336.61.1)
/System/Library/Frameworks/Cocoa.framework/Versions/A/Cocoa (compatibility version 1.0.0, current version 24.0.0)
/System/Library/Frameworks/AppKit.framework/Versions/C/AppKit (compatibility version 45.0.0, current version 2487.30.104)
/usr/lib/libsandbox.1.dylib (compatibility version 1.0.0, current version 1.0.0)
/usr/lib/libc++.1.dylib (compatibility version 1.0.0, current version 1600.157.0)
Compared with my linux build folder and realized that cef libs are missing
sharehand@SH-MacMini-M2 Release % ls -l
total 2080
-rwxr-xr-x 1 sharehand staff 478464 May 21 10:49 gstcefsubprocess
-rwxr-xr-x 1 sharehand staff 583648 May 21 10:49 libgstcef.dylib
it seems to try to run cef lib functions, but fails to do so
Hi! That's correct, CEF libraries are missing because on macOS, there are none. What the Spotify tarball ships is instead a framework.
I assume the intention of the developers was to consume it from an app, and so they architected the lazy load to resolve from said path (path_to_executable/../Frameworks/Chromium Embedded Framework.framework/...). It'll fail completely if you try to use it from a standalone executable, are you building such an example?
Hi! That's correct, CEF libraries are missing because on macOS, there are none. What the Spotify tarball ships is instead a framework.
I assume the intention of the developers was to consume it from an app, and so they architected the lazy load to resolve from said path (
path_to_executable/../Frameworks/Chromium Embedded Framework.framework/...). It'll fail completely if you try to use it from a standalone executable, are you building such an example?
Did you manage to run gstcefsrc on your end? If so could you provide example?
@SteveMcFarlin Hey! Did you manage to run these changes on your end? I feel like something still is missing there or I'm doing something wrong as I didn't get it to work :/
@reinismu I have not yet. I am getting setup to test it either today or tomorrow.
@reinismu I have finally got a system up and running. I installed GStreamer from the downloads. I can not even load the plugin currently.
dyld[53231]: Library not loaded: @rpath/libgstreamer-1.0.0.dylib
Referenced from: <07B6FD71-26C5-37F7-9B7A-DC944038F101> /Library/Frameworks/GStreamer.framework/Versions/1.0/libexec/gstreamer-1.0/gst-plugin-scanner
Reason: tried: '/Library/Frameworks/GStreamer.framework/Versions/1.0/libexec/libgstreamer-1.0.0.dylib' (no such file), '/Library/Frameworks/GStreamer.framework/Versions/1.0/libexec/gstreamer-1.0/../libgstreamer-1.0.0.dylib' (no such file), '/Library/Frameworks/GStreamer.framework/Versions/1.0/libexec/lib/libgstreamer-1.0.0.dylib' (no such file), '/Library/Frameworks/GStreamer.framework/Versions/1.0/libexec/gstreamer-1.0/../lib/libgstreamer-1.0.0.dylib' (no such file), '/Library/Frameworks/GStreamer.framework/Versions/1.0/libgstreamer-1.0.0.dylib' (no such file), '/Library/Frameworks/GStreamer.framework/Versions/1.0/libexec/gstreamer-1.0/../../libgstreamer-1.0.0.dylib' (no such file), '/Library/Frameworks/GStreamer.framework/Versions/1.0/libexec/libgstreamer-1.0.0.dylib' (no such file), '/Library/Frameworks/GStreamer.framework/Versions/1.0/libexec/gstreamer-1.0/../libgstreamer-1.0.0.dylib' (no such file), '/Library/Frameworks/GStreamer.framework/Versions/1.0/libexec/lib/libgstreamer-1.0.0.dylib' (no such file), '/Library/Frameworks/GStreamer.framework/Versions/1.0/libexec/gstreamer-1.0/../lib/libgstreamer-1.0.0.dylib' (no such file), '/Library/Frameworks/GStreamer.framework/Versions/1.0/libgstreamer-1.0.0.dylib' (no such file), '/Library/Frameworks/GStreamer.framework/Versions/1.0/libexec/gstreamer-1.0/../../libgstreamer-1.0.0.dylib' (no such file), '/usr/local/lib/libgstreamer-1.0.0.dylib' (no such file), '/usr/lib/libgstreamer-1.0.0.dylib' (no such file, not in dyld cache)
Additionally I get errors related to ../Frameworks/Chromium Embedded Framework.framework/Chromium Embedded Framework. Prior to trying the installers I built from source, and received the same errors. I may try a home-brew installation, but for now I am stuck.
I am now only having issues loading the CEF Framework with the distro from Spotify. I am not used to using those packages, so I am build CEF locally in order to see if I can get something working. I currently have no intention of building an App via the usual methods on MacOS, so I am going to work on that.
@reinismu I had to copy the framework into my gst installation. Now I get a crash. I have a feeling this is due to issues revolving around CEF not being bundled in an app as Amy pointed out.
Setting pipeline to PAUSED ...
Process 54332 stopped
* thread #18, name = 'cef-ui-thread', stop reason = EXC_BREAKPOINT (code=1, subcode=0x147ef4020)
frame #0: 0x0000000147ef4020 Chromium Embedded Framework`___lldb_unnamed_symbol7480 + 600424
Chromium Embedded Framework`___lldb_unnamed_symbol7480:
-> 0x147ef4020 <+600424>: brk #0
0x147ef4024 <+600428>: hlt #0
0x147ef4028 <+600432>: brk #0x1
0x147ef402c <+600436>: mov w0, #0x2
Target 0: (gst-launch-1.0) stopped.
(lldb) bt
* thread #18, name = 'cef-ui-thread', stop reason = EXC_BREAKPOINT (code=1, subcode=0x147ef4020)
* frame #0: 0x0000000147ef4020 Chromium Embedded Framework`___lldb_unnamed_symbol7480 + 600424
frame #1: 0x000000014769171c Chromium Embedded Framework`___lldb_unnamed_symbol7466 + 2518368
frame #2: 0x0000000147690a68 Chromium Embedded Framework`___lldb_unnamed_symbol7466 + 2515116
frame #3: 0x000000014459f39c Chromium Embedded Framework`cxxbridge1$rust_vec$u8$set_len + 216008
frame #4: 0x000000014459f114 Chromium Embedded Framework`cxxbridge1$rust_vec$u8$set_len + 215360
frame #5: 0x000000014457cd50 Chromium Embedded Framework`cxxbridge1$rust_vec$u8$set_len + 75132
frame #6: 0x000000014457ca9c Chromium Embedded Framework`cxxbridge1$rust_vec$u8$set_len + 74440
frame #7: 0x00000001444df0e8 Chromium Embedded Framework`cef_initialize + 312
frame #8: 0x0000000104025230 libgstcef.dylib`CefInitialize(CefMainArgs const&, CefStructBase<CefSettingsTraits> const&, scoped_refptr<CefApp>, void*) + 184
frame #9: 0x0000000103fedb60 libgstcef.dylib`run_cef(_GstCefSrc*) + 792
frame #10: 0x0000000100957c7c libglib-2.0.0.dylib`g_thread_proxy + 68
frame #11: 0x000000019d73af94 libsystem_pthread.dylib`_pthread_start + 136
Well I give up for now. I spent the day on it. I went so far as to create a console app and link everything properly. Still crashes when cefsrc initializes Cef.
Well I give up for now. I spent the day on it. I went so far as to create a console app and link everything properly. Still crashes when cefsrc initializes Cef.
Thanks! Currently contracting Centricular (Amy) to try and solve it :) Now I just hope that issue is not too complicated
I am still gong to do a local CEF build the way I do it on linux to see if it is any different. Hopefully this does get fixed. Always wanted it working on OS-X arm64 just for convenience.
Hi again @SteveMcFarlin @reinismu !
The reason why the update has been so troublesome on macOS is because Chromium's Sandbox V2 goes out of its way to ensure that the framework is loaded from within an app bundle. So far I have discovered the following:
- There is no workaround for initializing the plugin from inside an app bundle, Chromium itself enforces that at initialization
- There are overrides needed to allow loading the CEF framework itself from outside that app bundle, for ad-hoc/development use
- When the Cocoa event loop is not managed by CEF itself (see the call to
CefRunMessageLoop()in the existing gstcefsrc.cc code) its callee must be aware of CEF and implement a protocol in theNSApplicationrendering the UI
For the first item, I put together an app bundle for gst-launch-1.0 by moving the executable to bin/gst-launch-1.0.app/Contents/MacOS/gst-launch-1.0, symlinking it back to the bin folder, and adding an Info.plist. The complete bundle should look like this: gst-launch-1.0.zip
For the second item, the overrides are in detail here: https://github.com/amyspark/gstcefsrc/commit/9930d07044c56e895e9fa91b154849444787ddf9
For the third item, I started working on that (commit here, but I still need to port the following in the Java bindings: https://github.com/chromiumembedded/java-cef/blob/master/native/util_mac.mm#L70-L73).
I'll keep you posted, you can find what progress I make in this branch.