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:

• obs-filters: Add preprocessor guard to libSpeexDSP method #4730 or obs-filters: Don't require libSpeexDSP to compile #4601
• Resolve potential symbol clash on MSVC #4743
• libobs: Restrict emmintrin.h to x86(_64) MSVC platform #4746
• cmake: Add ENABLE_QSV11 option to disable QSV encoder #4748
• Remove Qt Windows Extra for Qt 6 and later #5654
• libobs: Add Windows X64 Emulation on ARM64 and move Rosetta Detection #7609

External Dependency

• 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 libobs: update simde #5067
• Qualcomm Hardware Encoding
• CEF Hardware Acceleration

Checklist:

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

[RytoEX]

Please don't include merge commits or revert commits in PRs.

Please adhere to our Commit Guidelines.

Multiple commits seemingly commit the same changes:

• 64fdaac
• c32c8ff

You do not need to use backticks in commit messages. They don't render in Git CLI, so they're just taking up extra characters.

Some of the dependent PRs make the same changes present in this PR, but with different commit messages.

[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.

[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 obsproject/obs-deps#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.

[paulh-aja]

2. For example, AJA stuff (until someone really need to hook AJA AV hardware onto a Windows ARM64 machine)

We don't have a Windows ARM64 driver for AJA devices yet. It is safe to disable AJA plugins in a Windows ARM64 build.