Interesting read, it’s a shame the ranty format makes it 3x longer than necessary.
Not sure why it takes a dump on VLC - it’s been the most stable and friendly video player for Windows for a long time (it matters that ordinary users, like school teachers, can use it without special training. I don’t care how ideological you are about Linux or video players or whatever lol).
> where I expect the exact same look and feel regardless of the underlying OS
Slightly ironic, as I think a new UI is underway (and coming soon?). Not sure what version it's planned for, but I think some beta has it enabled by default already, was surprised when I saw it. So the consistent UI is here today, and will be in the future, but there will be a slice of time where different users will run different versions where some switched to the new UI, and some haven't. But it'll hopefully be a brief period, and of course it's still cross-platform :)
No it doesn't, its Wayland support is a mess, its codec support is lackluster, and somehow the experience is worse when you use VA-API hardware decoding.
I don't believe it's the case anymore, but it was very common for VLC to cause video corruption (see [1] for example of what it looked like) in the past, the hate just stuck around and I don't think it's ever going away.
In the anime fan subbing community (which this document is likely from), it's very common to hate on VLC for a variety of imagined (and occasionally real but marginal) issues.
At least for the real part there was the great 10-bit encoding "switch off" at around 2012 where it seemed like the whole anime encoding scene decided to move into encoding just about everything with "10-bit h264" in order to preserve more detail at the same bitrate. VLC didn't have support for it and for a long time (+5 years?) it remained without proper support for that. Every time you tried playing such files they would exhibit corruption at some interval. It was like watching a scrambled cable channel with brief moments of respite.
The kicker is that many, many other players broke. Very few hardware decoders could deal with this format, so it was fairly common to get dropped frames due to software decoding fallback even if your device or player could play it. And, about devices, if you were previously playing h264 anime stuff on your nice pre-smart tv, forget about doing so with the 10-bit stuff.
Years passed and most players could deal with 10-bit encoding, people bought newer devices that could hardware decode it and so on, but afaik VLC remained incompatible a while longer.
Eventually it all became mutt because the anime scene switched to h265...
8-bit and 10-bit almost give digital video too much credit. Because of analog backwards compatibility, 8-bit video only uses values 16-235, so it's actually like… 7.8 bit.
It's nowhere near enough codes, especially in darker regions. That's one reason 10-bit is so important, another is that h264 had unnecessary rounding issues and adding bit depth hid them.
Mostly that VLC has had noticeable issues with displaying some kinds of subtitles made with Advanced SubStation (especially ones taking up much of the frame, or that pan/zoom), which MPV-based players handle better.
Note that, while I haven't had time to investigate them myself yet, IINA is known to have problems with color spaces (and also uses libmpv, which is quite limited at the moment and does not support mpv's new gpu-next renderer). Nowadays mpv has first-party builds for macOS, which work very well in my opinion, so I'd recommend using those directly.
He's talking about using VLC for transcoding or encoding, where the functionality has lots of issues and is kind of bolted on the side. VLC for playing is totally fine.
No it isn't, VLC plays everything back slightly incorrectly in all sorts of ways, the subtitle rendering and colorspace handling isn't compliant at all.
One difference I can immediately point to is that VLC always renders subtitles at the video's storage resolution and then up/downscales all bitmaps returned by libass individually before blending them. This can create ugly ringing artifacts on text.
I've also seen many reports of it lagging or choking on complex subtitles, though I haven't had the time to investigate that myself yet.
Either way, it's not as simple as "both players use libass." Libass handles the rasterization and layout of subtitles, but players need to handle the color space mangling and blending, and there can be big differences there.
Follow-up comment: I love how the author’s one brief take-down shot at VLC is currently the dominant criticism in the HN comments (inc. mine). 10,000+ words and the entire lot is being questioned because of one dubious throwaway comment about VLC.
There was an article[1] yesterday where a single poor word choice derailed much of the comment section with rat-holing and nitpicking until the author revised the article. HN's gotta HN.
If you're talking about the use of the word "hover", I think that was quite justified, given that it was a critical element of the claim, and the poor wording made it neigh impossible to reproduce the author's claim.
It seems to me he’s talking about using it for re-encoding/conversion as part of your editing workflow and is not really talking about its media playback capabilities. In that sense he is very much correct.
Not sure why it takes a dump on VLC - it’s been the most stable and friendly video player for Windows for a long time (it matters that ordinary users, like school teachers, can use it without special training. I don’t care how ideological you are about Linux or video players or whatever lol).