Windows ARM64 Support

[tommyvct]

Description

Port OBS Studio to Windows ARM64

You can find the latest build here: https://github.com/tommyvct/obs-studio/releases

Motivation and Context

Microsoft launched another ARM based Windows device in October 2019, and this time it looks promising. More and more manufactures are joining the Windows ARM64 force and their product looks promising, too. This time the situation is much better than Windows 8 era. ARM devices are always on, always connected, consume much less energy, and have days of battery life.

Then I bought it. It was great except the lack of native ARM64 software. I decided to do my part to make it better by porting open source software to Windows ARM64.

How Has This Been Tested?

It compiles, and can stream and record on Windows ARM64 devices like Surface Pro X.
CI Builds can be found here:

Types of changes

Breaking Changes, New Feature

See also

https://github.com/obsproject/obs-studio/wiki/Build-Instructions-for-Windows-ARM64

Road to official release

PR Dependency

The following PR needs to be merged first:

• [x] #4730 or #4601
• [x] #4743
• [x] #4746
• [x] #4748
• [x] #5654
• [x] #7609

External Dependency

• [x] Wait for OBS scripting to move to at least Python 3,8
• [ ] Wait for Python to officially support Windows ARM64
• [ ] Wait for LuaJIT
• [ ] Wait for VideoLAN to pay more attention to Windows ARM64 platform

Quality of Life Improvements

• [ ] SIMDe for Windows ARM64 #5067
• [ ] Qualcomm Hardware Encoding
• [ ] CEF Hardware Acceleration

Checklist:

• [x] My code has been run through clang-format.
• [x] I have read the contributing document.
• [x] My code is not on the master branch.
• [x] The code has been tested.
• [x] All commit messages are properly formatted and commits squashed where appropriate.
• [x] I have included updates to all appropriate documentation.

[tommyvct]

This is only a draft for now, and I may consider slowly cherry-picking them out from here to separate PRs if needed.

This branch does need some substantial rebase process. I'm currently thinking about how to do it. Maybe I'll delete all of these commits and start over.

The mentioned PRs are needed for it to compile for Windows ARM64, should I merge these PRs into this branch, or not? @RytoEX

[RytoEX]

Instead of merging other branches into your branch or creating merge commits, please rebase your changes on top of the current git master.

For an example of how you can incorporate changes from separate, but dependent, PRs into this one, see #5218 and its various related PRs.

[tommyvct]

Instead of merging other branches into your branch or creating merge commits, please rebase your changes on top of the current git master.

That's exactly what I did, git rebase master, but somehow I messed something up. Probably GitHub Desktop have something to do with this.

[RytoEX]

Instead of merging other branches into your branch or creating merge commits, please rebase your changes on top of the current git master.

That's exactly what I did, git rebase master, but somehow I messed something up. Probably GitHub Desktop have something to do with this.

Looks like the second force push you did corrected the issue I was seeing in the GitHub Web UI.

[WizardCM]

So, in terms of the remaining items:

External Dependency

• OBS Scripting on Windows ARM can be 3.8 without having to update it on Windows x32/x64, and I'd be OK with that as an intermediate
• LuaJIT apparently supports ARM on the 2.1 branch. Would definitely be worth attempting
• For VLC, it seems ARM support will be limited to VLC 4.0 anyway, and I don't know how well 4.0 works with OBS

Quality of Life Improvements

• The SIMDe update could probably be merged as-is, and if people run into issues they can PR the relevant fixes
• For Qualcomm hardware encoding, we have two possible paths. One would be much harder than the other, but I don't know just how much work either would require. I don't see much use in custom-writing a Qualcomm encoder at this time.
  • FFmpeg: Since 2017, it has had a Media Foundation wrapper, which we could use to access the Qualcomm encoder indirectly. Preferred.
  • Media Foundation encoder: Similar to VAAPI on Linux and Apple VT on macOS, writing a MF encoder that controls the Qualcomm encoder directly
• As mentioned in the CEF Discussion, we've made progress in updating to CEF 95. Additionally, we have successfully built an ARM64 version with our usual settings, but potentially without our best enhancements. It is likely in a shippable state though.

So, with all of that said - I think next steps to get this merged would be (in order):

1. [ ] Attempt building Windows ARM with a different Python version than x64
2. [ ] Attempt building with 2.1 LuaJIT
3. [ ] Attempt building/running with VLC 4.0, and skip this for the first Windows ARM release
4. [ ] Merge the SIMDe update if we're all happy with it
5. [ ] Validate our CEF update on ARM (I'll message you about this)
6. [ ] Research adding the FFmpeg Media Foundation to the list of encoders in OBS (this is likely very complex)

[tommyvct]

Attempt building Windows ARM with a different Python version than x64

Though I didn't test it, but I think x64 Python won't work with ARM64 OBS Studio. In another word they need ARM64 Python to make it work. The problem is there is no official ARM64 Python build for Windows yet.

Attempt building with 2.1 LuaJIT

I don't know how much ABI differences are there between 2.0 and 2.1. But it's indeed worth trying

Attempt building/running with VLC 4.0, and skip this for the first Windows ARM release

Let's see how long will they take to release VLC 4.0 . Their documentation sucks, and there is no good documentation on mingw-clang toolchain either. I need to wait until they fix their documentation, or someone from them to work with me.

Merge the SIMDe update if we're all happy with it

Don't merge it yet, that thing actually caused a lot of havoc on their CI, probably because SIMDe is simply not ready for Windows ARM64. I haven't touch that branch for quite a while, if I remember correctly, that new version of SIMDe also caused havoc on my end, especially for ARM64. I also remember that either RytoEX or Jim said SIMDe itself is rarely used, and the current version (software emulated SIMD) works just fine, so I'm not gonna update it yet if the current one is not broken.

Validate our CEF update on ARM (I'll message you about this)

👍
This should be the easy part.

Research adding the FFmpeg Media Foundation to the list of encoders in OBS (this is likely very complex)

I HATE AUTOTOOLS.
This may take a LONG time to implement, as I need to learn everything from ground up.

[tommyvct]

Update: PR #5155 merged

PR #5155 contains the long awaited Apple Silicon support along with a complete CMake overhaul by @PatTheMav is recently merged to master branch. Thus, by the side effect, the said PR introduced a lot of breaking changes to the build system which broke the current Windows ARM64 build. I'm really busy these days with school and other stuff, so I won't be active as before. I'll try my best to keep this updated.

[PatTheMav]

You might want to familiarise yourself with https://github.com/obsproject/obs-deps/pull/98 first, to get the dependencies for Windows arm64 built automatically - specifying different architectures to the script is built-in to the Powershell and Zsh frameworks used there.

[tommyvct]

@mosullivan93 Feel free to make yourself here home. Sorry I missed your email that long.

[mosullivan93]

Thanks @tommyvct :+1: I'm running the Surface Pro X (gen 1) and I'm happy to test out any functionality if you need.

[RytoEX]

You do not need to pull in commits that are unnecessary to this PR's scope into this PR. It just creates more notifications for those subscribed. I don't think that the Taskbar Overlay commit is in scope, and I do not think it needs to be included here. It can stand on its own in its own PR, #6658.

[driver1998]

@tommyvct I am working on building VLC on MSYS2 CLANGARM64 environment right now, seems to work just fine. Will keep you posted.

[tommyvct]

Which version? I don't think VLC3 will work for Windows on ARM without major change.

[driver1998]

3.0.17, I only added one more patch on top of the current PKGBUILD.

Will need to figure out how to incorporate it into obs-deps though, since MSYS2 does not currently support cross-compiling.

[driver1998]

I didn't see vlc stuff in obs-deps, how should I build it for OBS use? BTW, the MSYS2 CLANGARM64 build works:

[driver1998]

Speaking of Lua, will use original Lua makes more sense than building everything as ARM64EC and link to x64 version of LuaJIT? Lua 5.1 builds just fine on Windows ARM64.

[tommyvct]

Great work!

I wonder if the VLC you compiled uses hardware acceleration? For OBS Studio, libvlc is what it want instead of the VLC media player. But since you already figured out the VLC, libvlc should not be a hard problem.

About LuaJIT, we probably just have to wait for the upstream to figure it out.

ARM64EC is used to be an option, but other dependencies like Qt will fall apart. About half a year ago I figured out getting Qt 6 on ARM64EC, but it wasn't straight forward. It's also not optimized because the use of softintrin.h instead of real ARM SIMD. But for OBS Studio, getting Qt to work with ARM64EC isn't enough; there are ffmpeg, x264, etc, none of them liked ARM64EC. Microsoft claimed that ARM64EC is a drop-in solution for turning X64 apps into ARM64 apps, it was true for projects at a smaller scale, but definitely not true for large projects like OBS Studio with loads of external dependencies.

[driver1998]

Hardware acceleration does work in VLC, both H264 and HEVC decode is accelerated on my 8cx.

[RytoEX]

I didn't see vlc stuff in obs-deps

We do not build VLC for OBS. We only use VLC headers.

[driver1998]

Speaking of Lua, will use original Lua makes more sense than building everything as ARM64EC and link to x64 version of LuaJIT?

So I tried this route when porting Aegisub (Typesetting fork) to Windows ARM64, it also uses LuaJIT for automation. The build works just fine after some code fixing.

But since all Aegisub Lua scripts rely on FFI module (which is only supported in LuaJIT, not regular Lua), they all fail to run.

There is luaffi which brings FFI support to regular Lua but that looks like it is ported straight from LuaJIT, not very useful.

Not sure if OBS relys on Lua FFI, if it does not, regular Lua should work just fine.

My Aegisub fork is at https://github.com/driver1998/aegisub.

Edit: just found out https://github.com/q66/cffi-lua when googling around, which is based on libffi. Might try that later.

[driver1998]

BTW, my PR of VLC on MSYS2 CLANGARM64 is merged, binary packages are being processed right now.

Edit: It's in! https://packages.msys2.org/package/mingw-w64-clang-aarch64-vlc?repo=clangarm64

Looks like there is some interest making it official in upstream as well. https://mailman.videolan.org/pipermail/vlc-devel/2022-September/143475.html @tommyvct

[tommyvct]

To whoever forked this: please kindly leave a message here and say what are you working or plan to work on. This is to minimize double work.

I'm officially freed from most of the coursework. My current plan is to work on the dependencies first. The original dependencies were manually compiled and this process should be automated.

The changes here in this PR were already enough to make OBS Studio running on ARM64 Windows machines. Now the major lacking part of this project is 1) dependencies automation and 2) MediaFoundation encoding.

[tommyvct]

Current status

As of this commit, the Windows ARM64 port is near complete. The dependey automation is also almost complete and can produce usable dependencies. The CI on both OBS Studio and it's deps are still lacking.

[Xazax-hun]

Python has experimental arm64 installers on its website, and I believe LuaJIT can be compiled for arm64 on windows.

In case you need testers, I have an arm64 device and can do some light testing.

[Xazax-hun]

Oh, there are also arm64 nightly builds for VLC: https://artifacts.videolan.org/vlc/nightly-win64-arm-llvm/ So VideoLAN is also starting to pay more attention to Windows ARM64

[shijunz]

Current status

As of this commit, the Windows ARM64 port is near complete. The dependey automation is also almost complete and can produce usable dependencies. The CI on both OBS Studio and it's deps are still lacking.

what is news now? it is completed?

[tommyvct]

Current status

As of this commit, the Windows ARM64 port is near complete. The dependey automation is also almost complete and can produce usable dependencies. The CI on both OBS Studio and it's deps are still lacking.

what is news now? it is completed?

Unfortunately, due to some upstream changes, it’s currently no where near completed. The Windows dependencies are currently being overhauled to use the MSVC toolchain. It’s better to wait for that overhaul to be completed first, then we can have proper support for Windows ARM64.

[shijunz]

Current status

As of this commit, the Windows ARM64 port is near complete. The dependey automation is also almost complete and can produce usable dependencies. The CI on both OBS Studio and it's deps are still lacking.

what is news now? it is completed?

Unfortunately, due to some upstream changes, it’s currently no where near completed. The Windows dependencies are currently being overhauled to use the MSVC toolchain. It’s better to wait for that overhaul to be completed first, then we can have proper support for Windows ARM64.

could you guide me to build windows ARM64? I want to try it. I have qcom arm windows compute now.

[tommyvct]

Basically:

1. try to compile all the deps from obs-deps. They use pwsh scripts to automate the building process.
2. rule out what's not needed or not possible on Windows ARM64 platform. For example, AJA stuff (until someone really need to hook AJA AV hardware onto a Windows ARM64 machine), LuaJIT (it seems the upstream support is done, but still to be tested, just disable it for now), VLC (they don't have an official support for Windows ARM64 yet) and obviously any AMD/NVIDIA stuff.
3. once you can get a good deps package, compile OBS Studio itself using this deps package.
4. until you got a working binary, keep fixing what error spit out by the compiler.

The MSVC toolchain dep PR has been merged not long ago, and I just started getting back. So far there is one catch, as of now, lib carla is one of new deps added to the windows deps list. I don't exactly know why it was added, but it was being removed (see https://github.com/obsproject/obs-deps/pull/227). Make sure to apply this PR to the main branch before compiling.

The last time I tried to compile OBS Studio, there were some regressions that needs quite a lot of work. For example, NVENC is somewhat glued in while it needs to be removed entirely for Windows ARM64 build.