Nearly this entire HN comment section is upset about VLC being mentioned once and not recommended. If you can not understand why this very minor (but loud?) note was made, then you probably do not do any serious video encoding or you would know why it sucks today and is well past its prime. VLC is glorified because it was a video player that used to be amazing back in the day, but hasn't been for several years now. It is the Firefox of media players.
There is a reason why the Anime community has collectively has ditched VLC in favor of MPV and MPC-HC. Color reproduction, modern codec support, ASS subtitle rendering, and even audio codecs are janky or even broken on VLC. 98% of all Anime encode release playback problems are caused by the user using VLC.
And this pastebin doesn't even have all the issues. VLC has a long standing issue of not playing back 5.1 Surround sound Opus correctly or at all. VLC is still using FFmpeg 4.x. We're on FFmpeg 8.x these days
I can not even use VLC to take screenshots of videos I encode because the color rendering on everything is wrong. BT.709 is very much NOT new and predates VLC itself.
And you can say "VLC is easy to install and the UI is easy." Yeah so is IINA for macOS, Celluloid for Linux, and MPV.net for Windows which all use MPV underneath. Other better and easy video players exist today.
We are not in 2012 anymore. We are no longer just using AVC/H264 + AAC or AC-3 (Dolby Audio) MP4s for every video. We are playing back HEVC, VP9, and AV1 with HDR metadata in MKV/webm cnotainers with audio codecs like Opus or HE-AACv3 or TrueHD in surround channels, BT.2020 colorspaces. VLC's current release is made of libraries and FFmpeg versions that predate some of these codecs/formats/metadata types. Even the VLC 4.0 nightly alpha is not keeping up. 4.0 is several years late to releasing and when it does, it may not even matter.
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.
It seems really weirdly written. It's written with a lot of authority, like saying "Don't use VLC" and "Don't use Y" yet provides no reasoning for those things. Just putting "Trust me, just don't" doesn't suddenly mean I trust the author more, it probably has the opposite effect. Some sections seem to differ based on if the reader knows/doesn't know something, but I thought the article was supposed to be for the latter.
Would have been nice if these "MUST KNOW BEFORE" advises were structured in a way so one could easily come back and use it as a reference, like just a list, but instead it's like a over-dinner conversation with your "expert and correct but socially-annoying" work colleague, who refuses to elaborate on the how's and why's, but still have very strong opinions.
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.
You're talking about VLC for video playback, TFA is taking about video editing.
VLC ignores a lot for it's outstanding video playback support, which is great if you want the playback too just work... But that's the player perspective, not the editing/encoding
While VLC is excellent at playing every format under the sun, it's not good at playing all those formats correctly. Off the top of my head:
- Transfer functions are just generally a mess but are close enough that most people don't notice they're wrong. Changing the render engine option will often change how the video looks.
- Some DV profiles cause videos to turn purple or green.
- h.264 left and right crops are both applied as left crops that are summed together which completely breaks many videos. They could just ignore this metadata but from what I've heard their attitude is that a broken implementation is better than no implementation.
> Hanging out in subtitling and video re-editing communities, I see my fair share of novice video editors and video encoders, and see plenty of them make the classic beginner mistakes when it comes to working with videos.
Seriously, you quoted pretty much the only sentence in the whole article that's about plain playback, and even in that bullet point, the following sentence mentions hardcoding subtitles.
> It turns out that reading the (f.) manual actually helps a lot!
The non-recommendation of VLC vs mpc/mpv is literally for playback as I quoted! MPC also doesn't do any encoding, yet it's recommended
> the following sentence mentions hardcoding subtitles.
And that sentence starts with "Apart from simply watching the video" to tell you the same thing the previous sentence told you - that comparison where VLC was not receommended was about playback, not editing
Have you tried both? mpv is able to play high resolution HEVC videos backwards at real time by holding the "previous frame" key. VLC can't reliably jump backwards even at second intervals, forget about reverse playback.
I'm not the OP of the claim (and I love VLC) but maybe they're referring to this early 2018 issue: https://trac.videolan.org/vlc/ticket/19723 which seems to be being actively worked on.
How do you know it is technically correct without explanation. It's not much different from someone getting blown off for being annoying because they constantly question simple answers when seeking better understanding. I was fortunate to work with a group of engineers when I was very young that accepted my constant use of "why?" not as disrespectful questioning but realized I was actually learning so they naturally just provided more details leading to less "why?" being asked. This eventually got to the point where I would ask a question, and the answer would be to read a specific book on the shelf. This was way before the internet. I received a better education on the job than I ever was going to get in school.
So no, I'm not just going to take an opinion without more information. I don't change my mind just on say so.
Why?
Is the most simple test of a valid explanation. If you don't need to ask why any more, you've answered the question.
Sometimes it takes 3 or 5 white in a row!
When we switched from x264 to hardware based encoders it saved something like 90% on our customers' power and cooling bills.
So while this essay might be "technically correct" in some very narrow sense the author is speaking with far more authority than they have the experience to justify, which is what makes it obnoxious in the first place.
The author is directing this at complete noobs who are subbing their first anime and you are complaining that it is not applicable to running a datacenter?
This is already mentioned in the article. Software vs. hardware is a tradeoff. x264 produces higher quality (perceptual or compression efficiency) video, at the expense of latency.
It works if you know the person and have a baseline for how much confidence you give their opinions. If it's just a random person on the internet, they need to support their argument.
I mean—they can. They don’t need to give more than they’re already giving we anonymous strangers for free. For all we know, this person wrote this for people they encounter personally or professionally, and we’re just incidentally benefitting.
We as readers should gauge their credibility for ourselves, whether by reputation or by checking the claims. I don’t know who wrote it but it seems basically correct, consistent, and concisely argued to me.
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).
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.
> 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 :)
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.
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...
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.
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.
I bought a new dashcam. It generates .mp4 files. I tried to play them back with my new Roku media player, and it says invalid format. (They will play with Windows media player.)
Grump grump grumpity grump. Same experience with every dashcam I've bought over the years.
I'm always amazed when I see how many people are unfamiliar with VLC hate. It was notorious (to the point of it being a popular meme topic) for video artifacts, slow/buggy seeking, bloated/clumsy UI/menus, having very little format support out of the box, and buggy subtitles. I assume nowadays it's much better, since it seems popular, but its reputation will stick with me forever.
>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.
Up until just last month I had never had a problem with VLC. But I don't pirate content so maybe I just hadn't encountered the problematic files. However, recording voice notes in Opus format on my phone, it turns out that VLC has a bug playing Opus files at certain bit rates. However for me this is easily worked around by just using MPV.
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.
My own anecdotal experience with VLC was that while every update fixed something, they also broke something in return - and these updates were common. This got annoying enough at some point for me to hop ships, and so I switched to mpc-hc and never looked back.
I've since also tried (and keep trying) the to-me still newfangled mpv, but I'm not a fan of the GUI or the keybinds. I know it can be customized, but that's not something I'm interested in doing. I know there are alternative frontends as well, but I checked and they're not to my liking either. So I mostly just use it for when mpc-hc gives out, such as really badly broken media files, or anything HDR.
Out of pure curiosity, what kind of things were you VLC using for, for it to break so often? I'm almost never doing anything with video, so I'm completely clueless in this field.
I don't recall my issues being media file or workload specific [0]. It was specifically just general frontend stuff I believe [1]. Although I should probably also mention that I don't remember much to begin with, other than my decidedly negative conclusion that made me switch players, and the overall personal narrative around that. It's been quite a few years if not a whole decade.
[0] Doesn't mean there weren't any, but then I was not doing anything special. Just watched anime, listened to music, streamed YouTube. Hardly an extraordinary workload for VLC, or indeed any media player in general.
[1] I remember them changing around the volume slider widget back and forth ad nauseam for example, and that becoming in some particular way defective that I cannot recall.
You should make up your own mind. why bother reading comments at all? why bother reading reviews? I bet you watch every movie and never comment on how good or bad they are because you'll be telling everybody else what to do and that would be hypocritical. I wonder how you stumbled upon VLC in the first place - perhaps you read about it somewhere and followed that advice?
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.
Shameless plug for anyone that wants to go deeper on specific video topics: I've been organizing a conference for video devs for 11 years now and there's a wealth of info in the recordings. A talk from the most recent one on hacking a Sega Genesis to stream video might not seem that practical, but there were some fascinating bits on compression (or, rather, not being able to use actual compression). https://www.youtube.com/watch?v=GZdxdpw-3nI
If folks want to get involved, there's also a chat community that's pretty active: https://video-dev.org.
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
If someone has anti-AI opinions and spends zero effort explaining their position, I assume they have "AI Derangement" [1], a hate/fear perpetrated by the Big Scare media and podcasters seeking like/subscribes.
You can spend a tremendous amount of time using these tools to accomplish pretty stunning results already:
- https://www.youtube.com/watch?v=FAQWRBCt_5E - Created by a Hollywood TV writer for an FX show you've probably seen. Not the best animation or voicing, but you can see how it gives a writer more than just a blank page to convey their thoughts.
- https://www.youtube.com/watch?v=tAAiiKteM-U - Made by a film school grad as a Robot Chicken homage. If you're going to tell them "don't use AI", then are you going to get them a job at Disney? Also, all the pieces are hand-rotoscoped, the mouth animations are hand-animated, and every voice is from a hired (and paid) voice actor.
- https://www.youtube.com/watch?v=uKYeDIiqiHs - Totally 100% cursed. Made by a teenager following the comic book's plot. Instead of this teenager spending 100 hours on Fortnite, they made this.
[1] Creators and artists using AI have been harassed, doxxed, sent death threats, name-called, sent shock images, etc. by anti-AI folks at such volume, that we've become bitter about these people. This is literally just a new tool in the tool box. We shouldn't be treated like this.
OP makes zero comments about content generation, and the complaint is about upscaling introducing artifacts not in the original source. No different than hating a bad 4k remaster / sharpening.
That advice is not universal, and without context it's simply wrong.
You wouldn't upscale a classic film in this way, but there are plenty of low-resolution shots that benefit. Especially with VGA resolution renders and modern AI workflows.
Just looking at the Topaz marketing, you can see a lot of places where it indeed does work. And 20-year industry professionals are using it today for their day jobs.
If you want to say "don't upscale a classic film in Topaz", say that. Because context makes the advice correct. This blanket "do not use" statement is flat out wrong.
Sometimes I would want to convert from MPEG-TS H.264 to DVD video format, or other conversions, so there are reasons to do so. However, once I had got desynchronized audio, and I don't know if that is because of the original source, because of the conversion, or because some segments have not been recorded. (Also, it could not retain the EIA-608 captions, but that seems to be a limitation with FFmpeg, rather than something I did.)
MPV plugins can actually do frame-perfect cuts and crops for you (+ whatever ffmpeg filters you want), something that would generally require the hassle of opening editing software. And those cuts can be done in h264 lossless (for additional processing later at no additional quality loss from this step).
There is also a way to losslessly cut preserving the original encoding but you give up the precision of the cuts due to keyframes. The MPV script above can do that too: script-opts/encode_slice.conf
It's a simple tool which is great for many things, it has filters and there are most of the formats. I think it uses ffmpeg under the hood.
It's an old tool but it's fine for most things, when ffmpeg is to fastidious to use. ffmpeg is still what I use, but some more complex tasks are just more comfortable with avidemux.
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.
Something I've never been able to find satisfactory information on (and unfortunately this article also declares it out of scope), is what is the actual hard on-the-wire and on-disk differences between SDR and HDR? Like yes, I know HDR = high dynamic range = bigger difference between light and dark, but what technical changes were needed to accomplish this?
The way I understand it, we've got the YCbCr that is being converted to an RGB value which directly corresponds to how bright we drive the R, G, and B subpixels. So wouldn't the entire range already be available? As in, post-conversion to RGB you've got 256 levels for each channel which can be anywhere from 0 to 255 or 0% to 100%? We could go to 10-bit color which would then give you finer control with 1024 levels per channel instead of 256, but you still have the same range of 0% to 100%. Does the YCbCr -> RGB conversion not use the full 0-255 range in RGB?
Naturally, we can stick brighter backlights in our monitors to make the difference between light and dark more significant, but that wouldn't change the on-disk or on-the-wire formats. Those formats have changed (video files are specifically HDR or SDR and operating systems need to support HDR to drive HDR monitors), so clearly I am missing something but all of my searches only find people comparing the final image without digging into the technical details behind the shift. Anyone care to explain or have links to a good source of information on the topic?
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.
> 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.
I would disagree somewhat on his stance that video quality is not affected by container format (especially on part "Here is a list of things that people commonly associate with a video's quality"). Different container formats have different limitations regarding what video (and audio) formats they support. And while it subtitles support doesn't directly affect video quality, it does do so indirectly. If you cannot add subtitles without hardsubbing or subtitle formats are so limited that you end up needing hardsubbing anyway then the choice of the container format ends up affecting the video quality.
Yes, absolutely. The top answer on that Reddit link starts with: "MPV is the ultimate video player on planet earth, all the others are junk in comparison" and doesn't mention VLC at all. That's not a helpful answer, it's just signalling that they're a huge fan of MPV, with nothing to suggest they've ever even tried anything else.
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.
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".
Nah, see, I maintain a commercial video platform, and half the battle is people typing things in before they understand what a codec is. Theory first, practice after.
that's not a quick start guide. not once has the quick start guide with a printer explained the workings of the ink jet nozzle and the ability to precisely control the position of the head. it just says plug it in, hit this button to join wifi, open this app on your device, hit print.
The discussions in this thread are amusing. It’s a pretty great beginner guide. Almost a parallel to “how to ask questions the smart way” applied to videos.
I've had a lot of misconceptions that I had to contend with over the years myself as well. Maybe this thread is a good opportunity to air the biggest one of those. Additionally, I'll touch on subbing at the end, since the post specifically calls it out.
My biggest misconception, bar none, was around what a codec is exactly, and how well specified they are. I'd keep hearing downright mythical sounding claims, such as how different hardware and software encoders, and even decoders, produce different quality outputs.
This sounded absolutely mental to me. I thought that when someone said AVC / H.264, then there was some specification somewhere, that was then implemented, and that's it. I could not for the life of me even begin to fathom where differences in quality might seep in. Chief of this was when somebody claimed using single threaded encoding instead of multi threaded encoding was superior. I legitimately considered I was being messed with, or that the person I was talking to simply didn't know what they were talking about.
My initial thoughts on this were that okay, maybe there's a specification, and the various codec implementations just "creatively interpret" these. This made intuitive sense to me because "de jure" and "de facto" distinctions are immensely common in the real world, be it for laws, standards, what have you. So I'd start differentiating and going "okay so this is H.264 but <implementation name>". I was pretty happy with this, but eventually, something felt off enough to make me start digging again.
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. This applies to video, image, and sound formats; all lossy media formats. Except for telephony, all these codecs only ever specify the end result and how to decode that, but not the way to get there.
And so suddenly, the differences between implementations made sense. It isn't that they're flaunting the standard: for the encoding step, there simply isn't one. The various codec implementations are to compete on finding the "best" way to compress information to the same cross-compatibly decode-able bitstream. It is the individual encoders' responsibility to craft a so-called psychovisual or psychoacoustic model, and then build a compute-efficient encoder that can get you the most bang for the buck. This is how you get differences between different hardware and software encoders, and how you can get differences even between single and multi-threaded codepaths of the same encoder. Some of the approaches they chose might simply not work or work well with multi threading.
One question that escaped me then was how can e.g. "HEVC / H.265" be "more optimal" than "AVC / H.264" if all these standards define is the end result and how to decode that end result. The answer is actually kinda trivial: more features. Literally just more knobs to tweak. These of course introduce some overhead, so the question becomes, can you reliably beat this overhead to achieve parity, or gain efficiency. The OP claims this is not a foregone conclusion, but doesn't substantiate. In my anecdotal experience, it is: parity or even efficiency gain is pretty much guaranteed.
Finally, I mentioned differences between decoder output quality. That is a bit more boring. It is usually a matter of fault tolerance, and indeed, standards violations, such as supporting a 10 bit format in H.264 when the standard (supposedly, never checked) only specifies 8-bit. And of course, just basic incorrectness / bugs.
Regarding subbing then, unless you're burning in subs (called hard-subs), all this malarkey about encoding doesn't actually matter. The only thing you really need to know about is subtitle formats and media containers. OP's writing is not really for you.
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.
this is exactly what "higher" compression levels do (among other things like bigger dictionary) - they try harder, more iterations, to find the optimum combination of available knobs for a particular chunk of data.
Yes, that much was always clear. I just always thought the way these software go about finding those combinations was also standardized on a high level rather than proprietary to each implementation. It is a fairly recent development for me to realize that the various encoder options and presets are specific to the encoder, not the format (and now, that the same is true for lossless formats too).
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.
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.
> 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.
If the estimation is good it might be enough for some use cases. Is there any software out there that specializes in this? Similarly to maybe AI colorizing or upscaling, which both guess information that is not there anymore.
That looks interesting. Is there ready-made software that can do this? Doesn't have to be easy to use just useable with a time commitment of a few days.
The second technical definition in this document is wrong. Great way to put the "the author is opinionated but is clueless" marker right near the top.
> Actual video coding formats are formats like H.264 (also known as AVC) or H.265 (also known as HEVC). Sometimes they're also called codecs, short for "encode, decode".
Codec is coder/decoder. It's not the format.
There's a footnote claiming people mix the 2 terms up (a video format is apparently equal to a video codec according to this "expert") but apparently acknowledging the difference is seemingly only what nitpickers do. Sheesh. If you want to educate, educate with precision, and don't spread your misinformation!
> 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.
> I would recommend you to just learn basic ffmpeg usage instead
> but ffmpeg is fine for beginners
No, that's just nonsense for any guide targetting beginners, it's not fine, it's too error-prone and complicated and requires entering the whole unfriendly land of the cli!
> If you must use a GUI
Of course you must! It's much better to provide beginners with your presets in Handbrake that avoid the footguns you mention (or teach them how to avoid them on their own) rather than ask them to descend into the dark pit of ffmpeg "basics"
> Before you start complaining about how complicated ffmpeg is and how arcane its syntax is, do yourself a favor and read the start of its documentation. It turns out that reading the (f.) manual actually helps a lot!
It turns out that wrapping the bad UI in a simpler typed GUI interface wastes less of the collective time than asking everyone to read dozens of pages of documentation!
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"
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 had found that VLC does not play a MPEG-TS file very well (although it recognizes the file and plays it, it does not work very well); converting it to another format first, will cause it to play better, in my experience.
Nearly this entire HN comment section is upset about VLC being mentioned once and not recommended. If you can not understand why this very minor (but loud?) note was made, then you probably do not do any serious video encoding or you would know why it sucks today and is well past its prime. VLC is glorified because it was a video player that used to be amazing back in the day, but hasn't been for several years now. It is the Firefox of media players.
There is a reason why the Anime community has collectively has ditched VLC in favor of MPV and MPC-HC. Color reproduction, modern codec support, ASS subtitle rendering, and even audio codecs are janky or even broken on VLC. 98% of all Anime encode release playback problems are caused by the user using VLC.
We even have a dedicated pastebin on a quick run down of what is wrong: https://rentry.co/vee-ell-cee
And this pastebin doesn't even have all the issues. VLC has a long standing issue of not playing back 5.1 Surround sound Opus correctly or at all. VLC is still using FFmpeg 4.x. We're on FFmpeg 8.x these days
I can not even use VLC to take screenshots of videos I encode because the color rendering on everything is wrong. BT.709 is very much NOT new and predates VLC itself.
And you can say "VLC is easy to install and the UI is easy." Yeah so is IINA for macOS, Celluloid for Linux, and MPV.net for Windows which all use MPV underneath. Other better and easy video players exist today.
We are not in 2012 anymore. We are no longer just using AVC/H264 + AAC or AC-3 (Dolby Audio) MP4s for every video. We are playing back HEVC, VP9, and AV1 with HDR metadata in MKV/webm cnotainers with audio codecs like Opus or HE-AACv3 or TrueHD in surround channels, BT.2020 colorspaces. VLC's current release is made of libraries and FFmpeg versions that predate some of these codecs/formats/metadata types. Even the VLC 4.0 nightly alpha is not keeping up. 4.0 is several years late to releasing and when it does, it may not even matter.
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.
> It is the Firefox of media players.
So... the better option?
https://mpv.io/
IDK where you have been for the last decade, but Firefox has not been the better option since Chromium was made
Disliking Google Chrome proper is one thing, but Chromium is superior in every way. Rendering, features, speed, memory management
The person is asking for the better option.
It seems really weirdly written. It's written with a lot of authority, like saying "Don't use VLC" and "Don't use Y" yet provides no reasoning for those things. Just putting "Trust me, just don't" doesn't suddenly mean I trust the author more, it probably has the opposite effect. Some sections seem to differ based on if the reader knows/doesn't know something, but I thought the article was supposed to be for the latter.
Would have been nice if these "MUST KNOW BEFORE" advises were structured in a way so one could easily come back and use it as a reference, like just a list, but instead it's like a over-dinner conversation with your "expert and correct but socially-annoying" work colleague, who refuses to elaborate on the how's and why's, but still have very strong opinions.
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.
You're talking about VLC for video playback, TFA is taking about video editing.
VLC ignores a lot for it's outstanding video playback support, which is great if you want the playback too just work... But that's the player perspective, not the editing/encoding
While VLC is excellent at playing every format under the sun, it's not good at playing all those formats correctly. Off the top of my head:
- Transfer functions are just generally a mess but are close enough that most people don't notice they're wrong. Changing the render engine option will often change how the video looks.
- Some DV profiles cause videos to turn purple or green.
- h.264 left and right crops are both applied as left crops that are summed together which completely breaks many videos. They could just ignore this metadata but from what I've heard their attitude is that a broken implementation is better than no implementation.
The author did mention to use MPV, which is much much lightweight than VLC. Being using it as default for quite some times now.
what are you talking about? Of course it's only about playback just like the other 2 alternatives
> single best media player out there ... VLC is not recommended.
Literally the first sentence
> Hanging out in subtitling and video re-editing communities, I see my fair share of novice video editors and video encoders, and see plenty of them make the classic beginner mistakes when it comes to working with videos.
Seriously, you quoted pretty much the only sentence in the whole article that's about plain playback, and even in that bullet point, the following sentence mentions hardcoding subtitles.
Literally don't stop at the first sentence!!!
> It turns out that reading the (f.) manual actually helps a lot!
The non-recommendation of VLC vs mpc/mpv is literally for playback as I quoted! MPC also doesn't do any encoding, yet it's recommended
> the following sentence mentions hardcoding subtitles.
And that sentence starts with "Apart from simply watching the video" to tell you the same thing the previous sentence told you - that comparison where VLC was not receommended was about playback, not editing
VLC has always caused problems for me when seeking backwards (graphical glitches). mpv has never caused any issues in this regard.
VLC and mpv literally use the same underlying codec library. (As well as ffmpeg.)
Have you tried both? mpv is able to play high resolution HEVC videos backwards at real time by holding the "previous frame" key. VLC can't reliably jump backwards even at second intervals, forget about reverse playback.
So? Here is the post where VLC dev explains why you can't seek 1 frame back (you can do that in MPC and mpv) https://forum.videolan.org/viewtopic.php?f=7&t=126609&start=...
VLC is great for playing stuff back, but can produce some horribly incorrect video files especially if you're dealing with stuff for editing.
There's a reason why VLC isn't used in broadcast stuff and ffmpeg is.
IIRC VLC used the wrong primaries for converting to RGB for a long time (years) even after it being reported to them as wrong
>even after it being reported to them as wrong
Source?
I'm not the OP of the claim (and I love VLC) but maybe they're referring to this early 2018 issue: https://trac.videolan.org/vlc/ticket/19723 which seems to be being actively worked on.
There's also https://code.videolan.org/videolan/vlc/-/issues/25651 but that's an off by one error so likely not really relevant to video playback for the average user.
VLC has left me hanging many times. It's play a file wrong or not played at all while mpv plays it no problem. Do not use vlc.
And? It’s a GitHub gist not an oreilly book. Context.
technically correct is the best kind. who cares if it's obnoxious? take the opinions and agree or disagree with them.
How do you know it is technically correct without explanation. It's not much different from someone getting blown off for being annoying because they constantly question simple answers when seeking better understanding. I was fortunate to work with a group of engineers when I was very young that accepted my constant use of "why?" not as disrespectful questioning but realized I was actually learning so they naturally just provided more details leading to less "why?" being asked. This eventually got to the point where I would ask a question, and the answer would be to read a specific book on the shelf. This was way before the internet. I received a better education on the job than I ever was going to get in school.
So no, I'm not just going to take an opinion without more information. I don't change my mind just on say so.
Why? Is the most simple test of a valid explanation. If you don't need to ask why any more, you've answered the question. Sometimes it takes 3 or 5 white in a row!
How can I disagree when they don't provide a reasoning behind why something is the better option?
When we switched from x264 to hardware based encoders it saved something like 90% on our customers' power and cooling bills.
So while this essay might be "technically correct" in some very narrow sense the author is speaking with far more authority than they have the experience to justify, which is what makes it obnoxious in the first place.
The author is directing this at complete noobs who are subbing their first anime and you are complaining that it is not applicable to running a datacenter?
This is already mentioned in the article. Software vs. hardware is a tradeoff. x264 produces higher quality (perceptual or compression efficiency) video, at the expense of latency.
the author never talked about power savings or cooling bills, they talked about quality so they are still correct.
It works if you know the person and have a baseline for how much confidence you give their opinions. If it's just a random person on the internet, they need to support their argument.
I mean—they can. They don’t need to give more than they’re already giving we anonymous strangers for free. For all we know, this person wrote this for people they encounter personally or professionally, and we’re just incidentally benefitting.
We as readers should gauge their credibility for ourselves, whether by reputation or by checking the claims. I don’t know who wrote it but it seems basically correct, consistent, and concisely argued to me.
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).
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...
13 years since that post and this is the first time I’m hearing of this long-past issue.
Haters gonna hate I guess.
It has never been very common for VLC to cause video corruption.
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.
> 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 :)
VLC is pretty much one of the default things I download on any of my computers. Right now I use mac and it's my default video player here too!
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.
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.
Why is that?
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...
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.
If you want a MPV-based player GUI on macOS, https://github.com/iina/iina is quite good.
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
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.
1: https://news.ycombinator.com/item?id=46413256
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.
I bought a new dashcam. It generates .mp4 files. I tried to play them back with my new Roku media player, and it says invalid format. (They will play with Windows media player.)
Grump grump grumpity grump. Same experience with every dashcam I've bought over the years.
I'm always amazed when I see how many people are unfamiliar with VLC hate. It was notorious (to the point of it being a popular meme topic) for video artifacts, slow/buggy seeking, bloated/clumsy UI/menus, having very little format support out of the box, and buggy subtitles. I assume nowadays it's much better, since it seems popular, but its reputation will stick with me forever.
>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.
> I thought the meme was that it played basically everything? At least compared to windows media player or whatever.
Yes, that was in the 2000s though. During the 2010 VLC started falling behind because its shortcomings overweighted its capabilities.
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.
Up until just last month I had never had a problem with VLC. But I don't pirate content so maybe I just hadn't encountered the problematic files. However, recording voice notes in Opus format on my phone, it turns out that VLC has a bug playing Opus files at certain bit rates. However for me this is easily worked around by just using MPV.
I dropped VLC circa 2019 for all the reasons mentioned and ever since I use exclusively MPV, both on Windows and Linux.
So at least from those times
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.
Kinda the problem with anecdotes isn't it? :)
My own anecdotal experience with VLC was that while every update fixed something, they also broke something in return - and these updates were common. This got annoying enough at some point for me to hop ships, and so I switched to mpc-hc and never looked back.
I've since also tried (and keep trying) the to-me still newfangled mpv, but I'm not a fan of the GUI or the keybinds. I know it can be customized, but that's not something I'm interested in doing. I know there are alternative frontends as well, but I checked and they're not to my liking either. So I mostly just use it for when mpc-hc gives out, such as really badly broken media files, or anything HDR.
Out of pure curiosity, what kind of things were you VLC using for, for it to break so often? I'm almost never doing anything with video, so I'm completely clueless in this field.
I don't recall my issues being media file or workload specific [0]. It was specifically just general frontend stuff I believe [1]. Although I should probably also mention that I don't remember much to begin with, other than my decidedly negative conclusion that made me switch players, and the overall personal narrative around that. It's been quite a few years if not a whole decade.
[0] Doesn't mean there weren't any, but then I was not doing anything special. Just watched anime, listened to music, streamed YouTube. Hardly an extraordinary workload for VLC, or indeed any media player in general.
[1] I remember them changing around the volume slider widget back and forth ad nauseam for example, and that becoming in some particular way defective that I cannot recall.
And you think everybody else should stop using it because you had problems?
I'll make up my own mind on it.
Do you think everyone else should start or continue using it because you never had problems?
Let's be kind. Clearly not what either of us were thinking or intended to convey.
You should make up your own mind. why bother reading comments at all? why bother reading reviews? I bet you watch every movie and never comment on how good or bad they are because you'll be telling everybody else what to do and that would be hypocritical. I wonder how you stumbled upon VLC in the first place - perhaps you read about it somewhere and followed that advice?
Where did perching_aix say that?
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.
Do you have sources for that? As far as I know VLC has actually always been famous for supporting basically every format.
Shameless plug for anyone that wants to go deeper on specific video topics: I've been organizing a conference for video devs for 11 years now and there's a wealth of info in the recordings. A talk from the most recent one on hacking a Sega Genesis to stream video might not seem that practical, but there were some fascinating bits on compression (or, rather, not being able to use actual compression). https://www.youtube.com/watch?v=GZdxdpw-3nI
If folks want to get involved, there's also a chat community that's pretty active: https://video-dev.org.
"Don't use Topaz AI, Anime4k, RealESRGAN, RIFE, etc. Trust me, just don't."
Why? I only know Topaz and I always thought it had its narrow but legitimate uses cases for upscaling and equalizing quality?
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.
If someone has anti-AI opinions and spends zero effort explaining their position, I assume they have "AI Derangement" [1], a hate/fear perpetrated by the Big Scare media and podcasters seeking like/subscribes.
You can spend a tremendous amount of time using these tools to accomplish pretty stunning results already:
- https://www.youtube.com/watch?v=Tii9uF0nAx4 - Made by a film school grad as a demo of real filmmaking combined with AI VFX.
- https://www.youtube.com/watch?v=FAQWRBCt_5E - Created by a Hollywood TV writer for an FX show you've probably seen. Not the best animation or voicing, but you can see how it gives a writer more than just a blank page to convey their thoughts.
- https://www.youtube.com/watch?v=wWZYP5jn5w4 - Music video. Slightly MAGA-coded, but made by a Hollywood VFX person.
- https://www.youtube.com/watch?v=tAAiiKteM-U - Made by a film school grad as a Robot Chicken homage. If you're going to tell them "don't use AI", then are you going to get them a job at Disney? Also, all the pieces are hand-rotoscoped, the mouth animations are hand-animated, and every voice is from a hired (and paid) voice actor.
- https://www.youtube.com/watch?v=H4NFXGMuwpY - Made by a film school grad as a Robot Chicken homage. See previous comment.
- https://www.youtube.com/watch?v=d_KXYpaTe_8 - Another slightly MAGA-coded music video. Made by the same Hollywood VFX person.
- https://www.youtube.com/watch?v=9hlx5Rslrzk - Amazing Spider-Man vs. Carnage anime created with ComfyUI and other models.
- https://www.youtube.com/watch?v=oqoCWdOwr2U - Christmas Grinch anime.
- https://www.youtube.com/watch?v=uKYeDIiqiHs - Totally 100% cursed. Made by a teenager following the comic book's plot. Instead of this teenager spending 100 hours on Fortnite, they made this.
- https://www.youtube.com/watch?v=Ps5Dhc3Lh8U - A Pixar-like short film
[1] Creators and artists using AI have been harassed, doxxed, sent death threats, name-called, sent shock images, etc. by anti-AI folks at such volume, that we've become bitter about these people. This is literally just a new tool in the tool box. We shouldn't be treated like this.
OP makes zero comments about content generation, and the complaint is about upscaling introducing artifacts not in the original source. No different than hating a bad 4k remaster / sharpening.
That advice is not universal, and without context it's simply wrong.
You wouldn't upscale a classic film in this way, but there are plenty of low-resolution shots that benefit. Especially with VGA resolution renders and modern AI workflows.
Just looking at the Topaz marketing, you can see a lot of places where it indeed does work. And 20-year industry professionals are using it today for their day jobs.
If you want to say "don't upscale a classic film in Topaz", say that. Because context makes the advice correct. This blanket "do not use" statement is flat out wrong.
In any case, blindly apply upscaling is just wrong ..
You apply it to where it is needed. Not every scene need the same treatment.
The article simply says "Trust me, just don't."
No it doesn't. It says “don't, Unless you're extremely surgical with it and know exactly what you're doing”.
Which is a sensible piece of advice.
Sometimes I would want to convert from MPEG-TS H.264 to DVD video format, or other conversions, so there are reasons to do so. However, once I had got desynchronized audio, and I don't know if that is because of the original source, because of the conversion, or because some segments have not been recorded. (Also, it could not retain the EIA-608 captions, but that seems to be a limitation with FFmpeg, rather than something I did.)
MPV plugins can actually do frame-perfect cuts and crops for you (+ whatever ffmpeg filters you want), something that would generally require the hassle of opening editing software. And those cuts can be done in h264 lossless (for additional processing later at no additional quality loss from this step).
https://github.com/occivink/mpv-scripts
There is also a way to losslessly cut preserving the original encoding but you give up the precision of the cuts due to keyframes. The MPV script above can do that too: script-opts/encode_slice.conf
I wish he talked about avidemux.
It's a simple tool which is great for many things, it has filters and there are most of the formats. I think it uses ffmpeg under the hood.
It's an old tool but it's fine for most things, when ffmpeg is to fastidious to use. ffmpeg is still what I use, but some more complex tasks are just more comfortable with avidemux.
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?"
using a sledge to drive a finishing nail? yes, it's still a hammer and it's still a nail, but still the wrong tool for the job
Something I've never been able to find satisfactory information on (and unfortunately this article also declares it out of scope), is what is the actual hard on-the-wire and on-disk differences between SDR and HDR? Like yes, I know HDR = high dynamic range = bigger difference between light and dark, but what technical changes were needed to accomplish this?
The way I understand it, we've got the YCbCr that is being converted to an RGB value which directly corresponds to how bright we drive the R, G, and B subpixels. So wouldn't the entire range already be available? As in, post-conversion to RGB you've got 256 levels for each channel which can be anywhere from 0 to 255 or 0% to 100%? We could go to 10-bit color which would then give you finer control with 1024 levels per channel instead of 256, but you still have the same range of 0% to 100%. Does the YCbCr -> RGB conversion not use the full 0-255 range in RGB?
Naturally, we can stick brighter backlights in our monitors to make the difference between light and dark more significant, but that wouldn't change the on-disk or on-the-wire formats. Those formats have changed (video files are specifically HDR or SDR and operating systems need to support HDR to drive HDR monitors), so clearly I am missing something but all of my searches only find people comparing the final image without digging into the technical details behind the shift. Anyone care to explain or have links to a good source of information on the topic?
I found this explanation useful:
https://youtu.be/uMSV4OteqBE?si=QCOL_2_VpE7tBdAu&t=83
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...
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 would disagree somewhat on his stance that video quality is not affected by container format (especially on part "Here is a list of things that people commonly associate with a video's quality"). Different container formats have different limitations regarding what video (and audio) formats they support. And while it subtitles support doesn't directly affect video quality, it does do so indirectly. If you cannot add subtitles without hardsubbing or subtitle formats are so limited that you end up needing hardsubbing anyway then the choice of the container format ends up affecting the video quality.
Pretty good writeup but not sure why VLC is not recommended...?
What's wrong with VLC?
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.
Yes, absolutely. The top answer on that Reddit link starts with: "MPV is the ultimate video player on planet earth, all the others are junk in comparison" and doesn't mention VLC at all. That's not a helpful answer, it's just signalling that they're a huge fan of MPV, with nothing to suggest they've ever even tried anything else.
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.
Really good quickstart guide
>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".
Nah, see, I maintain a commercial video platform, and half the battle is people typing things in before they understand what a codec is. Theory first, practice after.
that's not a quick start guide. not once has the quick start guide with a printer explained the workings of the ink jet nozzle and the ability to precisely control the position of the head. it just says plug it in, hit this button to join wifi, open this app on your device, hit print.
The discussions in this thread are amusing. It’s a pretty great beginner guide. Almost a parallel to “how to ask questions the smart way” applied to videos.
Do you have any recommendations for literature on the subject of video encoding etc? I really want to learn more theory.
I've had a lot of misconceptions that I had to contend with over the years myself as well. Maybe this thread is a good opportunity to air the biggest one of those. Additionally, I'll touch on subbing at the end, since the post specifically calls it out.
My biggest misconception, bar none, was around what a codec is exactly, and how well specified they are. I'd keep hearing downright mythical sounding claims, such as how different hardware and software encoders, and even decoders, produce different quality outputs.
This sounded absolutely mental to me. I thought that when someone said AVC / H.264, then there was some specification somewhere, that was then implemented, and that's it. I could not for the life of me even begin to fathom where differences in quality might seep in. Chief of this was when somebody claimed using single threaded encoding instead of multi threaded encoding was superior. I legitimately considered I was being messed with, or that the person I was talking to simply didn't know what they were talking about.
My initial thoughts on this were that okay, maybe there's a specification, and the various codec implementations just "creatively interpret" these. This made intuitive sense to me because "de jure" and "de facto" distinctions are immensely common in the real world, be it for laws, standards, what have you. So I'd start differentiating and going "okay so this is H.264 but <implementation name>". I was pretty happy with this, but eventually, something felt off enough to make me start digging again.
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. This applies to video, image, and sound formats; all lossy media formats. Except for telephony, all these codecs only ever specify the end result and how to decode that, but not the way to get there.
And so suddenly, the differences between implementations made sense. It isn't that they're flaunting the standard: for the encoding step, there simply isn't one. The various codec implementations are to compete on finding the "best" way to compress information to the same cross-compatibly decode-able bitstream. It is the individual encoders' responsibility to craft a so-called psychovisual or psychoacoustic model, and then build a compute-efficient encoder that can get you the most bang for the buck. This is how you get differences between different hardware and software encoders, and how you can get differences even between single and multi-threaded codepaths of the same encoder. Some of the approaches they chose might simply not work or work well with multi threading.
One question that escaped me then was how can e.g. "HEVC / H.265" be "more optimal" than "AVC / H.264" if all these standards define is the end result and how to decode that end result. The answer is actually kinda trivial: more features. Literally just more knobs to tweak. These of course introduce some overhead, so the question becomes, can you reliably beat this overhead to achieve parity, or gain efficiency. The OP claims this is not a foregone conclusion, but doesn't substantiate. In my anecdotal experience, it is: parity or even efficiency gain is pretty much guaranteed.
Finally, I mentioned differences between decoder output quality. That is a bit more boring. It is usually a matter of fault tolerance, and indeed, standards violations, such as supporting a 10 bit format in H.264 when the standard (supposedly, never checked) only specifies 8-bit. And of course, just basic incorrectness / bugs.
Regarding subbing then, unless you're burning in subs (called hard-subs), all this malarkey about encoding doesn't actually matter. The only thing you really need to know about is subtitle formats and media containers. OP's writing is not really for you.
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.
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
Drives me crazy but I'm glad to learn of it :D
Makes a lot of sense in retrospect, to the extent it bothers me I haven't figured it out myself earlier.
this is exactly what "higher" compression levels do (among other things like bigger dictionary) - they try harder, more iterations, to find the optimum combination of available knobs for a particular chunk of data.
Yes, that much was always clear. I just always thought the way these software go about finding those combinations was also standardized on a high level rather than proprietary to each implementation. It is a fairly recent development for me to realize that the various encoder options and presets are specific to the encoder, not the format (and now, that the same is true for lossless formats too).
for video there is another constraint - time
hardware encoders (like the ones in GPUs) typically work realtime-ish, so they do minimal exploration of encoding space
you also have the one-pass/two-pass thing which is key for unlocking high quality compression
I'm curious what the issue is with using Handbrake? I use it all the time on macOS and it's generally a simple and effective tool for my purposes.
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 author can't stand how it simply re-encodes videos instead of extracting the video tracks and puts them in new containers.
The article talks about image comparisons but does not say what the best way to extract an image is.
If I want the best possible quality image at a precisely specified time, what would I do?
Can I increase quality if I have some leeway regarding the time (to use the closest keyframe)?
Is there a way to "undo" motion blur and get a sharp picture?
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.
I usually use a shortcut in mpv to extract the screenshot. If I want to do it via the command-line:
The means “go to 00:00:12.435 on the file /Users/weinzieri/videofile.mp4 and extract one frame to the file /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.
If the estimation is good it might be enough for some use cases. Is there any software out there that specializes in this? Similarly to maybe AI colorizing or upscaling, which both guess information that is not there anymore.
it's not gone, just more difficult to extract
video has certain temporal statistics which can allow you to fit the missing information
only true blurred white noise is impossible to recover
It really is gone. You can predict what you think it might have been, but you can't know what it was.
it's gone in a single still frame
but across many consecutive frames, the information is spread out temporaly and can be recovered (partially)
the same principle of how you can get a high resolution image from a short video, by extracting the same patch from multiple frames
https://en.wikipedia.org/wiki/Video_super-resolution
That looks interesting. Is there ready-made software that can do this? Doesn't have to be easy to use just useable with a time commitment of a few days.
No, it's not "restoring detail". The information is gone.
It is predicting what the information might maybe have been like.
The second technical definition in this document is wrong. Great way to put the "the author is opinionated but is clueless" marker right near the top.
> Actual video coding formats are formats like H.264 (also known as AVC) or H.265 (also known as HEVC). Sometimes they're also called codecs, short for "encode, decode".
Codec is coder/decoder. It's not the format.
There's a footnote claiming people mix the 2 terms up (a video format is apparently equal to a video codec according to this "expert") but apparently acknowledging the difference is seemingly only what nitpickers do. Sheesh. If you want to educate, educate with precision, and don't spread your misinformation!
> 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.
> I would recommend you to just learn basic ffmpeg usage instead > but ffmpeg is fine for beginners
No, that's just nonsense for any guide targetting beginners, it's not fine, it's too error-prone and complicated and requires entering the whole unfriendly land of the cli!
> If you must use a GUI
Of course you must! It's much better to provide beginners with your presets in Handbrake that avoid the footguns you mention (or teach them how to avoid them on their own) rather than ask them to descend into the dark pit of ffmpeg "basics"
> Before you start complaining about how complicated ffmpeg is and how arcane its syntax is, do yourself a favor and read the start of its documentation. It turns out that reading the (f.) manual actually helps a lot!
It turns out that wrapping the bad UI in a simpler typed GUI interface wastes less of the collective time than asking everyone to read dozens of pages of documentation!
This is a great write up. Thank you for sharing.
video format world is one where you nope out pretty quick once you realize how many moving pieces there are.
ffmpeg seems ridiculously complicated, but infact its amazing the amount of work that happens under the hood when you do
and tbh theyve made the interface about as smooth as can be given the scope of the problem.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"
Could have used this in the nineties, where hunting a specific codec to play that video you downloaded off a BBS was an actual thing.
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 had found that VLC does not play a MPEG-TS file very well (although it recognizes the file and plays it, it does not work very well); converting it to another format first, will cause it to play better, in my experience.