Add support for Windows ARM64

[tommyvct]

Description

Add support for Windows ARM64

Motivation and Context

Make OBS Studio great on Windows ARM64 devices.

How Has This Been Tested?

Still need further integrated test.

Types of changes

• New feature (non-breaking change which adds functionality)

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.

[PatTheMav]

Don't use third party actions, if you need a host-version of Qt, wait for the associated x64 job to finish, then use that artifact.

[tommyvct]

okay.

[PatTheMav]

Let us know if that is not feasible as-is - in doubt we can and should amend the current Qt build workflow to generate what this workflow needs. Also I don't think I have seen associated steps in the build scripts ensuring that a host installation of Qt is available to cross compile it?

[tommyvct]

I think that's possible in theory. I will need to dig a little bit about the CI though.

[pbo-linaro]

Hi everyone,

at Linaro, we are actively working to help some projects to support Windows on Arm and we would like to help OBS Studio to get ported on this platform.

It seems like a lot of work has been already done (thanks to @tommyvct - nice nickname by the way).
Is there a specific part where we can help? (automate CI for build dependencies, refactor an existing PR, anything else)

Thanks,
Pierrick

[derrod]

I believe @PatTheMav has also made some progress with getting OBS to run on Windows on ARM (in a VM on Apple Silicon at least) as part of the build system rework that's currently being finalised, so he'll probably have some more insight on the current status of things. This PR is a bit outdated, and will likely be superseeded.

One major concern I am aware of is the lack of hardware encoding support as this only seems to be available via MediaFoundation. And it would probably be quite important to have given the performance - or rather lack thereof - of pretty much all Windows on ARM machines.

[tommyvct]

Is there a specific part where we can help? (automate CI for build dependencies, refactor an existing PR, anything else)

First, thanks for your intention to help, @pbo-linaro !

I was pretty busy working on my degrees in the past 6 months, and after a quick smoke test that I did about a month ago, my previous work fell flat with the current OBS Studio codebase. One of the notable changes that caused the this is the CMake overhaul glued NVENC to the libobs and requires some effort to separate, which the ARM64 build need to get rid of them.

Another major roadblocker, as @derrod said, is the lack of hardware encoding. OBS Studio used to have a Media Foundation encoding backend, but it was removed long ago in favor to vendor-specific solutions like AMF, QSV, and NVENC. The encoding and streaming performance with the version of OBS I compiled before, using software encoding, on a Surface Pro X SQ1, is perfectly usable, even for some light gaming.

Qualcomm chips like 8/7cx series are based on Snapdragon chips for smartphones, which is known to have a hardware encoder. However, after extensive research, I cannot find any usable information about how to utilize the hardware. I did found something remotely close to somewhat useful: there is a PDF document claiming that the encoder supports Windows 8 and some example, indicating the documentation was obsolete. What's worse is the SDK is not easily accessible, at least without contacting and paying a lot of money. I know Linaro is not Qualcomm, and it's gonna be most probably impossible, but can you find us some recent and usable documentation on the Qualcomm hardware encoder? Thanks!

[tommyvct]

And for the CI/Automation part, @PatTheMav has full control of this part. I'm simply extending and replicating his work to make OBS Studio work on Windows on ARM.

For the dependencies, LuaJIT is one of the dependencies that need extensive work, and simd-everywhere also needs a lot of work, but it is not deal-breaking.

[pbo-linaro]

Thanks for your feedback @tommyvct and @derrod.

Good news to hear it's still a work in progress, and that @PatTheMav is on track to enable it.

Concerning the hardware encoding support, I'll contact engineers we work with in Qualcomm, and see what we can do about it.

[PatTheMav]

If we get around to implement ARM64 on Windows support (which will have to be dependent on whether contributors and volunteer supporters feel comfortable with the added support burden given the still somewhat limited availability of Windows for ARM64), we'd probably base it off the native Windows compilation toolchain for FFmpeg instead of cross-compilation.

In my tests there are the following remaining issues:

• libvpx fails to compile with MSVC's native toolchain:
  • libvpx\vpx_dsp\arm\fdct4x4_neon.c(55,52): error C2078
• x264 fails to produce ARM64 assembly by default. The gas-preprocessor perl script used by it are 9 years old and calls cpp to do actual preprocessing (even if cl.exe is used). FFmpeg's fork of the preprocessor fixes this, so the x264's version needs to be replaced with it to build on Windows
• FFmpeg itself just requires the same gas-preprocessor script to be downloaded and made available in the PATH for the compilation

On top of that I think that MediaFoundation support needs to be enabled again, as I would expect Windows on ARM to be running on SOC-based systems (either Qualcomm-based SOCs, Microsoft's own, or Apple Silicon), so much like VideoToolbox it will be the official way to get hardware acceleration working on Windows.

And as correctly pointed out this will also require the obs-studio Windows build system to require MediaFoundation on ARM64 again and ignore AMF/NVEnc and other x64-specific features.

[pbo-linaro]

@PatTheMav In previous messages, it was suggested your were working on the rewrite of the build system. Is that the case? If yes, is that close to completion?

I'm trying to understand when it will be possible to contribute to a "stable" state, to avoid redundant/lost work.

[PatTheMav]

@PatTheMav In previous messages, it was suggested your were working on the rewrite of the build system. Is that the case? If yes, is that close to completion?

I'm trying to understand when it will be possible to contribute to a "stable" state, to avoid redundant/lost work.

That'd be #186.

[tommyvct]

There's an update from the Qt side: https://www.qt.io/blog/qt-for-windows-on-arm

TL:DR is they have yet to decide whether ARM64 or ARM64EC will be their "native ARM64 architecture".

My previous work was all around the ARM64 ABI. If Qt changed their preferred ABI to ARM64EC, then most of my work (not my research and experience, though) would be in vain.

I did some experiments with the dependencies with the ARM64EC ABI before, and it seems that dependencies that's using anything other than msbuild or CMake, or heavily utilize intrinsics, will have major problems. The ARM64EC toolchain self-identifies the target machine as _M_X64, and the compiler and the linker don't have the same invocation behaviour as the x64 one. All in all, the program we are compiling will have some serious identity crisis, unless they are particularly patched for ARM64EC.

ARM64EC doesn't necessarily mean all trouble and no benefit, though. Say if a plugin like LuaJIT still doesn't have Windows ARM64 support, ARM64EC version of OBS Studio could just use the x64 version of DLL just fine.

In the end of the day, the choice between ARM64 or ARM64EC depends on 1) the usage and expectation from the WoA users and 2) the thoughts from the plugin developers and 3) the Qt company.

I personally would lean towards ARM64, since that what we have on hand that is working(?) for now.

[PatTheMav]

From our POV the requirements are quite simple:

• It has to compile when we throw it at MSVC's arm64 compiler

That's all there is to it. We will not cross-compile or use code generated by MINGW toolchains, it has to be compiled with MSVC. This works for almost all dependencies (as I outlined above), libvpx being the only one I wasn't able to figure out a fix for yet.

[tommyvct]

• It has to compile when we throw it at MSVC's arm64 compiler

The question I'm talking about is which compiler or toolset we should use, ARM64 or ARM64EC. I would say just stay with ARM64, since we don't have nasty legacies like some old commercial softwares.

Since our user interface is written in Qt, hence the decision of the Qt company is at important stake.

[driver1998]

If OBS supports va-api on Linux, we might be able to get it working on Windows with the new vaOn12 driver (which wraps va-api to DirectX 12). Not sure about how it works on Qualcomm platform though. (DirectX 12 in general is supported here, but not sure about DirectX 12 video).

Media Foundation is also an option.

[driver1998]

The question I'm talking about is which compiler or toolset we should use, ARM64 or ARM64EC.

I would say ARM64. We are mostly dealing with open source plugins right now, so the benefits of ARM64EC is not very appealing. (We can always port those plugins over, it's not like we haven't dealt with Linux ARM64 or anything).

Also with ARM64 we can use alternative toolchains like MinGW, even though we don't use it for official releases, some plugins might want or require it.

[tommyvct]

It looks that vaon12 is more promising than the media foundation encoder.

[driver1998]

Looks like vaOn12 is decode only on 8cx Gen 2:

$ vainfo
Trying display: win32
libva info: VA-API version 1.18.0
libva info: User environment variable requested driver 'vaon12'
libva info: Trying to open D:/msys64/clangarm64/bin/\vaon12_drv_video.dll
libva info: Found init function __vaDriverInit_1_18
libva info: va_openDriver() returns 0
D:\msys64\clangarm64\bin\vainfo.exe: VA-API version: 1.18 (libva 2.18.2)
D:\msys64\clangarm64\bin\vainfo.exe: Driver version: Mesa Gallium driver 23.1.2 for D3D12 (Qualcomm(R) Adreno(TM) 680 GPU)
D:\msys64\clangarm64\bin\vainfo.exe: Supported profile and entrypoints
      VAProfileH264ConstrainedBaseline: VAEntrypointVLD
      VAProfileH264Main               : VAEntrypointVLD
      VAProfileH264High               : VAEntrypointVLD
      VAProfileHEVCMain               : VAEntrypointVLD
      VAProfileHEVCMain10             : VAEntrypointVLD
      VAProfileVP9Profile0            : VAEntrypointVLD
      VAProfileVP9Profile2            : VAEntrypointVLD
      VAProfileNone                   : VAEntrypointVideoProc

VAEntrypointVLD is decoding support.

[tommyvct]

Well, how about the 8cx gen 3 on the Surface Pro 9?

[driver1998]

Gen 3 is decode only as well, got this output from a friend with Dev Kit 2023:

[driver1998]

I guess you may already know, but ARM64 Windows support of LuaJIT seems to be ready, cross-compiling from Windows x64 MSVC is possible too LuaJIT/LuaJIT#1081.

[tommyvct]

Yeah, I did notice that issue have been closed.

I'm currently waiting for #186 to be merged.

[shijunz]

Yeah, I did notice that issue have been closed.

I'm currently waiting for #186 to be merged.

@tommyvct could you double check the #186 , it maybe is ok today now?

[tommyvct]

Yeah, I did notice that issue have been closed.

I'm currently waiting for #186 to be merged.

@tommyvct could you double check the #186 , it maybe is ok today now?

There are still something to be done on top of that PR. I have been lazy and busy, I will try to find a time to try if it works

[i-lina]

Thanks @tommyvct your help in this would be much appreciated.

[i-lina]

Hello @tommyvct,
Were you able to make any progress on this?
Thanks!

[tommyvct]

Hello @tommyvct, Were you able to make any progress on this? Thanks!

This PR will most likely be superseded by #190.

There are still quite a few things that we are waiting to be fixed in the upstream.