MPV: Vulkan Video Decoding: Usage Guide and FAQ
3 points · Open discussionmpv-player
mpv
C2013–2026
mpv-player / mpv
mpv
🎥 Command line media player
130Distinct people
156Mentions
3Explicit recommenders
38.1KGitHub stars
What to know before exploring
What it is
🎥 Command line media player
GitHub
Where it is used
What people are saying
My favorite infamous example being the MPV C locale commit: https://github.com/mpv-player/mpv/commit/1e70e82baa9193f6f02... You can really feel the author's rage at the state…
0cf8612b2e1e used a recommendation phrase. 3 indexed comments match. This is a phrase match, not a verdict.
No classified warning is attached to this page. Read the discussions before treating silence as approval.
Also in these discussions
- iina/iina · linked in 2 of the same discussions
- yt-dlp/yt-dlp · linked in 2 of the same discussions
Mentioned in the same Hacker News threads. That is not proof they are substitutes.
This week on Hacker News
Nov 8–Nov 15 UTC · Direct repository links and separately labeled related project stories. Indexed through 11/15/2026, 5:58:02 AM UTC.
No direct repository links were found in the indexed HN discussions over the past seven days. Older discussions are available below.
Mentions over time
HN mentions by year156 dated mentions
Observed mentions: 2013-08-11 10:08:17 UTC to 2026-07-14 21:01:20 UTC.
* An incomplete calendar period is marked with an outlined bar. Its count is not directly comparable with a full period.
Counts come from the repository’s dated source evidence. Index cutoff: 2026-11-02 08:16:59 UTC.
View mention counts and date ranges
| Period | Start (UTC) | End (exclusive, UTC) | Mentions | Submissions | Comments |
|---|---|---|---|---|---|
| 2013 | 2013-01-01 00:00:00 UTC | 2014-01-01 00:00:00 UTC | 6 | 2 | 4 |
| 2014 | 2014-01-01 00:00:00 UTC | 2015-01-01 00:00:00 UTC | 6 | 0 | 6 |
| 2015 | 2015-01-01 00:00:00 UTC | 2016-01-01 00:00:00 UTC | 4 | 2 | 2 |
| 2016 | 2016-01-01 00:00:00 UTC | 2017-01-01 00:00:00 UTC | 6 | 0 | 6 |
| 2017 | 2017-01-01 00:00:00 UTC | 2018-01-01 00:00:00 UTC | 10 | 3 | 7 |
| 2018 | 2018-01-01 00:00:00 UTC | 2019-01-01 00:00:00 UTC | 7 | 1 | 6 |
| 2019 | 2019-01-01 00:00:00 UTC | 2020-01-01 00:00:00 UTC | 8 | 2 | 6 |
| 2020 | 2020-01-01 00:00:00 UTC | 2021-01-01 00:00:00 UTC | 21 | 4 | 17 |
| 2021 | 2021-01-01 00:00:00 UTC | 2022-01-01 00:00:00 UTC | 16 | 4 | 12 |
| 2022 | 2022-01-01 00:00:00 UTC | 2023-01-01 00:00:00 UTC | 22 | 2 | 20 |
| 2023 | 2023-01-01 00:00:00 UTC | 2024-01-01 00:00:00 UTC | 19 | 6 | 13 |
| 2024 | 2024-01-01 00:00:00 UTC | 2025-01-01 00:00:00 UTC | 23 | 6 | 17 |
| 2025 | 2025-01-01 00:00:00 UTC | 2026-01-01 00:00:00 UTC | 5 | 1 | 4 |
| 2026 (partial) | 2026-01-01 00:00:00 UTC | 2027-01-01 00:00:00 UTC | 3 | 1 | 2 |
From the project README
An excerpt from the repository, fetched Nov 12, 2026.
Read the project’s introduction
mpv
External links
Overview
System requirements
Downloads
Changelog
Compilation
Release cycle
Bug reports
Contributing
License
Contact
External links
Wiki
User Scripts
FAQ
Manual
Overview
mpv is a free (as in freedom) media player for the command line. It supports
a wide variety of media file formats, audio and video codecs, and subtitle types.
There is a FAQ.
Releases can be found on the release list.
System requirements
A not too ancient Linux (usually, only the latest releases of distributions
are actively supported), Windows 10 1607 or later, or macOS 10.15 or later.
A somewhat capable CPU. Hardware decoding might help if the CPU is too slow to
decode video in realtime, but must be explicitly enabled with the --hwdec
option.
A not too crappy GPU. mpv's focus is not on power-efficient playback on
embedded or integrated GPUs (for example, hardware decoding is not even
enabled by default). Low power GPUs may cause issues like tearing, stutter,
etc. On such GPUs, it's recommended to use --profile=fast for smooth playback.
The main video output uses shaders for video rendering and scaling,
rather than GPU fixed function hardware. On Windows, you might want to make
sure the graphics drivers are current. In some cases, ancient fallback video
output methods can help (such as --vo=xv on Linux), but this use is not
recommended or supported.
mpv does not go out of its way to break on older hardware or old, unsupported
operating systems, but development is not done with them in mind. Keeping
compatibility with such setups is not guaranteed. If things work, consider it
a happy accident.
Downloads
For semi-official builds and third-party packages please see
mpv.io/installation.
Changelog
There is no complete changelog; however, changes to the player core interface
are listed in the interface changelog.
Changes to the C API are documented in the client API changelog.
The release list has a summary of most of the important changes
on every release.
Changes to the default key bindings are indicated in
restore-old-bindings.conf.
Changes to the default OSC bindings are indicated in
restore-osc-bindings.conf.
Compilation
Compiling with full features requires development files for several
external libraries. Mpv requires meson
to build. Meson can be obtained from your distro or PyPI.
After creating your build directory (e.g. meson setup build), you can view a list
of all the build options via meson configure build. You could also just simply
look at the meson_options.txt file. Logs are stored in meson-logs within
your build directory.
Example:
meson setup build
meson compile -C build
meson install -C build
For libplacebo, meson can use a git check out as a subproject for a convenient
way to compile mpv if a sufficient libplacebo version is not easily available
in the build environment. It will be statically linked with mpv. Example:
mkdir -p subprojects
git clone https://code.videolan.org/videolan/libplacebo.git --depth=1 --recursive subprojects/libplacebo
Essential dependencies (incomplete list):
gcc or clang
X development headers (xlib, xrandr, xext, xscrnsaver, xpresent, libvdpau,
libGL, GLX, EGL, xv, ...)
Audio output development headers (libasound/ALSA, pulseaudio)
FFmpeg libraries (libavutil libavcodec libavformat libswscale libavfilter
and either libswresample or libavresample)
libplacebo
zlib
iconv (normally provided by the system libc)
libass (OSD, OSC, text subtitles)
Lua (optional, required for the OSC pseudo-GUI and youtube-dl integration)
libjpeg (optional, used for screenshots only)
uchardet (optional, for subtitle charset detection)
nvdec and vaapi libraries for hardware decoding on Linux (optional)
Libass dependencies (when building libass):
gcc or clang, nasm on x86 and x86_64
fribidi, freetype, fontconfig development headers (for libass)
harfbuzz (required for correct rendering of combining characters, particularly
for correct rendering of non-English text on macOS, and Arabic/Indic scripts on
any platform)
FFmpeg dependencies (when building FFmpeg):
gcc or clang, nasm on x86 and x86_64
OpenSSL or GnuTLS (have to be explicitly enabled when compiling FFmpeg)
libx264/libmp3lame/libfdk-aac if you want to use encoding (have to be
explicitly enabled when compiling FFmpeg)
For native DASH playback, FFmpeg needs to be built with --enable-libxml2
(although there are security implications, and DASH support has lots of bugs).
AV1 decoding support requires dav1d.
For good nvidia support on Linux, make sure nv-codec-headers is installed
and can be found by configure.
Most of the above libraries are available in suitable versions on normal
Linux distributions. For ease of compiling the latest git master of everything,
you may wish to use the separately available build wrapper (mpv-build)
which first compiles FFmpeg libraries and libass, and then compiles the player
statically linked against those.
If you want to build a Windows binary, see Windows compilation.
Release cycle
Once or twice a year, a release is cut off from the current development state
and is assigned a 0.X.0 version number. No further maintenance is done, except
in the event of security issues.
The goal of releases is to make Linux distributions happy. Linux distributions
are also expected to apply their own patches in case of bugs.
Releases other than the latest release are unsupported and unmaintained.
See the release policy document for more information.
Bug reports
Please use the issue tracker provided by GitHub to send us bug
reports or feature requests. Follow the template's instructions or the issue
will likely be ignored or closed as invalid.
Questions can be asked in the discussions or on IRC (see
Contact below).
Contributing
Please read contribute.md.
For small changes you can just send us pull requests through GitHub. For bigger
changes come and talk to us on IRC before you start working on them. It will
make code review easier for both parties later on.
You can check the wiki
or the issue tracker
for ideas o
Read the full README on GitHubWhat Hacker News says
19 sources> In addition, given the high industry demand for AV1 codec support, an AV1 decode extension release is imminent, with an AV1 encode extension development also underway.
That's good.
By the way, mpv already supports Vulkan video decoding:
https://github.com/mpv-player/mpv/issues/11739
Now we need OBS and Firefox supporting Vulkan video too.
In Vulkan video extensions for accelerated H.264 and H.265 encodeAuthor of ripgrep here.
Like automatic encoding detection and transparently searching UTF-16?
Or simple ways for composing character classes, e.g., `[\pL&&\p{Greek}]` for all codepoints in the Greek script that are letters. Another favorite of mine is `\P{ascii}`, which will search for any codepoint that isn't in the ASCII subset.
Or more sophisticated filtering features that let you automatically respect things like gitignore rules.
Those are all things that ripgrep does that grep does not. So I do not favor this explanation personally.
ripgrep has just about all of the functionality that GNU grep does. I would say the two biggest missing pieces at this point are:
* POSIX locale support. (But this might be a feature[1].)
* Support for "basic" regexes or some equivalent that flips the escaping rules around. i.e., You need to write `\+` to
Read the rest
match 1 or more things, where as `+` will just match `+ literally.
Otherwise, ripgrep has unfortunately grown just about as many flags as GNU grep.
[1]: https://github.com/mpv-player/mpv/commit/1e70e82baa9193f6f02...
It's been mostly fine for me as well, but that has only been the case because of things like Xwayland; there are a large number of styles of program that are either really difficult reimplement or simply can't work without it.
Multi-window programs, for example, are difficult to get working directly on Wayland. The issue has been brought up several times [1][2]. And it's not a particularly uncommon UI-style.
For example, most video production software I've worked with allows you to popout certain components into separate windows so that you can, for example, have your timeline, which may have many tracks taking up lots of vertical space, on a separate monitor from the preview viewport. This is a really nice feature. And the lack of its presence is one of the things I really dislike about DaVinci Resolve, despite it being an otherwise grea
Read the rest
t tool with some of the best, if not the best, colorgrading utilities.
This isn't something unique and niche to video production either, though; lots of photo editing, audio production, 3D modelling, CAD software, and other scientific/engineering applications have similar UI. Wayland makes it difficult, though, because there isn't a good way to request or suggest the kind of positioning these programs need [1].
Anyway, that said, I, too, have lived with a mostly Wayland desktop for a few years without too many issues, even as someone who doesn't have the most "typical" workflows or needs. So, to an extent, I think you're not wrong; the idea that Wayland is *entirely* unusable is, obviously, not true.
But again, key point, *mostly* Wayland; without Xwayland or similar, I think it'd be genuinely unusable for me and likely many others.
While the compatibility layers genenerally work well, and in many ways, still provide many of the benefits of Wayland, like security, I don't think it's unreasonable to want a better, native way to deal with some of these issues so that people can drop the additional legacy abstraction.
---
[1]: https://gitlab.freedesktop.org/wayland/wayland-protocols/-/m...
[2]: https://gitlab.freedesktop.org/wayland/wayland-protocols/-/i...
Related:
- https://github.com/PCSX2/pcsx2/issues/10065
- https://github.com/mpv-player/mpv/issues/8692
---
EDIT:
I think it's also worth noting that just because /our/ Wayland experiences haven't been too bad doesn't mean that its the case for everyone.
As I, and several others, mentioned in other comments, there are several implementations of Wayland compositors, for example. Our particular choice of components/desktop environments might be fine, but others may be more broken or intentionally lacking support for useful/semi-necessary "optional" extensions to the protocol.
It'd be one thing to intentionally pick a bad implementation as a user and then complain about it. But sometimes, people aren't aware they're using Wayland in the first place, let alone which compositor they're using.
As a developer, even if you don't care for a particular implementation, unless you do as PCSX2 did, you'll still likely need to think about everyone elses' quirks as well, because too many of your users will also be users of whatever is most problematic -- e.g., GNOME is very popular and also has/had been one of the more annoying ones.
As noted by other commenters, there are several compositors available for Wayland (essentially the bit that actually implements Wayland).
Some are developed independently of any particular desktop environment--like wlroots, labwc, hikari, etc--but some are part of a larger project, such as mutter and kwin (GNOME and KDE, respectively). Most of the time you install some sort of GNOME/KDE + Wayland distro, you'll usually also end up with their compositors, and thus potential quirks specific to their implementations.
GNOME's implementation in particular has historically caused a lot of drama relative to some of the others -- be it due to purely accidental, broken support for something, or sometimes intentional opposition to a particular concept that many applications rely/used to rely on, like server-side window decorations [1].
The accident
Read the rest
al issues that come with fragmentation of the ecosystem and the intentional decisions by different compositors to not support particular extensions/whatever, like the aforementioned, can cause a fair bit of pain for developers of end-user programs.
Users who may be totally unaware of the inherent differences between Wayland and X, who may not know that different compositors exist, who may not even know they are running Wayland, etc, inevitably run into strange issues, and then, understandably, file bug reports.
This can get old quickly under normal circumstances. But I imagine it sucks even more when you're maintaining software that is relatively understaffed given its importance. Outside of PCSX2, mpv would be a good example:
- It's incredibly popular software on its own, being probably the most popular open-source, cross-platform mediaplayer after VLC.
- It's also embedded and used as a base for other applications on a wide variety of systems, ranging from other open-source players that try to integrate more tightly with a given platform--e.g., IINA (macOS), mpv.net (Windows), etc--to proprietary, commercial software, such as a variety of Android players and, importantly, Plex, which uses mpv as the default backend on at least tvOS/iOS/iPadOS.
- It's software that needs to deal with pretty low-level graphics and audio stuff, so it's inherently a bit complex, and the available pool of potential contributors shrinks.
- It tries to be as lightweight as possible and allow for easy embedding into other applications and porting to different systems, so it has several things working against it:
-- It's mostly written in C, making it very easy to build and embed anywhere, but not only is C not the sexiest language in 2023 to many, it's also a hard language for someone without a good grasp to write safe, quality code, particularly for something like mpv.
-- It doesn't try to enforce a particular rendering backend--e.g., OpenGL, DirectX, Vulkan, Metal, software, etc--nor a particular UI toolkit. Again, great for someone building on top of it. But it makes things like the change from server-side decorations to client-side significantly more annoying / potentially fundamentally incompatiblew ith the project goals.
mpv sits in that perfect anti-goldilocks zone:
It's important enough to be a problem if it were to disappear, yet unlike the Linux kernel, not quite important enough to have the funding and hoardes of patches despite the project complexity. It's also low-level enough to need to worry about every display server and platform on the planet, yet not low-level/general enough to have a say in the design decisions (e.g., Wayland membership, I believe, is pretty much limited to compositors and UI toolkits - like QT/GTK).
All of that, and probably more, adds up to maintaining a surprisingly important, difficult project with relatively few developers but likely many millions of users, many of whom may not even know you exist; it's thankless yet important work.
As a result, unsurprisingly, in addition to the infamous locale rant [2] (unrelated to Wayland), mpv used to have a pretty spicy wiki section entirely dedicated to GNOME's Wayland implementation:
- https://github.com/mpv-player/mpv/wiki/FAQ/ddcbe1b88a99d2568... (2020)
This section still kind of exists, but it has been toned down a fair bit now that certian issues have been addressed [3]; it now mainly focuses on a couple of specific GNOME issues directly and more broadly addresses NVidia's poor Wayland support relative to some other vendors.
-----
[1]: https://gitlab.gnome.org/GNOME/mutter/-/issues/217
[2]: https://github.com/mpv-player/mpv/commit/1e70e82baa9193f6f02...
[3]: https://github.com/mpv-player/mpv/wiki/FAQ/a70c96040ad4fa374...
Something as simple as adding integers is tricky due to its implicitness. Due to promotion, the following code works on some platforms but is verboten on others:
int16_t a = 20000;
int16_t b = a + a;
But even ignoring size, it can bite you:
unsigned int c = 1;
signed int d = -2;
if(c + d > 0)
puts("1 + -2 > 0");
That code prints because of balancing: The signed value gets cast to an unsized int, which can't hold the value.
For not directly integer related semantics, creating an out-of-bounds pointer is UB, unless it points to one past the end of the object, in which case you can create the pointer but can't read from it. And if an object's lifetime has ended, pointers to it aren't valid anymore even if you don't even read from it:
void *foo_1 = malloc(1);
free(foo_1);
void *foo_2 = malloc(1);
pr
Read the rest
intf("Checking for same allocatoin: %d", foo_1 == foo_2);
If you go by the standard, strictly speaking this is UB:
#include <stdio.h>
int main(void) {
puts("Hello World);
}
But don't worry, real compilers will refuse to compile this. Most don't follow the standard anyways, because they don't treat writing to a memory location as side effect.
A large source of gotchas in C are the standard libraries. For example here's a taste of the trouble its locales cause:
https://github.com/mpv-player/mpv/commit/1e70e82baa9193f6f02...
For context, since I hadn't seen this before: https://github.com/mpv-player/mpv/commit/1e70e82baa9193f6f02...
(advisory: _lots_ of profanity)
In This code smells of desperationVulkan Video Decoding: Usage Guide and FAQ
4 points · Open discussionMy favorite infamous example being the MPV C locale commit: https://github.com/mpv-player/mpv/commit/1e70e82baa9193f6f02...
You can really feel the author's rage at the state of the world.
In Open source code with profanity in comments is statistically betterStream_libarchive: Workaround various types of locale braindeath
2 points · Open discussionThe first thing that comes to mind with C and locales is this legendary MPV commit: https://github.com/mpv-player/mpv/commit/1e70e82baa9193f6f02...
In Cuneicode, and the Future of Text in Cmpv's locale rant is another "blog post" about the frustration of locale.
https://github.com/mpv-player/mpv/commit/1e70e82baa9193f6f02...
In The C Standard Library Function Isspace() Depends on LocaleMpv now supports Vulkan Video Decoding
4 points · Open discussionThere are OpenGL extensions which can import a provided GPU buffer as a texture, using those you can achieve zero-copy.
For instance, with VAAPI->OpenGL you would use vaExportSurfaceHandle in conjunction with glEGLImageTargetTexture2DOES.
Check out the "hwdec" mechanism in MPV:
https://github.com/mpv-player/mpv/blob/master/video/out/hwde...
https://github.com/mpv-player/mpv/blob/master/video/out/hwde...
In Vulkan Video DecodingShowing the 15 most recent of 19 sources. Enable JavaScript to search and browse every indexed mention.