mpv-winbuild: hourly Windows builds of mpv from the latest commit

The repository is a scheduled compiler, not a source tree

What lives here is a build pipeline, and the distinction matters for anyone deciding whether to depend on it. There is no mpv source code in the repository. The contents are the machinery that fetches mpv from upstream, applies patches, configures the build and packages the result: a build.sh script, a directory of patch files, individual named patch files such as build-shared-ffmpeg.patch, compile-lgpl-libmpv.patch and use-librempeg.patch, a prunetags.sh script, an action directory and a .github directory holding the workflow definitions.

The project description is the whole mechanism in one line: it uses a GitHub Action to build mpv for Windows with the latest commit. The trigger is a timer, not a tag. The workflow checks the mpv repository every hour for updates, and if there is an update and it is relevant to the Windows build, it runs the compilation and releases it on success.

That design has an obvious appeal for a media player that is developed in the open and ships nightly upstream builds on other platforms: someone who wants the newest Windows binary can have it within an hour of the upstream commit, without waiting for a release cycle. The cost is the one that comes with any rolling build, which is that the artifact is not reproducible from a tag and the release list is a stream rather than a set of versions.

Releases are named after the date and the commit they came from

The release tags visible on the repository follow a date and short commit pattern, for example 2026-10-19-6a262d11f6 and 2026-10-18-fffe7a23a8. That naming does two jobs at once. The date prefix makes the ordering of the release page obvious at a glance, which matters when the list is long, and the commit suffix ties a binary to the exact upstream revision it was compiled from, which is what you need when a build misbehaves and you have to work out whether the regression was introduced upstream or by the packaging.

The releases in the recent list also show several builds landing on the same day, sometimes more than one, which is consistent with the hourly polling described in the documentation. A build that fails does not become a release, since the pipeline releases on success, so a gap in the sequence is a failed or skipped build rather than a withdrawn one.

Because the tags are commit-derived and the retention policy is short, the sensible way to consume this project is to pin a specific tag rather than to follow the latest release. The repository links to the latest release from its badge, and the release page carries a download count, but neither is a version you can depend on for a long-lived installation.

The 64-bit only rule and the fork escape hatch

The documentation is blunt about the scope. This repository only provides a 64-bit version, and if you need a 32-bit version the instruction is to fork the repository and run the MPV workflow yourself. That is a meaningful detail for anyone considering whether the project fits their needs, because 32-bit Windows builds are still wanted by people with old hardware or with software that expects the older mpv-1.dll naming, and the answer here is that you build it yourself rather than downloading it.

The same answer applies more broadly. Because the entire project is a workflow, using it for anything other than the default 64-bit build means maintaining a fork, which means you own the pipeline, the runner configuration and the release step, not just the download.

The workflow name is given as MPV, so the fork path is to run that workflow in your own copy of the repository, and the natural place to do it is a GitHub Actions runner on Windows, since the build targets Windows and the patches and scripts in the repository root assume that environment.

Two flavours of build: the standard player and a libmpv shared library

The release assets come in two shapes, and the difference is legal as much as technical. One archive is named mpv-dev-xxxx.7z and contains libmpv including the libmpv-2.dll file. The documentation explains the use case for that DLL directly: some media players are built on libmpv and use libmpv-2.dll or mpv-2.dll, and you can upgrade their libmpv by overwriting that DLL. In other words, the dev archive is a way to take an existing third-party player and move it onto a newer libmpv without rebuilding the player itself.

The second archive, mpv-dev-lgpl-xxxx.7z, is libmpv under the LGPLv2.1 or later licence. The description of how it is built is specific: it disables packages that are incompatible with LGPLv2.1 or later, and it statically links to ffmpeg under LGPLv3. That matters because a static link to ffmpeg removes the dynamic linking question for that dependency and lets the whole libmpv be distributed under LGPL terms.

The author then adds a disclaimer that deserves repeating: they are not a lawyer and cannot guarantee that every LGPL incompatible package has been disabled, so use it at your own risk. That is an unusual thing to find in a build script's documentation and it tells you something about how much confidence to place in the packaging. A licence claim that the packager cannot fully verify is a decision you have to make on your own, not one the archive makes for you.

Thirty days of history, and no version numbers to remember

The release retention policy is stated in one line: the last 30 days of builds will be retained. Everything older is removed. This is a deliberate design choice for a rolling build service, since keeping a year of daily binaries would fill the repository's release storage for no benefit, but it has a direct consequence for automation. A script that downloads the newest release has a moving target, and a script that points at a specific tag will eventually find that tag gone.

The workable pattern is to fetch the newest release at the moment you build or install, and to record which tag you used. The prunetags.sh script in the repository root is the counterpart to the policy on the publishing side, since the workflow has to delete the tags that fall outside the window, not just the release assets.

The build list in the documentation is long and specific, and it reads like a package manifest rather than a build log. The Git and Hg sources listed include the AMF headers, ANGLE, aom, the AviSynth headers, bzip2, curl with a set of TLS backends, dav1d, davs2, FFmpeg, fontconfig, freetype2, fribidi, harfbuzz, lame, lcms2, libarchive, libaribcaption, libass, libbluray, libbs2b, libdvdcss, libdvdnav, libdvdread and libjpeg, with the list continuing past what the summary shows. Each entry is tied to its upstream repository, so the dependency graph of a Windows mpv build is visible in the documentation even though the versions themselves are resolved by the build system.

What the project is based on, and where the divergence happens

The pipeline is explicitly based on another repository, shinchiro's mpv-winbuild-cmake, and even the package list is inherited from it, with the documentation pointing at that project's README for the information about packages. What this repository adds on top is the schedule and the release behaviour: the hourly check, the automatic release on success, the retention policy, the LGPL libmpv variant and the named patch files in its own tree.

That inheritance is also a maintenance consideration. A package list and a set of build scripts that live in another project and are copied here will drift, and a change in the upstream build recipe does not automatically reach this fork. The patches at the root of this repository are where that divergence becomes visible: build-shared-ffmpeg.patch, compile-lgpl-libmpv.patch and use-librempeg.patch are local modifications, and a patch that applied cleanly yesterday may conflict after an upstream change.

The practical difference in approach between the two projects is therefore about the release policy rather than the build itself. If you want the classic build recipe and can run it yourself, the upstream repository is the place to start. If you want a fresh binary every hour with no local runner, this repository is what that looks like.

MIT for the pipeline, and licences that differ for the binaries

The licence field on the repository says MIT, and that licence covers the build scripts and workflow in this repository. It does not extend to the artifacts the pipeline produces, and the documentation makes that distinction explicit by describing the LGPL flavour of libmpv separately from the standard build.

So there are two licence questions stacked on top of each other. The first is the terms for the scripts, which are permissive and impose no obligations beyond keeping the notice with copies. The second is the terms for the binaries the scripts produce, which come from mpv and from every dependency in the package list, and those terms differ between the standard and the LGPL build. Anyone redistributing a binary from this project needs to look at the licences of mpv, of FFmpeg and of the other libraries in the list, not just at the MIT notice in this repository.

The status of the project itself is clear. The repository is not archived, the last push was on 2026-10-19, and the recent releases are dated the same day, so the pipeline is running and producing builds rather than sitting as a script collection that no longer works.

Editorial conclusion

Adopt mpv-winbuild when you want a Windows mpv build from the current upstream commit rather than from a periodic release, or when you need a libmpv shared library you can drop into another player, and keep away from it if you need a signed installer, a 32-bit build, a stable URL that never moves, or a package set you can audit. Before you distribute anything built from it, read the note about the LGPL variant, since the project itself says it cannot guarantee that every LGPL incompatible package has been disabled, and check the thirty day retention policy before you point an installer script at a release URL.

Frequently asked questions

Official sources

1. Issues
2. License: MIT
3. README
4. Releases
5. zhongfly/mpv-winbuild on GitHub