Repository navigation
Video Library Release 9 (2.1) omits MacOs aarch build #199
Description
macos 12.3 M1 Pro
Processing4_07b
Video Library Release 9 (2.1)
using the capture example (standard)
responses with
Video Library for Processing 4 does not run on this architecture: macos-aarch64
UnsatisfiedLinkError: Can't load library: /Users/bradmiller/Library/Caches/JNA/temp/jna7646126819441549257.tmp
A library used by this sketch relies on native code that is not available.
no macOS-aarch64 targeted files in package
kind regards
Activity
codeanticode commentedon Apr 3, 2022
Thanks for pointing this out. I believe that the GStreamer project has not created macOS aarch builds yet, they only list macOS Universal (X86_64 & ARM64) for the latest 1.20 version. We'll see how this plays out, hopefully an aarch build of GStreamer will be available soon.
codeanticode commentedon Jul 3, 2022
@benfry The latest build of the GStreamer libraries released for macOS by the GStreamer project are described as "universal" (X86_64 & ARM64). Looks like this means that each library file contains both x86_64 and arm64 binaries, see for example the output of running
otool -L /Library/Frameworks/GStreamer.framework/Libraries/libgstreamer-1.0.0.dylib:So, if they are not releasing separate x86 and arm64 build that we could copy into the macos-x86_64 and macos-aarch64 folders in the Processing library, maybe it would be useful to add macos-universal to the supported platforms?
fabriek-huis commentedon Jul 5, 2022
is there any fix for this yet?
codeanticode commentedon Jul 6, 2022
I tested the universal native GStreamer libs and the library runs on Macs with Apple Silicon :-) I made a few changes to Processing to support a macos-universal folder under library, this is the PR, but needs to be revised by @benfry to make sure it does not have any unintended effects.
renaudfv commentedon Jul 29, 2022
Hey! The mentioned PR has been closed? Any ETA for the fix to be included in the lib?
codeanticode commentedon Jul 31, 2022
Don't have an ETA at this moment, but until the next version of the video library including the notarized native libraries of gstreamer for aarch64 is ready, you can generate them on your computer if feeling adventurous :-)
...Actually, you can simply install the universal gstreamer for MacOS from https://gstreamer.freedesktop.org/download/
The video library should use those native libraries instead of the ones bundled with the library.
But you can also generate the aarch64 native libs by running the script pack_macosx_libs.sh. You first need to clone this repo, and then run the script (which assumes that the universal gstreamer is already installed):
This should result in the macos-aarch64 folder inside processing-video/library
renaudfv commentedon Aug 5, 2022
Wonderful, thanks for the clear indications :)
codeanticode commentedon Aug 24, 2022
@renaudfv Please try this new release of the library: https://github.com/processing/processing-video/releases/tag/latest, it includes the aarch64 version of the GStreamer native libs.
mbodlund commentedon Aug 24, 2022
Tried the new release and I get on a M1 mini.
(Processing core video:1336) : GStreamer-CRITICAL **: 10:39:00.587: gst_bin_add_ many:
assertion 'GST_IS_ELEMENT (element_1)' failed
(Processing core video:1336): GStreamer-CRITICAL **: 10:39:00.594:
gst_element_link_pads_full: assertion 'GST_IS_ELEMENT (dest)' failed
renaudfv commentedon Aug 30, 2022
@codeanticode great, I have the exemples running properly on my setup now!
codeanticode commentedon Aug 30, 2022
@renaudfv Great, thanks for the confirmation!
@mbodlund not sure what's going on, I tested the library on a M1 macbook and worked without issues. The error you are getting might be caused by having another version gstreamer installed in the system
brad-miller commentedon Aug 30, 2022
macOS 12.5.1 M1 Pro
Processing 4.0.1
Video Library Release 10 (2.2)
have uninstalled system Library/Frameworks/GStreamer.Frameworks/
Processing video library using bundled GStreamer 1.20.3
Scanning GStreamer plugins... Done.
Available cameras:
[0] "FaceTime HD Camera"
(Processing core video:917): GStreamer-CRITICAL **: 08:50:52.215: gst_bin_add_many: assertion 'GST_IS_ELEMENT (element_1)' failed
(Processing core video:917): GStreamer-CRITICAL **: 08:50:52.223: gst_element_link_pads_full: assertion 'GST_IS_ELEMENT (dest)' failed
run it twice and Java quits:
Thread 33 Crashed:: Java: Animation Thread
0 libsystem_kernel.dylib 0x18dccad98 __pthread_kill + 8
1 libsystem_pthread.dylib 0x18dcffee0 pthread_kill + 288
2 libsystem_c.dylib 0x18dc3a340 abort + 168
3 libjvm.dylib 0x106015dd8 os::abort(bool, void*, void const*) + 56
4 libjvm.dylib 0x10625e398 VMError::report_and_die(int, char const*, char const*, char*, Thread*, unsigned char*, void*, void*, char const*, int, unsigned long) + 2684
5 libjvm.dylib 0x10625d910 VMError::report_and_die(Thread*, unsigned int, unsigned char*, void*, void*, char const*, ...) + 72
6 libjvm.dylib 0x10625e4e0 VMError::report_and_die(Thread*, unsigned int, unsigned char*, void*, void*) + 36
7 libjvm.dylib 0x106131c50 JVM_handle_bsd_signal + 436
8 libsystem_platform.dylib 0x18dd174a4 _sigtramp + 56
9 libgstreamer-1.0.0.dylib 0x166cca934 gst_element_link_pads_full + 100
10 libgstreamer-1.0.0.dylib 0x166ccbd10 gst_element_link_many + 144
11 jna12913282264558629518.tmp 0x166a9804c 0x166a88000 + 65612
12 jna12913282264558629518.tmp 0x166a96930 0x166a88000 + 59696
13 jna12913282264558629518.tmp 0x166a8e7e8 0x166a88000 + 26600
14 jna12913282264558629518.tmp 0x166a8eb44 Java_com_sun_jna_Native_invokeInt + 44
15 ??? 0x12080bbe0 ???
16 ??? 0x1208063bc ???
17 ??? 0x120806270 ???
18 ??? 0x120806270 ???
19 ??? 0x120806c60 ???
20 ??? 0x120806c60 ???
21 ??? 0x120806dac ???
22 ??? 0x1208063bc ???
23 ??? 0x1208066ac ???
24 ??? 0x1208066ac ???
25 ??? 0x1208066ac ???
26 ??? 0x1208066ac ???
27 ??? 0x1208066ac ???
28 ??? 0x1208066ac ???
29 ??? 0x1208066ac ???
30 ??? 0x120800140 ???
31 libjvm.dylib 0x105cb49b0 JavaCalls::call_helper(JavaValue*, methodHandle const&, JavaCallArguments*, JavaThread*) + 908
32 libjvm.dylib 0x105cb39cc JavaCalls::call_virtual(JavaValue*, Klass*, Symbol*, Symbol*, JavaCallArguments*, JavaThread*) + 284
33 libjvm.dylib 0x105cb3a98 JavaCalls::call_virtual(JavaValue*, Handle, Klass*, Symbol*, Symbol*, JavaThread*) + 100
34 libjvm.dylib 0x105d6cd28 thread_entry(JavaThread*, JavaThread*) + 196
35 libjvm.dylib 0x1061eec74 JavaThread::thread_main_inner() + 336
36 libjvm.dylib 0x1061ed2fc Thread::call_run() + 296
37 libjvm.dylib 0x10600d7dc thread_native_entry(Thread*) + 344
38 libsystem_pthread.dylib 0x18dd0026c _pthread_start + 148
39 libsystem_pthread.dylib 0x18dcfb08c thread_start + 8
can still call it directly
cam = new Capture(this, 640, 480, "pipeline:avfvideosrc device-index=0 ! video/x-raw, width=640, height=480, framerate=30/1");
mbodlund commentedon Aug 31, 2022
Tried the same as @brad-miller and I get the same result.
codeanticode commentedon Aug 31, 2022
@mbodlund ok so you can get video capture using the pipeline string, right? Sounds like there is an issue with the default capture settings, so will look into it.
ffd8 commentedon Sep 1, 2022
Also gave a try (MBP M1 max, MacOS 12.5.1, Processing 4.0.1) after manually installing latest release and have the same error as reported by @brad-miller when trying to capture (although a diff linenumber given). Nevertheless all
Movieplayback examples work fine.On a side note, was wondering if the library installed since I couldn't find the examples, until finding it under
Contributed Librariesrather than the officialLibrariessubfolder. Not sure if that's just because it was manually installed or if a pref needs to be adjusted?codeanticode commentedon Sep 4, 2022
@ffd8 The problem with capture, at least one of the problems, is this #205, the library was not setting a default framerate in gstreamer, which was fine before but stopped working at some point. This should be fixed with this commit ace6d59, and latest release 2.2.1: https://github.com/processing/processing-video/releases/tag/latest
Not sure if that solves everything, at least on one M1 laptop, the capture examples still crash after this fix. However, the pipeline suggested by @brad-miller seems like a good workaround for the time being.
In any case, the issue here was lack of availability of aarch64 gstreamer native libs, which as been solved already, so closing.
ffd8 commentedon Sep 4, 2022
Ahaa - it was continuing the crash with the latest lib, but then went back and saw the key line of code from @brad-miller just after the long crash report, which I overlooked. Repeating others who run into same situation (
video, for examples) :codeanticode commentedon Sep 4, 2022
Great that the pipeline capture works for you, I think the crash on aarch64 macs is due to something else, created a separate issue about #206
brad-miller commentedon Oct 11, 2022
codeanticode commentedon Oct 11, 2022
@brad-miller Capture on aarch64 macs is already fixed in the main branch of the code, with this commit c2f894f, it's just that was trying to find some time to fix a few more issues to release as 2.2 but I might just go ahead and release it without any other changes.
brad-miller commentedon Oct 11, 2022