Hacker News new | past | comments | ask | show | jobs | submit login
Mpv – A free, open-source, and cross-platform media player (mpv.io)
1113 points by Bluestein 3 months ago | hide | past | favorite | 559 comments



A fantastic mediaplayer, quite minimalistic and performant; it does what it's supposed to do!

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.


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.


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.

Legacy compatibility has value.


> 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.


The correct place to handle character sets is when you're reading the file, not to sprinkle it all throughout your program.


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.

Character encoding is the easy and safe part.


Locales are much more than character sets, but the question was about character sets.

Also for most of those things, you want to be explicit about when to use the locale and when to not.


> 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.


You can create/use a different string processing library without jumping to a completely different language.


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.


> 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.

What a legend.


Worth noting that the author of that commit has not been associated with mpv development in years.


Which is a shame because he's highly techinally competent.


in other words: they've kicked him out of his own project


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.


> 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.

This was a great read


Oh man! This was GOLD. Thanks.


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.


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.


That gnome even needs special support says it all. Does the commit have a similarly funny commit message?


> ...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.


> much of which has historically been made in China

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".


> 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.


> 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.


I started to use it on linux a few years ago.

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)


You can also play videos over http, many websites are supported, even YouTube:

    mpv <yt link>


It uses yt-dlp as the download backend, so it works with anything that yt-dlp handles.


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.


For 1, there might be settings that can help.

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.


Try setting `ytdl-format=ytdl` in `mpv.conf`, that fixed it for me.


> 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 think the issue with buffering on some videos is because of bad DASH support https://github.com/mpv-player/mpv/issues/7033


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.


I agree. With decent bandwidth it's more convenient to first download video with yt-dlp and then play it with mpv


If you're on Linux, don't forget to enable hardware acceleration by adding hwdec=auto to mpv.conf. Works with AMD/Intel/NVIDIA.

https://interfacinglinux.com/2024/01/10/hardware-acceleratio...


Huh. Apparently I've been watching videos on mpv for years without HW acceleration. Good thing I read this; thanks!


I do it like this:

    vo=gpu-next
    gpu-api=vulkan
    hwdec=vulkan
    gpu-context=waylandvk
You can replace hwdec=vulkan with hwdec=vaapi if Vulkan video doesn't work.


Is there a reason why one would prefer vulkan over vaapi, or the other way round?


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.

See also some details here: https://github.com/mpv-player/mpv/discussions/13909


Why would that be disabled by default?


Because if you don't have to enable a flag or two in a text config file what's the fun of using Linux after all :)


Hahaha yeah, that's why I don't like it.


Doesn't work on all systems, I presume. Better to default to something that definitely works everywhere.

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.


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.


Try watching UHD HDR on intel iGPU without accel, or AV1. MPV also supports vulkan decoders.


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.


Just do a quick automatic benchmark surely?


That's never been an issue on Windows or macOS. Apps only use the GPU if it's new enough


It breaks on suspend-to-memory for my system with a nVIDIA GPU. I assume that's a driver problem, though.


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?"


great to know this. thanks!


This is an extremely venerable project, formerly known as mplayer. There are half a million commits going back to 2001, and that’s just from when the CVS repo was converted to Subversion.

streamlink and mpv on a fanless Minix z100 running Ubuntu was a nigh-on perfect Olympics experience.

https://streamlink.github.io/

https://www.minix.com.hk/products/z100-0db-fanless-n100-mini...


I don't think mplayer and mpv are the same thing. It forked mplayer (among others), but mplayer is still its own thing.


I switch from mplayer to mpv some years ago but I don't remember when. I use it daily as my media center player.


It sounds stupid but the killer feature for me is possibility to have multiple subtitles visible, all easily configurable with a few keybinds (track, offset, position, size etc). No streaming service provides this, and they actively omit subtitle languages that aren't "relevant" to your geolocation. I cannot respect a service like that.


+1. This is a fantastic feature. I haven't even bothered learning the keybindings (perhaps I should), I just start with --sid1= and --sid2= and it works well enough.

Neither me nor my significant other are native English speakers, but we have different native languages. I'm comfortable enough with English, but like having English subtitles since I have a hard time with some dialects and occasionally just miss a word or two due to noisy audio. My SO likes having subtitles in their native language.

Being able to have multiple subtitles makes it possible for both of us to get the experience we like, at the cost of a little screen real estate. Well worth it.


They are not default keybinds, but like any configuration can be cycled or set at runtime. Actually I don't use the keybindings much directly since my default config usually is fine, but have a remote GUI to configure it when needed.


Depending on the aspect ratio of the video and playback viewport, you could move the subtitles into the potential black bar underneath.

If there is no black bar, you could get one of those long narrow LCDs off AliExpress, set up the driver, add it as an X display with the right positioning... and then drag the mpv window across that and the TV. Should work. Those little LCDs are just silly expensive though...


Mpv is great with subtitles. Not just being able to switch through subtitle tracks and configure positioning, but also being able to automatically find and play external subtitle files when playing a video. I wrote an article about this: https://www.baeldung.com/linux/mpv-subtitles-automatic. Only issue I found is the documentation for what subtitle formats are supported is lacking. You have to look through ffmpeg code to actually find what formats are actuallly supported.

Additionally, https://subdl.com/ with https://github.com/alexanderwink/subdl is a great resource for finding and downloading subtitles from the comand line.


Especially for things like language learning they are amazing, but services like Amazon show like two (English and the local language) out of the 30 something they have available. And I won't even go into the difference of subtitles and dubbing...


For language learning there are some scripts that allow you to hover words and show translations for them. I haven't used them myself with mpv, but I found that kind of tools to be invaluable on a browser when learning a language with a foreign script.


> actively omit subtitle languages that aren't "relevant" to your geolocation. I cannot respect a service like that.

This may also be due to legal issues / restrictions in the contract they had with that content's right holders or subtitles providers.


They probably don't want to license them globally, because the expected usage is low. But surely this could be taken into account in the contract / negotiation. Anyway I guess I'm just not in the target audience. But that's what MPV is great for, it allows you to tweak it for that 0.1% use-case.


I think it's also partially an issue with video + audio being paired by region.

AFAIK, the video you are being served is always based by the geolocation and what video was licensed for that. E.g. in a French version of a movie, text in the movie may have been localized into french inside the video. Additionaly there might be additional/missing scenes in the localized version to get the desired age ratings in that market.

The audio is then synced to that version of the video. That means that e.g. the French audio produced for the US video is not 1:1 the same audio as the French audio for the German video.

So that takes it beyond a licensing issue, and would mean additional effort to produce compatible audio tracks for content that they may only have streaming rights for temporarily. For content native to the streaming service they usually put that effort in.


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.


> 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.

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.


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.


> 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 ...


While great in general, vlc has many small seek/sync issues, and also seems to be in maintenance mode.


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.


> has many small seek/sync issues

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.


> audio/video get out of sync when seeking a lot

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.


Lots more folks use vlc I’d guess.

The media players we have on mobile don’t suffer from these issues, so they must be solvable.



> to be in maintenance mode.

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?


> 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.


> The general obsession with the idea that “software is never done, only abandoned” needs to end,

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.-


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.

A media player, though, has fewer challenges.


Media player projects are in an arms race with exploit devs, though, especially since Google keeps introducing and popularizing new media formats.

Speaking of which: which project tkaes security more seriously, vlc or mpv?


Hm, I've had (significant) issues with color representation playing back "HDR" media in mpv.


Then you must have not used "mpv --vo=gpu-next".

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 have used vo=gpu-next, actually. Still green/purple.

"I" shows: Primaries: bt.2020. Colormatrix: bt.2020-ncl. Levels: full. If that means anything.


"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.


Not something I have experience with so can’t speak to that.


was the material purple-green by chance?


Yeah. I did try playing around with some of the colorspace options you can find googling, but nothing seemed to work.


That's a Dolby Vision Profile 5 file. A format that's very very proprietary. The only PC apps that can play them at all are https://apps.microsoft.com/detail/9p9zh5fl1bfk?hl=en-ms&gl=M... and https://firecore.com/infuse


Nowadays mpv is able to decode it correctly, but it usually requires for that the command-line option "--vo=gpu-next".

A couple of years ago, mpv was unable to handle it.


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.


And you're sure it was a Profile 5, not 7/8 file?


Is there a way to use Infuse on PC? The only links I see are to the App Store


Macs are PC's, you can also make a hackintosh.

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


Infuse is great. I use it to play stuff (in basically any format) from the NAS through the Apple TV on a dumb TV.


Try this in your mpv.conf file

    no-config
    target-trc=pq
    target-prim=bt.2020
    vo=gpu-next
Wont be 100% accurate, but hopefully somewhat watchable

See also https://github.com/mpv-player/mpv/issues/10122


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.


Still very green/purple. It's fine, I was able to find a non-HDR version.


Then you probably have either a very old mpv or one that was compiled without including the "gpu-next" video output driver.

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.


mpv 0.36.0 from July 2023, nvidia 555.58.02 drivers from August 2024 (Fedora 39).


My output of "mpv --version":

  mpv 0.38.0 Copyright © 2000-2024 mpv/MPlayer/mplayer2 projects
  libplacebo version: v6.338.2
  FFmpeg version: 6.1.1 
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).


mpv is awesome. Shout-out, in no particular order, to:

- 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


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 :)

https://github.com/aksiksi/needle


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.


It seems to me that YouTube cripples their web player on purpose to "entice" you to download their app and upgrade to premium.


I have YouTube ReVanced, which is better than premium, which is still not as good as mpv.

Other services are strictly premium, paid affairs. Still not as good as mpv.


All it does is entice me to avoid that and go to mpv


MPV has versatile scripts. For example you can cut and crop a video you are watching[1].

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):

    n vf toggle normalize=smoothing=100
Or rotate a video:

    Ctrl+r no-osd cycle-values video-rotate "90" "180" "270" "0"
[1] <https://github.com/occivink/mpv-scripts>


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!

[1]: https://gist.github.com/madeindjs/f33225cf4d8fdc9f61e0fe3ebe...


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

Beats Star Wars over telnet :)


There are lua hooks for play/pause/stop which is great for dimming room lights when the video starts.


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.


Do you have an example?


Not OP but also wrote a similar thing for mpv.

https://github.com/ftk/mpv-confluence/tree/torrserver


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.

https://i.imgur.com/akmgzxX.png

https://github.com/hhirtz/mpv-retro-shaders


In my input.conf file I've created filter keyboard shortcuts:

  F1 af toggle "acompressor=ratio=4,loudnorm"
  F2 vf toggle "bwdif"
First one is an alright dynamic range compressor (makes the loud parts quieter and quieter parts loud). Second is a deinterlace at default settings. These are standard ffmpeg filters and mpv let's you turn these on in real time.


I amalgamated some audio filters to cycle through on a F1 press

- Loudness Normalization: "lavfi=[loudnorm=i=-14.0:lra=13.0:tp=-1.0]"

- Loudness Normalization + Mild Tinnitus Filter: "lavfi=[loudnorm=i=-14.0:lra=13.0:tp=-1.0,equalizer=f=6000:width_type=o:w=2:g=-20]"

- Mild Tinnitus Filter: "equalizer=f=6000:width_type=o:w=2:g=-20"

- Aggressive Tinnitus Filter: "equalizer=f=4000:width_type=q:w=1:g=-30,equalizer=f=6000:width_type=q:w=1:g=-30,equalizer=f=8000:width_type=q:w=1:g=-30"

- Bass Reduction: "bass=f=210:g=-17.7"

- Alternative Loudness Normalization: "loudnorm=linear=no"

- Dynamic Audio Normalization: "dynaudnorm=s=0"

- None: ""

F1 cycle-values af "lavfi=[loudnorm=i=-14.0:lra=13.0:tp=-1.0]" "lavfi=[loudnorm=i=-14.0:lra=13.0:tp=-1.0,equalizer=f=6000:width_type=o:w=2:g=-20]" "equalizer=f=6000:width_type=o:w=2:g=-20" "equalizer=f=4000:width_type=q:w=1:g=-30,equalizer=f=6000:width_type=q:w=1:g=-30,equalizer=f=8000:width_type=q:w=1:g=-30" "bass=f=210:g=-17.7" "loudnorm=linear=no" "dynaudnorm=s=0" ""

https://reddit.com/r/mpv/comments/xf8p9t/movie_volume_compre...

https://pastebin.pl/view/2f48e64c


Instead of using 2 compressors in tandem, it might be better to set the very good one to your preference:

  F1 af toggle "loudnorm=I=-14:LRA=1:tp=-1:linear=false:dual_mono=true"
The I=-14 is the target 'volume', which makes it as loud as YouTube and Spotify, setting it to -23 will be much quieter, but gives you more dynamic range. LRA=1 goes from 1-50, with 1 being the most compressing which is probably what you want in this case. TP=-1 sets the limiter to -1dB, which is plenty of clipping threshold because loudnorm calls the resampler for 192kHz before working in dynamic mode. Linear=false because we use dynamic mode here and cannot even use linear mode. Dual_mono=true makes -14 as loud for mono as stereo sources.

Since loudnorm adjusts volumes and sets limits for you, you can forego mpv's audio downmixing if your target is stereo and simply put all your channels together before bringing them to loudnorm:

  F1 af toggle "pan=stereo|c0=FC+LFE+FL+BL+SL|c1=FC+LFE+FR+BR+SR,loudnorm=I=-14:LRA=1:tp=-1:linear=false:dual_mono=true"


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.


It feels like the "Vim" of video players.-


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 ?


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.

MPlayer 20 years ago: 17 ms.


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.


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


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).


I don't think frames coming at most 8.3ms early/late are perceptible, much less "jerky."


It is perceptible and it is jerky.


I concur, it's definitely noticeable


The CPU computation time is definitely not a problem, the fact that 60/24 (or sometimes 23.97) is not an integer is


120Hz screens are good enough here that I'd call them a silver bullet.


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.


48hz support seems pretty common.


Is it ? I had dozens of monitors and never saw it


Just set it, it works.


doesn't work on the three monitors I tried, I get every time:

    $ xrandr -s 1280x1024 -r 48 
    Rate 48.00 Hz not available for this size


MPV is great for powerusers, for the vast majority of people just use VLC.

I used both over the year and there are still things that are really annoying in mpv:

- you can't render on a Chromecast

- opening a file that does not work does nothing, you don't know what's happening, is the file corrupted, is the codec not supported ??

- the no ui idea is nice for opening a single file, but then you go to the rabbithole of millions of settings / config to do anything more complicated, playlists? ( why can't I drag and drop on the window )

- it's hard to compile, so it's up to you to find up to date version on your distro


>- opening a file that does not work does nothing, you don't know what's happening, is the file corrupted, is the codec not supported ??

You could open the console to see errors. https://mpv.io/manual/master/#console

>- the no ui idea is nice for opening a single file, but then you go to the rabbithole of millions of settings / config to do anything more complicated, playlists? ( why can't I drag and drop on the window )

I cannot relate to that. "ad-hoc" playlists or even adding more files while some are already playing works fine for me on macOS. There's a chance the built-in UI differs between operating systems, not sure.

>- it's hard to compile, so it's up to you to find up to date version on your distro

I consider that hardly the fault of the mpv project. Other than that, there are usually third-party providers for mpv binaries.


Never had to deal with your third point, I just open it via the CLI and it's pretty verbose regarding issues it encounters.


If your distro has outdated packages, that's a problem with your distro.

You can always just open files with a CLI if you want to see the error messages.

What do you mean can't drag and drop on a window? That's literally how you add subtitles or open a file if you opened mpv from the shortcut, rather than by opening a file.


None of the distro keeps package up to date with mpv. Only rolling one are probably updated.

Adding a file does not enqueued them, it just open it and play it right away.


Hold shift while dropping the file to enqueue it. At least on macOS that works.


If anyone is looking for the mpv core with a GUI on macOS, take a look at IINA https://github.com/iina/iina


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.


Have you filled a bug report about this?


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.


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.


infuse will also do good job, but it's using apple engine instead of ffmpeg, and it's paid for the good stuff https://apps.apple.com/us/app/infuse-video-player/id11362209...


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.

https://developer.apple.com/documentation/technotes/tn3145-h...


mpv is always faster than IINA, especially with 4K playback on older MacOS. mpv is near perfect


It's excellent with companion tools as well. For example...

Streamlink, for watching live streams without a web browser:

https://streamlink.github.io/

Syncplay, for remote movie parties:

https://syncplay.pl/about/syncplay/


Mac users can get a very nice front end to mpv with https://iina.io

Bonus trivia: Plex Media Player uses mpv as the video player


IINA has various issues that mpv does not have, in particular with color space conversions (see https://news.ycombinator.com/item?id=41278331 for a few more details)


That is... not a glowing endorsement. I've had more bugs and player failures from Plex than any other media software I've ever used.


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?

https://github.com/ambroisemaupate/plex-profiles/blob/master...


plex uses terribly old build of mpv with questionable config


MPV is slowly becoming the major embedable media player on the PC side. It's in a bunch of stuff and that's great.


Adding onto this is Outplayer, which similarly uses MPV for its backend, for iOS & iPadOS.


One of the nice things about MPV is that you can apply FFMpeg filters at playback, allowing you to use a wide range of transformations on a source video without having to re-render it for each variation.

We're using inexpensive industrial mini-PCs, Alpine Linux, and MPV as a custom digital signage solution at my company, and centrally managing them via Ansible.


What does an industrial minipc offer that an RPI doesn't in this case? :)


It's x86; it works better for hardware accelerated video playback via VAAPI due to FOSS Intel drivers; because it's fully integrated out of the box, its total cost is a bit cheaper than an RPi, and as a single unit with no assembly, it's quite a bit faster to deploy.

I'm using these: https://www.amazon.com/MeLE-Fanless-Computer-Ethernet-PCG02/.... Works great with Linux, and has a very customizable BIOS.


Neat. How to get without Windows?


Haven't seen it available without preinstalled Windows, but even with that, the price is good, and it's easy enough to wipe it and install Linux.


Thanks. Shame to see MS get even a penny of my money however.


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.


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

https://mpv.io/manual/master/#options-hr-seek


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.


By default, mpv has vertical-scroll bound to volume and horizontal-scroll bound to scrubbing.


Yes, though you do have to enable that. For me I tend to have it buffer the video. That way I can even seek backwards of web streams.


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.


I love their section on how to embed mpv in other apps [1]. Too bad there's not an XEmbed equivalent for Wayland [2].

[1] https://github.com/mpv-player/mpv-examples/blob/master/libmp...

[2] https://github.com/mpv-player/mpv/issues/9654


Cannot recommend --video-sync=display-resample enough. The one reason I use mpv on every OS over every other media player


Can you explain what it does?


> Resample audio to match the video. This mode will also try to adjust audio speed to compensate for other drift. (This means it will play the audio at a different speed every once in a while to reduce the A/V difference.)

I'm not sure what's the benefit of that is though.


It's makes so the frame pacing fits the display refresh rate, making viewing a lot more pleasant and smoother. Eg.: Your Screen is 60hz, but the video is 59.97hz, then there will be a dropped frame. `--video-sync=display-resample` speeds the video up by a tiny percentage to make every display refresh match a new video frame. The correction factor is recalculated every frame and can be viewed by pressing I. This makes way more difference that one would imagine and makes 60hz gameplay look hyper smooth, even though not much changed. Frame pacing really matters. Applies to very closely matching framerates or multiples of (eg. 60hz screen with 29.97hz video), not to bigger differences like 50hz vs 60hz.

Drawback: MPV will be forced to run at screen V-Sync, draining battery faster. If your screen is 60hz, but the video is 29.97hz, MPV will re-draw the screen at 60hz, instead of just 29.97hz, doubling GPU load.


60 Hz display is a bad case to begin with. How visible it is let's say on 180 Hz one?

Though ideally, may be display should use adaptive sync to the player rather than the player trying to hack around the video to display?


It's makes so the frame pacing fits the display refresh rate, making viewing a lot more pleasant and smoother. Eg.: Your Screen is 60hz, but the video is 59.97hz, then there will be a dropped frame. `--video-sync=display-resample` speeds the video up by a tiny percentage to make every display refresh match a new video frame. The correction factor is recalculated every frame and can be viewed by pressing I. This makes way more difference that one would imagine and makes 60hz gameplay look hyper smooth, even though not much changed. Frame pacing really matters. Applies to very closely matching framerates or multiples of (eg. 60hz screen with 29.97hz video), not to bigger differences like 50hz vs 60hz.

Drawback: MPV will be forced to run at screen V-Sync, draining battery faster. If your screen is 60hz, but the video is 29.97hz, MPV will re-draw the screen at 60hz, instead of just 29.97hz, doubling GPU load.


Doesn't it already keep the audio in sync by default? What's the difference with this option?


It's makes so the frame pacing fits the display refresh rate, making viewing a lot more pleasant and smoother. Eg.: Your Screen is 60hz, but the video is 59.97hz, then there will be a dropped frame. `--video-sync=display-resample` speeds the video up by a tiny percentage to make every display refresh match a new video frame. The correction factor is recalculated every frame and can be viewed by pressing I. This makes way more difference that one would imagine and makes 60hz gameplay look hyper smooth, even though not much changed. Frame pacing really matters. Applies to very closely matching framerates or multiples of (eg. 60hz screen with 29.97hz video), not to bigger differences like 50hz vs 60hz.

Drawback: MPV will be forced to run at screen V-Sync, draining battery faster. If your screen is 60hz, but the video is 29.97hz, MPV will re-draw the screen at 60hz, instead of just 29.97hz, doubling GPU load.


I have been using mpv on Linux for like 10 years, it's simply amazing. No complaint, it just works.

Highly recommended.


One cool thing about mpv is that it can transcode audio encoded in different surround sound formats (AAC, FLAC, Atmos, etc.) into regular Dolby Digital for use with old pre HDMI AVRs using SPDIF. AFAIK it's the only player that can do this natively without any additional work on the OS level.

I'll just add this here but if you want this kind of transcoding for the entire system rather than just mpv you can use dcaenc with its virtual 6 channel input encoding everything to DTS. I send the encoded audio to the AVR using a cheap TI PCM27XX sound card with optical output.


libmpv is also amazing. It's a simple C API that allows you to render each frame into an OpenGL framebuffer or pixel array, using a fully hardware-accelerated path for the former.


What I like most about mpv is how you can control it through its socket. Often times I will play a movie or tv show on a separate monitor, so being able to pause or rewind or change volume without switching workspaces is important. I have in my i3 config, keybindings so I can easily control mpv with my keyboard: https://github.com/ediw8311xht/dotfiles/blob/6a765910ab5ac17...

Additionally, mpv has a powerful script system. One of my favorite scripts is fast foward through intro, which is crucial for watching a tv show. https://github.com/rui-ddc/skip-intro. Another nice script is https://github.com/familyfriendlymikey/mpv-cut, which enables creating clips in mpv. There are a ton of other useful scripts, and its not difficult to create a custom script yourself using lua.

Mpv automatically resuming is also nice for watching tv shows or movies. Only problem is that if you shutdown mpv through killing the window then automatically resuming from history gets messed up.


Is this worth a look when you are pretty happy with VLC already?


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).


Yes, it is. I don't understand the cult of VLC to be honest. There are better media players, at least on Windows.


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.


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.


We love VLC because it plays anything, everytime.

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.


VLC doesn't play everything though. mpv plays stuff that VLC can't play. I never have to worry about codecs or installing anything.


Sure. My point is that VLC gets a special place. It "just works" for a decade before MPV, still does and across 3+ platforms!

MPV is great too! I think it's important to also recognize how rad VLC was and continues to be.


I do use MPC-HC on Windows, but it's no longer under development :'( IIRC it can't do AV1.


There is a fork that's still under development [1], or you can use mpc-be [2].

[1] https://github.com/clsid2/mpc-hc/ [2] https://github.com/Aleksoid1978/MPC-BE


mpv has less UI affordances than VLC, but it’s very full-featured and configurable. It’s kind of like the ffmpeg to VLC’s Handbrake.

Of course, if you really want to be a purist you could use ffplay.


I have a 4k SDR display and 4k HDR content on VLC looks washed out.

Mpv does not have that issue and converts 4k HDR to SDR in real-time and shows a colorful image.


In my opinion, yes. It's smaller, simpler, snappier, yet has everything and then some under the hood if one really needs this or that function.


The famous VLC seeking corruption still happens to me. Happened on an i3 NUC HTPC recently. So using MPC-HC or MPV now depending.


Love the message when attempting to open a multi-volume rar video.

[libarchive] This appears to be a multi-volume archive.

[libarchive] Support is not very good due to libarchive limitations.

[libarchive] There are known cases of libarchive crashing mpv on these.

[libarchive] This is also an excessively inefficient and stupid way to distribute

[libarchive] media files. People creating them should rethink this.


mpv is the most active fork/evolution of the historical "mplayer" player of yesteryear. I've been using this program in one form or another for probably 20 years now. It's great; highly recommend.


This is S tier software. I remember using this on a laptop with 2gb RAM years ago. The combo of mpv and youtube-dl could deal with large number of sites (not just youtube), when even the browser struggled.


I think youtube-dl is no longer under development. Any suggestions for an alternative?


youtube-dl is still under development (last commit at the time of writing was 2 weeks ago), but there are forks with more features, such as yt-dlp.[1]

[1] https://github.com/yt-dlp/yt-dlp


yt-dlp[1] has now taken on that mantle. I think mpv nowadays just recognises yt-dlp as the de facto alternative, but if yours doesn't then you can just put this in your mpv.conf:

    script-opts=ytdl_hook-ytdl_path=yt-dlp
[1] https://github.com/yt-dlp/yt-dlp


You can use mpv on the framebuffer-terminal.

Pass the option —vo=drm and it works flawlessly with free drivers for AMD, Intel or Nvidia.


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.


The MPV of images for linux is IMV: https://sr.ht/~exec64/imv/


with a couple of lines in ~/.config/mpv/mpv.conf, mpv is the mpv of image viewers:

image-display-duration=inf autofit-larger=100%x100%


On macOS there is IINA which uses mpv under the hood but with a more native GUI.


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.


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.


It does have a drag-and-drop window if you start it with `mpv --profile=pseudo-gui` (I think the same as its .desktop file)


> It doesn't really have things such as "File → Open" like VLC has.

Huh, it does for me (in the menu bar) on macOS! I guess that's platform-specific then?


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.


You don't need to use the command line.

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.


There are graphical frontends like Celluloid.

https://celluloid-player.github.io/


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]

[1]: https://github.com/mpv-player/mpv/blob/master/etc/mpv.deskto...


you can just drag-n-drop a file on top of the window and it'll promptly get played


Love the scripting system. I spend 100% my time to write scripts for mpv and vim and 0% for actual work.


Mpv is great! And also the only player I found to be externally controlable, e.g. through a hardware jog/shuttle or an Arduino. This might be outdated (from 2018), but for reference (me talking to myself ;): https://softwarerecs.stackexchange.com/questions/53208/video...


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.


This kind of project always lacks better UI/UX. I wonder if there is a way to bring more UI/UX people to Open-Source projects.


I switched to MPV years ago - for some reason VLC started to stutter when opening a file, which is quite annoying. It does not matter whether it is local ol remote file, format does not matter - every open and every seek will trigger this few-second long stutter.

MPV does not do this, so over the years I began to use it as my daily driver.


My default player is VLC, because it's a great generalist for video, audio and video inputs, but I appreciate mpv very much too. Especially useful on CPU limited devices, I get more performance out of it than any other player.


Libmpv also has a much better api than libvlc.


Mplayer, or MPV was my go-to program, next to VLC player, when I still used Windows and had loose mp4 files to play. Nowadays I’m just streaming on my Mac.

Those good old days. [/ dream]


Technically superior with a bit of a learning curve, but really worth it. If they surfaced more of their functionality better, it would gain a lot of users.


If using KDE, I recommend Haruna as a frontend. Really easy to use!


I use it as a backend for smplayer: https://www.smplayer.info/en/mpv


I love mpv. But when I pause and resume the video, the first few seconds are jittery. I've not encountered that on other players. Does anyone know why this is?


For me I have that with VLC and MPV is the stable one (in Archlinux). In my experience, trying different sound output device or module settings sometimes fixes such issues (and usually pulseaudio is the laggy one)


Both sound and video are stuttering for me, would that still be caused by audio issues?


These two do seem connected, at least in my case, maybe the video is waiting for the audio codec. Of course your issue could be something entirely different than what I'm typically encountering!

I have like 3 things trying to be audio device on my linux (of which the graphics card is the most unwanted one and sometimes it randomly manages to take over despite me not changing any settings) and the list of audio modules that show up is simply enormous (pulseaudio, pipewire, alsa, ...), some of those make VLC stutter, others don't. It's a mess but at least pipewire works better than puseaudio in my case...


On my Macbook Air, mpv adds an orange tint to videos so I hate when I have to use it because it's the only player that can play a file I downloaded.


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.


mpv is one of my favorite pieces of software, incredibly useful and high quality, enjoyable to use. Right up there with (neo)vim, openssh, tmux.


No DVD or BD menu support as I've tried now


Apparently there is partial support for it: https://github.com/mpv-player/mpv/issues/14370#issuecomment-...

This should let you play a VIDEO_TS folder, ISO, or an actual disc… with the caveat that you need to figure out the coordinates of the menu yourself by using an external tool.


chiming in to say VLC is the best audio clip player I've found. every time in past I surveyed the space all other options I tried had one or more showstoppers like too buggy or not the right API. VLC (and driving it via either Golang or CLi) has been reliable, decently documented and ultra configurable.


The best media player available on linux. The worst GUI (none) out of the box. Bearable after tinkering a bit with configs.


> The worst GUI (none) out of the box.

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.



It does have a GUI in the form of video overlays. For me it's perfect. By default it just shows the video which is both necessary and sufficient.


> The best media player available on linux

Strong 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.-


> Strong clam, this ...

What's better?


mplayer


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.


mplayer has DVD menu support, mpv doesn't. I use Kodi if I need to navigate DVD menus these days, which is rare but it happens...


I used played for 20+ years but moved to mpv recently as I ran into a couple of things player won’t work with.

Struggling to see the benefit of mplayer over mpv today.


mpv is an active mplayer fork.


i used to be able to go frame by frame with quicktime.. is there any modern video player that can actually do this?


This is a build in feature that mplayer had and mpv has aswell

. and , on keyboard go frame-to-frame, you can also up and downspeed with [ and ]


mpv does it! Period key (.) for next frame, comma (,) for previous. Super handy.


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...).


Offtopic: vlc too


only next frame


The only player that has proper HDR playback support and proper HDR to SDR conversion plus GPU accel.


Licensed on a GNU General Public License (GPLv2+) except for the /video/out files which appear to be either unidentifiable or proprietary code rewritten from nVidia, and another unnamed company's repository.


I started using it after the latest Ubuntu version broke VLC, and am quite pleased


Does anyone else have a problem with it on Mac when trying to open videos using the 'Open With' dialog in Finder? I see it start for a second, and then it just quits. It works properly from the command line


mpv is a key part of my home theatre automation I wrote in PHP.

It runs on a Pi 4. PHP assembles playlists with a Dolby ad, a vintage dancing hot dog ad, trailers, and the feature. It runs mpv through proc_open.

It monitors the progress and controls mpv through a socket to know when to dim or raise the lights, open or close the curtain, etc.

https://www.youtube.com/watch?v=Q7YEVGWJjvI


> Dolby ad, a vintage dancing hot dog ad, trailers, and the feature

This is great.-

Particularly the vintage dancing hot dog ad, mind you :)


I added a hotkeys for change subtitles scale...well worth it


Does anyone here know more features that MPV offers that VLC and MPC don't, considering they are all free and open-source?


Like anothers comments said, mpv has some awesome native hw decoding and you can play frame by frame, previous and next, vlc you can only do next [1] (awesome thread btw). :) And mpc/mpc-hc is discontinued [2].

[1] https://news.ycombinator.com/item?id=41278203 [2] https://news.ycombinator.com/item?id=41277818


mpc-hc is not discontinued.

https://github.com/clsid2/mpc-hc

Plus there is also mpc-be which is actively developed and pretty much the same.

https://github.com/Aleksoid1978/MPC-BE


For a web media platform checkout https://zymo.tv


I absolutely love mpv. And if you have a Mac check out IINA. It’s just a relatively thin GUI over the mpv core.


Awesome, any open-source cross-platform media player is always welcome in my setup!


We have free, open-source, cross-platform media player at home [vlc].


Love the use of one of the best Kubrick scenes IMO on the main site


I am using it for listening to the online radio in terminal.


MPV can play stuff VLC can’t, and it’s HDR support is superior


What are the best upscalers for MPV these days?


I default on ewa_lanczossharp; it does pretty well at upscaling normal SD video to modern resolutions.

I also often use oversample, for video game footage and whatnot where I want all the pixels to be not blurry.


profile=high-quality


another good one in development is http://zymo.tv


Using for last couple of years, its best.


I use it to inspect video frames by frames, particularly being able to go back one frame. VLC doesn't support it, this thread about the feature is hilarious https://forum.videolan.org/viewtopic.php?t=120627


Wow those answers are indeed funny. I agree that as an OSS dev/maintainer, it's easy to fall on the vice of over-generalization and crusade for the perfect solution, and it feels that's exactly what happened there.

> this feature is algorithmically impossible

> You're just looking at one specific video, not the general problem.

> is not generally possible.

As a fellow multimedia dev, man, who cares? Sometimes we forget that software ought to be useful, not hypothetical ideals of truth. Just implement the feature for those codecs that support it and which probably are in the 98% percentile of what users actually use, regardless of the damned "general case".

Or accept and announce shamelessly that you don't have either the knowledge or the development resources to tackle such a complex feature. But excuses about not being possible for absolutely every possible codec in a completely generic way is just denying that the world is just a chaotic and dirty place where things are not ideal nor perfect. Just give your users a real-world solution (or rejection).


Disagree!

VLC is what it is today because the authors understood video standards enough to make the _right_ abstractions that could generalize to ~every video format ever. That is no easy task. Video container standards are utterly perverse, and seem to delight in stomping over even the most innocent intuitions about what you would expect to find in a stream of bits that purports to contain "video". They often refuse to make even basic promises, like "the first frame's timestamp starts at 0" or "every parcel of data has a timestamp". Seemingly reasonable ideas that a neophyte might propose, like "suppose we store the video's framerate-" must be immediately interrupted with "you FOOL, there IS no framerate, nothing can be certain, this video might not even have frames, it might in fact be an interactive gift basket experience merely PRETENDING to be an mp4-". That's just the nature of the beast.

A playback architecture that can wrangle all of that cruelty into a consistent experience was hard won. Of course they're not eager to throw new features into the mix that will pollute that mental model, and suddenly introduce thousands of codec-vs-player-feature checks that were heretofore ruled out in principle. At a certain point, the architecture is sacred, and it's the only thing making VLC maintainable. If a feature doesn't work for everything, it doesn't work.


You speak as if VLC is the pinnacle of video player technology. I know it is an open source darling, but it's been a buggy, overengineered mess since forever, which is why many use alternatives as mpv, IINA when I used macOS, SMplayer, etc.

On fact, with all due respect, I never understood why VLC was so widely praised. It is the only player to stutter for me on Windows, to get lost in its settings page, to have a terrible playlist implementation that's forced upon you, doesn't handle corrupted media as well as others, etc. mpv on the other hand does one thing and does it very well.

I'll skip ranting about VLC for Android TV this time


> On fact, with all due respect, I never understood why VLC was so widely praised.

It's praised because it "plays everything."

It developed this reputation in an era when even average people were installing numerous DirectShow "codec packs" (often of dubious pedigree) in an often futile effort to "play that thing I just downloaded" from the P2P file sharing network du jour.

For a number of reasons, installing a bunch of these codec packs would often leave video playback broken globally[1]. Since VLC is cross-platform, it does not use DirectShow, and would "fix" a system that had been "broken" by other software.

[1]: most of these issues could be fixed with the GraphEdit utility, which offered a simple but powerful UI for configuring and testing every codec in the system. GraphEdit should have been included with Windows, and be something you could invoke from within Control Panel.


Literally every FFMPEG-based player will play whatever you throw at it. While it may be an advantage over basic bith OS-provided players it hasn't been a unique selling point for VLC for a long long time.


VLC even plays incomplete files which i've found useful every now and again.


> On fact, with all due respect, I never understood why VLC was so widely praised.

For me the alternatives back when i first wanted a video player that could play various file formats were Media Player Classic (which worked only on Windows and relied on external codecs that sometimes didn't fully work), mplayer (which had annoying arcane commandline switches and weird shortcut keys), Totem (which used gstreamer which 90% of the time either didn't had the codecs i wanted or they were very buggy). More recently the only alternative seems to be mpv (which seems to be a mplayer fork that persists with the arcane switches and apparent hate of anything resembling a discoverable GUI).

VLC on the other hand is available on anything that has a display (or at least anything that has a display and i'd want to play videos on it - that is currently Linux and Android and sometimes Windows) and has a GUI that while might be a bit on the overloadedly bloated side, at least it shows everything you may (and often you may not) want to configure, with actual menus, categories, tooltips, etc. And when it comes to the most common aspect, playback of videos, it shows a simple and to the point UI with the play, seek, volume, etc buttons that you'd need 99% of the time (that admittedly most other players do too, except they don't do the 99% rest of the GUI that VLC does).

So, basically VLC is my preferred video player largely because 20 years ago i didn't had to read a tutorial on how to select the subtitle language (or something along these lines) and was able to play pretty much any video i threw at it without any extra fuss.


VLC is *amazing* at its design purpose: being a rock solid video player. The GUI, the UX, and other things can be criticized, but I dare you to find another video player that will play just about *anything*, and without having to install external codec separately with weird licence.

You can throw at it a broken mp4 file, a https url with basic auth, a weirdly encoded video, a DVD full of scratches, etc, chances are VLC will manage to play it (at least what is playable). There is just no other video player in the world that achieve that.

A lot of other video player might beat it at other features, but just straight video playing, VLC is just the best.


> without having to install external codec separately with weird licence.

What's up with this artificial limitation? I'd take frame back function over not having to install some codec pack once any time

And 99.99% of the time you don't play "everything, with scratches", so UX issues are much more consequential than that


It's not artificial at all. It's a real limitation that was so outrageously annoying for the reasons mentioned above that VLC was able to "win" by tackling this one issue alone.

The success of vlc is all the proof you need. As you say, why else would it be so popular?


> What's up with this artificial limitation? I'd take frame back function over not having to install some codec pack once any time

Then VLC is not for you - and there's nothing wrong with it or you - you just happen to have differing priorities. Back when the Internet was more p2p, the ability to play uncommon media formats and containers was crucial. Even today, VLC offers a lot of value to anyone who has to playback media whose encoding they have no control over.

VLC has other useful features as well (like streaming while playing back, allowing for multicomputer watch parties on the same network)


> VLC is amazing at its design purpose: being a rock solid video player. The GUI, the UX, and other things can be criticized, but I dare you to find another video player that will play just about anything, and without having to install external codec separately with weird licence.

MPV? You know, the subject of this post we are commenting on?

Or literally any FFMPEG-based player.


MPV use some library from FFMpeg, it is not based on FFMpeg. And yes, VLC still beat MPV and MPLayer, especially at accuracy or reading partially broken files. Although the situation has changed a lot in the last 10 or so years, and they improved a lot. But don't talk to me about UX when the two other option are MPV & Mplayer...


> I never understood why VLC was so widely praised.

Because it's the one you can reasonably suggest to all your utterly nontechnical friends and relatives to get them to stop downloading random sketchy exe's from the internet to install codecs.

mpv, and mplayer before it, has always been better for me and I find VLC to be pretty shoddy. But when it comes to people like my mom, I don't hesitate to sing praise for VLC. In that context, VLC is the greatest thing since sliced bread and I don't muddy the waters by even mentioning mpv.


> Because it's the one you can reasonably suggest to all your utterly nontechnical friends and relatives

I concurr.-

PS. On a related tangent the amount of unpaid "support" tech knowledgeable individuals are doing for (particularly) FAANG is enormous.-


> PS. On a related tangent the amount of unpaid "support" tech knowledgeable individuals are doing for (particularly) FAANG is enormous.-

Which is exactly the same for every profession. If you have a plumber friend and have issues with plumbing, who you call first, a random contractor or your friend? Replace "plumber/plumbing" with any profession and the answer is usually the same, you call your friend first, at least to get some more understanding before reaching out to a contractor.


The difference is that if your plumber friend helps you out with your toilet, Big Plumbing Inc does not get your business.

If however your tech friends help you with Windows/Android/Apple issues, MS/Google/etc. still get paid and save up on support costs.

These two situations aren't even remotely comparable.


> Windows/Android/Apple issues, MS/Google/etc. still get paid and save up on support costs.

This was kind of like what I was getting at: Kind of wondering what the total savings for FAANG on support costs would amount to, factoring in all this "offloaded" support that they hand off to their own customers (or, affiliated tech-savvy individuals).-


Sure. I understand, and agree.-

I was just wondering about what the sum total of the (otherwise) "billable" hours might amount to, were they to be accounted for as a cost of business for FAANG.-


Well stated.

VLC has a few nits, e.g. common settings and useful functionality buried somewhere. Like mouse gestures for instance, you have to go out of your way to enable them and cannot customize the mapping.

mpv on the other hand, I have multiple config profiles different viewing purposes. It introduced me to ffmpeg, which as someone who became a dev later in life, made me more comfortable with using cli tools and diving in to documentation. Being able to tinker made me feel like hackerman.gif and is one of the things that things that helped my career transition.

But yeah, not for my mom or wife, VLC is best for them.


I always saw VLC as subpar. A typical case of software that's just trying to copy what the pioneers do. As we all know, mediocrity it not antithetical to popularity, and VLC has become very popular indeed.

However, it never pushed the envelope in terms of codecs, features and performance and as a result was never at the forefront of opensource video playing: mplayer got the ball rolling with rapid breakthroughs including hardware acceleration (e.g. /dev/mga_vid) before standards such as xvideo even existed and that spirit of technical excellence has been passed on to Mpv which remains at the pinnacle.


> I always saw VLC as subpar. A typical case of software that's just trying to copy what the pioneers do.

What pioneer is/was VLC trying to copy? Media Player Classic? Windows Media Player? Before VLC, the ecosystem of video players was a mess, and if you came across a format you didn't already had installed codecs for, chances were you couldn't play that file. But VLC always could play it, no matter what file, as long as it said it was a video file.

> However, it never pushed the envelope in terms of codecs

VLC literally took over the world because you could install VLC and VLC only, and stop having to care about codecs at all, at the time at least. Maybe today it's different, because the ideas of VLC already spread, but at the time, things were different.

I personally use mpv most of the times today, but when I got started with computers and didn't understand as much as I do now, installing codecs to be able to view some video I just downloaded was a pretty confusing task. CCCP (Combined Community Codec Pack) for MPC helped a lot, but to even get to that point took some time.


Wasn't CCCP bundled with malware or something back in the day?


Not that I'm aware of, nor can I find any sources talking about it. Maybe you're confusing it with DivX that did something like that (https://news.ycombinator.com/item?id=6409888)? Both were popular during the same timeframe, so not impossible you're confusing the two.


Hmm... possibly. Funny how my memory works sometimes. ;)


I see VLC as the swiss army knife that can play anything you throw at it, no matter how weird. I see mpv as a more streamlined, less abstract implementation that supports many fewer options, but can contain special-case code paths for hardware acceleration, for example. Hardware-accelerated playback on my Raspberry Pi 3 works out of the box with mpv but requires some special trick or doesn't work at all in vlc. I assume mpv's design allows it to contain a special-case code path when you happen to be playing something compatible with a Raspberry Pi's GPU on a Raspberry Pi.


What files can your VLC play that MPV can't? Both get almost all of their codec support from FFMPEG.


AFAIK, VLC was the one of the first players that was able to read all sorts of formats... back in the day, you were lucky if you could play mp2 and mp4, let alone mkv/avi/etc...

Sadly VLC devs have let their software deteriorate to the point where VAAPI hw decoding doesn't even work anymore, they think it's ffmpeg's fault... except ffmpeg supports it just fine, VLC is just too lazy to update their ffmpeg calls to use the api correctly.


> many use alternatives as mpv, IINA when I used macOS, SMplayer, etc.

Those are all basically the same alternative in terms of backend. They're all based on ffmpeg and of mplayer lineage. I don't think there are many (any??k others comparable to VLC in terms of covering so many formats that are independent of FFMPEG. Maybe GStreamer?


The choice not to implement it for architectural reasons is entirely up to the devs, is likely justified, and in most cases users acting entitled to support and feature additions from OSS developers who are volunteering their time is something I side against. But the devs also should be able to talk to people who aren't marinated in that same viewpoint, for their own sake if nothing else. The leap from "there exist cases where implementing this feature in a performant manner wouldn't be feasible" to "we shouldn't implement this feature even for the many cases that would support it" isn't going to be obvious to everyone.

VLC's poor performance in seeking backwards in general, not just by frame, is a big part of why it's no longer my media player of choice. Which is fine! As an OSS project there's no real reason to care about the number of users as long as enough people are involved to sustain the project, and making the developer experience pleasant is more important than making the user experience pleasant on that front. It just means it's not as good a tool for some users as others, like mpv.


> A playback architecture that can wrangle all of that cruelty into a consistent experience was hard won.

No, it hasn't. The only reason I use mpv instead of VLC is because of the frame step feature. Everyone else has proven that it is possible and practical to do.

Never let the perfect be the enemy of the good. If people don't use your product, it doesn't matter how right and pure of vision you are.


> The only reason I use mpv instead of VLC is because of the frame step feature.

so from VLC's point of view your problem is solved - you have a good, open source video player that lets you step back a frame and you are happy to use it. they don't need to be all things to all people.


> No, it hasn't. The only reason I use mpv instead of VLC is because of the frame step feature

You realise your requirement is important for less than 0.01% of users? For every requirement you have to balance future maintainability and the impact it has on the code base against potential revenue


I assure you the figure is much, much greater than 0.01%.

Even outside of specialist uses (and not just in the field of video, either), most people like being able to pause a video on a specific frame to be able to study it more closely. Often that requires (or at least the task is made much simpler by) being able to step forwards and back frame-by-frame.


> most people like being able to pause a video on a specific frame to be able to study it more closely

I think the vast majority of people just want to be able to watch the film they downloaded.


Not sure VLC is balancing anything against "potential revenue"...


The developers had a philosophy and they stuck to it. It's an open source project, not a profitable service.


I'll admit I can't weigh on whether there's a plausible strategy for implementing backwards frame step in VLC without violating any of their sacred invariants. Maybe the existence of other players with that feature implies that the VLC devs just aren't seeing it. But without that knowledge, I'm left to trust the developer's presumably deep knowledge of their own architecture when they say that it just doesn't 'fit'. It seems more likely that the other players can do it because they're architected differently, or they make a different (smaller) set of guarantees about which formats they will play back in which scenarios.

>Never let the perfect be the enemy of the good. If people don't use your product, it doesn't matter how right and pure of vision you are.

This is great advice... for a business. VLC isn't a business, it's a useful thing that exists. It gives people fulfillment to donate their time to keep it useful and relevant. That fulfillment is going to be directly proportional to how elegant the design is and how much leverage they have, i.e. small amount of good code provides wide amount of functionality for many happy users. The more that maintenance of VLC degrades towards "brutal hand-crafted specialization of huge switch cases", the less well-maintained it's going to be. This is not an excuse, it's a statement about human nature, something akin to economics.

It's possible that mpv picked a better abstraction and they can provide a strictly better application for the same or less software maintenance cost. But I tend to suspect that the differences arise from levels of support, not better design. That's just a spider sense though.


    > VLC isn't a business
On the surface this is true, but my guess: The core team work as consultants. See "Consulting services" -> https://www.videolan.org/videolan/partners.html

I assume this means you can hire lead devs to fix bugs and add features.


VLC doesn't have perfect compatibility. I think it worked correctly on random video files less frequently than mpv the last time I tried it. And mpv can actually step forward and back frame by frame.


I found MPV because VLC was unreliable. Seeking was especially crazy sometimes, and not that I couldn’t seek to the exact moment, but I couldn’t seek at all. Even displaying was broken sometimes regardless of file types. I had none of these issues with MPV for the same files.


VLC is sometimes so unreliable for me, especially when seeking or frame-stepping, that it stops responding to playback commands entirely (although it pretends to still work) and I have to kill the zombie process before I can even re-open the file and try again.


So can mplayer and did that way before mpv could.


mplayer was forked into mplayer2, which in turn was forked into mpv

Though AFAIK, most of the rendering code behind mpv has been entirely rewritten.


What was the cause of the fork? An unresolvable internal debate? I am curious to know more about the history.


I'll refer you to the MPV FAQ for historical context.

https://github.com/mpv-player/mpv/wiki/FAQ#how-is-mpv-relate...

There were lots of drama in the media player scene. Even "wm4" the original maintainer, who forked mplayer2 into mpv, is no longer with the project: he deleted his Github account and disappeared.


Yet the bumblebee flies. mpv does, in fact, have a working "go back one frame" button, so VLC protestations that such a thing is infeasible look silly now. Great example of "red pen" versus "blue pen" thinking: we should spend less time decrying things as wrong or impossible and more time looking for approaches that we might have overlooked. Less "no", more "yes, if".


> VLC is what it is today because the authors understood video standards enough to make the _right_ abstractions that could generalize to ~every video format ever.

VLC used to be the dominant video player for this reason, but then everything has crystallized around h.264 (and h.265) which made the breadth of codec support not as important anymore, making VLC slowly losing relevance because they aren't focused on user experience enough.


> h.264 (and h.265) which made the breadth of codec support not as important anymore

You say that but just yesterday i used VLC to play some old videos i had which AFAICT were in RealVideo format or something like that.

And i transcode everything i want to watch in my Android tablet (where i also use VLC) to mpeg2 because the tablet is ancient (10+ years old) and can't handle anything newer, so i am glad that VLC a) still works on the ancient Android OS it has and b) still supports an old outdated but CPU light video format :-P.


I'm not saying it's useless. But now it's situational, which wasn't the case in the 2000s.


    > slowly losing relevance
I love this type of editorializing language. Ok, if VLC is "slowly losing relevance" (a claim for which you provide no evidence), what player is "slowly gaining relevance"?


Everything that is provided by default by the OS.

Installing VLC used to be one of the first things people did on a new computer, including many non tech-savy people, along with a web browser that isn't IE/Edge.

Now the fraction who bother installing it is much smaller. The default video player is good enough for most usage (overall usage has declined anyway because of streaming).


One could argue video players in general just lose relevance in an age of streaming ... And everything has definitely not crystallized around h.264. plenty of sources will give you widely different things, for instance digital cameras, webcam, even screen recorders. Basically most of the input is in completely different formats. If you were thinking about pirated movies then it is of course more the case, but I wouldn't think it is the biggest use case of VLC. I for one appreciate being able to read both Mac screen recordings and clips from my DSLR with the same software without installing a bunch of weird stuff.


Going back one frame is about as hard as going back one second. VLC allows you to click on the bar to go back to a time, which doesn’t work in all video formats (as mentioned by the dev). Going back one frame would not be any harder or more variable across formats than going to a specific time.


I wonder: Is this why vlc delays for 5 to 10 seconds every time I use the "skip backward" functionality on my iPad, where other players don't have that delay?


If so, how comes you can do the workaround one suggested of entering a time one second ago then going forward a frame at a time?


You can only do it for certain formats


Sure but I thought VLC only supports features that work for all formats, and supporting features that work for only some formats is a no no and for that reason previous frame is not possible. Yet skip to time is allowed.


Which is why VLC doesn't implement seeking because that only works for indexed formats? No of course not, that would be ridiculous, right? And if you can seek somewhat accurately you can then skip to a specific frame with bounded time. If your idea of supporting a multitude of formats is to only support the lowest common denominator then your software is not going to be very useful.

It's also not like only some very nieche professional-only formats will have the required indexes. No, 99.99% of videos support accurate-enough seeking because that's something most people expect to be able to do with their video files.

You are also making it sound like VLC is the only player that has managed to support a wide range of formats when there are countless of ffmpeg-based players that manage to do that, like the subject of this post.


> VLC is what it is today

VLC is the least common denominator of video players. Its UI is asinine and the two primary reasons for its popularity are its iconic logo and multi-OS compatibility.

I admit you're probably right on the topic of stepping backwards by one frame, but I wouldn't be so quick to shower VLC with broad praise like that.


    > Its UI is asinine
Well, that's not a very nice thing to say. And, it isn't productive to the conversation.

What is it about end-user software with a GUI that seems to trigger such heated, emotional responses on HN? Each time that I read discussions like these, everyone and there uncle pops into the conversation to add the "one thing" they don't like about it. Or "I'll never use it again after that UI bug from 2004." It is exhausting. One thing that I have learned over the years: Never ask a dev their opinion about a UI. Or, if you do, make sure to ignore whatever they say. It is mostly complaining about "hang-nails".


I know the devs are good and they want the feature to be perfect, but it reminds me that they removed the ability to browse files on the iPhone which is unexplainable, or show that they are a bit in denial of what users need, which is confirmed by this thread.


Wait, what? You can browse files on the iPhone just fine.


I notice a lot of devs try to deny the chaos of the world. It's almost like the code is where they go to hide from things that can't be cleanly and unambiguously expressed.

I don't know how they get away with that though. In the coding work that I do, I'm constantly dealing with rules that have exceptions on top of exceptions. I just need to special-case some things, because the alternative is not delivering what the business needs.


Because it's an open-source project, not commercial software.

In your job, you have to special-case some things because the alternative is not delivering what the boss wants. Regardless of the problems this may cause, or how much tech debt it generates - those are (in the end) business decisions, and while you can make a case to the boss that implementing the special case feature is going to cause huge problems, it's the boss's call as to whether it gets implemented.

In an open-source project the maintainer is the boss. If the maintainer thinks that the feature is going to cause problems, they're totally free to say "no, I'm not going to implement that feature". And, ofc, because it's FOSS, the user is totally free to fork it, or submit a PR for the feature, or whatever.

> just got here from a Google search. I gotta say the replies from Remi sound defensively toxic. I'm not here to program the app, I'm just here to find a simple feature and/or request it.

I think Remi sounds curt rather than toxic. There's no automatic right for anyone to go to a FOSS project and request a feature and have it implemented. The maintainer is perfectly within their rights to just say "no". It's their project, their code, their time, and they're free to do/not do anything they like with it.


If you say "no, we're not pursuing this feature because it's impossible" and users have used other software that implements the feature to a reasonable degree of functionality, you're not doing yourself any favours in terms of shutting down demands. You'd be better off either not giving a reason at all, or giving reasons that are clearer to people who aren't as knowledgable.


Reasons are actually stated, they explained it is not feasible for the general case.

Once the devs have made clear they don’t plan to do exceptions (as other softwares do) then users should accept it and move on instead of keep harassing volunteers.


... except VLC implements time-based seeking which has pretty much the same requirements and is consequently not possible with literally all files either. But both are possible with 99.99% of video files you will come accross.

VLC developers are of course free to reject any feature request but if they do it by bullshitting their users (and that includes tacking on additional requirements that no user actually needs like perfect support for all formats under the sun) then they will be rightfully called out for it. Then throwing a tantrum and citing CoC violations is not going to improve things.

It's their project so ultimately they get to choose to run it into the ground but this kind of behavior is not something I want to support as a user os I will stay away from VLC which includes not making helpful bug reports and not donating.


Why is it incumbent on the developers (who know their codebase and its capabilities better than the forum posters) to explain their decision to the forum posters begging for a feature, and not only explain it, but explain the decision and the reasoning behind in such clarity and depth that the forum posters (who might not even be programmers, let alone know the code base) understand it sufficiently well to refrain from begging and insulting?


Because - and more so for the maintainers/managers of those projects - being able to communicate effectively is part of what it means to run a successful project?

That may even mean that you have to hold yourself to a higher standard than some low-effort post on the part of some casual user. Especially if you're the boss, the maintainer, the leader. And if that's asymmetric then yes it is - but to be a maintainer/manager of a project is also asymmetric. Good managers might also promote that culture more widely across all the project's contributors and so yes it may apply to all developers, too.

Not everyone that engages with your project is going to be perfect, some may even be rude. But as a representative of that project it's a skill to be able to cope with that, on behalf of the project (not you). I think one of the most underrated skills of a FOSS maintainer is a degree of fault-tolerance, to use a systems analogy.

Or, you could argue that no, it's not incumbent on a maintainer to be anything, even to be kind. But then don't expect your users to come back.


But he didn't "just" say no:

> If it's so easy, why are you not doing it? Talk is cheap.

> I'll be waiting for your patch. Surely you're not as lazy and incompetent as the existing volunteer developers.

I'd say that is pretty toxic.

Specifically, that is no way to talk about other volunteer developers that contribute their time. It is precisely the kind of language that keeps people away from contributing to open source. It's the very definition of toxic.


Quite remarkable that you call the developer toxic when those were his replies paraphrasing what users had said and demanded up-thread.

> that is no way to talk about other volunteer developers that contribute their time.

He is not dissing the other developers. He is one of those developers that had been called lazy and incompetent by the forum posters. For example (from the thread):

> it's mostly an excuse to not implement the feature (and be "cool" about it with one-word answers).

> Please consider implementing this. It's not hard.

> All of the players I've named are open source, so it's easy to check how they are doing it.

> Seriously how hard is it to implement it? All Ive been hearing from the developers are excuses, excuses, excuses. I dont see how other players were able to have it. This is just pure laziness.

> I'm not here to program the app, I'm just here to find a simple feature and/or request it.

Personally, I would hold the people using a free product and begging for features without contributing anything to a higher standard than the developers that donate their time implementing it.


Yes ok, I did read the thread but didn't get the reference. I wouldn't say it's "quite remarkable", more simply that I misunderstood. My apologies.

But I stand by the broader point that I do not think his attitude is at all constructive or helpful, and while I am sure he is fed of up what he views as entitled users this is not a productive way to handle it. The toxicity is that it casts shade on FOSS and pushes people away from the community. And VLC would be half what it is today without it's users. He would do well to remember that, too.


> And VLC would be half what it is today without it's users. He would do well to remember that, too.

I disagree. It would be exactly the same as it is now without the users. The users have not contributed anything to the project. Popularity doesn't write code, it just creates communication overhead.

Again, this is not commercial software. Commercial software needs popularity. For FOSS projects, popularity is cool and can be an ego-boost for the maintainers, even open some doors and get some funding, but it's not the point of thing (and never covers costs anyway). The point is to write some good code that scratches some itch the maintainers have.

That whole point of view from the users, of "you owe us because your thing is popular now" is toxic entitlement. If you didn't contribute to the project, you didn't affect it, and you're owed nothing, absolutely nothing, by the maintainers. Everyone would do well to remember that.


Ah, fair enough. I think we agree mostly then - he is fed up, he is justified in it, yet it is not very productive. (I wouldn't call it toxic, though.)


This is taken out of context. He actually respects contributors, including their decision to not implement reverse play.

The meaning here is "if you think the existing contributors are as incompetent and lazy as you are implying, then do better".

I think he got caught up in the argument and that he should have just put the question in a FAQ entry and lock the thread before people start mentioning nazis.


Thanks for this. It seems you got that I misunderstood. I've clarified my point in another reply.

Also agree that if this is a question that keeps coming up a much better response would be to simply explain your reasoning once in an FAQ that carefully presents the argument and point all future discussions to that entry. Done.

To the average user, it's not at all obvious why reverse play is so much harder than it looks. Surely it's possible to understand that users might be confused by this? An well written FAQ on the subject would solve all of this.


The QuickTime API supported reverse play around 1993 or so, when I enjoyed using it for "back and forth" animated sprites, and playing music videos backwards to reveal the satanic messages with demonic backmasking.

Reverse / Backwards Moonwalk - Michael Jackson - Better Than The Original!!!

https://www.youtube.com/watch?v=IT_Aq2FjJo0

Here's the documentation and code I wrote when working at Kaleida Labs (a joint venture of Apple and IBM) on a ScriptX animation library that used QuickTime and other renderers, and depended on QuickTime's support for playing videos backwards, and single stepping forward and backwards of course:

ScriptX Animation Library:

https://www.donhopkins.com/home/catalog/lang/scriptx/anim.ht...

ScriptX Animation Implementation Module:

https://donhopkins.com/home/archive/scriptx/animimp.sx

ScriptX's QuickTime renderer would even play audio backwards and at whatever speed, too. ScriptX had excellent multimedia clock synchronization, and we would have considered it a terrible bug if ScriptX was not able to seamlessly and transparently synchronize video and audio with any arbitrary clock, time offset, and time scale, no matter what the speed and direction.

https://en.wikipedia.org/wiki/ScriptX

I'm sad that 31 years later, web browser video and audio players (not to mention VLC) don't support hierarchical clocks like ScriptX did for multimedia synchronization. (Each child clock can have a time offset and time scale relative to its parent, and everything's automatically kept in sync, from the simulation to the renderer.)

Here is Kaleida's (then Apple's) 1993 patent on "Synchronized clocks and media players", which has long since expired in 2013:

https://patents.google.com/patent/US5452435A/en

>Abstract: A media player and the clock which controls it are integrated into a single object. This integration may be achieved by the construct of inheritance between objects in an object oriented programming environment. A software class for player objects is established which inherits from a software class for clock objects. In this way, a player "is a" clock. This integration provides improved synchronization among different media, and simplifies design of applications which employ player objects and clock objects. Each object is synchronized to a RootClock object which operates at the speed of the fastest media player in the system. The RootClock may be separated into "low" order and "high" order components and a compare register in order to reduce interrupt overhead.

>[...] QuickTime essentially allows a multimedia player to process timebased data. Since the data are time based, QuickTime provides for the description of "time" (called time basis) for the data as well as a definition of the context for evaluating that "time." In QuickTime, a movie's or media's time basis is called its "timebase."

>A timebase is essentially a vector that defines the direction and velocity of time for a movie or media. The context for a timebase is called its time coordinate system. Conceptually, a time coordinate system provides an axis for measuring time. The time coordinate system, like a geometrical axis, is divided into units of measurement by a measurement system, called a time scale. [...]

https://news.ycombinator.com/item?id=18781950

DonHopkins on Dec 29, 2018 | parent | context | favorite | on: Steve Jobs hired a career juggler to teach program...

Oh, of course I wish Apple and IBM had made it free! But it included Apple's "crown jewels", the QuickTime player source code, and they were't going to give that away in 1995. Apple were even trepidatious about IBM having access to that source code.

Besides having proprietary decoders, it could also do some things you can't even do well with the Flash player or html video component today: like smoothly playing videos and music backwards!

Ever since the music industry switched from vinyl to CD, listening to demonic backmasking in Devil Music like the Beatles and Led Zeppelin's promotion of Satanism became much less convenient. ScriptX solved that important problem elegantly with its synchronized clock system, but today's HTML video player still hasn't, alas.

https://en.wikipedia.org/wiki/Backmasking

https://www.youtube.com/watch?v=5BDh_j5qAJ4

Here's a description of ScriptX's clock system:

https://news.ycombinator.com/item?id=18350511

>Kaleida Lab's ScriptX (a multimedia programing language kinda like Dylan with classes) had built-in support for hierarchal clocks within the container (in the sense of "window" not "vm") hierarchy. The same way every window or node has a 2D or 3D transformation matrix, each clock has a time scale and offset relative to its parent, so anything that consumes time (like a QuickTime player, or a simulation) runs at the scaled and offset time that it inherits through its parent container. And you can move and scale each container around in time as necessary, to pause movies or simulations.) You could even set the scale to a negative number, and it played QuickTime movies backwards! (That was pretty cool in 1995 -- try playing a movie backwards in the web browser today!)

Is it possible to play HTML5 video in reverse?

https://stackoverflow.com/questions/5277293/is-it-possible-t...

Kinda, but it's not smooth enough to sing along while dancing backwards and worshiping Satan to:

https://codepen.io/adrianparr/pen/qmCek

kragen on Dec 29, 2018 [–]

Yeah, I remember het AVI porn in the early 1990s where time alternated between forward and backward, thus providing an infinite video in only a few frames. (Probably it would have been more realistic with a sinusoidal rather than triangle-wave temporal waveform.)

I think there's a lot of space for experimentation here, generating video as an arbitrary three-dimensional slice of a potentially higher-dimensional space — like how horse-race photo-finish cameras map one vertical spatial dimension and one temporal dimension into two spatial dimensions for the photo, or how Julia-set animations map two of the dimensions of the four-dimensional Julibrot onto screen space while mapping a smooth path through the other two dimensions onto time. I've gotten some stunning still images by taking even fixed horizontal or vertical slices through video, but you could also do things like delay one side of the picture more than the other, or foreshadow future action by curving part of the frame into a timelike angle through the source material. It might be difficult to record a source video with more than one temporal dimension with a camera, but you can certainly do it with ray-tracing or other rendering techniques.

Presumably if you want to play a video backward with a modern codec, you need to buffer up decoded P-frames in memory from at least the previous I-frame — much like iterating backwards over the lines in a file, except that each "character" is a megabyte or two of YUV pixels. Should be totally feasible on a modern cellphone, even for aggressive modern formats that only have I-frames every few seconds… but it would be nothing short of a miracle in 1995! I guess MPEG-2 didn't exist yet, so maybe MPEG-1 with N=18, M=2 was the worst case you'd need to handle at that point? That should only require a 10-P-and-I-frame buffer.


The whole point that Remi was making is that doing this for one format is probably easy. Doing this for all formats in a consistent manner with a consistent experience is not easy, verging on impossible. Other players only support a limited set of formats, so can do this easily. VLC supports everything, so therefore has to handle all the bizarre quirks that make this a very difficult task.


> lock the thread before people start mentioning nazis.

Which will invariably happen. What was that "rule" called again?


It's Godwin's law (of Nazi analogies): https://en.wikipedia.org/wiki/Godwin%27s_law


It may be slightly rude but it's also correct and it's something that not enough people realize, so they need ot be told. If you want something done, you can ask, but if the answer is no, you have to do it yourself. That's reality in FOSS.


When I was hired for my first real programming job, my future manager spent a lot of time asking me questions about how I deal with ambiguity. This stuck with me as a really important element to consider in people, but that doesn't seem universal, especially in tech circles.


And this is exactly the problem when these devs are in charge of creating systems that actually do matter. They will not support edge cases, problems in a process, etc.


I mean.. can you show anyone piece of software or hardware or for that matter any man made creation that solves for all edge cases?


But it’s just simple things, like allowing an override of a status field.

Or using a status field to check something is ok or not, instead of always checking the data itself.

People make wrong assumptions, and requirements change. Don’t make it all rigid that you always need to implement every case


Everything is a “simple thing” unless you’re the one implementing it. Things that seem simple on the surface rarely are, especially long-term.


I’d say it has to do with not willing to duplicate data. On paper forms, it is simple. Why can’t it be in a digital form?



That article means: inexperience and unprofessional. Sounds about right.


If you’ve never written software that needed to be used by tens of thousands or hundreds of thousands of people, then sure, it could seem that way.


Outside of those contributing to open source projects professionally, the vast majority of contributors will (naturally) be those with greater technical abilities, which unfortunately impacts the general UX of free/OSS overall in my opinion.


This is a very broad generalization and not a good one either. Particularly in this context. It's obviously not possible to do it for all video formats in a consistent way. I haven't read through all of it yet I could tell all the proposed solutions are hacky ones. Your scenario doesn't apply here. Businesses are different. This is on open source project. Anyone can work on it.

What are you even saying about the choas of the world?! Every dev knows how work is. You are just describing every other software job. Somehow it sounds like you are boasting how matured you are just because you do what your client asks/needs. Even then, many business/software make a concious choice to support or not support something based on some guidance. The guidance could be some core principles or just some product managers whim.

It's highly likely that VLC developers chose not to support the feature for the very reason(s) that's described in the post. It's a concious choice they made. I don't see anything wrong in that. They definitely are not some school kids with some daddy issues to hide behind some code. They clearly have answered all the questions from a technical stand point.


But the hacky solutions actually get done what people want the software to do. The point between me and the parent poster is that a solution necessarily being hacky is not a good reason to not implement a feature.

And TBH the VLC example hardly even seems hacky. If you have a stream that can be seeked backwards in, then find the previous I-frame and internally run the video forward to the frame the user wants to see. That is exactly what the user is forced to do manually anyway.

As far as it sounding like I'm boasting, all I can really do is assure you that was not the point. I was contrasting my experiences with how people tend to write about software development in blog posts and in comments on places like here. I do not think I'm better than them simply because I am ok with implementing hacky solutions where I think they make sense. But I am annoyed when useful features are denied because it would require a hacky solution. For FOSS, it's entirely within the devs rights to operate that way, but to me that's one way FOSS software can sometimes fall short of commercial software.


> But excuses about not being possible for absolutely every possible codec in a completely generic way is just denying that the world is just a chaotic and dirty place where things are not ideal nor perfect.

It's also not consistently applied. VLC will happily let you jump around in the videos, so his claim that the only way to do it is to play the video as fast as possible from the start of the video just doesn't jive with what is already there.


>Sometimes we forget that software ought to be useful, not hypothetical ideals of truth.

I've long since come to the understanding that if I want software that are useful, I must go and pay for it. Commercial software exist to make money, and to make money they must be useful.

If I want software that are hypothetical ideals of truth, I go and shitpost at the nearest neckbeard communion. Free-beer software exist to satisfy a man's desire to display his voluminous beard, everything else is tertiary.


This might be true in some application areas, but certainly not generally.

Where is that commercial kernel that works over a wide spectrum of architectures and system sizes?

Where is that commercial compiler that works on many architectures?

Where is that commercial packet capture software that people a paying for to get work done?

Where is that commercial emulator that can run your operating system on a very different machine in countless combinations.

The list could go on and on...


What commercial video player do you use which is better than both mpv and VLC?


It's the opposite in my experience. Commercial software only cares at most about what is useful to the average user while anything for power users is written off as too expensive to maintain. And these days even if you pay you are often not the main customer since your data and attention is sold to someone else anyway, in which case what is useful to you matters even less.


> I've long since come to the understanding that if I want software that are useful, I must go and pay for it. Commercial software exist to make money, and to make money they must be useful.

Even if it were free, wouldn't you want to do something nice (like give them money) for the person(s) who made the useful thing for you?


Wonder how mpv deals with backwards step in infinite GOP/long GOP situations.


"I'll be waiting for your patch. Surely you're not as lazy and incompetent as the existing volunteer developers."- Rémi Denis-Courmont

I see Rémi Denis-Courmont's arrogant attitude and disrespect for users and developers hasn't improved in all these years. And neither has VLC's spectacularly awful UI. Coincidence, or cause and effect?

https://news.ycombinator.com/item?id=13573499

DonHopkins on Feb 5, 2017 | parent | context | favorite | on: Nullsoft: The death of the last maverick tech comp...

VLC's UI sucks so terribly, it's like they went WAY out of their way to make it sucks on purpose, and stubbornly refuse to acknowledge that there are any problems or ever consider fixing them. One example of many [1]:

Type CMD-E (on Mac, or whatever the equivalent is on Windows) to get the video effects window.

Select "Geometry". Now check "Magnification/Zoom".

Notice how you get a picture-in-picture in the upper left corner, with a white rectangle showing the zoomed area, that you can move around by clicking. But if you press and hold, it also drags the entire windows (on a Mac -- I haven't tried on Windows -- VLC's UI and behavior on Mac and Windows diverges widely so I won't try to predict what happens).

Now look underneath the picture-in-picture and notices some ugly upper case pixelated text that says "VLC ZOOM HIDE". See how it's jaggy and rendered at the resolution of the movie you're playing itself, not at screen in a full resolution overlay with readable text?

Now look at the triangle with a jaggy curved hypotenuse below the jaggy words. That is the zoom "slider" (which also drags the window when you drag the mouse, so it's more like a clicker than a slider). See how it gets narrower and narrower in a succession of jaggy stair-step chunks, until it's merely one jaggy pixel wide? Well guess what: the TARGET AREA also gets narrow to match the width of the slider, so it's almost impossible to click on the bottom of the slider, to select the larger zoom sizes! Since the zoom slider is not very tall and its pixels fat and jaggy, you don't have fine grained access to very many zoom sizes at all, either. The zoom pixel steps are much bigger than screen pixels, depending on the video resolution!

What possible purpose could that serve? Why would any user guess that the lower narrow part of the slider represents a wider zoom showing a bigger rectangle over the picture-in-picture, while the top wider part of the slider represents a tighter zoom showing a smaller rectangle over the picture-in-picture? And what slider have you ever used that gets narrower from top to bottom, with a jaggy curve, and an impossibly narrow hard to click target area at the bottom?

This single facet of VLC's terrible UI deserves to be front and center in the User Interface Hall of Shame [2] -- it's even worse than Apple's infamous schizophrenically skeuomorphic QuickTime 4.0 player [3], from 1999! The latest version of VLC in 2017 is still much worse than the shameful QuickTime player was 18 years ago!

Who could have possibly gone so far out of their way to design and implement such a terrible user interface on purpose, then smugly brushed off and ignored 16 years of bug reports and cries for help on the VLC message boards, without harboring a malicious contempt for their users?

That's not even the worst of it. Now check "Transform" and pick one of the transforms like "Rotate by 90 degrees". Guess what? The magnification interface itself is rotated 90 degrees, because it's drawn on the video before it's rotated, so now it appears at the top right of the screen, rotated 90 degrees itself.

And guess what else? The mouse clicks are not even transformed properly, so clicking on the magnification interfaces does NOTHING, rendering it completely useless! Depending on the aspect ratio of the video, you can't even click in the upper left corner where it USED to be and SHOULD still be to operate it, because it is clipped off the right edge of the window.

Are those ugly cosmetic and impossible usability problems not bad enough for you? Then make a playlist with one item. Select "Repeat" mode. Play the movie. Now go to the finder and remove, rename or move the movie you're playing, or just unplug the USB stick containing the video. Not an uncommon occurrence, right? Now VLC will hang up, consuming 100% of the CPU time, often times seizing up the entire Mac, turning on the fan, locking out all user input, and forcing you to reboot! This happens to me all the time.

These bugs have been around for years. The more you fiddle around with it, testing out the edge cases and trying to combine various poorly designed and implemented features, the more bugs you find.

File a bug report, they say. People report these problems again and again. The developers just ignore them and brush them off. I've tried reporting these and other bugs, describing them in meticulous detail, which is frustrating because once I start writing step-by-step instructions to reproduce one problem, I keep finding more and more problems, each worse than the last, and then they just brush me off and ignore my bug reports too.

VLC's user interface is maliciously terrible in so many ways, the developers are careless and arrogant towards their users, and there's no hope of the developers ever changing their ways, acknowledging the problems, and improving it. Instead of improving usability for everyone, they're more interested in adding yet another obscure anime decoder feature so they can watch their AMV cartoon porn [4] [5].

[1] http://imgur.com/gallery/g0acV

[2] http://hallofshame.gp.co.at/index.php

[3] http://hallofshame.gp.co.at/qtime.htm

[4] https://www.videolan.org/vlc/releases/2.1.5.html

FOR ANIME FANS

New 6.1 downmixer to 5.1 and Stereo from MKV/Flac 6.1. Correct YUV->RGB color matrix in the OpenGL shaders. Improved MKV support for seeking, and resiliancy. Editions support in MKV. Better subtitles and metadata support from MKV. Various ASS subtitles improvements.

[5] https://myanimelist.net/forum/?topicid=208770

Now, if you are an AMV (Anime Music Video) creator and want to edit the video directly, the MKV is your best friend since it's a lossless video-content container due to the fact that you will find yourself adding effects to the video frames/audio. In this case you will want to lose as little as possible in your video, so MKV compression best suits.

TOPIC ANSWER: The reason why MKV is popular for anime is because of it's noted lossless compression. Anime show creators most likely notice this fact and use it to contain their video frames and audio tracks for maximum quality. - it has nothing to do with HD.

derefr on Feb 5, 2017 [–]

> Instead of improving usability for everyone, they're more interested in adding yet another obscure anime decoder feature so they can watch their AMV cartoon porn Mind you, FOSS is contributed to by people scratching their own itch. It's not so much that VLC has a lot of otaku developers; it's that a lot of people who watch (or subtitle) "AMV cartoon porn" see a problem with, or missing feature in, VLC, and think "I'm a programmer; I can fix that", and dash off one-off patches.

DonHopkins on Feb 6, 2017 | parent | next [–]

It just puzzles me that out of eight bullet points summarizing the new features in VLC 2.1.5, one of them was "FOR ANIME FANS" and none of them were "FOR USABILITY". It's the contempt and dismissal that the developers show to usability bug reports when they brush them off and ignore them, which bewilders and frustrates me. Go read some of the discussion group postings and bug reports over the many years, and you will see what I mean. It's a deeply entrenched pattern of behavior.

majkinetor on Feb 6, 2017 | parent | prev [–]

Its very hard to contribute patch to foss tool in general. There is no substitution for agile development team.

DonHopkins on Feb 6, 2017 | root | parent [–]

Oh I certainly wanted to contribute to the VLC project and integrate it into my own projects, but after having my concerns that I wrote up in great detail flippantly dismissed with such contempt, and seeing how the exact same thing happened to other users reporting legitimate longstanding bugs who were brushed off and ignored over so many years, I had no interest in contributing after that. It's fortunate that not every open source project suffers from such arrogant developers as VLC.


> "I'll be waiting for your patch. Surely you're not as lazy and incompetent as the existing volunteer developers."- Rémi Denis-Courmont

> I see Rémi Denis-Courmont's arrogant attitude and disrespect for users and developers hasn't improved in all these years.

That's out of context quote: https://news.ycombinator.com/item?id=41282178


You've got some very confused beliefs about what mkv is and why it's used. Mkv is a container, not a codec, which is most often used to store lossy video and audio tracks. It can store lossless tracks too, but that is uncommon in practice. Other popular containers, such as mp4 (e.g. MPEG-4 Part 14), can also store lossless tracks.

The biggest reason anime people prefer mkv to mp4 is because mkv supports the ASS/SSA subtitle format, which is favored by the anime subbing community for its extremely versatile formatting options. For instance, it is common for subbers to cover up signs containing Japanese text with translated subtitle text, tracked to the video, styled and transformed to appear virtually seamless. Less relevant but still important to some people, mkv supports a plethera of old (and very lossy) video codecs, which is sometimes relevant when it comes to repackaging old encodes of hard to find media. Being able to copy in the old video codec without transcoding preserves what little quality there is while allowing you to package it with modern subtitles. Mkv also has superior support for chapters, metadata, etc.

But I get it, you hate anime and think weebs are pervs. I thought you were a man who values tolerance highly, but whatever man. It has little bearing on technical matters. Incidentally, anime people generally favor mpv above VLC, because the ASS/SSA support is a lot better in mpv (mpv uses it for rendering the psuedo-GUI.)

As for the bugs and UX issues in VLC, I assume that your claims are more accurate than your understanding of media containers, but VLC is nevertheless the best video player to recommend to nontechnical users you might find yourself playing tech support for. They won't tinker with it and therefore won't discover most of the issues you're talking about. What they'll get out of it is a media player that plays whatever file they throw at it, without feeling the need to run sketchy "codec packs" they found god knows where on the internet.


Those aren't my confused beliefs, I was literally quoting the text at the links.

And you don't have to be so defensive by jumping to conclusions that I hate "weebs" and think they're all pervs (although the ones obsessed with sexualizing little girls are certainly misogynistic pervs). What I hate is spending precious time and effort catering to small groups of people obsessed with particular fetishes (perverted and misogynistic or not), at the expense of prioritizing solving the real problems of large groups of people suffering from particular egregious bugs and usability issues.

Remember: it's been A DOZEN YEARS since I reported the problems in great detail with step-by-step instructions to reproduce them, and they STILL haven't fixed those problems that I and other people reported. Maybe refusing to ever acknowledge or fix those horrible bugs is Rémi Denis-Courmont's way of getting revenge on me for hurting his feelings by posting a wall of text he claims he didn't bother to read, at the expense of all of his other users and the quality and usability of VLC, so now I'm sorry I ever took the time to try to help by reporting and documenting the bug, and I'll never do that again, but he still seems pretty arrogant and thin skinned to me, even quite recently. And VLC's user interface STILL sucks.

Edit: The link I'm quoting is myself, quoting the text in another link written by SOMEONE ELSE. Literally, the VLC release notes, and an anime discussion about MKV which I read before I quoted it, so I already fully understand what you're mansplaining to me, and I'm not complaining about cartoon porn or MKV, I'm complaining about idiotic priorities. I'm sorry I touched a nerve that triggered you, but I don't hate "weebs" or porn, just misogyny and child abuse and terrible user interfaces. If you want to argue in favor of those things, go back to 4chan.


The link you're quoting is yourself, complaining about anime porn and asserting that mkv is popular because it's lossless.

Mkv really has nothing to do with VLCs usability problems. You're just grinding an axe against it because it's not a feature you value (or seem to even understand) but is valued by people you have evident disdain for (why even bring pornography into the discussion?)


VLC is pretty bad and it shows the more you use it.

It doesn't let the audio clip/exceed safe volumes and always applies some sort of a limiter, even if it's disabled everywhere in the settings. Try using an EQ on a bass-heavy track and see that it's limited.

Try jumping back multiple times in a song at its beginning, and it will play in lower pitch.


That strikes me as such a strange statement, I’ve always considered it to be among the most impressive OSS projects out there. It tackles enormous complexity, works everywhere, and has a trove of a million hidden features. For example, I use it to headless play streams from CLI.


If you enter video-related enthusiast scenes, such as fansubbed anime releases, mpv is recommended over anything else across the board. There are releases that break in VLC, and mpv is usually first to support new features. It also has particularly good defaults in terms of good and accurate playback, so where you might see some people say "install mpc-hc and these scripts and change these settings", with mpv it's just "use mpv". mpv is extremely configurable on top of great defaults also. Setting default audio and sub languages in order of your preference (such as enm before eng and en if you prefer honorifics tracks) is a common tweak.

I thought VLC was awesome while growing up, and at the time it probably was compared to Windows Media Player and such. I remember a common bit of praise was that it supported more types of video files. I haven't really run into anything mpv won't play (I even use it when an image I saved ends up as .html for some reason and then use the info screen to determine the real extension it should be so I can rename it), but also I'm guessing we've standardized more on codecs and containers these days which doesn't hurt.


> I even use it when an image I saved ends up as .html for some reason and then use the info screen to determine the real extension it should be so I can rename it

If you’re on Linux on macOS, you’ll have access to the `file` command-line tool which can do it effectively. In a couple of lines of shell scripting you can even have it auto-change the extension.

https://en.wikipedia.org/wiki/File_(command)


I had someone try to tell me this or some similar alternative method once, but for this particular use-case my method seemed faster. Usually I'm viewing the dir with the file in ranger, hit r (shortcut for :open_with ), type mpv, enter, I in mpv for info, q to quit, a in ranger to rename the file with old name pretyped in. It's a pretty smooth workflow. Assuming I start from the same place in ranger I have to press colon and type `shell -w file %s` and hit enter which may or may not be faster but I think is more keystrokes. I could bind it to a key in ranger if I found an open one and then that might be better. It's sometimes weeks between instances of the mis-saved images or else I might've tried harder to optimize this. The shell script idea is neat.


Personally I use a shell script to do it automatically for me... with "file":

    #!/bin/bash
    # Usage: fix-extensions <media file(s)>
    # Renames the files to consistent file extensions based on content

    for file in "$@"; do
        [ -f "$file" ] || continue
        dir=$(dirname "$file")
        name=$(basename "$file")
        prefix="${name%.*}"
        ext="${name##*.}"

        magic=$(file -b "$file")
        newext=""
        case "$magic" in
        *"Apple QuickTime movie"*)        newext=mov;;
        "ISO Media, Apple iTunes Video"*) newext=mp4;;
        "ISO Media, MP4"*)                newext=mp4;;
        "ISO Media, MPEG-4 (.MP4)"*)      newext=mp4;;
        "Macromedia Flash data"*)         newext=swf;;
        "Macromedia Flash Video")         newext=flv;;
        "Matroska data")                  newext=mkv;;
        "Microsoft ASF"*)                 newext=wmv;;
        "MPEG sequence"*)                 newext=mpeg;;
        "Ogg data, OGM video"*)           newext=ogm;;
        "RealMedia file")                 newext=rm;;
        "RIFF "*" data, AVI,"*)           newext=avi;;
        "WebM")                           newext=webm;;
        esac

        if [ -z "$newext" ]; then
            echo >&2 "$file: not renaming, unknown extension for type '$magic'"
        elif [ "$ext" != "$newext" ]; then
            mv -v "$file" "$dir/$prefix.$newext"
        fi
    done


> The shell script idea is neat.

Could be something as simple as:

  file_path="${1}"
  mime="$(file --mime-type --brief "${file_path}")"
  ext="${mime#image/}"
  mv "${file_path}" "${file_path%.*}.${ext}"
That does no checks (e.g. is the file an image) and may not work on something on something like a video, but it’ll do for common image types such as png, jpeg, webp, heic, gif…


As someone who went MPC-HC + MadVR + ReClock -> mpv years ago (well, I also switched to Gentoo, to be fair). This is completely right.

BUT mpv still isn't perfect. The script in https://github.com/mpv-player/mpv/issues/8463 is really needed to handle some stuff (mainly clandestine anime) and the libplacebo/gpu-next transition wasn't exactly the smoothest (my config still has hotfixes for https://github.com/mpv-player/mpv/issues/10716 and https://github.com/mpv-player/mpv/issues/14474).

Nitpicking aside, it really is the new gold standard these days, and for good reasons.


VLC is only praised in "normie" places. It is hated in places like anime forums, 4chan, etc.


TIL I'm a normie. And I thought I was a hotshot tech guy.


Maybe not hated but yeah I think the memes about the first memes I've seen about artifacts/stuttering in VLC are basically as old as VLC itself. And new ones keep getting made


VLC makes video choppy on my low-end Debian machine. MPV plays them perfectly.


> works everywhere

No, it doesn’t. I had problems with it, which was tackled by basically every other players easily (e.g. seeking or simply playing anything).


> has a trove of a million hidden features

No software person would find this praiseworthy. A million features = two million bugs, and indeed it shows.


Speak for yourself. I would much rather have a buggy feature than no feature at all.


I guess I don't want my video player to let audio exceed safe volumes...


> VLC is pretty bad and it shows the more you use it.

Compared to what? Such a statement is meaningless without comparison.


Compared to mpv. Some would also say compared to mpc-hc.


The first sentence on https://mpc-hc.org/ is, "MPC-HC is not under development since 2017. Please switch to something else."


Instead of MPC-HC v1.7.13 (2017) maybe try MPC-HC v2.3.4 (2024)

https://github.com/clsid2/mpc-hc

In many ways it's a display wrapper about codec components, the display part is in active maintainance and bug fix mode (last update two weeks ago) and the codecs are constantly being improved (and expanded as new ones emerge).

https://www.codecguide.com/

There are two or three MPC-HC spin offs that are tweaking the core to do new things.


it's annoying that the clsid fork isn't associated with the website- it adds a lot of confusion to what is probably the video player that compromises between user friendliness and customizability. It's usually the video player that I recommend to people because it seems beter than vlc and has a GUI for settings as opposed to mpv.


This is one of the many reasons why forks should use a distinctive name to differentiate themselves. Just realeasing new versions with the same name as the upstream project is generally a dick move.


I am pretty sure the dev (clsid2) worked on mpc-hc originally as well before.


search engines and wikipedia point to actively maintained versions


> mpv

can you please explain what you mean with this acronym?

EDIT: this seems to correspond to https://en.wikipedia.org/wiki/MPlayer


mpv is the name of the actual program, I'm not aware of it standing for anything. MPlayer is an older project.


I don't think the target audience are the same. Not so sure about this. Just my impression.


The developer responds to a comment:

But many players are able to do it for years.

with:

If it's so easy, why are you not doing it?

He's not just a butthole, he's a stereotypical open source developer butthole. On the other hand, if he worked for Microsoft, he'd be claiming that it takes a PhD to do it...


In his defense, some commenters had a pretty rude attitude. You cannot demand developers to implement a feature or call them out on being lazy.

Nobody even offered to research how other players accomplish this. They just expect that because they believe it can be done someome should do the work for them.

At least Remi was actually andering questions on the forums.

This attitude towards open source maintainers is what's getting them all burned out.


As a FOSS maintainer, I have sympathy for him, but as a communicator, I see he really failed to address multiple commenters pointing out that several other FOSS video projects had the feature. (At least in the first page of comments.)


I don't think the other people commenting were being at all rude. They asked nicely if a feature would be possible. He replied with a blank "No" and from then on it was pretty much "but other players can do it so it must be possible" and him rudely and incorrectly asserting that it isn't and that anyway if it was why don't they do it if they want it so much.

The correct response would have been something like "it's more difficult to do and in some circumstances it will have very bad performance so we haven't done it yet".

This is classic "It's hard and I can't be bothered so I'll make up some technical reason why it's impossible". Programmers do this all the time and it's kind of annoying.

(And yes I understand video coding and I know why it's more difficult in some cases.)


I think the answer (read from between the lines) is more: "There is no way to make it work for the general case of all video formats, and we don't implement a feature unless it works for the general case, so we choose not to implement it at all. If that means that we don't have that feature for the file formats where it would works, that's a sacrifice that we are willing to take."


Agreed, and this is actually a really good point:

> we don't implement a feature unless it works for the general cas

I used to make that mistake a lot. My boss would say "can we do this", for example report memory usage per operation. And I would say "no because sometimes memory is shared between operations so it would be meaningless". In other words I couldn't do it perfectly so I said we couldn't do it at all.

That's what the VLC guy is doing and I didn't realise until I worked with that boss that it is COMPLETELY WRONG!

Just because you can't do it perfectly doesn't mean giving up entirely is the best you can do. In cases like this you can absolutely do something that works sometimes but not in every case and that is way better for users than just giving up.

Lots of programmers fall into that trap though.


VLC is able to abstract over a ton of extremely complicated codecs by providing some common tools that work for all of them.

I guess if VLC has a feature, you can always expect it to work. That's their design choice. There's nothing "COMPLETELY WRONG" about that.


The most entertaining part of this thread is that VLC is actually in the process of replacing its backend with the mpv-derived libplacebo.

In the end, VLC has admitted defeat


Both use FFMPEG anyway so it's not like VLC's codec abstraction was really something that sets it apart.


Exactly an in this case it even works 99.99% and VLC already has a related feature (seeking to a specific time) that has pretty much the same codec requirements.


Except even that answer makes no sense since VLC implements time-based seeking which has the same requirements as seeking to a specific frame number. The only additional part to implement is automatically skipping forward a number of frames after the closest preceeding seek point.

Adding a requirement of supporting this perfectly with literally all formats you can think of is not reasonable at all since a video player that stuck to that principle would not be able to support any controls at all. It's the kind of bullshit excuse developers or corporations like to give when they don't want to implement something but also don't want to be honest about that.


He really sounds like an asshole :D sorry for this stupid comment, but i had to tell.


The dev said they are happy to accept patch for this feature. Remember that you're not entitled to demand new features, as a (non-paying) user, you can't allocate dev's time to work on what you want.


> The dev said they are happy to accept patch for this feature.

Did they? Because I read a bunch of the thread and “happy” is he last word I’d use to describe the developer’s sentiment. All I see is “let’s see you provide a patch, and I don’t believe you will”.

Everything about it screams that if a patch were provided, they’d do anything in their power to find reasons for refusal.

Even if I cared about VLC, reading those replies guarantees I would never attempt to submit the patch.


This card is played too often by developers who only want to work on features they personally find interesting or worthwhile.

Yes, you realistically cannot implement everything every user wants, but at the same time your software is meant to solve problems. Keeping direct communication with your users, and understanding what they find useful or not, should be the driving force of the design and features of your app.

FWIW, I've been on both sides of this discussion, as an OSS maintainer and user, and have experience with demanding users and arrogant and, yes, _lazy_ developers alike. Let's stop the narrative that users don't have the right to request features because they're not paying customers, and that this is driving developers to burn out. Communication is key to producing useful software regardless of its license. OSS development in particular is not just about throwing some code online and forgetting about it.


> developers who only want to work on features they personally find interesting or worthwhile.

you say that like it's a bad or even a surprising thing. for a lot of people that's the entire point of open source development - in their day jobs they do what they are required to do for the company that pays them, and then in their own open source projects they can do what genuinely interests them.


Why bother releasing OSS at all then? What do developers who don't want to listen to their users honestly gain from this? Padding on their résumé?

If you just wish to solve your own problems, build things for yourself and keep it private. If, on the other hand, you want to help others and make your software public, then do right by the people who decided to try your software and listen to what they have to say.

How anyone can defend the attitude of the VLC developer in the thread linked above is beyond me.


Imagine finding a piece of art you like, but finding a minor anatomy flaw. When you point it out, the artist says they aren't going to fix it, because the piece is finished, and it would be impossible for them to do it, you point out that other artists have touched up their finished pieces, and they tell you to do it yourself, then.

Why is the artist obligated to do the work you think they should do? Why, if they don't do this work, should they be obligated to not release their work publicly?

FOSS is not an obligation to do everything that every user wants you to do. It's not an obligation to even communicate with those users. In fact, it comes explicitly with no warranty, even for fitness for any purpose.

The developer is a poor communicator, but how anybody can be defending those annoying, entitled, lazy users is beyond me.


You release it to the public so other developers can stand on the shoulders of giants when it's time to scratch their itch, instead of wasting time re-implementing the basics. Why did this need explained?


A FOSS project can be FOSS and refuse all other contributions. FOSS does not make any requirements towards how the creator/main contributor handles and treats users, submitted patches, and feature requests. So no, FOSS users have zero inherent right to request anything - until the creator allows for it.

I agree that taking that kind of "closed" approach is not helpful.


> A FOSS project can be FOSS and refuse all other contributions.

It can, yes. There's nothing preventing it, except that it's a shitty way to work in the open, and you may as well make the project proprietary or source available. The maintainers might have their own vision of the project direction, and they may reject contributions, but refusing contributions outright is how forks are made. Nothing wrong with that either, but usually the projects that are more receptive and responsive to user feedback are the ones that users and developers gravitate towards.


You have been a maintainer and yet you said "your software" instead of "the software you are maintaining". When you maintained an OSS project, did you accept pull requests from lots of contributors or was it a solo show? If so, did you get burned out?


> Yes, you realistically cannot implement everything every user wants, but at the same time your software is meant to solve problems.

It's a question of whose problems. It's highly unlikely that we perceive the same problems in the same order of priority, so why should I donate my time to your problems when I am already wishing for more time to implement the solutions to my own? In commercial software there's an obvious incentive to work on features that are in demand by people who will pay for them. Expecting people to act like that incentive still exists even when it doesn't is insane.

> I've been on both sides of this discussion, as an OSS maintainer and user, and have experience with demanding users and arrogant and, yes, _lazy_ developers alike.

The gall to call someone who doesn't want to work on your problems for free "lazy"... Now imagine that you voluntarily participate in a very active OSS project and there are tens of people like you who extend that massive middle finger over and over whenever they can't convince you to donate a work week to their esoteric dream feature.

> Let's stop the narrative that users don't have the right to request features because they're not paying customers, and that this is driving developers to burn out.

The "narrative", again, is "that you're not entitled to demand new features, as a (non-paying) user, you can't allocate dev's time to work on what you want." This is the card you insist is played too often, not that "users don't have the right to request features". I don't see how you could honestly get these two things mixed up.

> Keeping direct communication with your users, and understanding what they find useful or not, should be the driving force of the design and features of your app.

Who are you to decide what should motivate me?


Users don't have a right to requrest features but as a maintainer you are shooting yourself in the foot if you act like Remi here.


> The dev said they are happy to accept patch

No he didn’t.


You need to send an email to the admin and ask for approval in order to register an account on VLC website to report bugs.

This says it all.


That's the result of being successful for wide non-technical audience. The signal over noise would approach zero if everybody could create a bug report when something does not work as they wanted.

Have you tried to create a meaningful bug report (not feature request) that has not been previously reported and were rejected? If so your complaint is valid. I haven't so I don't know.


> The signal over noise would approach zero if everybody could create a bug report when something does not work as they wanted.

I hear you, but it could be something not so extreme. Lots of even more popular projects work fine with bug reporting system on GitHub, which everyone has access to.

> Have you tried to create a meaningful bug report (not feature request) that has not been previously reported and were rejected?

No I don't, I just want to subscribe to the issues I care, which you can't do without having an account..


It says it's a project on the Internet that has to deal with spam. Are you reading more into it than that?


I'll be happy to switch over to MPV for this alone. VLC is great in general, but lacking some basic features. This sort of 'not possible' nonsense from developers is always a sign of a project's long-term decline.


"not possible" is as much nonsense as "everything is possible". Is it possible for vlc to implement support for rendering and editing common 3d object models? Yes! But is it possible given what vlc was set out to do? No!

I think another sign of a projects long term decline is developers that are all too happy to expand the scope of the project. If that happens I just know that down the line the feature I started using the software because of is down prioritized due to the "need of supporting markdown in the email editor" when the software started as a MSN chat archiver.


I see your point, but frame advance/rewind is very very basic stuff, a feature that has been around since VCRs went on sale to consumers in the 1980s. Doing it on digital videos with intraframe compression obviously requires some memory tradeoffs, but it's inarguably core functionality for a video playback application.


So you’re saying going forward 1 frame in a video is in the scope, but going back 1 frame is out of scope. Weird stance.


If that feature would introduce a need to reactor or re-architect major parts of the the logic since everything has been built with the purpose of the playing video forwards supporting as many codecs as possible. Then, yes. And as a long time user of vlc video playback (and transcoding) I have never wanted to go back one frame. I always wanted to go back like 15 seconds, and that has worked forever.


Sure but that's completely different than claiming that it's out of scope or technically impossible. And that's completely different than your earlier example of implementing 3d rendering or something like that. They could just say that they don't want to do the feature, I think the pain point here is the claim that it is not possible.


Of course it's possible, that's my point. Both the maintainer and the requestors should avoid that word. The real questions are. Is it reasonable? Is it worth it? Is it along the lines of the problems the software set out to solve?


> I have never wanted to go back one frame

Good for you I guess? I have never wanted to go forward one frame so let’s remove that too


So you've never paused a video to figure out what's going on with a transition of piece of motion, or to try to get the perfect screenshot? OK, but that doesn't make other people's way of using video players invalid.


VLC supports seeking to arbitraty time points (as long as the codec provides the neccassry data). Adding seeking to specific frames on top of that is hardly scope bloat.


I was hoping that mpv would work a bit better than vlc for sending video to chromecast, but unfortunately, another similarly amusing thread: https://github.com/mpv-player/mpv/issues/177


It's a former developer that's no longer affiliated with the project since 2021 or thereabouts. They did not part on good terms because he behaved in the same way towards other mpv developers, "my way or the highway".

So you probably shouldn't let anything that old sour your opinion on the current mpv.

(I don't belong to either side, just have been using the player since its inception.)


Ghost is my soulmate. As a OSS maintainer, I feel that.

Not a week goes by without some random dude coming to my repos expecting I implement whatever they ask, or else be called a dick.

Particularly: you don’t have to use mpv if it doesn’t do what you want it to do, and don’t bust my ** because of it.


> Ghost is my soulmate. As a OSS maintainer, I feel that.

You also close issues without even trying to understand what they’re about?

https://github.com/mpv-player/mpv/issues/177#issuecomment-29...

https://github.com/mpv-player/mpv/issues/177#issuecomment-62...

> some random dude coming to my repos expecting I implement whatever they ask, or else be called a dick.

If that’s what you took from that discussion, I sincerely recommend you take a break. You may be experiencing burnout. It’s of course your choice to not implement something you don’t want in your project, but let’s not pretend everyone making a request, especially people who have shown research are dicks out to get you.

I tell you this as fellow open-source maintainer. I’ve learned over the years that if people opening issues are a frequent source of frustration, the first step is to investigate how I can make that less of an issue (e.g. using a GitHub template that forces a specific kind of action) and secondly realise that I need some distance and to relax. When you feel like everyone is an asshole, it’s probably just you.

By the way, that maintainer in particularly was known for lashing out at the smallest things and being rude unprovoked. Perhaps consider reading more of the history before calling them your soulmate.


No man, you don’t understand. I take every step possible to avoid people opening issues, they just either disregard the 4 steps between the problem and the GitHub issue, or just come out swinging saying I should just implement it “because many people want it” or I should suggest an alternative. My issue template specifically says “do not request this feature” and they still delete it and request it.

I have no patience for people who are assholes and you shouldn’t either. They’re blocked on sight and that’s how I deal with them.

You say “unprovoked”, I see people completely disregarding my wellbeing by telling me how to spend my free time and how to design my product.

> Perhaps consider reading more of the history before calling them your soulmate.

I don’t need to judge a person by his whole life, I’m just talking about that specific issue as it matches my experience as described above.


> My issue template specifically says “do not request this feature” and they still delete it and request it.

If they can delete it, that’s the first problem you should fix. Don’t use the old style of GitHub templates where it just dumps a bunch of prewritten text. Use the modern style with the YAML template that makes a GUI form.

You can have mandatory checkboxes which say “I am not requesting [feature]”, with a link to some other document explaining why something won’t be implemented. Add another with “I understand my issue will be closed without review and I will be blocked if I don’t follow this guide”. Finally, disable free-form issues. Only allow people to go through the templates.

> You say “unprovoked”, I see people completely disregarding my wellbeing

I thought it was pretty clear I was talking about the maintainer from the issue, not you. I don’t know if you were unprovoked or not, I know this maintainer wasn’t.

> I don’t need to judge a person by his whole life

In general, sure. But when calling someone a soulmate… That implies a deep level of connection, not one event.

Anyway, could you clarify exactly in which way you see the people in this issue being assholes, particularly before the maintainer arrived and closed the issue without even beginning to understand the request?

> No man, you don’t understand.

I maintained large open-source projects you definitely heard of, and today continue to have to deal with these kinds of requests daily. If you think the initial requests in this issue are enough to call these people “assholes” and that they’re being disrespectful to the maintainer’s well being, I maintain you should take a break. One of the signs of burnout is seeing every little comment as a personal attack. I know, I’ve been there. Stop accepting requests and take a vacation from it. Or even stop entirely. Have empathy for yourself and regain empathy for others. I wish you the best.


> that’s the first problem you should fix.

But you see how this is a battle against stupid people? I also had checkboxes before for other issues, people still blindly check them.

There is no winning. If people insist that they’re right and that I’m rude for closing the 25th issue that, ahem, reading 5 words would have avoided, I just block them and move forward.

> seeing every little comment as a personal attack

I’m patient when people open duplicate issues because they couldn’t find them, but this is different.

Imagine you’re talking to someone in person and you tell them “please don’t eat the cake” straight to their face, 4 times on the way to the kitchen. Then 5 minutes later they yell at me asking why the cake tastes like cardboard and glue.

Is that not completely disrespectful? I very much doubt you’ll think of them highly after that accident, unless they’re 5 year olds.

> in which way you see the people in this issue being assholes, particularly before the maintainer arrived and closed the issue without even beginning to understand the request?

I was talking about my own experience. As for him, it’s clear that he did understand the issue and he did not agree that it should be part of the player, for several reasons he then went on to explain.

I also get why one would want a player to also be able to cast videos, but then his suggestion to just use libmpv in a caster app made complete sense.


For entertainment purposes, I’ll give you another example of someone I encountered on my repos.

One guy opens 2 extremely long and conversational issues describing how my software is really ugly and it should be more like other software. Then went ahead suggesting that the other developer hasn’t updated his software for a while because he got lazy (their words), so I should just rip his code and improve it, disregarding mine.

This went back and forth for a while, eventually arriving at the solution they wanted: that miraculous feature I don’t want to implement and that they knew I didn’t want to implement. Closed and locked both issues, so they opened another one.

What am I supposed to do? I said no and you keep saying you know better.

Is it because I’m burned out or because they’re the usual OSS user who has nothing to offer and a lot to expect?


Far from me to defend the whole mpv team[1], but the dev in that thread is a ghost (deleted user). I remember them, they were always rude and eventually got kicked out of the project and loudly complained about “being removed from the project [they] created”. I never found the exact reason why, though I can’t help but think the attitude had something to do with it.

[1] Some are quite nice and competent. Others are exceedingly rude and will e.g. jump on an issue that had thus far been entirely cordial just to, without provocation, insult users for using whatever OS they don’t like.


The last issue that caused them to leave was their desire to move mpv to their own build system, which they believed they could write in a weekend. Other mpv developers thought that was a stupid idea and argued in favor of something more standard, such as meson. That was the last straw for both sides.


> their own build system, which they believed they could write in a weekend.

That doesn’t seem right:

> (…) I started this over a year ago (…)

https://github.com/mpv-player/mpv/pull/7801#issuecomment-641...

> Other mpv developers thought that was a stupid idea and argued in favor of something more standard

That doesn’t seem right either. I just read the whole PR thread and I see a bunch of users arguing for it, not other maintainers.

The maintainer was certainly controversial and I found several commits and bad decisions which look to be almost universally hated, but it’s not clear to me this specific problem was what caused them to quit or that it was motivated by other maintainers.

If you could provide a source for your claim, it would be appreciated.


This isn't remotely similar. Nowhere is the MPV developer ( wm4) being unreasonable in that thread. And while wm4 was not exactly known for interpersonal skills, he was rarely wrong unlike Remi in this case in claiming things to be impossbile when they are not.


Quote from that thread:

> It can be added in theory, but there would be certain problems. Like said earlier codec frame access is very problematic (I, P and B frames), because in worst case scenario you have to decode about 248 sequential Full HD H.264 frames before you can get previous image (so there will be major LAG).

Having used the 'previous frame' feature in mpv, I suspect this is exactly how it's implemented.


Slightly related: mpv also has excellent backward playing capability! Of course video encodings aren’t optimized for this so it does some work to make the performance reasonable.


This thread is amazing. Thanks for pointing it out.

What's lovely is that it is indeed possible, but not trivial, and you can see Remi is sort of baiting to catch smart talented programmers to the project.

You can see the patience and long term horizon needed to lead a volunteer open source project. Time to study VLC more.

Thanks!


I don't see Remi's behavior in that thread attracting more developers than it pushes away.


Yeah he’s probably playing 5d chess, not just being an ass


> Like said earlier codec frame access is very problematic

Wow. Talk about not understanding the user.


That was an interesting read.

- Great example of letting perfect be the enemy of good.

- Hilarious example of a developer making claims of what users want while ignoring the users in front of him.

- Shows how CoCs can be and often end up being used in toxic ways.

Is Remi the sole active developer or why did no other dev chime in to defuse the discussion?

I'm all for open source projects sticking to their vision and standing up to unreasonable user demands but it really is in your own best interest as a developer to learn to communicate effectively - and keep an open mind for feature requests that sound unreasonable to you and first make sure if you understand what is being asked for.


i wonder why he's such an ass about it, and totally adamant that it's impossible when multiple players already do this fast. ego?


I think technically he’s correct (I haven’t worked on media decoding code, but I understand how common video encoding formats work). If you have a long video with only a single key frame at the beginning then to step back you would need to, starting from the beginning of the video, decode every frame up to the previous frame you wanted to jump to in order to apply frame deltas, also assuming you have some sort of frame counter to determine when you’ve reached the target frame. In the worst case this does require a lot of compute, but this is an edge case if you primarily care about common video formats with normal encoding settings. I assume seeking backwards is also painfully slow on videos encoded in this manner, so why stepping back 1 frame is out of the question when compared to seeking backwards, I don’t fully understand, it must have something to do with precise frame counts being unavailable on some hardware decoders for some formats (and there being no good workaround) so you _may_ not actually go back 1 frame.

I don’t see any reason it couldn’t be supported for a set of formats with reasonable encoding/decoding settings, and provide some error message for other formats if a user attempts to step back, e.g. reverse frame stepping unavailable for current video due to format/encoding/decoding settings.


> video with only a single key frame at the beginning

I've literally never seen a video like that in my life, but I'd still expect it to work. Just decode everything starting from frame 1. My desktop can decode H265 at 1,666 fps. I can wait.

https://docs.nvidia.com/video-technologies/video-codec-sdk/1...


That blows up pretty quickly though? Even a 10 minute video will take in the worst case ~20 seconds to decode at that rate.

Not really an excuse not to have it (since most video wont be encoded in such an insane way), but the developers owe no obligation to users to implement it.


Theoretically. Practically, 10+ minute videos with just a single i frame at the beginning do not exist.


> If you have a long video with only a single key frame at the beginning then

...you can't support the scrub bar efficiently either, so no one encodes video that way.

Typically to go to a frame you find the last IDR frame before it (and in reasonable encodings those are frequent enough) and decode forward until you get to the frame of interest. Doing that every time the user presses the single frame back button really doesn't seem that bad, and neither does holding onto some extra reference images for at least like 1080p frames. (8k video and such starts getting more expensive but maybe even then start doing all some references after the first press of the frame back button in this GOP or some such.)

It's of course work to do, and I'm not super motivated to send them that patch, and there's the question of it it would be merged and maintained indefinitely, but what folks are asking for is technically possible.

> I don’t see any reason it couldn’t be supported for a set of formats with reasonable encoding/decoding settings, and provide some error message for other formats if a user attempts to step back, e.g. reverse frame stepping unavailable for current video due to format/encoding/decoding settings.

Yeah, this. That's likely more or less what they already do with the scrub bar.


> It's of course work to do, and I'm not super motivated to send them that patch, and there's the question of it it would be merged

That's my issue; he calls for people to send patches, but anyone capable of writing such a patch is also probably going to see that he's not positive on the matter, and that his "patches welcome" is really pretty passive aggressive in this instance. At least, that's how it comes off to me. I would expect that, should I submit such a patch, it would simply be rejected on the basis that "it is not a general solution".


I learned this the hard way.

One other team at my workplace insisted that they can’t make their product compatible with our product, because it would take a team and half year. I knew that it’s a lie, but we convinced them to “allow” us to make for them. I finished - alone - in four days.

It was never merged. It was purely political. It was never about whether it’s possible or not.


There's also a middle ground: Painstakingly describe the solution first, along with its downside of not being general in the same way as some of the existing features (I guess for example seeking back 10 seconds) are not, and ask whether a patch implementing this solution would be welcome before implementing it.


Oh, I already tried that, and it didn't work.

https://forum.videolan.org/viewtopic.php?f=12&t=103604&p=407...

I wanted to report a big about VLC's extraordinarily badly designed "Magnification/Zoom" user interface, so first I searched the forum to see if there was any other discussion about it, which there naturally was.

So I painstakingly wrote up an extremely detailed description of a bunch of interrelated bugs related to zooming and how it terribly interacted with other features like rotation, in response to the VLC development team brushing off another user complaining about its terrible "Magnification/Zoom" user interface, and they brushed me off too because they were too lazy to read it.

They told me to just submit a bug report, but I pointed out that I was describing a several interrelated bugs, which would require submitting many bug reports, which they would have known if they had actually bothered to read what I painstakingly wrote in great detail with step by step instructions about how to reproduce the bugs and suggestions for improvements, so I obviously wanted to discuss them all first to see if they were even worth my time submitting multiple bug reports about, or if all my efforts reporting bugs and trying to fix them and submit patches would be a waste of time, brushed off and ignored like they did to the other users who described the bugs and usability problems they were experiencing.

Jean-Baptiste Kempf himself replied "If you did shorter posts, maybe people will read them..."

To which I replied "if you did less arrogant responses to long posts, maybe people wouldn't give up on trying to help you."

And of course most of the pathologically terrible bugs I described are still there, a dozen years later. And Jean-Baptiste Kempf still continues to act that way.

More details:

https://news.ycombinator.com/item?id=41281153

HN user KingMob's post perfectly summarized my discouraging experience from a dozen years ago, about a set of bugs and usability problems relating to the horrible "Magnification/Zoom" interface:

https://news.ycombinator.com/item?id=41280375

>KingMob 5 hours ago | unvote | parent | context | flag | favorite | on: Mpv – A free, open-source, and cross-platform medi...

>It's because the developer is misconstruing a non-technical decision they made as a technical limitation. The commenters are trying to point this out, which misses the reality that the developer probably isn't going to budge from their requirement of universal support.

>That dev's rationalization also sends a signal to any commenter with the technical chops to submit a PR, that it will probably be rejected for not supporting 100% of the codecs. I have no doubt people who could do it, over the years looked at that thread and concluded it would be a waste of their time.

Jean-Baptiste Kempf still continues to act that way, and still hasn't even admitted to those bugs and usability problems, let alone fixed them or accepted patches from anyone else who did. He just discourages qualified developers from collaborating, and brushes off legitimate requests from users who can't code but fucking well know other video players don't suffer from those problems.


To be fair, as a maintainer I also dread walls of text from super motivated people about details to which I assign very low priority. I’m never an asshole about it, though.


To also be fair, to "Painstakingly describe the solution first" absolutely requires a wall of text to enumerate all the multiple layers of interacting bugs, and give step-by-step instructions for reproducing them.

At least I put in the effort to search the discussion group for an existing thread about the problems I had, and contributed to that thread by supporting other users and validating their complaints, instead of opening yet another redundant thread.

The reason I went into so much detail was that the VLC developers were ALREADY acting like assholes by brushing off other people's shorter less detailed descriptions of the same problems, with glib quips like "The holy grail already exists... built in to OS X."

The zooming built into OS X definitely doesn't solve the problems that they refuse to admit exist with their astoundingly terrible "Magnification/Zoom" interface, so I described the problems for their benefit in the same detail I would appreciate in bug reports on my own open source software, in response to their rudely and curtly brushing off other users with the same problems, who don't all have a background in user interface design and software development and writing bug reports.

If the holy grail already exists and solves the problem, then they should REMOVE the horrible unusable "Magnification/Zoom" feature that breaks even worse when you dare to rotate or flip the video, or better yet they should have never allowed that broken "feature" to be merged into VLC in the first place, because of its ridiculously poor design and implementation quality (like drawing and tracking the gui with gigantic fat pixels in un-scaled, un-rotated video pixel coordinates, instead of full resolution screen overlay coordinates, and ignoring the flip/rotation for mouse tracking so you can't see what you're pointing at, which is negligent and insane).

Ironically, VLC accepting and distributing features like the "Magnification/Zoom" interface certainly undermines their arguments that they don't want to accept other patches because of quality and reliability and usability issues. If they refuse to fix it, they should remove it instead, it's just so bad.

And if I didn't bother going to the effort of describing the problems in detail with step-by-step instructions to reproduce them, I'm afraid that Jean-Baptiste Kempf is so thin skinned and arrogant that he would have brushed off my bug report for that reason too. Just like he CONTINUES to rudely and passive-aggressively brush off and ignore other people's perfectly valid bug reports to this day, 12 years later. He's not going to suddenly change.


that's still a whole lot of yapping that as an end user I don't care about. i can frame scrub forwards and backwards in multiple other apps. right? very weird response from the vlc team in that original thread.


The back and forth in itself feels so weird to me, with so many hurt feelings:

- the devs expressed in no uncertain terms that they don't want to do it (the first answer is just perfect)

- every third comment is about "we know you don't want to do it, but as users why should we care ?"

Well, if you don't care about the devs, on what base are you asking them to care about your specific problem ?


> Well, if you don't care about the devs, on what base are you asking them to care about your specific problem ?

Caring about the user's requirements is part of the dev's job description. Caring about the dev's... anything is not in the user's job description. (one advantage commercial software has: it really does help when there's an interface between the dev and the user in the form of customer support. or a commercial incentive to actually work on what the user wants.)


> job description

Money getting involved would indeed simplify the question.

Here no money is changing hand, so coming up with an angle that's motivating enough for the devs is IMHO the only option. Either bring up an aspect they're not considering that changes the equation for them, or come up with a solution that isn't plaggued by the issues they are afraid to deal with.

That's where I see listening to the devs and caring about their issues to be the only path forward, short of contributing as a dev oneself..


> Caring about the user's requirements is part of the dev's job description.

For OSS project, it's better to assume that the user persona for the software is the devs or the maintainers. The dev-user relationship you expect is actually the vendor-client in commercial software.


> I think technically he’s correct (I haven’t worked on media decoding code, but I understand how common video encoding formats work).

He’s technically simply wrong (I have worked on media decoding code, hell I’m working on a related project today). His player supports seeking back by 10 seconds or whatnot, but he insists that somehow to implement precise seeking to the previous frame, you need to seek from the very beginning of the video, no two ways about it:

> There is not a slight technical difficulty. On a logical level, this feature is algorithmically impossible, except for the extreme: You can decode all frames up to the previous one. But this would be far too slow for anything except really short videos.

It’s obvious bullshit, if you encounter one of those pathological videos (that don’t really exist except in his mind or in some test suites) you just give up after a reasonable amount of time, same as how you give up if you can’t seek back ~10s in a reasonable amount of time.

And players do give up seeking all the time already, not just on these hypothetical one-I-frame-per-hour videos, but real world videos with messed up pts/dts with no reasonable way to go back a short interval.


Wouldn’t creating in-memory key frames for every nth frame resolve substantial computations on a frame-by-frame basis?


There is no reason to start caching previous frames until AFTER the user has paused and pressed the "back frame" key. Only THEN does it need to rewind to the previous i-frame and re-render and cache frames. And there is no measurable cost to remembering the timestamp of the last i-frame, so you know where to rewind to.


you'd have to "rebase" all the other frames to be derived from those


You wouldn't have to any more than you need 0 through N frames in memory to calculate frame N+1. Whatever your decoding state completes at frame N can be considered a key frame.


decoding state can be bulkier than a key frame and opaque to the CPU if hardware acceleration is used

I wonder if caching semi-compressed frames would be more efficient in either case (CPU or GPU)


It doesn’t have to be every frame though. Pre calculate to 25%/50%/75%, then as I’m playing, save key frames for more incremental points, and if I start scrubbing, calculate more around that region.

Edit: this doesn’t have to happen synchronously either, it can occur in a background thread or passively.


Or in the less-than-worst case you could cache the created full frame if no native full frame is encountered for X seconds and then in the worst case you don't have to go to the beginning of the video, but to that cached intermediate full frame?


all that's correct, but it's besides the point since other players are able to do this.


As outlined in some other thread, mpv is not able to stream eg to ChromeCast, unlike VLC. Maybe VLC supports certain things that make the previous-frame thing harder. I suspect it is so, but I don't have insight into the detailed architecture of VLC, unlike I assume the VLC developers. Do you?


Why is their architecture making it harder on them relevant to the question if it's possible? Because the root question is if it's possible, and there's multiple existence proofs that it's possible. Maybe the VLC developers are just tired. I don't blame them. They had to do a whole refactor to get Chromecast support working, and they got no thanks for that. Or maybe it just wasn't enough thanks and they don't feel like doing another refactor. Chromecast support is quite tricky, I've dug into the protocol.

Anyway, I'm not in control of their development, I'm just pointing out that seeking backwards is possible.


He mentions in the thread that he had to delete posts offensive to the developers. Maybe that's why?

In fairness to him, he offers the posters an opportunity to propose a technical solution and responds to all the posts that do it. It is interesting that nobody in the thread went to check in the code of mpv, smplayer, etc. to see how it's done there. Surely this would be the best response to his request for technical suggestions?


> It is interesting that nobody in the thread went to check in the code of mpv, smplayer, etc. to see how it's done there. Surely this would be the best response to his request for technical suggestions?

Maybe because these users just can't code?


> Maybe because these users just can't code?

It would be still interesting that the intersection between the set of users who claim on this forum it's possible and the set of users who can code is empty.


The users noticed that other players can do that, so it wasn't hard to deduce this is possible. You don't need to know how to code to notice that someone, somewhere had done something


I haven't looked into any claims or followed these links, so I don't know what the limitation is.

But abstractly, it's absolutely possible to write a program that decodes frame at a time and displays them slowly.

Now, whether there is some architectural difficulty based on design decisions within their player, or any player, I don't know.

Edit: I guess downvoters have never worked with a video decoder api before? I just read the link and it seems like the rationale is to not seek one frame backwards because you'd have to seek to a key frame and waste some work? That's not the same as it not being possible.


He also accuses other users whose (benign) posts weren't deleted of CoC violations so I'm not going to assume his judgement for deletion was reasonable unless I see the deleted posts.


> He mentions in the thread that he had to delete posts offensive to the developers. Maybe that's why?

Maybe. As those posts have (allegedly) been deleted, it is now impossible to say. It seems probable though. I do find it interesting that he didn't delete the post, spewing actual verbal abuse at the people who dared to propose possible solutions in good faith.

> It is interesting that nobody in the thread went to check in the code of mpv, smplayer, etc. to see how it's done there. Surely this would be the best response to his request for technical suggestions

He has flatly ignored and refused to address, that these other players can do this at all. He makes only mention of "video editors". Well, and YouTube -- cherry picking the easiest case to attack (on grounds of single file format).

At the end of the day, what he needs is an algorithm, which can then be applied against the VLC codebase. For example:

* track timestamp of latest keyframe

* track nframes since latest keyframe

* optionally, keep some sort of unique id to positively identify this keyframe

- now, scrub back to last keyframe (if time accounting is sloppy for this format, overscrub by some amount, the run forward to the keyframe. If overscrubbing is significant, this is where you could compare the keyframe against the reference, to ensure you aren't way far back and needing to run forward further)

- okay, you've found your keyframe; advance (nframes - 1)

- profit

If he comes back and says "that's not fully general", that's true --- but the people asking for this don't care if it's fully general; it's suitable for common use cases and that's what they want. Let it work where it will work. Give up where it won't.

If he comes back and says "sure, that could work, but I don't have time, send a patch", well, okay, that's understandable.

What's actually happening is he's coming back and saying that won't work at all, that it won't support the majority of cases, will take too much compute, etc. and that's just flat out not true. You can do it selectively for the common cases. He might not want to, but that's different from can't.

Like, consider a scenario where you're playing back realtime video over a network connection. You won't necessarily be able to seek forward in that scenario -- you might not have enough video buffered, or hell, the connection could be plain interrupted. Imagine if they just didn't implement forward seek because the solution could not be fully generalized...

And who is going to spend time coding such a thing up, knowing that it is likely to be rejected as "not fully general"?


From what I can see, he's neither an ass nor adamant that it's impossible. He claims it's impossible to universally support the jump within certain technical constraints (which VLC supposedly limits itself to).

The only time I saw him being unpleasant in the thread is when people ignored his explanations and acted very entitled. Correct me if I'm wrong on anything here, but VLC is an independent free software project developed in no small part by volunteers; they have every right to choose their technical direction and compromises, and it seemed the people insulting them were in no position to demand anything from them.


To do this well you need to keep the old frames around...or go back to the previous keyframe and re-render. That might be hard if your design is playback-optimized.


Re-rendering shouldn't be hard, it's just a specialized version of seeking. VLC has seeking.

The claim that you would have to decode all previous frames in the entire video is... completely baffling to see coming from the dev. He's arguing a stupid technicality that a video might not have keyframes. That's not a reason to omit the feature entirely.


The strange thing is that the same argument is true for seeking in general.

Going back from frame 500000 to frame 499999 is in the limiting case as complex as seeking from 1 to 499999, and in most cases far better.

I think the forum thread would be better answered "you do it, I don't need this feature" which is basically the gist of it and is a completely fair answer.


It's not even about doing it, once added you have to maintain it, and then tomorrow a new format arises that makes this more a hassle, or some memory issue in an existing format is fixed in a way that changes it's memory profile and now VLC will crash with an out of memory.

Seriously, I don't get these people that have infinite demands from open source developers and contribute zero.


It's because the developer is misconstruing a non-technical decision they made as a technical limitation.

The commenters are trying to point this out, which misses the reality that the developer probably isn't going to budge from their requirement of universal support.

That dev's rationalization also sends a signal to any commenter with the technical chops to submit a PR, that it will probably be rejected for not supporting 100% of the codecs. I have no doubt people who could do it, over the years looked at that thread and concluded it would be a waste of their time.


If someone really wanted to do it they will be contributing already continually and at some point start working on this with the expectation that they are the one maintaining it. And it would be fine because by then developers would already trust that person since they've been reliable.

It's not about "technical chops", it's about being constantly available, reliable person that shows to contribute day after day. If you don't do that why should a dev make the scope of their work bigger if they won't be able to keep putting the same quality of work?


> why should a dev make the scope of their work bigger if they won't be able to keep putting the same quality of work?

They shouldn't...but that's not at all what the primary developer said.

The issue is the primary dev seems to require reverse seek functionality to work with all codecs, and since some obscure codecs can't efficiently support it, they're not interested. Their challenge to others to submit a PR is counteracted by all the signs that they might provide a high-to-impossible barrier to approval.

It's not clear that even a trusted contributor would be able to sway this person's mind. Most likely, contributors either agree, or keep quiet on the issue if they disagree.


It's telling that there is no other VLC developer commenting in that thread - neither to support the decision and calm things down nor to go agains Remi's decree.


You already have to maintain seeking code, stepping back one frame is just a specialized case for your seeking code.


You already have to maintain code for seeking by time. There's not necessarily any easy way to convert between time and frame count.


VLC knows the timestamp of the current frame. From that information it can seek to a frame that is before the current frame, possibly by just subtracting the inverse of frame rate from the current frame's timestamp and if seeking to that time results in seeking to the same frame, try again a bit older.

I'm relatively sure this can be implemented in terms of timestamp-based seeking. Quite possibly the metadata of the frames is already in the memory, further simplifying the process.


> just subtracting the inverse of frame rate from the current frame's timestamp

Variable frame rate (VFR) videos break this approach. It might seem like an esoteric edge case, TV and movies aren't VFR after all, but VFR is extremely common in videos from smartphones.


> TV and movies aren't VFR after all

There are TV shows that have telecined film segments and also interlaced VFX sections. While this wasn't broadcast as VFR the best way (as in highest quality result) to convert to a fully progressive frame sequence for display on modern displays would end up recombining the two fields for telecined segments (keeping the framerate) while doubling the framerate during deinterlacing for the VFX segments.

But VFR is also irrelevant to the problem at hand since it doesn't make it harder to find the next keyframe before the current frame - you need an index for that anyway.


This is why I also suggested a fallback in case it lands up in the same frame, but yes, it also needs checking that the next frame is indeed the original frame.

I expect it to work unless the frame rate is wildly varying, e.g. 60 fps and 60 spf in the same video. I guess one reasonable use case would be video that's triggered by motion, though. It would still work for almost every video.


You misunderstand. The point is you have to go backwards to find a keyframe, then render forwards from that.

Going backwards might be hard because if you structured your code in certain ways you may not be able to go backwards efficiently. You can "seek", but how far back to you want to seek? A second? Two seconds? current-X frames?

key frames may be in a standard cadence, but they may not be. So again, how far back do you seek to go back one frame? And keyframes may be abstracted away from the player itself, since really, the codecs are the ones that deal with that stuff. For example, I believe mjpeg doesn't do frame differencing (I'm probably wrong about that).

The ideal implementation would save the last X frames then re-render once you go back like X/2 frames. But again, it depends.


I don't misunderstand. The program already has seeking code, and if it needs to aim back slightly so that it can be more precise that's not a massive change to how it already works.

Efficiency is not as important as having the feature at all. "Go back 5 seconds and then run forward to the right frame" is a sufficient algorithm, as long as it can track and combine multiple presses of the previous-frame key. Improvements can come later. Maybe buffering, maybe tracking keyframes, maybe other things. But this is a big case of letting the perfect be the enemy of the good.

If it fails to find a keyframe, that sucks, but 99% of the time it'll work.


Since I can drag the bar backwards in VLC and have it resume playback apparently this is already implemented? This would be a very narrow use of that.


yeah that's a weird edge case that's not really worth considering. it's obviously something that can be done technically even if some edge cases are not performant.


Again: There is no reason to start caching previous frames until AFTER the user has paused and pressed the "back frame" key. Only THEN does it need to rewind to the previous i-frame and re-render and cache frames. And there is no measurable cost to remembering the timestamp of the last i-frame, so you know where to rewind to.


Just a ridiculous idea, could a reversed version of the video be kept around so that if you hit frame backwards it's frame forwards operation on the reversed video so you can show that frame, if you continue playback the head goes to the closest second of the forward video


This would require completely re-encoding the video or keeping all decoded frames around. This is what he referred to as the "unbounded memory" solutions.


That makes sense, thank you!


i can imagine how it would be annoying in a system that is designed to process live streams as opposed to one that is designed to have random access to the stream via persistent storage.

if the target frame were not an i frame, you'd have to dig up the preceding i frame and replay everything up to the target frame. pretty easy for random access, not so much for a monotonic stream of frames.


That is one funny, informative read! Although, the first response, I feel, aught to have been 'non'. I can hear it now.


That guy sounds like a nightmare to work with.


I have ran into this issue as well. I believe my solution was to use pot player but i am not sure if its open source


Wow, reading this now very old discussion makes me cringe a little bit when I see dingers like these:

    > If you think it is easy, VLC is open-source: you are welcome to provide the easy patch. Somehow, I won't be holding my breath.

    > If it's so easy, why are you not doing it? Talk is cheap.

    > I'll be waiting for your patch. Surely you're not as lazy and incompetent as the existing volunteer developers.

    > And I don't take moral lesson from an hypocrit who feels like they can demand work from "toxic" volunteers and even state that they are not there to do any actual work.
There are so many (passive-)aggressive comments in that discussion. This is the primary reason why I never get involved with open source projects any more. The discussions are so toxic. I always wind up feeling terrible about myself after "trying to help" an open source project by reporting bugs or submitting patches to fix bugs.


What really sucks ass is mpv doesn't have features to show what the frame count of the frame you're looking at is.


You can press e to frame advance. Can't go back though.


Goat




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: