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 How to build libvmaf.lib for use with Visual Studio #1097
• Related to libvmaf with CUDA -- how to build for Windows #1301 (CUDA on Windows; fully addressed together with CUDA: Fix compile, SIGSEGV and tests #1573)

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.

[StormBytePP]

Hi @kylophone,

just a gentle ping on this PR.

I noticed the task list still shows some unfinished items (mainly due to dependencies on other PRs), but the work is actually complete and ready for review.

Would really appreciate it if you could take a look whenever you have a moment. Happy to address any feedback!

Thanks a lot for maintaining VMAF 🙏

[kylophone]

Hi @kylophone,

just a gentle ping on this PR.

I noticed the task list still shows some unfinished items (mainly due to dependencies on other PRs), but the work is actually complete and ready for review.

Would really appreciate it if you could take a look whenever you have a moment. Happy to address any feedback!

Thanks a lot for maintaining VMAF 🙏

I am working my way through the PR backlog. I will be taking a look at this before our next release.

[StormBytePP]

@kylophone I've rebased the PR against the latest master and updated the code so everything works again.

A couple of notes:

• There is a very small difference (~0.0001) in the VMAF score on the MSVC + FFmpeg test. It is negligible and does not affect practical results.
• I have added a new option -Dbundled_winpthreads (default: true). This allows using either the bundled pthread-win32 implementation or an external Windows pthreads library.
  More details can be found in the updated Windows documentation:
  https://github.com/StormBytePP/vmaf/blob/86c9829e31e74537adbe55661f84f9abda6e4177/resource/doc/windows.md
• To compile FFmpeg with libvmaf using MSVC, please use Meson 1.10.0. Meson 1.11 introduced a regression that prevents proper detection of libvmaf (and possibly other plugins): MSVC: /release linker flag leaks into cl.exe command line in has_function() tests (regression in 1.11) mesonbuild/meson#16086
• While enabling CUDA on MSVC I also hit a few serious build/runtime issues that were not Windows-specific. Those are fixed in PR CUDA: Fix compile, SIGSEGV and tests #1573 (and help Linux as well).

The CI now also tests both the bundled and external pthreads modes on MSVC.

Please let me know if you need any further changes.

P.S. GitHub Actions is currently hitting network issues (e.g. Chocolatey 503, resource downloads failing), so some CI jobs are red for reasons unrelated to this PR. I don’t have permission to re-run the failed jobs from here.

[StormBytePP]

Hi everyone,

Apologies for the additional noise on this PR.

I rebased the branch against the latest master and resolved the conflicts introduced by the most recent upstream commits. The force-push simply updates the PR so it applies cleanly on current master and stays fully functional.

This should also make life easier for anyone who has been cherry-picking commits from this branch — they will encounter the same merge conflicts when they rebase, so having a clean, up-to-date version here helps keep those references maintainable.

No functional changes beyond what was needed to resolve the conflicts. The goal remains the same: solid native MSVC support that continues to work against master.

Thanks for your patience!