Add native arm64 build slice to all Windows dependencies

[PatTheMav]

Description

This is an exploratory PR for possible future native ARM64 builds on Windows.

Some dependencies cannot be built for ARM64 yet, others require specific workarounds, yet others can be built for ARM64 but themselves are too recent to be supported by OBS Studio.

This PR will stay in draft state until these and other issues are solved and are in a state that do not result in unnecessary support burden to current maintainers and supporters.

This PR is based on #186 and the PRs it depends on.

Motivation and Context

Due to Visual Studio 17 2022 having full support for ARM64 builds as well as clang- and Ninja-based builds, selecting the correct build architecture for MSVC builds does most of the work to achieve native builds, there are some caveats though:

• libvpx requires disabling more advanced NEON features not made available by Microsoft's ARM64 implementation.
• x264 requires an update of the gas-preprocessor it ships with - luckily FFmpeg provides a very recent version of it (the version shipped with x264 is 9 years old)
• FFmpeg requires the same gas-processor to be made available in the PATH
• svt-av1 has not been made available as it's not well optimised for ARM64 - dav1d would be a better alternative, but aom is "good enough" for now
• Qt6 builds without any additional hacks or issues
• LuaJIT has merged ARM64 and is available now
• Python supports Windows ARM64 since version 3.11, alas OBS Studio does not support Python 3.11 at runtime yet (you could build OBS Studio with it, but people couldn't add its libraries at runtime)
• mbedtls is still broken on ARM64 with version 3.5.1
• libdatachannel requires at least mbedtls 3.4.0, so both are entirely broken on ARM64 right now
• vpl is disabled for ARM64
• Aja NTV2 is disabled for ARM64

How Has This Been Tested?

Tested on Windows 11 ARM64.

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.

[driver1998]

What is the error exactly in building mbedtls? I saw upstream fixed similar issues multiple times.

[PatTheMav]

What is the error exactly in building mbedtls? I saw upstream fixed similar issues multiple times.

Compiling aes.c breaks with version 3.5.1:

error C1189: #error:  This header is specific to X86, X64, ARM64, and ARM64EC targets

This is possibly fixed by Mbed-TLS/mbedtls#8168, so we're waiting for MbedTLS to cut a new release with those fixes included.

[tommyvct]

This needs to be rebased and merge #227 in.

[RytoEX]

This needs to be rebased and merge #227 in.

@PatTheMav and I work closely together off-thread. Rest assured, that we discuss this regularly. However, do note that this is being worked on as time and other priorities allow. Thank you for your understanding.

[tommyvct]

together off-thread. Rest assured, that we discuss this regularly.

May I join the conversation?

[RytoEX]

together off-thread. Rest assured, that we discuss this regularly.

May I join the conversation?

I appreciate the enthusiasm, but these are conversations that we have either on voice calls or in ongoing DMs about getting stuff to work. It is mostly stuff like "so about that PR" and "here's an idea" and "here's how we might get that to work when we have time". The point is that he doesn't need a reminder to rebase this. He's aware. This is on our roadmap to address.

[tommyvct]

How about we start a separate thread in the development channel? Or I could just ask and @ both of you in the channel?

[RytoEX]

Just some quick observations. I did get a local Qt build working, but it requires setting both QT_QMAKE_TARGET_MKSPEC and QT_HOST_PATH. I've commented how I might approach this for CI. We can attempt to optimize it later.

[RytoEX]

Was just skimming back over this.

• x264 requires an update of the gas-preprocessor it ships with - luckily FFmpeg provides a very recent version of it (the version shipped with x264 is 9 years old)
• FFmpeg requires the same gas-processor to be made available in the PATH

This seems like it should be a trivial Merge Request on the x264 repo. Ideally, I'd like the change to happen there at some point.

• svt-av1 has not been made available as it's not well optimised for ARM64 - dav1d would be a better alternative, but aom is "good enough" for now

VideoLAN's dav1d is a decoder only. It is not an encoder. Xiph's rav1e is an encoder.

[RytoEX]

I don't think we can update to libsrt 1.5.3 or we'll run into the issues linked in #240.

Restating that, if possible, I'd like to see the patches for SRT and libpng upstreamed to their respective repos. I'm mostly only concerned that the patches get submitted. I have been unable to register an account on the VideoLAN GitLab instance to open an Issue about their outdated gas-preprocessor.

[RytoEX]

As discussed off-thread with @PatTheMav , updating libsrt to 1.5.3 has known issues in OBS Studio on Windows. These are supposedly resolved in libsrt 1.5.4, which is not yet out/stable. It's not clear to me that libsrt 1.5.3+ is required for WoA/arm64. Can we confirm?

Separately, MbedTLS 3.6.0+ is required for WoA/arm64, as far as I know. However, we cannot update that until Haivision/srt#2957 is fixed. This seems to have been addressed by deps.ffmpeg/patches/srt/0002-update-mbedtls-discovery-windows.patch included in this PR. We should submit that as a PR to the srt repo. They can decide whether or not to merge it.

If we need libsrt 1.5.3+, either we wait for all dependencies to be stable, or we teach the Windows dependency build scripts to build different versions per target architecture.

Additionally, I still cannot build obs-studio on Windows against libsrt 1.5.3+ and mbedTLS 3.6.0+ due to the bcrypt linking issue, even with the patch here. I haven't tried obsproject/obs-studio#11056 because it fails on CI, and needs to be rebased (I'm guessing gersemi changes).

[PatTheMav]

Updated srt to 1.5.3 and MbedTLS to 3.5.2.

[RytoEX]

Can you fix the merge conflict here so that CI creates new artifacts?

[PatTheMav]

Can you fix the merge conflict here so that CI creates new artifacts?

Done.

[RytoEX]

Some questions and some paper trail keeping.

[RytoEX]

SRT streaming works with these deps and I cannot seem to reproduce any freezes or crashes, though I am admittedly not clear on the exact steps to reproduce the previously reported freeze/crash.

RTMPS streaming to YouTube works fine.

HLS streaming to YouTube sometimes seems to fail with these deps. The failure state will result in the stream output dropping all frames. Clicking "Stop Streaming" will result in a stuck "Stopping stream..." button, and trying to exit will hang the application. I suspect the "Stopping" and hang issues are not related to these deps specifically, and I'm not sure that the initial failure is either (it could just be timing issues with YouTube's disconnect detection with HLS weirdness).

MbedTLS and SRT are the only deps updated here, so the tests above seem sufficient for now. If we find issues with either update, we'll need to aggressively debug them and open issues as needed, or figure out a way to use the newer deps only for WoA.

[Fritomaster]

Appreciate you guys working on this. As an artist who streams my work and uses mostly arm now this would be great!

[i-lina]

Thank you for this feature. Which release is this feature targeted at?