PS. For the controversy: Please note I am not disputing the claim - particularly when many claim this is the best player on any platform, not just Linux.-
Isn't mpv a more modern and maintained mplayer fork? Mplayer was my go-to for many many years, starting in the early 2000s, but I switched at one point and can't remember why. What do you prefer about mplayer?
If I recall correctly, for a brief time mplayer disappeared from Debian. At the time I evaluated various alternatives and mpv was one of them, but I switched back to mplayer as soon as it made its way back to the distribution. For me, mplayer is the standard media player. I guess I just don't see any reason to switch to mpv or to any other player.
I see no reason to cling to mplayer/mplayer2, mpv has pushed things forward from there.
mplayer is what I used to use ages ago, can't think of a single thing I miss that it did which mpv doesn't. Like you, I was introduced to mpv through the debian disappearance, and it's been fine. Forks can be necessary to keep development active; it's one of the core features of FOSS.
That's funny, for me that's exactly the best GUI out of the box. I actually did some tinkering to reduce the GUI parts even more, and added more keyboard shortcuts.
I use SMPlayer as a front end for mpv (you can select mplayer or mpv as backend). Not sure if that is common or even a good idea. But I am generally happy with it.
That's funny. SMPlayer was my preferred MPlayer front end before I switched to MPV years ago. And I've never really felt like I needed more GUI for MPV.
VLC plays pretty much any media file from pretty much anywhere it can be stored, and it's got a pretty standard interface, so folks find it easy to understand how to operate it. That's it. No real "cult" situation there. Just an app that does it's job well. Same is true of mpv, but some people will prefer it (as I do) because it's lightweight and clean and quick (and all the stuff people also like about VLC).
Maybe I'm an outlier, but I've always found the VLC GUI quite cluttered and confusing.
99% of the time I use it, I just want to play a local video file or watch a web radio stream. I don't want to create a playlist or browse my computer using a built-in media library, yet both are front and center in VLC.
I'd say there are a few aspects that make VLC an easy, common choice: 1) it has incredibly extensive functionality (even if MPV has more capabilities, with VLC, it's all available through menus/GUI - no need to memorize any commands) 2) handles any files you throw at it EVERY time - out of the box. Throughout the years, VLC has been the only player which didn't choke on ANY file I threw at it. 3) It's multiplatform and works (in my experience) equally well on Windows, Linux, and MacOS - OUT OF THE BOX! Even on Android, where I normally prefer using MX Player Pro (bc it has a slightly nicer UI/UX), it was able to handle video files where the audio was in the DTS format. MX Player Pro required the installation of codecs to make the audio work. 4) It's been around forever, so if you want to look up any info related to it, you're sure to find it more easily than for any other player.
All that said, VLC is not always my video player of choice. On Windows, I typically prefer PotPlayer and MPC-BE. On MacOS - IINA. On Android - MX Player Pro. But I always keep it installed on all those platforms because I know that I can fall back to it reliably at a moment's notice and it will simply work.
Additionally, with regard to MPV, where I think it makes the most sense is for the highly discerning user who wants to tweak the rendering of video in a specific way. I think anime fans really like it a lot (I'd imagine they upscale or improve the image quality in very subjective, specific ways, though I didn't investigate this in detail). The other good use case is when you have somewhat limited hardware and you want the most efficient video player application. That is perfectly valid, I suppose, but I think for most people, whatever hardware they're playing a video file on is likely more than capable of running with a more 'unoptimized' video player app such as VLC.
I switched from VLC to mpv. Mpv loads quicker and is more (CPU) efficient. Besides that, I like the minimalist UI.
I think it's worth it, but to get the most out of it, you'll need to customize it to your liking (tweaking the OSC, the keyboard shortcuts... you can do many things, but it requires some reading/searching).
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.
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.
> 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.
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.
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.
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
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.
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).
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 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.
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 also hold those keys to play normally at the speed set with [ and ], so you can actually play the video in reverse and slow motion or whatever. Be aware that it's usually very intensive on cpu time (and maybe gpu decoding if applicable) since it has to usually go back a whole keyframe and compute all frames between while doing that, which may result in less than smooth playback on some videos.
Reverse usually works significantly worse, at least with common video codecs that work on key frames and intraframes. Depending on your work flow, codecs that don't operate on keyframes/intraframes will actually provide mpv the capability of playing backwards at full speed (eg: rawvideo, ffv1, magicyuv...).
Now its on every device, even on my android tablet. Its perfect. Minimalistic, sane defaults, fast and just works.
It can even play natively over ssh. Its awesome
> mpv sftp://mit@nyx/home/mit/Work/merged.mp4
Recently I needed a hotkey to rotate a video (which seems not like any player can easily do this; for mpv it was a 'r cycle_values video-rotate "90" "180" "270" "0"' in the in input.conf)
I have found this not to be as straightforward as this. In particular:
1. Although `yt-dlp` consistently is able to download videos at link speed (even when the said link is in multi-gig range!), streaming the video through `mpv` will not work as well and some videos would buffer every couple chunks. But that was in the past…
2. With recent changes to how videos are served and "protected", I'm still able to download them with recent versions of `yt-dlp`, but streaming a `yt-dlp` generated playlist will reliably fail to work (this is true for the newpipe android app too.)
3. Even back when streaming youtube worked, closed captions and other such features would not work by default.
I download videos first, nowadays. And then play them with mpv anyway.
I used to use mplayer(of which mpv is a fork) to watch pirate streams of premier league games several years ago, via acestream. Since this was live, lag was a real issue; you can't buffer ahead when there's nothing to buffer yet. Eventually I figured out that mplayer had settings to do things like buffer for 2 minutes at the beginning of the stream before playing. You could also configure it by megabytes pre-buffered. This solved my lag issues very neatly. I can't remember what the settings were, it's been a long time and I don't have those config files anymore. But it should all be in the docs somewhere.
> 1. Although `yt-dlp` consistently is able to download videos at link speed (even when the said link is in multi-gig range!), streaming the video through `mpv` will not work as well and some videos would buffer every couple chunks. But that was in the past…
I still get this with YouTube from time to time. Works with some videos, others are unwatchable. Seeking also generally seems broke and is often slower than downloading even the whole video.
I wish seeking word work better in this mode though. There is no reason seecon should freeze the player for minutes or indefinitely if the whole video can be downloaded from start to finish in seconds.
it also has a robust Lua scripting interface. I made a tool in Golang and Lua that allows Mpv to treat torrent files and magnet links as if they were http links. You can then stream a torrent directly.
People also don't realize that mpv not only has the ability to stream youtube videos but you can also search youtube on the CLI using mpv `mpv ytdl://ytsearch:query`
it can also play videos directly in the terminal using ascii, sixel or kitty image protocol (which is by far the highest quality)
> I made a tool in Golang and Lua that allows Mpv to treat torrent files and magnet links as if they were http links. You can then stream a torrent directly.
Increíble. Consider putting this up somewhere folks can find it.-
> it can also play videos directly in the terminal using ascii
it's crazy what you can do with its plugin scripts. MPV Android also supports them.
I wrote one which turns off keyboard backlight and maxes brightness for HDR.
Also I'm using it to stream from Gerbera and to sync progress seamlessly between phone and PC.
I personally use MPV to play my music libraries containing mainly FLAC file and I wrote a plugin [1] using JS to send my listens to listenbrainz.org . It's damn simple, but it worked for the past few months!
The best media player in existence: superb minimalist UI, makes use of hardware accelaration, and just plays videos.
Its continued excellence is one of the reasons why I will probably remain a pirate for life. Streaming services spend millions on their players and don't come close.
A long, informative read, with some profanities. Highly recommended!
25 years ago, Spolsky wrote an article called “everything you wanted to know about Unicode and character sets”. Those of you who only lived in the post Unicode/UTF world might find that one informative as wel.
As strange as it is to say, I think avoiding problems like this might be one of the biggest productivity boosts from new languages like Go, Rust, Swift, etc. New ecosystems get a chance to “do over” the standard library and flush all the horrible legacy choices made before we knew better (locales, UTF16, etc).
The standard library in Zig, Go, Rust, and many others is miles ahead of the C standard library or posix api. That is reason enough to use them.
Right. And the rust standard library provides (in my mind) the right API for this. Strings are always internally utf8. But they have constructor methods to create strings from UTF16 bytes, or utf32 or whatever.
Rust isn’t unique. Swift, Go and Python3 all expose more or less the same api. C’s standard library, with the benefit of hindsight, is uniquely terrible here.
Locales are so much more than character sets. E.g. an Arabic locale changes the direction of writing, it also changes the characters used for numbers, and completely changes the way numbers and dates are formatted. This is where the C locale functions are problematic.
> Also for most of those things, you want to be explicit about when to use the locale and when to not.
Right. And that's where the POSIX C API falls down. The locale isn't named explicitly. Its not a function parameter. Its specified via a global variable that gets shared between all your threads.
You might think you can use scanf to parse a string in a JSON file. It might appear to work fine on your local computer. But scanf behaves differently depending on the system locale. You can wrap scanf with a helper function which sets the locale to something sensible, calls scanf, and restores the locale. But because the locale is shared with other threads, which might be depending on the locale in other ways. So this can introduce race conditions.
The whole thing is horribly designed - and it leads to buggy, unreliable code that is hard to reason about. Even in the best case, introducing thread syncronization into a function like sscanf will lead to a dramatic decrease in performance.
> I'm skeptical that rust magically deals with, for example, character sets in 30 year old subtitle files, in a way that makes C seem inadequate.
It's not just that C is "inadequate" - C and its standard library provide no assistance in that task. As the mpv author explains in profane detail in the linked commit message, POSIX locales are an active hindrance, not a useful form of "legacy compatibility".
Not "magically", but more reasonably and without forcing your entire program into a different state, breaking any ability for libraries to work with a huge range of functionality consistently. C locale handling is basically impossible to work with robustly, even before you get into how it can't be effectively used at all in a thread safe way.
> All in all, I believe this proves that software developers as a whole
and as a culture produce worse results than drug addicted butt fucked
monkeys randomly hacking on typewriters while inhaling the fumes of a
radioactive dumpster fire fueled by chinese platsic toys for children
and Elton John/Justin Bieber crossover CDs for all eternity.
Loved the last paragraph of the long, justified rant. Hilarious:
“All in all, I believe this proves that software developers as a whole
and as a culture produce worse results than drug addicted butt fucked
monkeys randomly hacking on typewriters while inhaling the fumes of a
radioactive dumpster fire fueled by chinese platsic toys for children
and Elton John/Justin Bieber crossover CDs for all eternity.”
I actually thought that last paragraph really undermined his case, because rather than substantiating like he did before, here he goes all out and just insults whoever he can think of; people who take it in the ass, greybeards, the Chinese, listeners of bland music...
I get him though. It's one of those writings from a foul mood. There was probably more going on in his life than some trouble dealing with locales.
> ...here he goes all out and just insults whoever he can think of...
No, he observes that software devs as a group, and as a culture tend to produce worse results than incredibly-distracted and certainly-fatally-intoxicated simians banging on typewriters.
It's a bit of hyperbole, but the overall state of software is absolutely dire.
> ...the Chinese, listeners of bland music...
In some-to-much of the world, it's pretty well-known that a lot of cheap crap (much of which has historically been made in China) is very shoddily made and fairly quickly finds its way to the landfill. One shouldn't confuse criticism of shoddily-made products for criticism of the citizens of the country of origin of said products.
I'd also expect the referenced (certainly entirely-hypothetical) CD to be something that ends up getting thrown into the dumpster in huge numbers because store inventory managers expect it to be WAY more popular than it actually ends up being. Also, see above about not getting confused about what the target of the insult is. ;)
> There was probably more going on in his life than some trouble dealing with locales.
shrug Not everyone chooses to write in sterile $DAYJOB-approved language when explaining in detail the root of their frustration with the absolutely bullshit garbage pile they have to build upon for their non-corporate side project.
> No, he observes that software devs as a group, and as a culture tend to produce worse results than (...)
Yeah, to that I say "meh". Maybe. In my view, on a different day he would have hacked in a workaround, explained quickly that it is because of the illogical locale system, cited a few sources and moved on with his life. Sure, man-made stuff is a mess. Nothing's ever perfect. But stuff's particularly not perfect when you're in an absolutely foul mood.
It's unconstructive to entertain the thought that software in general is awful. A waste of energy. Reading his rant, I just think "improve it and move on"!
> One shouldn't confuse criticism of shoddily-made products for criticism of the citizens of the country of origin of said products.
Yeah, fair enough. There's different ways to interpret it. Maybe a proud modern Chinese person would be mildly offended by it. No biggie, the point was: in the last paragraph, he's firing a machine gun. A full release of rage.
> Not everyone chooses to write in sterile $DAYJOB-approved language
Of course. It feels great to talk bad when you're in a shit mood. I don't know about you though, but the next day I usually wish I'd just kept my cool. :-)
> In my view, on a different day he would have hacked in a workaround, explained quickly that it is because of the illogical locale system, cited a few sources and moved on with his life.
If you were this guy, sure. I advise you to carefully re-read the ~2,200 word essay contained in that commit message bearing foremost in mind that there exist people who intentionally write messages that make their frustration plain and obvious.
> No biggie, the point was: in the last paragraph, he's firing a machine gun.
No, that's a wrap-up, and it fits the tone of the rest of the essay.
> It feels great to talk bad when you're in a shit mood. I don't know about you though, but the next day I usually wish I'd just kept my cool.
1) I doubt that you're the sort of person to write an angry, in-depth ~2,200 word essay and then regret it the next day. To be clear, I expect that you would not put that much effort into writing something that clearly and frankly expresses your frustration.
2) Did you forget about this statement in the opening paragraph of the essay?
> To justify this emotional outbreak potentially insulting to unknown persons, I will write a lot of text. Those not comfortable with toxic language should pretend this is a religious text.
The tone is deliberate and intentional. Please adjust your worldview to include the existence of people who get angry about stupid bullshit and then write and publish in-depth, angry essays about exactly how stupid that bullshit is.
> Nobody looks at an iPhone and says "ugh, Chinese crap".
Well, the really important parts are Taiwanese crap. ;)
But (more seriously), the thing to remember is that the "Chinese crap" stereotype dates back to the days when China didn't have a notable electronics assembly industry... so nearly all the crap hitting US shores was cheap crap. Japan was the big Asian tech producer back then, and we still did a substantial bit of consumer (and industrial) electronics production in-country.
To be fair, he has other issues than dealing with C locales. The author of that commit used to be the main developer behind mpv, until he decided to delete all support for GNOME in a single commit.
> Imagine they had done this for certain other things. Like errno, with all the brokenness of the locale API.
They did. See for example time functions like localtime (and localtime_r) and tzset. It is admittedly locale adjacent, since it depends on the locale. But the time zone is also global state, so it is impossible to get the time in a different timezone with standard apis in multi-threaded portable (for posix) c code.
> Both C locales and wchar_t are shitfucked retarded legacy braindeath. If
the C/POSIX standard committee had actually competent members, these
would have been deprecated or removed long ago. (I mean, they managed to
remove gets().) To justify this emotional outbreak potentially insulting
to unknown persons, I will write a lot of text. Those not comfortable
with toxic language should pretend this is a religious text.
Wow that comment is so educating. I guess I'll pay more attention now to standard functions I use in C code.
As for weirdness of C standard, I guess it is because they wanted to make it compatible with obscure proprietary platforms which might not even exist anymore.
Joining the praise in this thread. Extremely reliable, fast, versatile, plays anything.
What I haven't seen mentioned is that it has 1- or 2-key keyboard shortcuts for almost everything, down to adjusting audio/video delay, subtitle size and offset, etc etc.
Once you've had the experience of adjusting the video just how you like it in 5 seconds with a series of keypresses without having to pause or disrupt the playback, you'll never want to go back.
What's cool that you can control it from your editor. It feels so nice managing YouTube video playback from Emacs, makes the note-taking so easy. elfeed-tube/elfeed-tube-fetch command lets you follow the transcript, while ignoring commercial bits. You can basically search through the text and play it from that point.
I didn’t know mplayer had been forked - this looks good to me.
The primary reason why I used mplayer in the early 2000s was performance, both in terms of cpu and for lack of a better word ‘ smoothness ‘.
Basically all other players seemed to produce choppy videos ( including regular dvd players ) but mplayer didn’t ( and there was no motion interpolation). A friend of mine told me that mplayer was very accurate ( ie each frame lasted exactly the same duration), unlike most players on the market at the time and this explained the ‘smooth’ feeling.
Is this smoothness advantage still the case ? Would anyone know why it felt like that years ago ?
It's impossible for video players to be exactly accurate on normal monitors as most computer monitors don't handle movie frame rates. Either a frame gets skipped or elongated here and there, audio get resampled while video speed changes, etc. but there's definitely no silver bullet due to imperfect hardware not matching movie data formats
A lot of monitors these days support a kind of variable refresh rate like Freesync, so this should be possible. I've never actually got it to work with AMD, Linux and mpv, though.
It's relatively easy to get 100us level precision in CPU wait and mpv has 42ms (42,000us) to emit each frame (at 24fps). Nevermind that the monitor refresh is likely 60fps or better so each frame lasts for two+ monitor frames anyway. As long as it is consistent with each frame timing it should be very rare that a video frame is skipped or doubled up.
Frames shouldn't be skipped but if the monitor is at 60Hz and the video is at 24 then many frames will have to come early or late. That's what causes the stutter that is most apparent on slow planning scenes. It's like the reel in the projector is being fed through in a jerky manner so each from lines up with one of the monitor frames rather than going through at constant speed like it's supposed to. There's no way around this. However with 120Hz monitors you just display one frame every 5 frames and no jerky motion is required (except the fact that US releases are at 23.976fps, not 24, so a frame will have to be doubled every now and then I guess, or maybe the soundtrack is just pitched up to 24? Don't know).
That can't be it. The circuit outputting video onto the wire triggers every 1/60th of a second, always the same duration.
There are situations where a player could time things so badly an entire frame has to be skipped, but that shouldn't happen often. And it should basically never happen on a regular DVD player. Any variations smaller than that disappear; whether a frame is ready 15ms before the deadline or 1ms before the deadline has no impact on the output.
The primary reason that many of us still used MPlayer 20 years ago was that it did keyboard-based seeking really well. Nothing fancy, just look for the closest I-frame from the target time and move exactly there.
This art of quick seeking sort of got lost in time as the distance between UX people and people who understand H.264/265/etc in detail grew.
On Apple TV: At best it takes like 500 ms. At worst (the Max app), like 6000 ms.
My favorite thing about mpv is that it works under the console using framebuffer or drm. This can be used with configuration or scripting for image viewing, reading pdfs, and more without needing needing a lot of specialized tools, especially on non-linux platforms where graphical framebuffer tools aren't available. Tmux +(e)links + mpv can nearly completely obviate the need for a graphical environment and removes a lot of distracting things from view.
Can it do smooth scrubbing (i.e. scrolling the progress bar)?
So many media players only show the key frames when scrubbing, making it a much less pleasant experience. Some mobile phones (Apple, Samsung) built-in media players seem to do it nicely, but I've never found a desktop media player that does it (VLC can't).
Probably would require a lot of extra decoding behind the scenes to extract all the frames, but worth it on a modern machine.
I don't really know what "scrubbing" is, but If you add "exact" to seek then it will use exact (non-keyframe) seeks. I think that's what you want? For example from my input.conf:
Right seek 5 # In seconds; these are limited by keyframes
Left seek -5
Shift+Right seek 2 exact # Smaller non-keyframe-limited, seeks with shift
Shift+Left seek -2 exact
Obviously, this is slower. Sometimes much slower (depending on the file).
> Obviously, this is slower. Sometimes much slower (depending on the file).
Anecdotally, I’d change that “sometimes” to “often”. After years of using `exact` I finally stopped. It always felt that the wait was longer than going to the previous keyframe and rewatching the bit. Now if I could only find the perfect timing to go back, though.
A lot of stuff I watch is 720p, and it's okay with that. But with some types of higher quality files it can be (very) slow.
That said, I have replaced most of my "exact seeks" with "sub-seek"; in input.conf:
Alt+Right sub-seek 1 # Go to next/previous sub (within demuxer-readahead-secs)
Alt+d sub-seek 1
Alt+Left sub-seek -1
Alt+a sub-seek -1
And then in mpv.conf:
demuxer-readahead-secs=120 # sub-seek only works within this cache
demuxer-hysteresis-secs=60 # Fill cache only if lower than this; saves battery
This allows me to fairly quickly skip past stuff that's not too interesting, while still actually following the gist of what's going on.
I think it's also bound by default, but I'm not sure what that is from the top of my head. You'll definitely need to set that cache as it's only 2 seconds or so by default.
I don't believe the scrollwheel works to seek video, not sure, but MPV can go frame by frame. It's bound to the keyboard by default, but you can tweak your config and bind it to the scrollwheel.
Outside of low bitrate streaming (youtube), most media has sufficient keyframes (I frames) that this distinction really doesn't matter. I don't know what mpv does, though.
Yes, you have to turn it on through hr-seek=yes but then you can seek arbitrarily; great when I have to quickly step through something but not actually miss anything.
For the scrolling you can bind smoething like a .1s seek to the wheel
Not to take away from the work done on the plugin, but that’s a “basic” skip intro implementation.
To reliably be able to find intros/credits, you need to some non-local analysis - basically, you need to look for common chunks of audio across episodes in a season or entire show.
I wrote a CLI tool that can do this, albeit it’s not really “finished” and probably will never be. My initial goal was to use it to develop a Jellyfin plugin, but then I discovered that there was already such a plugin :)
It’s also the only way I can play HDR on macOS that looks decent (besides the native players like QuickLook/Quicktime/Photos).
I went into a rabbit hole recently playing iPhone-recorded Dolby hdr videos and tweaking all the various mpv settings but nothing really looked the same as in Photos. Iina is closer but also not exactly the same as the native players.
iPhone-recorded Dolby Vision videos uses an additional metadata called "Ambient Viewing Environment", and I don't think any third-party player supports it at the moment.
IINA has issues with color space conversions. I've heard that the specific issue is that it always (incorrectly) assumes a BT601 matrix for all videos, though I haven't verified it myself and cannot really right now. (I did verify its colors differing from stock mpv before writing this comment, though.)
Various mpv wrappers exists, but for reasons like these stock mpv is the only fully reliable version.
Huh, that explains it, I was wondering why I was having problems with some video that VLC would even playback correctly, I didn't think to try the stock mpv.
I’m not the person you asked, and I don’t have that issue, but this common trend of replying to any criticism with “have you filed a bug report?” rubs me the wrong way.
I have opened detailed issues on IINA which describe a bug, how to reproduce, and the correct behaviour (according to their own docs), and they’ve just sat there unacknowledged for years.
IINA’s issue count is twice as big as mpv’s, despite being a UI covering a single OS. Personally I don’t think it’s worth it over vanilla mpv, which I’ve recommended even to non-technical users who like it.
I fully understand your frustration, as this is what I felt about many other projects.
But surprisingly it was only IINA that got my problem fixed when I reported it with how to reproduce and correct behaviour. Hence why I asked if he had filed any bug report.
Admittedly I have not, but I did search for and find similar issues on their github before making this comment, and I do plan to investigate this more one day and possibly make a proper issue. There are indeed a lot of "X tool is broken because of Y" statements of varying credibility floating around in the multimedia community where it's unclear if they were actually ever reported upstream or even double-checked recently (people still claim that VLC uses nearest-neighbour chroma scaling, for example, but that's no longer true (except for screenshots, it's still a problem there)), and that is something I'm trying to work against by investigating and reporting this when I can.
But since I don't use IINA myself and since, as another commenter pointed out, IINA bug reports don't seem to get a lot of responses on average, it hasn't been the highest priority for me.
Still, isn't this bizarre? Over the last couple of decades using Windows and macOS across many machines, I've encountered one time I had to mess with settings like this. That's the time I temporarily disabled hw accel in chrome so I could screenshare and watch a show with someone.
Meanwhile on Linux you gotta configure every app one at a time because sane defaults and auto configuration weren't invented here.
In addition to what others have said, hardware decoding comes with other drawbacks. There’s occasionally decoding inaccuracies and there’s no support for most video filters (unless you’re using `auto-copy`)
Do you know if/why on apple silicon Macs there’s a difference between videotoolbox and videotoolbox-copy ? I thought the SoC memory is shared and that there wouldn’t be a need for copying data from VRAM to RAM.
If you autodetect hw accel, even the slowest underpowered gpu might get returned, which could result in worstened user experience compared to just using cpu.
Vulkan in theory should be more flexible, but in practice VAAPI still has some advantages when it comes to power efficiency due to Vulkan path lacking some needed features (I think something to do with color space conversions which in Vulkan now have to happen using regular GPU compute units which is inefficient). In the longer term, Vulkan should be preferable in all scenarios.
Not sure why but I've had lots of issues with worse performance (lagging/stuttering) on Fedora (I think kernel 6.10) with a Vega 64. Every year or so I'll give it a try and it just won't work well and I give up again.
Yeah, I just pacman-installed mpv and tried running it on a 4k video. My CPU fan immediately kicked on, and top showed multiple cores getting involved. Kept scrolling this HN post to learn about hwdec=auto. Coming from mplayer and vlc my immediate question is, "What tradeoffs are the maintainers trying to make by not making this the default?"
Streaming or player errors? Plex has basically never failed to play any video I've ever given it, but a bad connection can totally ruin streaming. I wish they would implement pause and allow to buffer.
In my experience Plex has a serious problem with determining whether or not it's capable of playing a file back directly without converting. I regularly have to switch it to "convert automatically" to make a file play.
What can be directly played and not directly played are just lists of formats that Plex bakes into the app, and not really anything to do with mpv, right?
Happy VLC user here, but might give this a try, I want to find a better UX with the player controls, like a way to pin the controls bar when full screen (it disappears after some seconds), a 10s forward/backwards control, bigger buttons, less bloated settings, less features that I don't use like radio and other stuff.
But one thing that confused me seeing that homepage is that it shows a player UI screenshot, but it says " mpv is a free (as in freedom) media player for the command line", isn't just for the command line right? I assume you can install it as an app and it has an UI like VLC. (I'm on the phone rn will check it on my PC later).
mpv has a UI for things like seeking forward and backward, displaying info, etc. But you typically start it like:
% mpv file.mp4
That's what they mean.
It doesn't really have things such as "File → Open" like VLC has. At least not out of the box, but it's scriptable with Lua and there are scripts and even entire "alternative frontends" that can do this.
It can also be remote controlled via a socket; I built an audio player like this; works pretty well.
In general, if you want a "Windows-like" or "macOS-like" experience then VLC is pretty good. If you want a more "unix-beardy" experience then mpv is pretty good.
Thanks for your response. Understand. So MPV may not be for me, I don't know how to use a command line app, I remember have to use to fix an Ubuntu issue and the UX was painful to me.
mpv tries to be pretty minimalist (and does this well), you could try a frontend (Celluloid, Haruna, etc.). And for the commandline, when you install the mpv package, depending on the distro, the package creates a default shortcut/desktop file, so you can open videos on your WM without hitches, on the menu bar. You can associate the shortcut to mime/file types and set as default player too. You can create yourself a desktop file too if necessary on your profile (eg: $HOME/.local/share/applications/mpv.desktop) with this file/content [1]
Ahhh.... sounds like tweaking vim/nvim (which is one of my daily tools).
Sure the possibility to tweak the UI is limitless, but at least there are minimum usable UI, like gvim (Windows, Linux) or macvim (macOS) which are easy to install.
My favorite feature of mpv so far is being able to apply CRT shaders in real time to content. This solution also handles properly downscaling HD videos into actual 240p buffers that then gets upscaled to your screen resolution by the shader.
Do you have the Apple silicon version? The brew package is messed up somehow IIRC a the up to date version for Apple silicon doesn't have the graphical shortcuts (I don't remember what brew calls these), but the one that does is for the Intel CPUs.
575 comments
[ 0.20 ms ] story [ 449 ms ] threadStrong clam, this ...
PS. For the controversy: Please note I am not disputing the claim - particularly when many claim this is the best player on any platform, not just Linux.-
What's better?
mplayer is what I used to use ages ago, can't think of a single thing I miss that it did which mpv doesn't. Like you, I was introduced to mpv through the debian disappearance, and it's been fine. Forks can be necessary to keep development active; it's one of the core features of FOSS.
Struggling to see the benefit of mplayer over mpv today.
That's funny, for me that's exactly the best GUI out of the box. I actually did some tinkering to reduce the GUI parts even more, and added more keyboard shortcuts.
And has done this, for a long time, since times when other players struggled.
Maybe it's not the "Best" - it is still the goodest.
MPV is great too! I think it's important to also recognize how rad VLC was and continues to be.
99% of the time I use it, I just want to play a local video file or watch a web radio stream. I don't want to create a playlist or browse my computer using a built-in media library, yet both are front and center in VLC.
[1] https://github.com/clsid2/mpc-hc/ [2] https://github.com/Aleksoid1978/MPC-BE
All that said, VLC is not always my video player of choice. On Windows, I typically prefer PotPlayer and MPC-BE. On MacOS - IINA. On Android - MX Player Pro. But I always keep it installed on all those platforms because I know that I can fall back to it reliably at a moment's notice and it will simply work.
Additionally, with regard to MPV, where I think it makes the most sense is for the highly discerning user who wants to tweak the rendering of video in a specific way. I think anime fans really like it a lot (I'd imagine they upscale or improve the image quality in very subjective, specific ways, though I didn't investigate this in detail). The other good use case is when you have somewhat limited hardware and you want the most efficient video player application. That is perfectly valid, I suppose, but I think for most people, whatever hardware they're playing a video file on is likely more than capable of running with a more 'unoptimized' video player app such as VLC.
Of course, if you really want to be a purist you could use ffplay.
I think it's worth it, but to get the most out of it, you'll need to customize it to your liking (tweaking the OSC, the keyboard shortcuts... you can do many things, but it requires some reading/searching).
Mpv does not have that issue and converts 4k HDR to SDR in real-time and shows a colorful image.
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 ...
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?
A media player, though, has fewer challenges.
Speaking of which: which project tkaes security more seriously, vlc or mpv?
“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.
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.-
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.
The media players we have on mobile don’t suffer from these issues, so they must be solvable.
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.
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
A couple of years ago, mpv was unable to handle it.
See also https://github.com/mpv-player/mpv/issues/10122
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.
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.
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.
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" shows: Primaries: bt.2020. Colormatrix: bt.2020-ncl. Levels: full. If that means anything.
"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.
. and , on keyboard go frame-to-frame, you can also up and downspeed with [ and ]
Now its on every device, even on my android tablet. Its perfect. Minimalistic, sane defaults, fast and just works.
It can even play natively over ssh. Its awesome
> mpv sftp://mit@nyx/home/mit/Work/merged.mp4
Recently I needed a hotkey to rotate a video (which seems not like any player can easily do this; for mpv it was a 'r cycle_values video-rotate "90" "180" "270" "0"' in the in input.conf)
1. Although `yt-dlp` consistently is able to download videos at link speed (even when the said link is in multi-gig range!), streaming the video through `mpv` will not work as well and some videos would buffer every couple chunks. But that was in the past…
2. With recent changes to how videos are served and "protected", I'm still able to download them with recent versions of `yt-dlp`, but streaming a `yt-dlp` generated playlist will reliably fail to work (this is true for the newpipe android app too.)
3. Even back when streaming youtube worked, closed captions and other such features would not work by default.
I download videos first, nowadays. And then play them with mpv anyway.
I used to use mplayer(of which mpv is a fork) to watch pirate streams of premier league games several years ago, via acestream. Since this was live, lag was a real issue; you can't buffer ahead when there's nothing to buffer yet. Eventually I figured out that mplayer had settings to do things like buffer for 2 minutes at the beginning of the stream before playing. You could also configure it by megabytes pre-buffered. This solved my lag issues very neatly. I can't remember what the settings were, it's been a long time and I don't have those config files anymore. But it should all be in the docs somewhere.
I still get this with YouTube from time to time. Works with some videos, others are unwatchable. Seeking also generally seems broke and is often slower than downloading even the whole video.
You can also introduce hotkeys for functionalities I have never seen in another player.
I use this (input.conf) sometimes to normalize the brightness and colors of a scene I'm watching (may not work when using hardware decoding):
Or rotate a video: [1] <https://github.com/occivink/mpv-scripts>People also don't realize that mpv not only has the ability to stream youtube videos but you can also search youtube on the CLI using mpv `mpv ytdl://ytsearch:query`
it can also play videos directly in the terminal using ascii, sixel or kitty image protocol (which is by far the highest quality)
https://github.com/ftk/mpv-confluence/tree/torrserver
Increíble. Consider putting this up somewhere folks can find it.-
> it can also play videos directly in the terminal using ascii
Beats Star Wars over telnet :)
Also I'm using it to stream from Gerbera and to sync progress seamlessly between phone and PC.
[1]: https://gist.github.com/madeindjs/f33225cf4d8fdc9f61e0fe3ebe...
Its continued excellence is one of the reasons why I will probably remain a pirate for life. Streaming services spend millions on their players and don't come close.
Other services are strictly premium, paid affairs. Still not as good as mpv.
Also has a fantastic commit where the author rants about locales: https://github.com/mpv-player/mpv/commit/1e70e82baa9193f6f02... worth a read for some chuckles.
25 years ago, Spolsky wrote an article called “everything you wanted to know about Unicode and character sets”. Those of you who only lived in the post Unicode/UTF world might find that one informative as wel.
The standard library in Zig, Go, Rust, and many others is miles ahead of the C standard library or posix api. That is reason enough to use them.
Legacy compatibility has value.
Rust isn’t unique. Swift, Go and Python3 all expose more or less the same api. C’s standard library, with the benefit of hindsight, is uniquely terrible here.
Character encoding is the easy and safe part.
Also for most of those things, you want to be explicit about when to use the locale and when to not.
Right. And that's where the POSIX C API falls down. The locale isn't named explicitly. Its not a function parameter. Its specified via a global variable that gets shared between all your threads.
You might think you can use scanf to parse a string in a JSON file. It might appear to work fine on your local computer. But scanf behaves differently depending on the system locale. You can wrap scanf with a helper function which sets the locale to something sensible, calls scanf, and restores the locale. But because the locale is shared with other threads, which might be depending on the locale in other ways. So this can introduce race conditions.
The whole thing is horribly designed - and it leads to buggy, unreliable code that is hard to reason about. Even in the best case, introducing thread syncronization into a function like sscanf will lead to a dramatic decrease in performance.
Its horrible. Just horrible.
It's not just that C is "inadequate" - C and its standard library provide no assistance in that task. As the mpv author explains in profane detail in the linked commit message, POSIX locales are an active hindrance, not a useful form of "legacy compatibility".
This was a great read
“All in all, I believe this proves that software developers as a whole and as a culture produce worse results than drug addicted butt fucked monkeys randomly hacking on typewriters while inhaling the fumes of a radioactive dumpster fire fueled by chinese platsic toys for children and Elton John/Justin Bieber crossover CDs for all eternity.”
I get him though. It's one of those writings from a foul mood. There was probably more going on in his life than some trouble dealing with locales.
No, he observes that software devs as a group, and as a culture tend to produce worse results than incredibly-distracted and certainly-fatally-intoxicated simians banging on typewriters.
It's a bit of hyperbole, but the overall state of software is absolutely dire.
> ...the Chinese, listeners of bland music...
In some-to-much of the world, it's pretty well-known that a lot of cheap crap (much of which has historically been made in China) is very shoddily made and fairly quickly finds its way to the landfill. One shouldn't confuse criticism of shoddily-made products for criticism of the citizens of the country of origin of said products.
I'd also expect the referenced (certainly entirely-hypothetical) CD to be something that ends up getting thrown into the dumpster in huge numbers because store inventory managers expect it to be WAY more popular than it actually ends up being. Also, see above about not getting confused about what the target of the insult is. ;)
> There was probably more going on in his life than some trouble dealing with locales.
shrug Not everyone chooses to write in sterile $DAYJOB-approved language when explaining in detail the root of their frustration with the absolutely bullshit garbage pile they have to build upon for their non-corporate side project.
Yeah, to that I say "meh". Maybe. In my view, on a different day he would have hacked in a workaround, explained quickly that it is because of the illogical locale system, cited a few sources and moved on with his life. Sure, man-made stuff is a mess. Nothing's ever perfect. But stuff's particularly not perfect when you're in an absolutely foul mood.
It's unconstructive to entertain the thought that software in general is awful. A waste of energy. Reading his rant, I just think "improve it and move on"!
> One shouldn't confuse criticism of shoddily-made products for criticism of the citizens of the country of origin of said products.
Yeah, fair enough. There's different ways to interpret it. Maybe a proud modern Chinese person would be mildly offended by it. No biggie, the point was: in the last paragraph, he's firing a machine gun. A full release of rage.
> Not everyone chooses to write in sterile $DAYJOB-approved language
Of course. It feels great to talk bad when you're in a shit mood. I don't know about you though, but the next day I usually wish I'd just kept my cool. :-)
If you were this guy, sure. I advise you to carefully re-read the ~2,200 word essay contained in that commit message bearing foremost in mind that there exist people who intentionally write messages that make their frustration plain and obvious.
> No biggie, the point was: in the last paragraph, he's firing a machine gun.
No, that's a wrap-up, and it fits the tone of the rest of the essay.
> It feels great to talk bad when you're in a shit mood. I don't know about you though, but the next day I usually wish I'd just kept my cool.
1) I doubt that you're the sort of person to write an angry, in-depth ~2,200 word essay and then regret it the next day. To be clear, I expect that you would not put that much effort into writing something that clearly and frankly expresses your frustration.
2) Did you forget about this statement in the opening paragraph of the essay?
> To justify this emotional outbreak potentially insulting to unknown persons, I will write a lot of text. Those not comfortable with toxic language should pretend this is a religious text.
The tone is deliberate and intentional. Please adjust your worldview to include the existence of people who get angry about stupid bullshit and then write and publish in-depth, angry essays about exactly how stupid that bullshit is.
The "Chinese crap" argument fails to realize that yes, all cheap crap is made in China, because everything is made in China.
Nobody looks at an iPhone and says "ugh, Chinese crap".
Well, the really important parts are Taiwanese crap. ;)
But (more seriously), the thing to remember is that the "Chinese crap" stereotype dates back to the days when China didn't have a notable electronics assembly industry... so nearly all the crap hitting US shores was cheap crap. Japan was the big Asian tech producer back then, and we still did a substantial bit of consumer (and industrial) electronics production in-country.
They did. See for example time functions like localtime (and localtime_r) and tzset. It is admittedly locale adjacent, since it depends on the locale. But the time zone is also global state, so it is impossible to get the time in a different timezone with standard apis in multi-threaded portable (for posix) c code.
What a legend.
As for weirdness of C standard, I guess it is because they wanted to make it compatible with obscure proprietary platforms which might not even exist anymore.
What I haven't seen mentioned is that it has 1- or 2-key keyboard shortcuts for almost everything, down to adjusting audio/video delay, subtitle size and offset, etc etc.
Once you've had the experience of adjusting the video just how you like it in 5 seconds with a series of keypresses without having to pause or disrupt the playback, you'll never want to go back.
Highly recommended.
Basically all other players seemed to produce choppy videos ( including regular dvd players ) but mplayer didn’t ( and there was no motion interpolation). A friend of mine told me that mplayer was very accurate ( ie each frame lasted exactly the same duration), unlike most players on the market at the time and this explained the ‘smooth’ feeling.
Is this smoothness advantage still the case ? Would anyone know why it felt like that years ago ?
There are situations where a player could time things so badly an entire frame has to be skipped, but that shouldn't happen often. And it should basically never happen on a regular DVD player. Any variations smaller than that disappear; whether a frame is ready 15ms before the deadline or 1ms before the deadline has no impact on the output.
This art of quick seeking sort of got lost in time as the distance between UX people and people who understand H.264/265/etc in detail grew.
On Apple TV: At best it takes like 500 ms. At worst (the Max app), like 6000 ms.
MPlayer 20 years ago: 17 ms.
So many media players only show the key frames when scrubbing, making it a much less pleasant experience. Some mobile phones (Apple, Samsung) built-in media players seem to do it nicely, but I've never found a desktop media player that does it (VLC can't).
Probably would require a lot of extra decoding behind the scenes to extract all the frames, but worth it on a modern machine.
Anecdotally, I’d change that “sometimes” to “often”. After years of using `exact` I finally stopped. It always felt that the wait was longer than going to the previous keyframe and rewatching the bit. Now if I could only find the perfect timing to go back, though.
That said, I have replaced most of my "exact seeks" with "sub-seek"; in input.conf:
And then in mpv.conf: This allows me to fairly quickly skip past stuff that's not too interesting, while still actually following the gist of what's going on.I think it's also bound by default, but I'm not sure what that is from the top of my head. You'll definitely need to set that cache as it's only 2 seconds or so by default.
For the scrolling you can bind smoething like a .1s seek to the wheel
https://mpv.io/manual/master/#options-hr-seek
- Seeds of Might/JySzE's base `mpv.conf`[1]
- uosc, a feature-rich but still minimalist UI[2]
- thumbfast, a fast thumbnailer to be used with uosc or another custom UI[3]
- Eisa01's SmartSkip, which allows to skip intros & more (audio-based)[4]
[1] Windows: https://gist.github.com/JySzE/db4149cad726b3b6955dca8d47a197..., macOS: https://gist.github.com/JySzE/34ee131da3974811a9469e1e3b7d4d... [2] https://github.com/tomasklaen/uosc [3] https://github.com/po5/thumbfast [4] https://github.com/Eisa01/mpv-scripts#smartskip
To reliably be able to find intros/credits, you need to some non-local analysis - basically, you need to look for common chunks of audio across episodes in a season or entire show.
I wrote a CLI tool that can do this, albeit it’s not really “finished” and probably will never be. My initial goal was to use it to develop a Jellyfin plugin, but then I discovered that there was already such a plugin :)
https://github.com/aksiksi/needle
I went into a rabbit hole recently playing iPhone-recorded Dolby hdr videos and tweaking all the various mpv settings but nothing really looked the same as in Photos. Iina is closer but also not exactly the same as the native players.
https://developer.apple.com/documentation/technotes/tn3145-h...
I have opened detailed issues on IINA which describe a bug, how to reproduce, and the correct behaviour (according to their own docs), and they’ve just sat there unacknowledged for years.
IINA’s issue count is twice as big as mpv’s, despite being a UI covering a single OS. Personally I don’t think it’s worth it over vanilla mpv, which I’ve recommended even to non-technical users who like it.
But surprisingly it was only IINA that got my problem fixed when I reported it with how to reproduce and correct behaviour. Hence why I asked if he had filed any bug report.
https://interfacinglinux.com/2024/01/10/hardware-acceleratio...
https://github.com/mpv-player/mpv/blob/a3baf94ab9f3b43a8027d...
Would be appropriate to have true/false/auto instead of auto==true though, so auto wouldn't use it unless it confirmed to be working.
Meanwhile on Linux you gotta configure every app one at a time because sane defaults and auto configuration weren't invented here.
See also some details here: https://github.com/mpv-player/mpv/discussions/13909
Bonus trivia: Plex Media Player uses mpv as the video player
https://github.com/ambroisemaupate/plex-profiles/blob/master...
But one thing that confused me seeing that homepage is that it shows a player UI screenshot, but it says " mpv is a free (as in freedom) media player for the command line", isn't just for the command line right? I assume you can install it as an app and it has an UI like VLC. (I'm on the phone rn will check it on my PC later).
It doesn't really have things such as "File → Open" like VLC has. At least not out of the box, but it's scriptable with Lua and there are scripts and even entire "alternative frontends" that can do this.
It can also be remote controlled via a socket; I built an audio player like this; works pretty well.
In general, if you want a "Windows-like" or "macOS-like" experience then VLC is pretty good. If you want a more "unix-beardy" experience then mpv is pretty good.
If you set it as your default video player it will work as you expect.
If you don't want to set it as your default video player you can probably do something like "Right Click -> Open with..." and choose MPV.
https://celluloid-player.github.io/
[1]: https://github.com/mpv-player/mpv/blob/master/etc/mpv.deskto...
Sure the possibility to tweak the UI is limitless, but at least there are minimum usable UI, like gvim (Windows, Linux) or macvim (macOS) which are easy to install.
Huh, it does for me (in the menu bar) on macOS! I guess that's platform-specific then?
Streamlink, for watching live streams without a web browser:
https://streamlink.github.io/
Syncplay, for remote movie parties:
https://syncplay.pl/about/syncplay/
https://i.imgur.com/akmgzxX.png
https://github.com/hhirtz/mpv-retro-shaders