Too many mpv builds for windows (confusing)

[Obegg]

At first, there was mainly this mpv build - https://github.com/shinchiro/mpv-winbuild-cmake
❌ But this mpv build lacked "frequent" builds, this one is daily.

Then, there was this mpv build - https://github.com/zhongfly/mpv-winbuild
✅ This one solved the previous one's issue by going further and doing more frequent builds.
Also, at that time - shinchiro mpv builds repo wasn't updated too often (commits), so choosing zhongfly build was an easy choice.
✅ I even contributed to the new mpv build repo and added the option to choose edition of yt-dlp (stable/nightly/master), this PR also adds the option in settings.xml which allows you to finally install yt-dlp unattended to some degree.
❌ shinchiro mpv build did NOT add the PR I mentioned earlier (with the yt-dlp and settings.xml and unattended).

Great, so far easy to understand, right?
Here's the confusing part for me:
Now there's another mpv build - https://github.com/dyphire/mpv-winbuild
❌ This one also did NOT add the PR I mentioned earlier (with the yt-dlp and settings.xml and unattended).
Which has the following changes:

Changed
        LuaSocket is built and included, so [simple-mpv-webui](https://github.com/open-dynaMIX/simple-mpv-webui) can be used out of the box
    Fixes and Minor Enhancements
        davs2: enable 10bit
        libass: parse script properties even if missing "[Script Info]"
        FFmpeg: check for double BOM in UTF-16 subtitle files
        FFmpeg: Parsing ASS subtitle files with missing [Script Info] in the first line
        FFmpeg: only handle negative durations for non-ASS subs
        FFmpeg: handle long TrueHD input_timing gaps
        FFmpeg: Potential TrueHD FFmpeg Passthrough Fix

And another mpv build - https://github.com/Andarwinux/mpv-winbuild
✅ This one also DID add the PR I mentioned earlier (with the yt-dlp and settings.xml and unattended).
Which has the following changes:

x86-64 version is built with PGO to improve performance.

x86-64 version based on MSVC-compatible 64-bit long double ABI instead of UNIX/MinGW 80-bit long double ABI, so any FP operations are lowered to AVX instead of x87 FPU (software emulated) to improve performance.

The x86-64-v4 build uses rocketlake as the ISA baseline, but chooses the znver5 scheduling model (512bit vector width), so it can be used for rocketlake, tigerlake, znver4, znver5. However, due to DownFall mitigation (mandatory since 24H2) and AVX512 downclocking, performance regression is expected on Intel MSDT series CPUs.

The x86-64-v3 build uses skylake as the ISA baseline and applies compiler mitigation (-mno-gather) to avoid the performance penalty of the DownFall microcode mitigation.

All EXEs are integrated with mimalloc.

libmpv can't use mimalloc, the only alternative is system-wide Segment Heap:

reg add “HKLM\SYSTEM\CurrentControlSet\Control\Session Manager\Segment Heap” /v Enabled /t REG_DWORD /d 1 /f

The mpv is built with consoleAllocationPolicy, so make sure you are using Windows 11 24H2 or higher otherwise you will see a console when starting mpv. Alternatively, you can use mpv-legacy.exe

The OpenSSL has been patched to use winstore by default, so tls-verify for mpv can be enabled out of the box. Consider enabling it for security.

The profdata used by PGO is generated manually, so it usually only scrolls every few weeks, during which time there might be random performance regressions.

If LargePages support is enabled on your system, mimalloc will automatically use it, and you can also enable LargePages for exe:

reg add “HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Image File Execution Options\mpv.exe” /v UseLargePages /t REG_DWORD /d 1 /f

You can use [VMMap](https://learn.microsoft.com/en-us/sysinternals/downloads/vmmap) to check if LargePages works or is a placebo.

Private Data Locked WS are LargePages explicitly allocated by mimalloc via VirtualAlloc API.

Image Locked WS are LargePages coalesced by NT kernel for exe.

First I have to admit I'm not an expert (otherwise I would have not created this discussion), so forgive my ignorance.
So I have a few questions/suggestions:

1. If dyphire mpv builds include some fixes, why other repo did not include those fixes, yes you can argue that each dev have it's own opinion on each subject, but generally speaking, common sense is that a fix is a fix, it's a good thing, but at the same time I have to say that I don't have enough knowledge about those fixes so I can't say for sure, and while you can also say "why don't you just ask each dev?", while this would be a good question, it would also be to some degree hiding from the "mess" of mpv builds (even if not official like this one - https://nightly.link/mpv-player/mpv/workflows/build/master).
2. (Andarwinux mpv builds) Why there are so many builds like v2, v3, v4, why can't there be only one version which adjusts itself automatically bases on the user CPU, I have no I idea what is AVX512 and why we need it, but I can somehow grasp the idea that if my CPU has it, then it's good to enable it, my problem with the v2, v3, v4, is that it creates this maze of "which one to download?", and not offering a solution where there's one mpv build that fit all, a universal mpv build that fit all CPUs without degrading performance.

There's also the official mpv build - https://nightly.link/mpv-player/mpv/workflows/build/master
But this one doesn't include any updaters like the rest, doesn't include yt-dlp, doesn't include ffmpeg, so there's no reason to choose the official one.

Lastly, I would like to thank shinchiro, zhongfly, dyphire and Andarwinux for creating each repo, even if it's confusing, I still want to show my appreciation.

[CounterPillow]

the v2/v3/v4 stuff is people thinking ricing the builds with autovectorisation options for different made-up x86 architecture levels actually does anything. it doesn't. Anything performance critical already has hand-written SIMD which will be picked at run-time based on the CPU used and does not benefit from it. Anything non-performance-critical is unlikely to get much out of autovectorisation above the x86_64 base level of SSE 4.2, and is more likely to accidentally thrash the icache or expose dumb compiler optimiser bugs than bring any measurable real-world benefit.

This type of "ricing" can be seen as a form of Cargo-cult, and outside of Windows circles is most commonly practiced by Gentoo users, a primitive more basal form of Linux user that lives in caves and feeds on lichen growing on the damp rock walls for sustenance.

[Andarwinux]

My build is made entirely for personal use (it's not just for compiling mpv), and the main purpose of my repository is to demonstrate the extensibility and functionality of the cmake meta-build system and how to customize it to meet your own needs. As others have said, there is no stability guarantee. Someone suggested that something like x86-64-v4 was needed, so I added it because it was easy.

I wish people could learn to customize mpv-winbuild-cmake and mpv-winbuild to customize their own builds instead of relying entirely on prebuilt. With WSL2, you can get your own custom daily builds in minutes using mpv-winbuild-cmake. cmake and ninja seem to be more reliable as meta-build systems than a bunch of bash scripts for building software with very complex dependencies.

I recommend zhongfly's prebuilt. For build issues, zhongfly can provide fixes faster and I will assist with that.

Incidentally, compilers can't generate optimized code for multiple ISAs without explicit dispatch from the developer: doing so would exponentially expand both the binary size and the compiler's internal logic. ffmpeg doesn't like these explicitly dispatched intrinsics, which makes sense, as performance and buildability depend on the compiler. ASM, on the other hand, allows for fine-tuning without the compiler's intervention.

One issue with x86-64-v3 is ASM code: some legacy ASM paths only have SSE implementations, and we have the compiler generate a bunch of AVX code around them, which results in SSE/AVX transition penalties. clang and gcc have a workaround with -msse2avx, but this only works for GAS, not NASM, which ffmpeg uses.
I've tried some hacks to get around this, and eliminating some unnecessary uses of vzeroupper instructions.

Also, Windows seems to have enforced DownFall mitigations, causing significant regressions in AVX gather performance on Intel CPUs, I added -mno-gather to workaround this.

[hooke007]

ffmpeg has more more more more more more more more and more personal builds. Choose any one you like.

[ahaoboy]

I totally agree. MPV has so many customization options that it's very confusing to choose which build to use. What are the differences between them? Is there a performance improvement or size reduction? If you're not familiar with these projects, you can only choose the one with the most stars.
MPV also has no official support on other platforms. For example, the Ubuntu version of https://fruit.je/apt and the corresponding Android version of mpv-android do not support js scripts.

[ahaoboy]

After setting the relevant environment variables, there is no warning, and the first startup time is significantly improved.

set -x MIMALLOC_ARENA_EAGER_COMMIT 0
set -x MIMALLOC_ALLOW_LARGE_OS_PAGES 0
[mpv_easy] render time(react): 1000 3 176 3.75

You can download portable_config from this link and unzip it into the directory where you built mpv
https://mpv-easy.github.io/mpv-build/#mpv-build=%22%7B%5C%22state%5C%22%3A%7B%5C%22selectedRowKeys%5C%22%3A%5B%5D%2C%5C%22externalList%5C%22%3A%5B%5D%2C%5C%22ui%5C%22%3A%5C%22mpv-easy%5C%22%2C%5C%22platform%5C%22%3A%5C%22mpv-v3%5C%22%7D%7D%22

Then set SHOW_FPS=true and MAX_FPS_FRAME=64 (only count the rendering time of the most recent 64 frames) and you can view the messages of mpv-easy in the console

v8-v7 is a good test, if you are interested you can add a mujs-pgo version to js-engine-bench
https://github.com/ahaoboy/js-engine-benchmark

mpv-easy is implemented using React and front-end tools, so it requires significantly more memory than Lua. This may also be why it's slow to start up initially.

Other mpv.exe seems to filter the console to improve performance? I don't quite understand the difference between the two. How to generate mpv.com? Copying from other places doesn't seem very convenient.

Finally, thank you for your reply; I learned a lot from it.

[ahaoboy]

I think pgo may not be very suitable for testing UI scripts, because the performance bottleneck of UI scripts is creating and updating osd-overlay. I plan to add a v8v7 script that can run v8v7 directly in mpv. This may be more suitable for computationally intensive tasks.
mpv-easy/mpv-easy#159

[ahaoboy]

Nice~ At least the v8v7 test has been greatly improved

You can download portable_config from this link and unzip it, then run mpv to start the v8v7 test that's easy~

https://mpv-easy.github.io/mpv-build/#mpv-build=%22%7B%5C%22state%5C%22%3A%7B%5C%22selectedRowKeys%5C%22%3A%5B%5C%22mpv-v8v7%5C%22%5D%2C%5C%22externalList%5C%22%3A%5B%5D%2C%5C%22ui%5C%22%3A%5C%22osc%5C%22%2C%5C%22platform%5C%22%3A%5C%22mpv-v3%5C%22%7D%7D%22

[ahaoboy]

I added the ability to export the results to the same directory as the script, so that it is easier to compare different builds

https://github.com/mpv-easy/mpv-easy/blob/main/blog/Running-v8-v7-Benchmarks-in-mpv-Player.md

[ahaoboy]

The test results seem to have about a 10% margin of error, so I added the V8V7_RUNS environment variable to run the test multiple times and obtain an approximate average.

If you encounter any other issues, feel free to provide feedback at ahaoboy/mpv-v8v7 or mpv-easy/mpv-easy. It seems our discussion has drifted away from the original topic, but once again, thank you for your excellent work — this appears to be the best way to improve performance without changing the JavaScript engine.

[avih]

mpv doesn't provide binaries for any platform.

All the binaries are built either by individual 3rd party volunteers, or by distro maintainers - which are typically also volunteers.

If some builds are missing some features, then the best way forward is to ask the build maintainers to add it, or maybe even help them to do that.

[hooke007]

mpv-install was originally maintained by https://github.com/rossy/mpv-install
Then shin also took this method. https://github.com/shinchiro/mpv-packaging

It's not official. But it was just a standalone script which can be used for any build.

Also check #15912

[kasper93]

Should I finish #15912 ? Last time there was some push back on this change.

[Andarwinux]

It would be great if we could merge that soon. Those objections don't seem to me to be really well-founded, and even if there are any problems it can be improved later.

[hooke007]

Why not?

[emeyedeejay]

Thank goodness I'm not the only one hella confused. Just tried a few downloads (yes, windows - sorry! And wouldn't know how to compile etc.) but mpv.exe runs then any URL I drag to it results in a ~1s delay and then pooof it's gone/crashed.