Proposal to make CI Build artifacts have its content in same level

[og-mrk]

Motivation behind this

For a long time now (a few month, approx. year and a half) I've wanted to add mpv to Windows Packages repo (winget-pkgs), but couldn't due to limited knowledge/time.

And with the release of binaries in latest release (making it the only "Official" binaries for mpv), and as zip files (the only supported format by winget), it's now easy to make a package for it so winget users can enjoy installing mpv with ease!

Unfortunately although Winget does support archives.. it can only extract an archive file, and see it contents, and if, lets say, the actual executable is nested inside another archive, then Winget couldn't extract that nested archive (from what I can find), which leads us to the topic at hand..

and to make my previous statement clearer, the following is a comparison between msvc builds, and mingw builds.

The msvc builds has its content like this:

mpv-v0.41.0-x86_64-pc-windows-msvc.zip <-- winget extracts it no problem
|_mpv.pdb
|_mpv.exe
|_mpv.com
|_mpv-register.bat
|_mpv-unregister.bat

everything fine with msvc builds 👍

while mingw builds has its content like this:

mpv-i686-w64-mingw32.zip <-- winget extracts it no problem
|_mpv-git-2025-12-28-4ecf729-i686.zip   <-- winget CAN NOT extract it
  |                            All files inside it can not be accessed by winget
  |_mpv.exe
  |_mpv.com
  |_mpv-register.bat
  |_mpv-unregister.bat
  |_...
  |_...

Possible Solution(s)

I've noticed inside ci/build-mingw64.sh a few lines at end of build that makes the mpv-git-2025-12-28-4ecf729-i686.zip (i.e. these lines), we could remove these lines, and problem solved!
now because of my limited experience with mpv project.. I don't know if this archiving step is being depended on by another script/part of the project, so simply removing it might cause issues/headaches.

another solution is to extract the contents of mpv-git-2025-12-28-4ecf729-i686.zip (the archive made by ci/build-mingw64.sh script) inside the .github/workflows/build.yml and re-archive the files using actions/upload-artifact@v5 step just like msvc have done it, making msvc and mingw builds have its content at the same level.

Thoughts & Notes

• Although many package managers on windows (scoop, Chocolatey) do support scripting (i.e. each package has an install and uninstall script) making the aforementioned problem of nested archives a trivial issue to solve.. Winget doesn't, and will probably never have scripting support, due to added complexity on package maintainers, and the validation pipeline that Microsoft has, so I think we'll be sticking to Yaml for the time being

• If you're reading this, Thanks! it means I haven't wasted my time writing this, and hope I haven't dragged this proposal for too long, have a nice day stranger 👋

[avih]

Without commenting on whether we actually want mpv to be published via winget, two comments:

1. The internal zip name in the mingw build is useful, because it identifies the exact source revision. The MSVC build doesn't have it, and it's not ideal - as far as identifying the content goes. I think that ideally there would indeed only be one level of zip, and that name would include the source revision (the "git describe" part). However, I don't know how much that's possible with the CI. Currently neither the mingw nor the MSVC builds have this ideal form.
2. As the message just above the release binaries says, these builds are missing some features, maybe most notably encoding (basically things where ffmpeg uses an external library to do the encoding - like libx264 or libx265, etc), so I don't know how good it would be to make them generally available via winget, because users would get a sub-par experience if they need to encode anything (and probably some other things too).

[avih]

As I said, I don't know whether the naming thing is possible. If you know how to do that (and ensure the artiffacts are uploaded and remain accessible etc), you can start by opening a PR to make the artifacts have better naming and only one level of zip.

As for why the artifacts don't include more features, it's because they're our CI builds, and their main goal is to test that any changes in mpv are being built correctly etc. 3rd party libraries which ffmpeg can utilize - like libx264 etc, typically don't affect what we need the CI to test, and we do prefer that the CI build completes fast. So they're not there because we don't need them for CI, and they would also slow down the builds.

It was suggested in the past to add special CI builds which include more features but are not enabled by default, so that such CI tasks could be enabled for release tags, for instance, but that takes time and effort, and no one has done that. So that's another thing you could open a PR for, again, if you have the know how.

As for adding a comment about missing features, personally I don't think it would help much. If this is the official build and it's missing features then it would be sub optimal however one looks at it. So I don't think a note is a good solution here.

As for whether the mpv team wants to publish it on winget, I don't know, but I think we might, especially if it ties directly to this (the main mpv) repostory, and controlled by the team - and not by a 3rd party user. But that's an estimation.

I don't know how publishing in winget works, but if you can open a PR which would allow the team to upload new versions when they see fit, then I'm guessing it would not be ignored. But again, that's a guess.

[og-mrk]

@avih I'll try and contribute on this in the upcoming days 👍

Also a quick note about giving the team control over mpv releases onto Winget Pkgs repo, there's a way to do so by editing the Auth.csv file, but from what I've understood reading issue microsoft/winget-pkgs#100 and microsoft/winget-pkgs#325096, it's still a work-in-progress, and again, I'm unsure if this feature works or not, at least from validation pipeline side, and currently the Winget CLI can't tell from Official (made by package devs themselves) from Unofficial (made by community) packages, at least for now.

[avih]

Please note that it appears the double-zip and naming issues are handled here #17199 .

[og-mrk]

@avih May I message you over Discord about building mpv with encoding support? if you don't mind helping me ofc, can't figure out how to build ffmpeg inside this repo (to use available tools) and not pull/clone https://github.com/mpv-player/mpv-build repo when building mpv, which isn't optimal from dependency stand point.. but maybe it's the only sensible solution, as the scripts their are stable & ready for use.

[avih]

I don't use discord, and also I'm probably not the best person to ask about build/meson issues. The official IRC support channel is "#mpv" on Libera, and for development issues (maybe build issues too), there's also "#mpv-devel", and the developers hang there.