Closed BryanHaley closed 2 years ago
tjhorner
commented
3 years ago I get this too. Here's a temporary workaround until this gets resolved:
export DYLD_LIBRARY_PATH="/opt/homebrew/lib"
# might need to change the below to wherever your OBS.app is
/Applications/OBS.app/Contents/Resources/bin/obsNote that this will technically be running inside of whatever terminal emulator you use, so you'll need to grant that access to accessibility, screen recording, etc.
BryanHaley
commented
3 years ago That worked to get it to open, but I've run into another strange issue:
$ /Applications/OBS.app/Contents/Resources/bin/obs
error: Failed to load locale
info: == Profiler Results =============================
info: run_program_init: 11732.4 ms
info: ┗OBSApp::AppInit: 8568.46 ms
info: ┗OBSApp::InitLocale: 8566.16 ms
info: =================================================
info: == Profiler Time Between Calls ==================
info: =================================================
info: Number of memory leaks: 1
I looked and confirmed that OBS.app/Contents/Resources/data/obs-plugins/obs-outputs/locale/en-US.ini exists and is identical to the version shipped with the Intel app.
Very strange that the application seems to be having issues finding files. Could this maybe be related to new file-access permissions in Monterey?
ntelementary
commented
3 years ago Can concur, I get the same "locale/en-US" issue as @BryanHaley after a fresh build when using the DYLD trick above.
One thought was that this was related to the com.apple.quarantine "xattrs" feature on the compiled package (you can see a note about this on the obs-deps GitHub page), but running a few xattr -p com.apple.quarantine checks on the Resources/data/...etc/...locale direction didn't show anything interesting.
File permissions seem correct in the package as well. Maybe this is a side-effect of the DYLD launch trick coming from a different terminal-process sandbox? (Wanton speculation here).
adamalbers
commented
3 years ago I just ran this script on my 2020 13" Macbook Pro M1 and had no errors. OBS seems much faster running natively with this build.
My terminal app (iTerm 2) has Full Disk Access and I had previously installed some prereqs described in a reddit post about compiling OBS for Apple Silicon.
brew install akeru-inc/tap/xcnotary cmake cmocka ffmpeg jack mbedtls@2 qt@5 swig vlc
https://www.reddit.com/r/MacOS/comments/mycoul/obs_for_m1/
BryanHaley
commented
3 years ago No dice with giving terminal full disk access and installing those things through brew.
adamalbers
commented
3 years ago Curiously, if I run /Applications/OBS.app/Contents/Resources/bin/obs from a terminal, I get the same locale/en-US error. But when I run from double clicking OBS.app in Finder, it opens without error.
This is all out of my wheelhouse as I'm not a programmer, but want to contribute what I can.
***EDIT: Have to change working directory then launch OBS in terminal to avoid the locale error.
cd /Applications/OBS.app/Contents/Resources/bin ./obs
BryanHaley
commented
3 years ago I deleted the OBS.app and ran the script fresh. This time, OBS works as expected; no need to launch it from the terminal.
Not sure what exactly changed between the first attempt and the most recent one. I don't think setting the DYLD_LIBRARY_PATH in my bash_profile would affect launching an app via finder. That just leaves running
brew install akeru-inc/tap/xcnotary cmake cmocka ffmpeg jack mbedtls@2 qt@5 swig vlc
before install. I thought the build script installs everything it needs before building, but maybe it's missing one of these? Or perhaps setting the DYLD_LIBRARY_PATH before building changes something?
ntelementary
commented
3 years ago Same here, after the suggestions I also tried a different build and — success!
It turns out I already had the packages installed that @adamalbers suggested. I do not have DLYD path overrides in my bash profile.
The only change I made before my rebuild was to grant Full Disk Access to Terminal in Preferences > Security.
After another build with the script, OBS is now running successfully on Apple-M1 architecture. It uses far less CPU than the Intel version, even when idle (from 100% on one core, down to ~72% CPU). And when actively streaming to twitch, it consumes drastically less CPU. The Intel version would peak at ~245% CPU, whereas the native version stayed around 140% or below in my testing.
Hopefully OBS will have native M1 builds soon, they're noticeably quicker to launch (~2 seconds versus 5-10 seconds), and saves tons of CPU.
The only downside is that Apple identifies the app as 'sh' (The application "sh" would like screen recording access), but this is a minor triviality.
BryanHaley
commented
3 years ago I also enabled full disk access for terminal before the build; forgot about that. Hopefully we'll get hardware encoding soon, but I suspect we'll have to wait for movement from the OBS team for that.
If anybody is reading this in the future looking for a solution, try the following:
brew install akeru-inc/tap/xcnotary cmake cmocka ffmpeg jack mbedtls@2 qt@5 swig vlcexport DYLD_LIBRARY_PATH="/opt/homebrew/lib"
# might need to change the below to wherever your OBS.app is
cd /Applications/OBS.app/Contents/Resources/bin && ./obsShouldn't we keep this issue open until the workaround is no longer needed?
carlosonunez
commented
3 years ago Hey, @BryanHaley ! Thanks for opening this issue. I apologize that you're running into this.
Which version of OBS are you trying to compile? I can't replicate this with OBS 27.0.1 on my M1 Pro MacBook.
You shouldn't need to enable FDA for OBS.
Also, can you show me your output from running ./install.sh?
carlosonunez
commented
2 years ago Closing due to staleness. Re-open and submit logs per the comment above if needed.
Machine info: MacOS Monterey Version 12.0 MacBook Pro (16 inch, 2021) Chip Apple M1 Max Memory 32GB
Crash log:
Seems that it can't find libavcodec. Strangely, copying libavcodec* from /opt/homebrew/lib/ over to /usr/local/lib/ where it's supposedly looking for it makes no difference; it will crash with the same output.