I'm also surprised by people's defense of VLC. It's a nice project, especially when it was created, but the bugs I regularly encountered were numerous and in seemingly common use cases.

Here's a post I made 4 years ago describing each bug, shortly before switching to MPV: https://www.reddit.com/r/VLC/comments/pm6y1n/too_many_bugs_o...

> It is the Firefox of media players.

So... the better option?

MPC-HC is still a thing? I remember installing that (and K-Lite Codec Pack) on Windows, back in the day. Haven't used, or even thought about MPC-HC in years.

I've really felt gaslit over the last decade from people continuing to promote VLC as such a great thing, when I've had nothing bug bugs, crashes, glitches, issues with it for a full decade now (on Linux). From 10-25 years ago I definitely used it for everything, all the time, but now even the default Ubuntu totem video player (or whatever it's called) seems like 2-3 times as likely to be able to play a random video file without an issue as VLC does.

Thanks, I didn't realize the situation was so dire.

MPV is not user friendly, but I was very impressed by the gapless playback.

Honestly the pastebin link needs to be re-submitted and frontpaged.

I even encounter this in professional a/v contexts! If VLC can read and decode your stream, that's a good sign that most things should able to view it, but it absolutely should not be trusted as any measure of doing things correctly/to spec.

I did recently see someone compare mpv and vlc on a 8k HDR @ 60fps file with mpv really lagging while vlc doing it fine. I could confirm the mpv lags but don't have vlc, so not sure if it's just better in that specific case or did something like no actual HDR

> It is the Firefox of media players.

Ironically, my main gripe about Firefox is that it has no support for HDR content and its colour management is disabled by default… and buggy when enabled.

Many HN readers won't be familiar with the fansub culture that this writeup originates from, so sharing a helpful resource in case anyone is interested in learning more:

ENTRY LEVEL FANSUBBERS' BEGINNERS GUIDE:

https://github.com/zeriyu/fansub-guide

Hope this helps anyone interested in the ancient art of subbing Japanese animes!

Be sure to read every link thoroughly, and don't worry, there are more link lists linked from the above link list.

Arigatou gomenasai!

Knowing nothing about video stuff my only question from this is: what's wrong with Firefox?

It works well enough, and I doubt the majority of VLC users are watching anime with it.

Yeah, as far as I know, to understand video formats, you need to understand encode-decode process, how film/video editor operate normally (keeping in mind film/video editing has levels from $100s to way beyond me), history, how optics and cameras work, etc. Then particular choices and confusions can be understood.

This indeed just seems to jump-in in the middle and give a bunch very specific recommendation. I have no idea if they're good or bad recommendations but this doesn't seem like the way to teach good procedures.

And? It’s a GitHub gist not an oreilly book. Context.

Exactly, very hard to take the rest of it seriously after the VLC bit. VLC has literally never left me hanging, across I don't know how many decades. It's gonna take more than a trust me bro to challenge that.

technically correct is the best kind. who cares if it's obnoxious? take the opinions and agree or disagree with them.

VLC works great on Linux too! It's one of the few programs where I expect the exact same look and feel regardless of the underlying OS.

mpv is okay but its complete reliance on command line flags and manually written config files makes it a bore.

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.

[1] https://www.reddit.com/r/glitch_art/comments/144vjl/vlc_star...

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.

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.

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.

A lesson to learn in that.

Lol

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.

>It was notorious (to the point of it being a popular meme topic) for [...] having very little format support out of the box

???

I thought the meme was that it played basically everything? At least compared to windows media player or whatever.

The other items I can't say I've noticed, but then again I only play the most common of files (eg. h.264/h.265 with english subtitles in a mkv) so maybe it's something that only happens with unusual formats/encodes.

edit: based on other comments (eg. https://news.ycombinator.com/item?id=46465349), it looks like it might indeed be caused by uncommon files that I haven't encountered.

What year was this? I don't know there has ever been a normal format it doesn't support, and I think this has been the case for at least 15 years.

I've never had problems with VLC, and I've used it off and on for 20 years.

I don't doubt that there's some obscure, elite videophile hate towards it, but I'm hardly going to stop using it because a few random internet strangers hate on it.

For a long time it was the only graphical user-friendly option for non-technical Windows users that had decent support for a wide range of formats. I don’t know about its early years, but friends, family and I have been using it for a good 15+ years without encountering the issues folks are describing in these comments.

It seems there’s a lot of open-source lovers that haven’t also accepted that bugs can get fixed, projects can improve, etc. They’d rather treat a project as though it was stuck at version 0 from 20 something years ago. Deeply ironic.

Agree. Never mind how far they were behind on the more power user options like scaling, dealing with mismatches in video framerate and monitor refresh rate, etc.

Havent used it in ages, but a decade ago it felt a joke for all the video artifacts and subtitle glitches.

The one part that does get me some about people who blindly still praise it as THE video player at least outside of more technically inclined spaces like this, is so many people assume it exists as some monolith. Clearly library free, entirely the original work of VideoLAN, gracious they be that they give it all away for free.

| I assume nowadays it's much better...

It's not, but the Linux weenies won't hear of it. Maybe it's a great choice on Linux, but on Windows, it often renders things much worse than stock WMP (both legacy and modern). Videos with a lot of motion play especially poorly.

But, yeah, it opens everything.

Do you have sources for that? As far as I know VLC has actually always been famous for supporting basically every format.

remux vs reencode itself is a big point for video noobs such as myself.

in the past, cropping out a part of a video would meant reencoding it in some random preset. this would often take longer than required. however, accidentally realized the difference when trying out avidemux [1] and clipping together videos blazing fast (provided in same container and format)!

[1] http://fixounet.free.fr/avidemux/

Can't mind read the guy obviously, but the usual motivation that I'm aware of is that you pretty much fuck over everyone else that comes later. Upscalers improve over time, but in terms of distribution, recency bias is strong and visual treats are inviting. So when those much better upscalers eventually come around, what's more likely to still be available is the secondary source you distributed, which is already upscaled once with a then-inferior upscaler. This leads to a form of generational rot.

Other likely explanations are:

- them not liking how these upscalers look: you can imagine if they can nitpick minor differences between different encodes that most people don't notice, they'll hate the glaring artifacts these filters usually produce

- boycotting AI

Topaz looks bloody awful. Instead of big blocky upscaled pixels you've got weird artifacty "oil painting effect" smeary blobs.

[flagged]

Some of the simple tools might not be using ffmpeg per se, but using the libav or similar libraries. ffmpeg is just a tool built to utilize the functionality of multiple libraries like this.

> to fastidious

Do you mean "too fussy?"

The keywords you're missing are color spaces and gamma curves. For a given bandwidth, we want to efficiently allocate color encoding as well as brightness (logarithmically to capture the huge dynamic range of perceptible light). sRGB is one such standard that we've all agreed upon, and output devices all ostensibly shoot for the sRGB target, but may also interpret the signal however they'd like. This is inevitable, to account for the fact that not all output devices are equally capable. HDR is another set of standards that aims to expand the dynamic range, while also pinning those values to actual real-life brightness values. But again, TVs and such may interpret those signals in wildly different ways, as evidenced by the wide range of TVs that claim to have "HDR" support.

This was probably not the most accurate explanation, but hopefully it's enough to point you in the right direction.

> Naturally, we can stick brighter backlights in our monitors to make the difference between light and dark more significant,

It's actually the opposite that makes the biggest difference with the physical monitor. CRTs always had a residual glow that caused blacks to be grays. It was very hard to get true black on a CRT unless it was off and had been for some time. It wasn't until you could actually have no light from a pixel where black was actually black.

Sony did a demo when they released their OLED monitors where they had the top of each monitor type side by side: CRT, LCD, OLED. The CRT was just gray while the OLED was actually black. To the point that I was thinking in my head that surely this is a joke and the OLED wasn't actually on. That's precisely when the narrator said "and just to show that the monitors are all on" as the video switched to a test pattern.

As for the true question you're getting at, TFA mentions things like color matrix, primaries, and transfer settings in the file. Depending on the values, the decoder makes decision on the math used to calculate the values. You can use any of the values on the same video and arrive at different results. Using the wrong ones will make your video look bad, so ensuring your file has the correct values is important.

From TFA: https://gist.github.com/arch1t3cht/b5b9552633567fa7658deee5a...

Do you have a device that supports HDR such as any MacBook in the last 10+ years, any iPhone since iPhone 4, or most high end Androids?

If so, try this: https://gregbenzphotography.com/hdr-gain-map-gallery/

Clicking the "Limit to SDR" and "Allow Full HDR (as supported)" should show a significant difference if you device supports HDR. If you don't see a difference then your device doesn't support HDR (or your browser)

For these images, there's a specific extension to JPEG where they store the original JPEG like you've always seen, and then a separate embedded gain map to add brightness if the device supports it. That's for stills (JPEGs) though, not video but the "on the wire difference" is that gain map

I'm not an expert but for videos, ATM, afaict, they switched them to 10bits (SDR is 8bits), and added metadata to map that 10 bits to values > "white" where white = 100nits. This metadata (PQ or HLG) can map those 10 bits up to 10000 nits.

HDR is nothing more than metadata about the color spaces. The way the underlying pixel data is encoded does not change. HDR consists of

1. A larger color space, allowing for more colors (through different color primaries) and a higher brightness range (though a different gamma function)

2. Metadata (either static or per-scene or per-frame) like a scene's peak brightness concrete tonemapping settinsg, which can help players and displays map the video's colors to the set of colors it can display.

I actually have a more advanced but more compact "list of resources" on video stuff in another gist; that has a section on color spaces and HDR:

https://gist.github.com/arch1t3cht/ef5ec3fe0e2e8ae58fcbae903...

YCrCb can also be better for HDR or not - 4:2:2 vs 4:4:4

if you expand limited YCrCb to a large HDR range you'll get a "blurred" output.

Imaging converting 1 bit image (0 or 1, black or white pixel) to full range HDR RGB - it's still black and white

here you go

> 10 bits per sample Rec. 2020 uses video levels where the black level is defined as code 64 and the nominal peak is defined as code 940. Codes 0–3 and 1,020–1,023 are used for the timing reference. Codes 4 through 63 provide video data below the black level while codes 941 through 1,019 provide video data above the nominal peak.

https://en.wikipedia.org/wiki/Rec._2020

Compare to

https://en.wikipedia.org/wiki/Rec._709

I found this explanation useful:

https://youtu.be/uMSV4OteqBE?si=QCOL_2_VpE7tBdAu&t=83

Do youngins even know why AVI files are under 700mb? I think obsessions over quality/compression are the concern of us aging hobbyist encoders.

Unless one lives in a country where the internet is slow and/or hard drives are expensive, I think the audience does not care.

Yeah, similarly, my DSLR makes some huge video files, but they aren't that much better quality than my phone's. Of course, the sensor is massively better, and that makes a difference, but I don't know why the files are so much bigger.

My hypothesis is that they use a really high quality value, and that there are diminishing returns there.

For all the hate Handbrake gets, it does the job of simplifying video encoding enough for casual users while still allowing for plenty of functionality to be leveraged.

this complication causing people to nope out has made my career. for everyone that decides it is too complicated and is only the realm of experts, my career has been made that much more secure. sadly, i've worked with plenty of video that has clearly been made by someone that should have "noped out"

Yeah, this is a very common misconception. There are hardware encoders that might be distribution quality, but these are (to my knowledge) expensive ASICs that Netflix, Amazon, Google, etc. use to accelerate encode (not necessarily to realtime) and improve power efficiency.

GPU acceleration could be used to accelerate a CPU encode in a quality-neutral way, but NVENC and the various other HW accelerators available to end users are designed for realtime encoding for broadcast or for immediate storage (for example, to an SD card).

For distribution, you can either distribute the original source (if bandwidth and space are no concern), or you can ideally encode in a modern, efficient codec like x265 or AV1. AV1 might be particularly useful if you have a noisy source, since denoising and classification of the noise is part of the algorithm. The reference software encoders are considered the best quality, but often the slowest, options.

GPU is best if you need to temporarily transcode (for Plex), or you want to make a working copy for temporary distribution before a final encode.

You might want to try dumping your work from Resolve out in ProRes 422 HQ or DNxHR HQ and then encoding to h264/h265 with Compressor (costs $; it's the encoder part of Final Cut as a separate piece of software) on a Mac or Shutter Encoder. Also, I'm making a big assumption that you're using the paid version of Resolve; disregard otherwise. It might not be worth it if your input material is video game capture but if you have something like a camera that records h264 4:2:2 10bit in a log gamma then it can help preserve some quality.

Making such a bold, unsubstantiated claim is a curious item in an otherwise detailed document. I went looking for other explanations and found this gem: https://www.reddit.com/r/mpv/comments/m1sxjo/it_is_better_mp...

I think it might be one of those classic “everyone should just get good like me” style opinions you find polluting some subject matter communities.

In the olden times of not working/playing movies (00's) and being a clueless tech support for ppl even more clueless about them computers,

The vlc was how you could get any movie to work (instead of messing with all these codecs, which apparently, in lieu to another comment in this thread, aren't really codecs).

my biggest pet peeve was that VLC was always considered a streamer and treated local files as streams as well. for the longest time, stepping within the video was not possible. reverse play was also a bane as well, even with i-frame only content. i have long found players that are better for me, but still find myself using VLC frequently because it still has features these other players do not.

The core idea of YCbCr - decoupling chrominance and luminance information - definitely has merit, but the fact that we are still using YCbCr specifically is definitely for historical reasons. BT.601 comes directly from analog television. If you want to truly decouple chrominance from luminance, there are better color spaces (opponent color spaces or ICtCp, depending on your use case) you could choose.

Similarly, chroma subsampling is motivated by psychovisual aspects, but I truly believe that enforcing it on a format level is just no longer necessary. Modern video encoders are much better at encoding low-frequency content at high resolutions than they used to be, so keeping chroma at full resolution with a lower bitrate would get you very similar quality but give much more freedom to the encoder (not to mention getting rid of all the headaches regarding chroma location and having to up- and downscale chroma whenever needing to process something in RGB).

Regarding the tone of the article, I address that in my top-level comment here.

I would have also expected at least a passing mention of chroma subsampling beyond 4:2:0 if only just to have an excuse to give the "4:2:0" label to the usual case they mention. And you might run across stuff in 4:2:2 or 4:4:4 not all that rarely.

>Really good quickstart guide

It really isn't. You have to scroll 75% of the way through the document before you it tells you what to actually type in. Everything before (9000+ words) is just ranty exposition that might be relevant, but is hardly "quick".

I was a DVD programmer for 10 years. There was a defined DVD spec. The problem is that not every DVD device adhered to the spec. Specs contain words like shall/must and other words that can be misinterpreted, and then you have people that build MVP as a product that do not worry about the more advanced portion of the spec.

As a specific example, the DVD software had a random feature that could be used. There was one brand of player that had a preset list of random numbers so that every time you played a disc that used random, the random would be the exact same every time. This made designing DVD-Video games "interesting" as not all players behaved the same.

This was when I first became aware that just because there's a spec doesn't mean you can count on the spec being followed in the same way everywhere. As you mentioned, video decoders also play fast and loose with specs. That's why some players cannot decode the 10-bit encodes as that's an "advanced" feature. Some players could not decode all of the profiles/levels a codec could use according to the spec. Apple's QTPlayer could not decode the more advanced profiles/levels just to show that it's not "small" devs making limited decoders.

The issue is encoding is an art, especially as it's lossy. You choose how much data to throw away (kind of like when you pick a quality in JPEG). Further, for video, you generally try to encode the differences between 2 frames. Again, because it's a lossy difference, it's up to the creator of the encoder to decide how to compute the difference. different algorithms come up with a different answers. There result still fits the spec.

Let's just say we were encoding a list of numbers. So we get a keyframe (an exact number) and then all frames after that until the next keyframe are just deltas. How much to add to that keyframe number

    keyframe = 123
    nextFrame += 2   // result = 125
    nextFrame += 3   // result = 128
    nextFrame -= 1   // result = 127

The "spec" or "codec" only defines that each frame is encoded as a delta. it doesn't say what those detlas are or how they are computed, only how they are applied.

This is also why most video encoding software has quality settings and those settings often includely the fact higher quality is slower. Some of those settings are about bitrate or bitdepth or other things but others are about how much time is spent looking for the perfect or better delta values to get closer to the original image as searching for bettter matches takes time. Especially because it's lossy, there is no "correct" answer. There is just opinion.

> And then, not even a very long time ago, the mystery unraveled. What the various codec specifications actually describe, and what these codecs actually "are", is the on-disk bitstream format, and how to decode it. Just the decode. Never the encode.

Soooo with everyone getting used to creative names instead of descriptive names over the past decade or two, I guess "codec" just became a blob and it just never crosses peoples' minds that this is right there in the name: COding/DECoding. No ENCoding.

Thanks for bringing this up, since I'm realizing that I did not explicitly spell this out in the post. I'll add a paragraph making this even clearer.

what if I told you the same issue is true for lossless plain compression like .zip files

the compressor (encoder) decides exactly how to pack the data, it's not deterministic, you can do a better job at it or a worse one

which is why we have "better" zlib implementations which compress more tightly

Did you use a decent piece of DVD authoring software? Here are some options: https://www.videohelp.com/software/sections/authoring-dvd

Handbrake is fine if you truly need to reencode (aka “transcode”) your video, but if you find yourself with a video that your player can’t read, you might be able to just change the container format (remux it) using ffmpeg, copying the video and audio streams directly across.

With video there are 3 formats: the video stream itself, the audio stream itself, and the container (only the container is knowable from the extension). Formats could technically be combined in any combination.

The video stream especially is costly in CPU to encode, and can degrade quality significantly to transcode so it’s just a shame to re-encode if the original codec is usable.

Container format mkv is notorious for not being supported out of the box on lots of consumer devices, even if they might have codecs for the audio and video streams they typically contain. (It has cool features geeks like, though, but for some reason it gets less support.)

If you search the page you'll find a reference to having “numerous foot guns”.

I can't say I've experienced either of the ones mentioned, but I have had trouble in the past with output resolution selection (ending up with a larger file than expected with the encoding resolution much larger than the intended display resolution). User error, of course, but that tab is a bit non-obvious so it might be fair to call it a footgun.

the short version is there's nothing wrong with it for your use case.

The author's POV is that the handbrake is a lossy conversion and often people use it in cases where they could have used a different tool that is lossless.

My uses of handbrake are that I always want a lossy conversion so no issue. A good example is anytime I make screen capture and want to post it on github. I want it to be under the 10meg limit (or whatever it is) so I want it to be re-encoded to be smaller. I don't mind the loss in quality.

the author can't stand how it simply re-encodes videos instead of extracting the video tracks and puts them in new containers.

Oh man it extended well past the 90’s. Finding some weird windows video codec in a dodgy .ru domain was a time honored tradition for quite some time.

I remember all the weird repackaged video codec installers that put mystery goo all over them machine.

The article bashes VLC but I tell you what… VLC plays just about everything you feed it without complaint. Even horribly corrupt files it will attempt to handle. It might not be perfect by any means but it does almost always work.

I usually use a shortcut in mpv to extract the screenshot. If I want to do it via the command-line:

  ffmpeg -ss 00:00:12.435 -i '/Users/weinzieri/videofile.mp4' -vframes 1 '/Users/weinzieri/image.png'

> Is there a way to "undo" motion blur and get a sharp picture?

Not really, no, any more than there is a way to unblur something that was shot out of focus.

You can play clever tricks with motion estimation and neural networks but really all you're getting is a prediction of what it might have been like if the data had really been present.

Once the information is gone, it's gone.

You'll need to settle on a decoder. I personally just use my video player for this, mpc-hc.

In mpc-hc, you can framestep using CTRL+LeftArrow (steps a frame backward) or CTRL+RightArrow (steps a frame forward). This lets you select the frame you want to capture. You do not need to be on a keyframe. These keybinds are configurable and may be different on the latest version.

Then in the File menu, there's an export image option. It directly exports the frame you're currently on, to disk. Make sure to use a lossless format for comparisons (e.g. PNG).

I'm aware this can be done in other players - like mpv - as well, although there I believe no keybinds are set up for this by default, and the default export format is JPEG.

The article defines quality as being as close to the source as possible. AI upscaling adds detail that wasn't there in the first place.

AI upscaling can also be done during playback, to the benefit of lower file sizes, but at the cost of higher processor utilisation. So it is a trade-off.

> If you want to educate, educate with precision, and don't spread your misinformation!

I would assert that the author was already being precise. A statement that X is "sometimes called" Y already conventionally carries the subtext that Y isn't actually the correct term; that Y is instead some kind of colloquial variant or corrupted layman's coinage for the more generally-agreed-upon term X.

Why mention the incorrect terminology Y at all, then?

Specifically in the case that pertains here, where far more laymen are already familiar with the Y term than the X term, giving Y as a synonym in the definition of X is a way to give people who are already familiar with this concept — but who only know it as Y — an immediate understanding of what is being discussed, by connecting their knowledge of "Y" over to the X term the author is defining. This is an extremely common practice in academic writing, especially in textbooks.

Thanks for the "encoder/decoder" correction.

But yes, as the other reply says, I am aware of this distinction, and I make a point not to use the word "codec" at any other point in the article. and explain in a lot of detail how much the encoder matters when it comes to encoding in some format. I mention the term to make people aware that it exists.

But, you're right, I will clarify this a bit more.