Video Library Release 9 (2.1) omits MacOs aarch build #199
Comments
|
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. |
|
@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 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? |
|
is there any fix for this yet? |
|
Hey! The mentioned PR has been closed? Any ETA for the fix to be included in the lib? |
|
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 |
|
Wonderful, thanks for the clear indications :) |
|
@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. |
|
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: |
|
@codeanticode great, I have the exemples running properly on my setup now! |
|
macOS 12.5.1 M1 Pro have uninstalled system Library/Frameworks/GStreamer.Frameworks/ Processing video library using bundled GStreamer 1.20.3 (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: can still call it directly |
|
Tried the same as @brad-miller and I get the same result. |
|
@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. |
|
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 On a side note, was wondering if the library installed since I couldn't find the examples, until finding it under |
|
@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. |
|
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 ( |
|
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 |
|
Hello
Just out of interest
I have continued to use video lib 2.1 (release 9)
And have tried various implementation including streamer update 1.20.3
On M1 Max 12.5
I am forced to use
"pipeline:avfvideosrc device-index=0 ! video/x-raw, width=640, height=480, framerate=30/1”
Instead of pull reference from Capture.list();
Available cameras:
[0] "FaceTime HD Camera"
(Processing core video:33374): GStreamer-CRITICAL **: 19:11:59.084: gst_bin_add_many: assertion 'GST_IS_ELEMENT (element_1)' failed
(Processing core video:33374): GStreamer-CRITICAL **: 19:11:59.092: gst_element_link_pads_full: assertion 'GST_IS_ELEMENT (dest)' failed
?
Kind regards
On 1 Aug 2022, at 12:17 am, codeanticode ***@***.******@***.***>> wrote:
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):
git clone https://github.com/processing/processing-video.git
cd processing-video/scripts
./pack_macosx_libs.sh
This should result in the macos-aarch64 folder inside processing-video/library
—
Reply to this email directly, view it on GitHub<#199 (comment)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/AB3THKEI2UZB3XCRQSHBGSLVW2DIXANCNFSM5RGLKLUA>.
You are receiving this because you authored the thread.Message ID: ***@***.***>
|
|
@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. |
|
Thx, l did notice and can confirm
B
…Sent from my iPhone
On 11 Oct 2022, at 6:36 pm, codeanticode ***@***.***> wrote:
@brad-miller<https://github.com/brad-miller> Capture on aarch64 macs is already fixed in the main branch of the code, with this commit c2f894f<c2f894f>, it's just that was trying to find some time to fix a few more issues to release as 2.2<https://github.com/processing/processing-video/issues?q=is%3Aopen+is%3Aissue+milestone%3A%22Version+2.2.2%22> but I might just go ahead and release it without any other changes.
—
Reply to this email directly, view it on GitHub<#199 (comment)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/AB3THKFGD4IQQAAAL7DYCZLWCWCPTANCNFSM5RGLKLUA>.
You are receiving this because you were mentioned.Message ID: ***@***.***>
|
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
The text was updated successfully, but these errors were encountered: