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.
Given how VLC is basically bulletproof and will play absolutely anything thrown at it - it's great to hear that mpv is up there ...
This has long since been the case, even back in the MPlayer days in the early 2000s.
I'm not really sure why this is the case though, because I believe both largely rely on the same libraries for many codecs.
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.
Sad to hear.-
PS. On a tangent, rethorically - baring bugs and security - at one point is (if ever) software "finished"?
"We built this search engine. It works. The infrastructure has team enough to run it. But we have this huge payroll of people."
So "improvements" and "features" (and constant UI and UX changes) ...
... "enshittification" ensues.-
When is "good enough" ... good enough?
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.
no-config
target-trc=pq
target-prim=bt.2020
vo=gpu-next
A media player, though, has fewer challenges.
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” 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.
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
install CoreELEC on it and enjoy DV.
https://github.com/CoreELEC/CoreELEC/releases https://discourse.coreelec.org/t/dolby-vision-for-minix-u22x... Recommended settings: https://justpaste.it/divn9 Installation instructions 1: https://discourse.coreelec.org/t/guide-s922x-j-ugoos-am6b-co... Installation instructions 2: https://www.reddit.com/r/PleX/comments/1ajszn9/remux_lovers_...
EDIT: I forgot that for Windows playback, you also need the HEVC and DoVi codec packages.
https://apps.microsoft.com/detail/9P9ZH5FL1BFK https://apps.microsoft.com/detail/9PLTG1LWPHLF https://apps.microsoft.com/detail/9nmzlz57r3t7
My thinking was along those lines. Or at least along the lines of "engineering and/or organizational processes should exist to know when to stop".-
PS. Thanks for your attention to detail. It was a "PS" to an otherwise one-sentence comment.-
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.
Or else the GPU drivers for your GPU card have not been updated for a very long time.
A recent mpv and recent GPU drivers should solve this problem, because it was frequently encountered only up to a couple of years ago.
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.
The media players we have on mobile don’t suffer from these issues, so they must be solvable.
"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.
mpv 0.38.0 Copyright © 2000-2024 mpv/MPlayer/mplayer2 projects
libplacebo version: v6.338.2
FFmpeg version: 6.1.1
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.