Excited for this release since it contains M1 Apple VT H264 Hardware Encoding support[1] — I know on my Intel Mac, OBS would massacre the CPU if I didn't have the hardware encoding enabled. On the M1 it's not quite so bad, but being able to use hardware encoding does save a lot of CPU cycles when streaming at higher bitrates!
So I've had the reverse issue. With hardware encoding on and external monitors plugged into my intel macbook, everything would overheat and I would get kernel throttling of everything.
The external monitors cause the GPU to draw more power, but I'm not sure why that combined with hardware encoding in OBS caused issues. When I switched to software encoding the cpu was a bit higher but everything was fine.
Apparently this is related to VRM overheating and people have workarounds posted on reddit, but it seem like switching to software encoding made it go away for me.
I’ve had the same issue, it’s critical to get fans to cool your MacBook pro since they are not capable of cooling themselves under load, especially i7 or i9.
I have cabinet fans under mine and it works great, just don’t ask me to use a MacBook Pro as a laptop.
And if not fans, I actually just elevated my MacBook Pro on a cooling laptop stand (with no ventilation) and that was enough to keep it cool for hours-long streaming.
Any idea when it’s coming? I know no one likes that question, but... well, I have an M1 Air, and I’d love to stream some coding sessions or tutorials. So arm64 support would be tasty.
Is there some way we could help with the arm64 patching?
I actually managed to build OBS for M1 Mac. All the dependencies do have arm support. I only had to make small changes in the cmake file for arm64. Right now I am stuck at the part of signing the OBS app package. Without code signing Mac cannot open it.
My smoothbrained take is that it'll be a little bit, since optimizing it for ARM is going to take a little effort. Like GP said, it's really about the encoders slowly being updated to better support the hardware.
There’s still also the lack of Metal support - OBS still uses OpenGL to composite everything together, and Metal should be more highly optimised on newer macOS versions and the new chips than the long-deprecated (on Mac) OpenGL.
Somebody actually did write a Metal renderer and contributed it in a pull request a few years ago. The comments were like “Oh, why did you do this? OpenGL is fine” from the lead developer. The backend just didn’t get merged (I think the developer who contributed it didn’t have great English so struggled to explain why they’d want it, and nobody who commented really seemed to know much about the Mac platform… the code looked fine though).
So that renderer was never merged, and then about six months later OpenGL was deprecated on macOS. The contributed backend is probably quite out of date with changes to OBS’s APIs etc. now.
It’s a shame, there just don’t seem to be many developers contributing to OBS that care at all about Mac as a platform, so I wouldn’t hold my breath if I was you for them doing much “optimising for ARM”.
> there just don’t seem to be many developers contributing to OBS that care at all about Mac as a platform
This has definitely become a trend as of late. If I had to guess, the lead devs are (rightfully) frustrated that Apple depreciated OpenGL so quickly for a proprietary solution that nobody really likes working in. Furthermore, maintaining a Metal compositor would be a royal pain in the ass, since there's no real middleware layer to help with debugging or tuning.
Honestly can't blame the poor people. Maintaining Mac software is a neverending chore.
I was able to build OBS from source for M1 Mac. I don’t know how optimized it is. But with few changes to the cmake files you can build it without errors. The only part I am stuck is with code signing. You need to code sign, if not it crashes.
[1] https://github.com/obsproject/obs-studio/issues/4170