Add native MSVC build support for Windows

[StormBytePP]

Add native MSVC support

This pull request introduces first-class, native MSVC support for libvmaf on Windows.
The goal is to enable building, testing, and integrating libvmaf using the Microsoft Visual C++ toolchain without relying on MinGW/MSYS2, greatly improving compatibility with Windows-native projects and CI environments.

Motivation

Until now, libvmaf could only be built on Windows through MinGW/MSYS2. While functional, this approach had several limitations:

• Native Windows projects (CMake, Visual Studio, FFmpeg builds, etc.) could not easily consume MSYS2-compiled libraries.
• MSVC is the standard toolchain in most Windows CI/CD pipelines.
• Debugging, profiling, and static analysis tools on Windows work best with MSVC binaries.
• Distributing official Windows binaries is significantly easier when built with MSVC.

This PR adds full native MSVC support, including:

• Meson build configuration compatible with MSVC
• Working static library build
• Working test suite execution
• Fully functional GitHub Actions CI for MSVC builds (both standalone library and with FFmpeg)

Dependencies / Related PRs

This PR depends on the following PRs being merged first.

Merging them first is especially important to ensure proper credit and authorship for all contributors — particularly for the two PRs that were not authored by me (#1410 and #1428).

Once those PRs are merged upstream, the temporary copies of their commits (included here only for CI to pass) will be removed. This way the original authors receive full and fair attribution in the git history.

The required PRs are:

• AVX2: Improve SIMD portability by replacing non‑portable indexing and casts #1475
• Add ya_getopt, a 2-clause-BSD-licensed implementation of getopt_long() #1410
• Fix UB in void* pointer arithmetic and memory leak in VIF init #1476
• MSVC: Avoid the use of variable-length arrays #1428

This ensures:

• CI runs correctly
• MSVC builds succeed
• The test suite passes
• No regressions are introduced

What’s included

• Added pthread-win32 as a git submodule for MSVC builds
• Native MSVC build support via Meson
• Updated Meson configuration for full MSVC compatibility
• New Windows CI workflow using a matrix for MSYS2 + MSVC
• Automatic installation of required tools in CI (meson, ninja, xxd, cmake)
• Full test suite passing on Windows (standalone library and with FFmpeg)
• Clean separation between MSYS2 and MSVC environments
• No changes to existing Linux/macOS workflows
• Updated Windows.md documentation to include MSVC instructions

CI Improvements

The new GitHub Actions workflow builds both MSYS2 and MSVC in parallel, runs the full test suite under each environment, and uploads artifacts for both toolchains.

Importantly, the inclusion of the Windows MSVC tests (both with FFmpeg and the standalone library) in CI guarantees that Windows support will not be accidentally broken in the future. This provides ongoing assurance and prevents regressions as the project continues to evolve.

Issue reference

Closes #1097

Notes

• This PR does not modify existing behavior on Linux or macOS.
• MSVC support is fully optional and isolated from other platforms.
• Once the dependent PRs are merged, this branch will be rebased to remove the temporary commits.
• Run git submodule update --init after checkout to pull the pthread-win32 submodule.

About tox tests on Windows

This PR intentionally does not enable the Python tox test suite on Windows.
While the MSVC build and the C test suite are fully supported, the Python tests rely on several Unix-specific behaviors (e.g., fork()-based multiprocessing, POSIX path assumptions, and .exe suffix handling).
These issues require non-trivial work to make the tox suite fully compatible with Windows and would significantly increase the scope of this PR.

Windows tox support will be evaluated and implemented in a separate PR once native MSVC support is merged.

About the FFmpeg build used in CI

The MSVC CI job also builds FFmpeg to validate that libvmaf integrates correctly with a Windows-native FFmpeg toolchain. For this purpose, the workflow uses the Meson-based FFmpeg port maintained by the GStreamer project.

This port provides a clean Meson build of FFmpeg that supports MSVC out of the box, making it ideal for verifying that libvmaf builds and runs correctly in a fully native Windows environment. The Meson-based FFmpeg port is used exclusively for the MSVC job; the Linux and macOS CI jobs continue to use the official FFmpeg repository exactly as before.

Status

• Builds successfully with MSVC
• Test suite passes
• Models compile correctly
• CI green for both MSYS2 and MSVC
• No regressions on other platforms
• Commit history cleaned and ready for merge

[StormBytePP]

Hi everyone,

First of all, apologies for the noise — there were quite a few force‑pushes while I was trying to understand what looked like a regression in the macOS FFmpeg+libvmaf build. I genuinely thought I had introduced the issue myself, and it took a while to figure out what was actually happening.

Good news: the PR is now fully green across all platforms, including MSVC, which produces exactly the same VMAF score as the original workflow.

A small warning regarding macOS: while investigating, I temporarily removed continue-on-error: true and noticed that the VMAF test fails on macOS with:

93.663964
vmaf score doesn't match 93.663925

After dropping all my changes to double‑check, I confirmed that the original workflow also prints this mismatch — it simply goes unnoticed because continue-on-error: true was already there. I’ve restored that behavior so the PR matches the original CI logic, but the underlying discrepancy was not introduced here.

The difference is very small, but I wanted to highlight it explicitly so reviewers are aware.

With everything now stable and the CI behaving consistently, the PR is ready for review.
Thanks for your patience!

P.S. Ironically, I don’t even use Windows except for gaming — but at least now FFmpeg+libvmaf builds cleanly on MSVC.