This has always worked well for me, handling anything that’s thrown at it with ease.
Things may have changed since then, but when I first encountered the project several years ago it seemed like the thing that made this project stand out compared to other player projects was a big emphasis on correctness and accurate playback. There have files I’ve encountered that for example VLC will play with quirks (color reproduction is not quite right, etc) that mpv plays perfectly.
The explanation I’ve read in the past is that the difference lies in how VLC was initially focused on playback of video streamed over a network (hence the name Video LAN Client), which was generally more rocky a couple decades ago when the quality and bandwidth of the average connection was lower and the only routes between the client and server could be highly indirect or routed through weak nodes.
In that environment, playing at all without constantly dropping out or buffering is the goal, which is more achievable when fudging accuracy/correctness (which wouldn’t have been possible anyway).
Not sure how true that is though, it’s not something I’ve ever verified.
What non-maintenance work needs doing? From the outside, it plays basically all the formats. There is always the potential for improving algorithms, but it strikes me as pretty feature complete.
Playback issues... scrub problems mentioned elsewhere, audio/video get out of sync when seeking a lot; need to hit left arrow to reset, speed changes lag when changed a lot, when there's a short clip it can end audio early, etc, etc.
Not a huge deal, but if you use it every day for video and audio file testing/lyric transcribing these little bugs get old. The playback core needs a rewrite to be "preemptive" I'd guess.
I have a very similar issue with subtitles in MPV sometimes. Some unknown (at least to me) combination of codec, encoding settings, subtitle format, switching subtitle tracks, and seeking will utterly break it to the point that I have to exit and reopen the file. I can't be bothered to debug the issue (so far).
In general I don't understand the negative comments I see VLC get. I've never encountered major problems with either piece of software. I've encountered minor bugs and annoyances with both.
> PS. On a tangent, rethorically - baring bugs and security - at one point is (if ever) software "finished"?
“PS” originates from “post scriptum”, meaning “written after”. It doesn’t make sense to have it at the start of the text.
But to answer your question, yes, it is definitely possible for software to be done and finished. I’ve done it multiple times, where I have built something that does exactly what I set it out to do, it does it fast and without bugs and has been doing so for years and years with zero maintenance needs.
The general obsession with the idea that “software is never done, only abandoned” needs to end, it’s harmful to good software and its users.
Here’s millions more examples of finished software, in a single word: games.
A web search engine is never done because spammers never cease attempts to.game it in new ways, and because new phenomena keep appearing on the web, from presidents posting official news on twitter to the proliferation of AI-generated texts with subtly incorrect information.
Playing HDR and Dolby Vision encoded movies has been solved a long time ago in mpv, but they usually need the option shown above, which may not be the default on your system.
There are plenty of additional options in mpv that provide a finer control of how HDR colors are handled.
While playing a movie with mpv, press "I", so that mpv will display the information it has about the color space supported by your display and the color space used in the movie, which will allow you to verify if they are correct.
"I" must show two sets of "Format: Levels: Colormatrix: Primaries: Transfer:", one set for "Display:" and one set for "Video:".
"mpv" or any other player must make a conversion from the color space used for encoding the video file to the color space supported by the monitor. A monitor that has not been reconfigured after the initial installation is likely to use the sRGB color space. Any good monitor should have a configuration menu that allows the selection of a better color space, but mpv can convert BT.2020 to sRGB, if necessary (which will reduce the saturation of many colors).
Did mpv print after being launched a line starting with "VO: [gpu-next]"?
Where "gpu-next" is not available, mpv will start anyway, but it will use one of the other video drivers, none of which convert correctly Dolby-encoded video.
On the computer where I normally play HDR/Dolby Vision movies, I use an NVIDIA GPU, so I know for sure that gpu-next works fine with it.
I do not remember whether I have played any HDR/Dolby Vision movie with an AMD or Intel GPU, but I doubt that any of those is incompatible with gpu-next.
In any case, if mpv prints "VO: [gpu-next]" without any error message and if "I" shows for "Display:" the correct color space supported by your monitor, e.g. sRGB or DCI-P3, then you should try to upgrade the GPU driver, which could be too old. Like I have said, IIRC this problem has been solved in 2022 and since then I have never encountered again color conversion errors, so you must have some software component that is older than 2022.
Because my monitor is configured to use the color space DCI-P3 (with 10-bit colors), I alias "mpv" to "mpv='mpv --vo=gpu-next --target-prim=dci-p3'", and it has been working fine for the last two years, including with any HDR and/or Dolby Vision movie.
You can play it with mpv, it depends on the hardware/drivers. It worked fine on a random Ryzen Lenovo laptop with Linux even though MacOS version of mpv couldn't play it correctly on M2 (even though Apple claims that M2 is compatible with the format).
It depends on what format/decoder support went into your particular build of mpv. It offloads almost all of its capabilities onto ffmpeg and its supporting libraries, which in turn won't necessarily be built with exactly everything enabled.
EDIT2: if you consider an ARM board that you can install custom OS on as a PC – admittedly, bit of a stretch – then you can grab UGOOS AM6B plus / AM6 plus / Minix u22x-j max
I believe that the target primaries must be those of your monitor.
BT.2020 are the primaries used to encode the HDR movie.
Monitors with such primaries are rare and extremely expensive. For most good monitors "--target-prim=dci-p3" should be appropriate, if DCI-P3 has already been selected from the on-screen monitor configuration menu, because most monitors come configured by default to use the ugly sRGB color space, so you must change the defaults to be able to display content with bigger color spaces.
Some monitors might have the option to use the BT.2020 color space, when they would still not be able to display all of it, but they would do internally the conversion between the BT.2020 used to encode the movie and whatever color space the monitor can actually display.
I do not remember which was the first version that worked fine. For some time, "gpu-next" was not included by default in the releases, but you had to compile a custom variant to include it.
Pay attention that "libplacebo" is required. If libplacebo is absent, then the Dolby Vision conversion will not work. This could be the reason of your problem, if your Linux distribution does not have libplacebo as an automatic dependence of mpv, or if mpv has been compiled without support for libplacebo.
I would try updating to 0.37.0 or 0.38.0, IIRC it only started to work for me after I updated to one of those (I always build mpv from the latest commit myself, so I'm not sure which release version exactly has the crucial fixes).
Things may have changed since then, but when I first encountered the project several years ago it seemed like the thing that made this project stand out compared to other player projects was a big emphasis on correctness and accurate playback. There have files I’ve encountered that for example VLC will play with quirks (color reproduction is not quite right, etc) that mpv plays perfectly.