Add libvmaf wrap (Netflix VMAF) by diegonieto · Pull Request #2851 · mesonbuild/wrapdb

diegonieto · 2026-07-21T09:50:33Z

Add libvmaf wrap (Netflix VMAF 3.2.0)

VMAF (Video Multimethod Assessment Fusion) is a perceptual video
quality assessment algorithm developed by Netflix.

Dependency: libvmaf
Upstream: https://github.com/Netflix/vmaf
Version: 3.2.0 (tag v3.2.0)

Notes:

Upstream already ships a Meson build system inside libvmaf/.
A root meson.build is provided in packagefiles/ to serve as
the entry point when used as a subproject.
libvmaf_dep and meson.override_dependency() are declared in
the root meson.build to enable dependency('libvmaf').
Build requires nasm (on x86) and xxd.
MSVC is not supported. MSVC lacks support for
upstream's GCC-specific AVX2 intrinsics.
Docs and tools are disabled in CI; tests are enabled and pass
on all other platforms.

bgilbert · 2026-07-21T09:57:48Z

+    "build_options": [
+      "libvmaf:enable_tests=false",
+      "libvmaf:enable_docs=false",
+      "libvmaf:enable_tools=false"


Likewise, it's good to verify that the tools successfully build.

Not fixed; the override is still here.

It's still here. Disabling docs is fine but we should not disable tools unless there's a good reason.

bgilbert · 2026-07-21T10:16:05Z

AssertionError: Found files subprojects/packagefiles/libvmaf/meson.build with license headers in a project without a LICENSE.build.  The LICENSE.build file in the patch ZIP defaults to MIT unless the patch directory has its own LICENSE.build, which should state the license for the wrap's build files.

False positive; you'll need to reword the header comment.

diegonieto · 2026-07-22T11:57:16Z

@bgilbert I've update the PR to pass the CI. Both msvc and msys2 have been disabled since it fails in either building or passing some of the tests. See Netflix/vmaf#1477.

ylatuya · 2026-07-22T15:13:41Z

@bgilbert I've update the PR to pass the CI. Both msvc and msys2 have been disabled since it fails in either building or passing some of the tests. See Netflix/vmaf#1477.

vmaf supports mingw64, their CI runs compilation and tests successfully -> https://github.com/Netflix/vmaf/actions/runs/29288566688/job/86946759491

bgilbert · 2026-07-22T20:50:09Z

Okay, what's the situation here? Is the intention to temporarily carry a downstream fork of the Meson build scripts while PRing changes back to the upstream project?

build_on is meant for projects that categorically don't support an OS. If support is expected in an upcoming release, just let the CI fail.

diegonieto · 2026-07-22T21:01:06Z

Okay, what's the situation here? Is the intention to temporarily carry a downstream fork of the Meson build scripts and PR changes back to the upstream project?

Yes, the idea is to make libvmaf part of wrapdb and upstream all the portable changes.

build_on is meant for projects that categorically don't support an OS. If support is expected in an upcoming release, just let the CI fail.

The "windows": false (Visual Studio/MSVC) is permanent, not temporary. Upstream libvmaf does not support the MSVC compiler — it uses GCC-specific SIMD intrinsics (__m256i type casts, __builtin_clz, etc.) and requires POSIX headers like pthread.h. The wrap's meson.build explicitly errors out for MSVC/clang-cl.

This is consistent with upstream, which also doesn't test MSVC in their CI. MSYS2 (GCC-based Windows builds) is the supported path upstream, and the one we should support here as well.

Should I leave it building without passing the tests for msys2?

bgilbert · 2026-07-22T21:08:20Z

Yes, the idea is to make libvmaf part of wrapdb and upstream all the portable changes.

Making sure I understand the "portable" qualification: will the wrap eventually just be the root meson.build and meson_options.txt with the paths changed, as in early drafts of this PR?

The "windows": false (Visual Studio/MSVC) is permanent, not temporary. Upstream libvmaf does not support the MSVC compiler — it uses GCC-specific SIMD intrinsics (__m256i type casts, __builtin_clz, etc.) and requires POSIX headers like pthread.h. The wrap's meson.build explicitly errors out for MSVC/clang-cl.

You previously linked to Netflix/vmaf#1477, which has a comment saying the PR will be reviewed before the next release.

Should I leave it building without passing the tests for msys2?

Yes, if they can't be made to pass. But the current problem is MSYS2 failing to install vim, which is a bug in the PR.

bgilbert · 2026-07-22T21:09:43Z

+    "build_options": [
+      "libvmaf:enable_tests=false",
+      "libvmaf:enable_docs=false",
+      "libvmaf:enable_tools=false"


Not fixed; the override is still here.

diegonieto · 2026-07-23T15:17:17Z

Yes, the idea is to make libvmaf part of wrapdb and upstream all the portable changes.

Making sure I understand the "portable" qualification: will the wrap eventually just be the root meson.build and meson_options.txt with the paths changed, as in early drafts of this PR?

Once those land upstream, the wrap reduces to just the root meson.build (with libvmaf/ path prefixes since we're one level up from upstream's entry point) and meson_options.txt. That's the goal, yes.

The "windows": false (Visual Studio/MSVC) is permanent, not temporary. Upstream libvmaf does not support the MSVC compiler — it uses GCC-specific SIMD intrinsics (__m256i type casts, __builtin_clz, etc.) and requires POSIX headers like pthread.h. The wrap's meson.build explicitly errors out for MSVC/clang-cl.

You previously linked to Netflix/vmaf#1477, which has a comment saying the PR will be reviewed before the next release.

Sorry, what I meant by "permanent" is that we don't really know when libvmaf will actually merge and release those changes supporting msvc.
The lack of supporting msys2 in wrapdb (this PR) might be temporary since the libvmaf CI already supports it. However, after reviewing @ylatuya comment, I will try to make it work in this PR as well.

Should I leave it building without passing the tests for msys2?

Yes, if they can't be made to pass. But the current problem is MSYS2 failing to install vim, which is a bug in the PR.

To avoid the CI back and forth I will try to make the tests pass in local for msys2. After that I'll let you know. Let me know whether you have any additional comments about this.

To give some context, this PR comes from: https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/12101

diegonieto · 2026-07-27T17:55:38Z

@bgilbert I think I've addressed your feedback. It should be also supporting now msys2, as libvmaf CI does. Let me know whether you have any additional comments.

bgilbert · 2026-08-01T21:37:29Z

+    "build_options": [
+      "libvmaf:enable_tests=false",
+      "libvmaf:enable_docs=false",
+      "libvmaf:enable_tools=false"


It's still here. Disabling docs is fine but we should not disable tools unless there's a good reason.

bgilbert · 2026-08-01T21:43:42Z

+    cdata.set10('ARCH_X86_32', host_machine.cpu_family() == 'x86')
+
+    # check NASM version
+    nasm = find_program('nasm')


For the record, upstream would ideally switch to the built-in nasm support in Meson 0.64+.

VMAF (Video Multimethod Assessment Fusion) is a perceptual video quality assessment algorithm developed by Netflix. Upstream ships its own Meson build system inside the libvmaf/ subdirectory. A root meson.build is provided to act as entry point. A patch adds the libvmaf_dep declare_dependency() needed for consuming libvmaf as a subproject. Dependency name: libvmaf Upstream version: 3.2.0

bgilbert · 2026-08-03T11:34:06Z

Our Alpine ppc64le CI is broken.

Thanks for the PR!

diegonieto force-pushed the add-vmaf-wrap branch 2 times, most recently from 3a21f3d to ce74def Compare July 21, 2026 10:00

bgilbert reviewed Jul 21, 2026

View reviewed changes

diegonieto force-pushed the add-vmaf-wrap branch 2 times, most recently from f8f6bcc to abae7a9 Compare July 21, 2026 10:14

diegonieto force-pushed the add-vmaf-wrap branch 16 times, most recently from 56d6f01 to d82db63 Compare July 22, 2026 11:38

diegonieto force-pushed the add-vmaf-wrap branch from d82db63 to 4d83dd5 Compare July 22, 2026 20:42

bgilbert reviewed Jul 22, 2026

View reviewed changes

diegonieto force-pushed the add-vmaf-wrap branch 2 times, most recently from 346b7b4 to a74e940 Compare July 27, 2026 17:44

diegonieto requested a review from bgilbert July 28, 2026 08:38

bgilbert reviewed Aug 1, 2026

View reviewed changes

diegonieto force-pushed the add-vmaf-wrap branch from a74e940 to 8454816 Compare August 3, 2026 07:42

diegonieto force-pushed the add-vmaf-wrap branch from 8454816 to fcbffa0 Compare August 3, 2026 11:27

bgilbert merged commit 237fd7d into mesonbuild:master Aug 3, 2026
17 of 23 checks passed

diegonieto deleted the add-vmaf-wrap branch August 4, 2026 07:28

Conversation

diegonieto commented Jul 21, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

bgilbert commented Jul 21, 2026

Uh oh!

diegonieto commented Jul 22, 2026

Uh oh!

ylatuya commented Jul 22, 2026

Uh oh!

bgilbert commented Jul 22, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

diegonieto commented Jul 22, 2026

Uh oh!

bgilbert commented Jul 22, 2026

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

diegonieto commented Jul 23, 2026

Uh oh!

diegonieto commented Jul 27, 2026

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

bgilbert commented Aug 3, 2026

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants

diegonieto commented Jul 21, 2026 •

edited

Loading

bgilbert commented Jul 22, 2026 •

edited

Loading