mpv: a versioned release gets no fixes, only the rolling build does

Releases are cut for distributions, then frozen

The release cycle section is short and it settles the whole maintenance question. Once or twice a year a release is cut off from the current development state and assigned a 0.X.0 version number. No further maintenance is done, except in the event of security issues. Releases other than the latest release are unsupported and unmaintained.

The stated purpose is not user convenience. The goal of releases is to make Linux distributions happy, and distributions are also expected to apply their own patches when there are bugs. So a numbered mpv is a snapshot handed to packagers, and what happens to it afterwards is the packager's business.

The tag list shows the cadence and the consequence together. v0.40.0 shipped on 2025-03-25 and v0.41.0 on 2025-12-21, roughly nine months apart, and above them sits a tag called git-release, an mpv development build, dated 2026-06-04. The last push to the repository was on 2026-09-26, so development is where the work is. If you install a numbered release you are choosing to own a frozen binary with no upstream fixes except a security one, and if you want current behaviour you want the rolling build. The numbering also never reaches 1.0, so there is no stability milestone arriving to wait for.

The repository ships no binaries and says so in one line

The downloads section is a single sentence. For semi-official builds and third-party packages, see mpv.io/installation. That is the whole answer, and it is a redirect to a web page rather than a download link.

This matters because the demand for mpv arrives as a download request, and there is a real gap between what people type and what this repository can give them. Searches around this project cluster on getting the player for Windows, on 64-bit builds, on an executable. The project's position is that it does not host those files. Semi-official builds and third-party packages exist, and they are found on a separate page, which means the person installing is trusting a channel this repository does not control and does not describe.

For a C project using meson with FFmpeg, libplacebo and libass as hard dependencies, that is a defensible choice, since producing and signing binaries for several operating systems is a distribution problem rather than an upstream one. It does mean the honest answer to where to get mpv is a URL, and the honest answer to who is responsible for the binary you end up running is not this project.

Hardware decoding is off by default, and the default video output is a shader

The system requirements section is unusually candid about what mpv is not built for. It says the focus is not on power-efficient playback on embedded or integrated GPUs, and gives hardware decoding not being enabled by default as the example. A somewhat capable CPU is listed as the requirement, and hardware decoding might help if the CPU cannot decode video in realtime, but it must be explicitly enabled with the --hwdec option.

So the default configuration is a software decode path on a machine with a weak GPU. The stated remedy for low power GPUs, which may cause tearing or stutter, is the --profile=fast option. And the reason is structural rather than a missing feature: the main video output uses shaders for video rendering and scaling rather than GPU fixed function hardware. That choice is what buys the consistency and quality people come to mpv for, and it is also what makes a weak GPU a liability rather than a non-event.

Two more edges in the same paragraph. On Windows you are told to make sure the graphics drivers are current, and fallback video output methods exist, --vo=xv on Linux for instance, but that use is described as not recommended or supported. Combined with the sentence about older hardware, where the project says it does not go out of its way to break them but development is not done with them in mind and anything that works is a happy accident, the picture is consistent: mpv trades old-hardware tolerance for output quality on no assumption that your GPU is up to the job.

There is no complete changelog, so key binding changes are a file diff

The changelog section opens by admitting the gap. There is no complete changelog. What exists instead is a set of partial records, and one of them is a configuration file.

Changes to the player core interface go in an interface changelog, changes to the C API in a client API changelog, and the release list carries a summary of most of the important changes on each release. Then there are two files for the thing users actually notice. Changes to the default key bindings are indicated in restore-old-bindings.conf, and changes to the default OSC bindings are indicated in restore-osc-bindings.conf.

Those two files are the mechanism, and they are an elegant one. A default binding changes between versions, and instead of writing a changelog entry, the project ships a file that restores the previous set. Diff your configuration against it, or diff two versions of it against each other, and you have an exact list of what moved. It is a machine-readable changelog for the part of the behaviour that scripts and muscle memory depend on.

For an embedder or a script author, that is the part that matters, because the C API changelog covers the interface and the conf files cover the keys, and neither of them is a substitute for a full release history. If you need to know what a given build does rather than what changed, you read the option defaults in options/ and the manual.

meson configure is the only way to see the build options

The build is meson, which can come from the distribution or from PyPI, and the documented sequence is three commands:

meson setup build
meson compile -C build
meson install -C build

The build directory is yours to choose, build in the example. Once it exists, there are two ways to see every option the project exposes: run meson configure build, or open the meson_options.txt file. The naming in the repository is meson.options rather than meson_options.txt, which is the newer meson spelling, and the logs are written to a meson-logs directory inside the build directory rather than to the terminal.

That is the discovery story for the whole configuration surface, and it matters because mpv has a large number of build-time switches. The dependency list is marked incomplete and runs from a compiler through X development headers, ALSA and pulseaudio audio headers, the FFmpeg libraries, libplacebo, zlib, iconv and libass, with Lua, libjpeg, uchardet and the nvdec and vaapi libraries all optional. Optional does not mean ignorable: Lua is what the OSC pseudo-GUI and youtube-dl integration need, libjpeg is for screenshots, and uchardet is for subtitle charset detection. So the three commands above are how you find out which of those your build actually turned on.

There is also a documented escape hatch for the one dependency most likely to be missing or too old. Meson can use a git checkout as a subproject for libplacebo and link it statically:

mkdir -p subprojects
git clone https://code.videolan.org/videolan/libplacebo.git --depth=1 --recursive subprojects/libplacebo

For everything else, including FFmpeg and libass, the answer is a separate wrapper, mpv-build, which compiles those first and then links the player against them statically.

Native DASH needs --enable-libxml2, and the README calls the bugs out

Three dependency notes carry warnings rather than instructions, and they are the ones to read before you build.

The first is DASH. For native DASH playback, FFmpeg needs to be built with --enable-libxml2, and the parenthesis that follows says there are security implications and that DASH support has lots of bugs. That is the project telling you the feature is available and the path to it is not one to enable casually, in the same sentence, with no version qualification.

The second is text rendering, and it is the one that produces the most confusing bug reports if you skip it. Harfbuzz is required for correct rendering of combining characters, called out specifically for non-English text on macOS and for Arabic and Indic scripts on any platform. A build without it will not fail to compile and will not warn loudly. It will render text incorrectly, which looks like a font bug rather than a missing dependency. The libass side of the build also needs fribidi, freetype and fontconfig, and nasm on x86 and x86_64.

The third is codec and vendor coverage. AV1 decoding requires dav1d. Good NVIDIA support on Linux needs nv-codec-headers installed and findable by configure. And several FFmpeg features have to be enabled explicitly when compiling FFmpeg, including OpenSSL or GnuTLS, and libx264, libmp3lame and libfdk-aac if you want encoding. None of this is mpv's code, but all of it lands in your binary, which is why the wrapper exists.

Two licence files, and Python tooling that is only a linter

The root carries LICENSE.GPL and LICENSE.LGPL side by side, with a separate Copyright file. That pairing is why a licence field on this project reports nothing automatically: a dual GPL and LGPL repository has no single answer to give, and the choice is made by whoever consumes it rather than declared once here. SECURITY.md sits alongside them.

The tooling is more surprising than the licence. The source is C, spread across the directories you would expect, with audio/, video/, demux/, filters/, input/, stream/, sub/, player/, options/, common/ and osdep/ doing the work, and mpv_talloc.h at the root with a ta/ directory. Then there is a fuzzers/ directory, a ci/ directory, TOOLS/ and DOCS/. Alongside sit a .luacheckrc for the Lua side, a .swiftlint.yml, an .editorconfig with an .editorconfig-checker.json, a .pre-commit-config.yaml, and a pyproject.toml.

That pyproject.toml is worth opening, because it will not do what its name suggests. It contains no project metadata, no dependencies and no build system. It holds a ruff configuration and nothing else, with a line length of 100 and a lint selection of pyflakes, pycodestyle, pep8-naming, pyupgrade, flake8-builtins, flake8-quotes and flake8-commas. So the Python in this repository is helper tooling, and its presence in pyproject.toml is for linting those scripts rather than for shipping a package. A C project that lints its Lua, its Swift, its Python and its Markdown before commit is telling you something about the review bar, and the presence of fuzzers/ is telling you something else.

Big changes start with an IRC conversation, and small issues need the template

The contribution and bug policies both have a gate in front of them, and neither gate is a tool.

For bug reports and feature requests, the instruction is to use the GitHub issue tracker and follow the template, because otherwise the issue will likely be ignored or closed as invalid. Questions go to discussions or IRC instead of the tracker, which is a deliberate split: the tracker is for reproducible defects, and everything else is a conversation. For contributions, small changes can be sent as pull requests directly through GitHub, but bigger changes require coming and talking on IRC before you start working on them, with the stated reason that it will make code review easier for both parties afterwards.

So the escalation path is: read contribute.md, open a pull request if it is small, or find someone on IRC first if it is not. The idea list is the wiki Stuff-to-do page and open feature-request issues in the tracker.

Read alongside the release policy, this paints a consistent picture of how the project makes decisions. Releases exist to hand snapshots to packagers, the rolling build is where development happens, questions are answered in chat rather than in issues, and substantial proposals are discussed before they are written. It suits a project whose maintainers care about review load more than contributor volume, and it is a poor fit if you need a self-service path to get a change merged.

Editorial conclusion

Adopt mpv if you want a keyboard-driven player you configure from a config file and a terminal, and you are willing to track the rolling development build rather than a numbered release. Do not adopt it expecting packaged Windows binaries, vendor support, or a stable branch, because the repository publishes none of the three and states that releases other than the latest are unsupported and unmaintained. Before you commit, check two things on your own hardware: whether --hwdec actually helps on your GPU, since the default video output is shader based and decoding is not enabled by default, and whether your distribution carries a recent enough mpv, since the project's own answer to that is that you want git master built with the mpv-build wrapper.

Frequently asked questions

Official sources

1. Official documentation
2. Official README
3. Project repository
4. Release notes