15 ms·

What you need to know before touching a video file

376 points by qbow883 9mo ago

webdevver 9mo ago
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 ffmpeg -i input.mp4 output.webm and tbh theyve made the interface about as smooth as can be given the scope of the problem.
- dylan604 9mo ago
  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"
- mywittyname 9mo ago
  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.
swiftcoder 9mo ago
Really good quickstart guide
- gruez 9mo ago
  >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".
  - swiftcoder 9mo ago
    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.
    - fbias 9mo ago
      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.
    - wizhi 9mo ago
      Do you have any recommendations for literature on the subject of video encoding etc? I really want to learn more theory.
    - dylan604 9mo ago
      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.
tmaly 9mo ago
This is a great write up. Thank you for sharing.
BitsAndObjects 9mo ago
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).
- throwaway2046 9mo ago
  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.
  - embedding-shape 9mo ago
    > 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 :)
  - binarygit 9mo ago
    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!
  - heavyset_go 9mo ago
    No it doesn't, its Wayland support is a mess, its codec support is lackluster, and somehow the experience is worse when you use VA-API hardware decoding.
- howenterprisey 9mo ago
  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.
Jabrov 9mo ago
What's wrong with VLC?
- Waterluvian 9mo ago
  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_mpv_or_vlc_in_terms_of_video_quality/ 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.
  - abanana 9mo ago
    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.
- dylan604 9mo ago
  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.
  - krackers 9mo ago
    This matches with my observation, VLC tends to be more tolerant of slightly broken files or random issues that you encounter when streaming. Especially for hls streams, vlc often works when ffplay refuses to play it, I believe because vlc uses their own demuxer (instead of relying on libavformat).
- wafflemaker 9mo ago
kwar13 9mo ago
Pretty good writeup but not sure why VLC is not recommended...?
embedding-shape 9mo ago
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.
- ramesh31 9mo ago
  technically correct is the best kind. who cares if it's obnoxious? take the opinions and agree or disagree with them.
  - snakeboy 9mo ago
    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.
    - alwa 9mo ago
      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.
  - dylan604 9mo ago
    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.
g4zj 9mo ago
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.
- dspillett 9mo ago
  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.
- SG- 9mo ago
  the author can't stand how it simply re-encodes videos instead of extracting the video tracks and puts them in new containers.
- xp84 9mo ago
  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.)
  - Izkata 9mo ago
    Subtitles are another kind of stream aside from video/audio. Also there's one user-level aspect of MKV that makes it not too surprising to me: It can contain any number of video/audio/subtitle streams and the interface needs some way of allowing the user to pick between them. Easier to just skip that complexity, I guess.
pandemic_region 9mo ago
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.
- cruffle_duffle 9mo ago
  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.
  - zzo38computer 9mo ago
    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.
    - duskwuff 9mo ago
      MPEG-TS files are just a pain to play in general. It was never intended as a file format for prerecorded video, and lacks some features (like seek indexes) which are required for reasonable playback. In most circumstances, a MPEG-TS file can be remuxed (without reencoding) to a more reasonable container format like MP4, and it'll play better that way. In some cases, it'll even be a smaller file.
  - Agingcoder 9mo ago
    I used mplayer ( the ancestor to mpv as I’ve just realized ) in the early 2000s which I think could handle everything under the sun back then.
    - astrange 9mo ago
happytoexplain 9mo ago
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.
- gruez 9mo ago
  >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 https://news.ycombinator.com/item?id=46465349), it looks like it might indeed be caused by uncommon files that I haven't encountered.
  - littlestymaar 9mo ago
    > 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.
  - morshu9001 9mo ago
    Pretty sure VLC can play /dev/urandom
- dooglius 9mo ago
  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.
  - u_sama 9mo ago
jokoon 9mo ago
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.
- globnomulous 9mo ago
  > to fastidious Do you mean "too fussy?"
  - dylan604 9mo ago
    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
- dylan604 9mo ago
  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.
  - astrange 9mo ago
    ffmpeg and libavcodec are the same project.
    - dylan604 9mo ago
      yes. but do you have to include the ffmpeg part to include just the other libraries?
      - astrange 9mo ago
        No, ffmpeg itself is a pretty small wrapper around them. But the rest are true libraries and not frameworks, so you have to make all kinds of playback decisions yourself. A/V sync is hard.
perching_aix 9mo ago
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.
weinzierl 9mo ago
"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?
- echelon 9mo ago
  [flagged]
  - cnntth 9mo ago
    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.
    - echelon 9mo ago
      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.
      - unloader6118 9mo ago
        In any case, blindly apply upscaling is just wrong .. You apply it to where it is needed. Not every scene need the same treatment.
        echelon 9mo ago
        The article simply says "Trust me, just don't."
craftkiller 9mo ago
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?
- dylan604 9mo ago
  > 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/b5b9552633567fa7658deee5aec60453/#other-parameters https://gist.github.com/arch1t3cht/b5b9552633567fa7658deee5a...
weinzierl 9mo ago
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?
- ErroneousBosh 9mo ago
  > 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.
  - weinzierl 9mo ago
    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.
  - memoriuaysj 9mo ago
    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
    - ErroneousBosh 9mo ago
      It really is gone. You can predict what you think it might have been, but you can't know what it was.
      - memoriuaysj 9mo ago
        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 https://en.wikipedia.org/wiki/Video_super-resolution
deleted 9mo ago
[deleted]
netsharc 9mo ago
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!
- derefr 9mo ago
  > 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.
  - netsharc 9mo ago
    Maybe it's my bubble, but a video format is a name given to the description of how the video is stored as a stream of bytes/how to get the video from the stream of bytes, and "codec" is the piece of software (more generally, logic) that handles that work. It's not fine to say "oh those 2 things are the same", especially in an introduction, because then you're leading people astray instead of educating them.
    - derefr 9mo ago
coppsilgold 9mo ago
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 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
mmcclure 9mo ago
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 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 https://video-dev.org.
eviks 9mo ago
> 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!
buzer 9mo ago
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.
Drybones 9mo ago
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 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.
- jaapz 9mo ago
  > It is the Firefox of media players. So... the better option?
  - SirMaster 9mo ago
    https://mpv.io/ https://mpv.io/
zzo38computer 9mo ago
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.)
- liampulles 9mo ago
  Did you use a decent piece of DVD authoring software? Here are some options: https://www.videohelp.com/software/sections/authoring-dvd https://www.videohelp.com/software/sections/authoring-dvd
  - zzo38computer 9mo ago
    I used the "ffmpeg" to convert the video/audio, and then I used the "dvdauthor" to make the files into the video DVD format, and then I used the "genisoimage" to make the disk image file in the DVD format.
WalterBright 9mo ago
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.
deleted 9mo ago
[deleted]
hamonrye 9mo ago
Container formats for x.264, AVC, or H.264 are in .mkv or .mp4 codecs to encode and decode. [1] Technically the term codec refers to a specific program that can encode and decode a certain format.
jdprgm 9mo ago
Just writing off AI upscaling completely is bs. It's not some magic bullet to use on every video and there is a learning curve on how to apply but there are absolutely scenarios where you can get shockingly good results. I think a lot of people make judgements on it based on super small sample sizes. On a separate note also not mentioned llm's are really good at generating ffmpeg commands. Just discuss with chatGPT your source file and goals for a video and you can typically oneshot a targeted command even if you aren't familiar with ffmpeg cli.
- tuna74 9mo ago
  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.
- liampulles 9mo ago
  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.
ro_bit 9mo ago
I edit videos on a hobbyist level (mostly using davinci resolve to edit clips of me dying in video games to upload to a shareX host to show to friends). The big takeaway for me was reading that for quality/efficiency libx264 is better than nvenc for rendering h264 video. All this time I’ve assumed nvenc is better because it used shiny GPU technology! Is libx264 better for recording high quality videos too? I know it will run on CPU unlike NVENC but I doubt that’s an issue for my use case. Edit: from some googling it looks like encoding is encoding, whether it’s used for recording or rendering footage. In that case the same quality arguments the article is making should apply for recording too. I only did a cursory search though and have not had a chance to test so if anyone knows better feel free to respond
- avidiax 9mo ago
  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.
- zten 9mo ago
  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.
amelius 9mo ago
Nowadays, I just ask an LLM to give me the ffmpeg command that I need. No need to know anything about the video file anymore. (Of course if you're hosting billions of videos on a website like YouTube it is a different story, but at that point you need to learn a _lot_ more e.g. about hardware accelerators, etc.)
effnorwood 9mo ago
They are very hot
jorl17 9mo ago
I thought it was a good read, although with a couple of mistakes and a somewhat (IMO) childish sense of entitlement. This reads a bit like something a young teen who is heavy into tech wrote. I'm sure I could have authored something with the same overall tone and vibe when I was younger (perhaps not same quality, though!). Either way, it's a very decent read! The idea that YCbCr is only here because of "legacy reasons", and that we only we discard half of chrominance because of equally "legacy reasons" is bonkers, though.
- zerocrates 9mo ago
  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.
- arch1t3cht 9mo ago
  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.
socalgal2 9mo ago
Tangential but, at least for me, I find lots of video creators making 2-3 gig videos for no noticable difference in quality for me re-encoding them to 1/4th the size or less. My impression is, their audience equates file size with quality so the bigger the file the more "value" they got from the creator. This is frustrating because bigger files means hitting transfer limits, slower to download, slower to copy, taking more space, etc...
- stavros 9mo ago
  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.
- liampulles 9mo ago
  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.
arch1t3cht 9mo ago
Original post author here. It seems like the main criticisms I am getting for this article are because it's escaped past its main target audience, so let me clarify a few things. This post was born out of me hanging out in communities where people would make their own shortened edits of TV series and, in particular, anime, often to cut out filler or padding. Many people there would make many of the mistakes mentioned in the post, in particular reencoding at every step without knowing how to actually control efficiency/quality. I spent a lot of time helping out individual people one-on-one, but eventually wrote the linked article to collect all of my advice in one place. That way I (or other people I know) can just link to it like "Read the section on containers here," and then answer any follow-up questions, instead of having to explain from scratch each time. > It seems really weirdly written. / ranty format So, yes, it does. It was born out of one-to-one explanations on Discord. I wouldn't be surprised if it may seem condescending to a more advanced reader, but if I rant about some point to hammer it down it's because it's a mistake I've seen people make often enough that it has to be reenforced this much. I wouldn't write a professional article this way. The other point many people seem to get hung up about is the "hate" on VLC. Let me clarify that I do not "hate" VLC at all, I just don't recommend it. VLC is only mentioned once in the entire page, exactly because I didn't want to slot in an intermission purely to list a bunch of VLC issues. I felt like that would qualify more as "hate." That said, yes, pretty much anyone I know in the fansubbing or encoding community does not recommend VLC because of various assorted issues. The rentry post [1] is often shared to list those, though I don't like how it does not give sources or reproducible examples for the issues it lists. I really do want to go through it and make proper samples and bug reports for all of these issues, I just didn't have the time yet. Let me also clarify that I have nothing against the VLC developers. VideoLan does great work even outside of VLC, and every interaction I've had with their developers has been great. I just do not recommend the tool. [1] https://rentry.co/vee-ell-cee https://rentry.co/vee-ell-cee
- rldjbpin 9mo ago
  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/ http://fixounet.free.fr/avidemux/
liampulles 9mo ago
I remember using Gordian Knot to create avi files from my DVDs back when XviD was the pragmatic method for encoding videos, and the whole goal was to get movies under 700mb so that you could write them to a CD. Avisynth and community filters were largely geared towards undoing all sorts of crap done to an image because artifacts that were relatively unnoticeable on a general CRT television were quite apparent on a computer monitor, as well as to then prepare the video to look good once it has been highly compressed with XviD or DivX. These days I'm much more inclined to try and transparently encode the source material, tag it appropriately in the media container, and let the player adjust the image on the fly. Though I admit, I still spend hours playing around with Vapoursynth filter settings and AV1 parameters to try and get a good quality/compression ratio. I have to say that the biggest improvement to the experience of watching my videos was when I got an OLED TV. Even some garbage VHS rip can look interesting when the night sky has been adjusted to true black. Given the increasing abilities of TVs and processing abilities and feature sets of players, I'm not much persuaded to upgrade my DVD collection to Blu-Ray. Though I admit some of that is that I enjoy the challenge of getting a good video file out of my DVDs. I partially disagree with the use of ASS subtitles. For a lot of traditional movies, using SRT files is sensible because more players support it, and because it's often sensible to give the player the option of how to render the text (because the viewing environment informs what is e.g. the appropriate font size).
vivzkestrel 9mo ago
would be nice if someone like epic spaceman actually broke down how videos are encoded, stored, processed and how encoding algorithms work visually, i am bad at understanding things by reading about them

376 points by qbow883 9mo ago

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 ffmpeg -i input.mp4 output.webm and tbh theyve made the interface about as smooth as can be given the scope of the problem.

dylan604 9mo ago
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"
mywittyname 9mo ago
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.

swiftcoder 9mo ago

Really good quickstart guide

gruez 9mo ago
>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".
- swiftcoder 9mo ago
  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.
  - fbias 9mo ago
    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.
  - wizhi 9mo ago
    Do you have any recommendations for literature on the subject of video encoding etc? I really want to learn more theory.
  - dylan604 9mo ago
    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.

tmaly 9mo ago

This is a great write up. Thank you for sharing.

BitsAndObjects 9mo ago

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

throwaway2046 9mo ago
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.
- embedding-shape 9mo ago
  > 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 :)
- binarygit 9mo ago
  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!
- heavyset_go 9mo ago
  No it doesn't, its Wayland support is a mess, its codec support is lackluster, and somehow the experience is worse when you use VA-API hardware decoding.
howenterprisey 9mo ago
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.

Jabrov 9mo ago

What's wrong with VLC?

Waterluvian 9mo ago
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_mpv_or_vlc_in_terms_of_video_quality/ 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.
- abanana 9mo ago
  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.
dylan604 9mo ago
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.
- krackers 9mo ago
  This matches with my observation, VLC tends to be more tolerant of slightly broken files or random issues that you encounter when streaming. Especially for hls streams, vlc often works when ffplay refuses to play it, I believe because vlc uses their own demuxer (instead of relying on libavformat).
wafflemaker 9mo ago

kwar13 9mo ago

Pretty good writeup but not sure why VLC is not recommended...?

embedding-shape 9mo ago

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.

ramesh31 9mo ago
technically correct is the best kind. who cares if it's obnoxious? take the opinions and agree or disagree with them.
- snakeboy 9mo ago
  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.
  - alwa 9mo ago
    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.
- dylan604 9mo ago
  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.

g4zj 9mo ago

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.

dspillett 9mo ago
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.
SG- 9mo ago
the author can't stand how it simply re-encodes videos instead of extracting the video tracks and puts them in new containers.
xp84 9mo ago
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.)
- Izkata 9mo ago
  Subtitles are another kind of stream aside from video/audio. Also there's one user-level aspect of MKV that makes it not too surprising to me: It can contain any number of video/audio/subtitle streams and the interface needs some way of allowing the user to pick between them. Easier to just skip that complexity, I guess.

pandemic_region 9mo ago

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.

cruffle_duffle 9mo ago
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.
- zzo38computer 9mo ago
  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.
  - duskwuff 9mo ago
    MPEG-TS files are just a pain to play in general. It was never intended as a file format for prerecorded video, and lacks some features (like seek indexes) which are required for reasonable playback. In most circumstances, a MPEG-TS file can be remuxed (without reencoding) to a more reasonable container format like MP4, and it'll play better that way. In some cases, it'll even be a smaller file.
- Agingcoder 9mo ago
  I used mplayer ( the ancestor to mpv as I’ve just realized ) in the early 2000s which I think could handle everything under the sun back then.
  - astrange 9mo ago

happytoexplain 9mo ago

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.

gruez 9mo ago
>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 https://news.ycombinator.com/item?id=46465349), it looks like it might indeed be caused by uncommon files that I haven't encountered.
- littlestymaar 9mo ago
  > 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.
- morshu9001 9mo ago
  Pretty sure VLC can play /dev/urandom
dooglius 9mo ago
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.
- u_sama 9mo ago

jokoon 9mo ago

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.

globnomulous 9mo ago
> to fastidious Do you mean "too fussy?"
- dylan604 9mo ago
  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
dylan604 9mo ago
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.
- astrange 9mo ago
  ffmpeg and libavcodec are the same project.
  - dylan604 9mo ago
    yes. but do you have to include the ffmpeg part to include just the other libraries?
    - astrange 9mo ago
      No, ffmpeg itself is a pretty small wrapper around them. But the rest are true libraries and not frameworks, so you have to make all kinds of playback decisions yourself. A/V sync is hard.

perching_aix 9mo ago

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.

weinzierl 9mo ago

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

echelon 9mo ago
[flagged]
- cnntth 9mo ago
  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.
  - echelon 9mo ago
    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.
    - unloader6118 9mo ago
      In any case, blindly apply upscaling is just wrong .. You apply it to where it is needed. Not every scene need the same treatment.
      - echelon 9mo ago
        The article simply says "Trust me, just don't."

craftkiller 9mo ago

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?

dylan604 9mo ago
> 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/b5b9552633567fa7658deee5aec60453/#other-parameters https://gist.github.com/arch1t3cht/b5b9552633567fa7658deee5a...

weinzierl 9mo ago

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?

ErroneousBosh 9mo ago
> 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.
- weinzierl 9mo ago
  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.
- memoriuaysj 9mo ago
  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
  - ErroneousBosh 9mo ago
    It really is gone. You can predict what you think it might have been, but you can't know what it was.
    - memoriuaysj 9mo ago
      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 https://en.wikipedia.org/wiki/Video_super-resolution

deleted 9mo ago

[deleted]

netsharc 9mo ago

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!

derefr 9mo ago
> 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.
- netsharc 9mo ago
  Maybe it's my bubble, but a video format is a name given to the description of how the video is stored as a stream of bytes/how to get the video from the stream of bytes, and "codec" is the piece of software (more generally, logic) that handles that work. It's not fine to say "oh those 2 things are the same", especially in an introduction, because then you're leading people astray instead of educating them.
  - derefr 9mo ago

coppsilgold 9mo ago

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

mmcclure 9mo ago

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 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 https://video-dev.org.

eviks 9mo ago

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

buzer 9mo ago

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.

Drybones 9mo ago

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

jaapz 9mo ago
> It is the Firefox of media players. So... the better option?
- SirMaster 9mo ago
  https://mpv.io/ https://mpv.io/

zzo38computer 9mo ago

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

liampulles 9mo ago
Did you use a decent piece of DVD authoring software? Here are some options: https://www.videohelp.com/software/sections/authoring-dvd https://www.videohelp.com/software/sections/authoring-dvd
- zzo38computer 9mo ago
  I used the "ffmpeg" to convert the video/audio, and then I used the "dvdauthor" to make the files into the video DVD format, and then I used the "genisoimage" to make the disk image file in the DVD format.

WalterBright 9mo ago

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.

deleted 9mo ago

[deleted]

hamonrye 9mo ago

Container formats for x.264, AVC, or H.264 are in .mkv or .mp4 codecs to encode and decode. [1] Technically the term codec refers to a specific program that can encode and decode a certain format.

jdprgm 9mo ago

Just writing off AI upscaling completely is bs. It's not some magic bullet to use on every video and there is a learning curve on how to apply but there are absolutely scenarios where you can get shockingly good results. I think a lot of people make judgements on it based on super small sample sizes. On a separate note also not mentioned llm's are really good at generating ffmpeg commands. Just discuss with chatGPT your source file and goals for a video and you can typically oneshot a targeted command even if you aren't familiar with ffmpeg cli.

tuna74 9mo ago
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.
liampulles 9mo ago
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.

ro_bit 9mo ago

I edit videos on a hobbyist level (mostly using davinci resolve to edit clips of me dying in video games to upload to a shareX host to show to friends). The big takeaway for me was reading that for quality/efficiency libx264 is better than nvenc for rendering h264 video. All this time I’ve assumed nvenc is better because it used shiny GPU technology! Is libx264 better for recording high quality videos too? I know it will run on CPU unlike NVENC but I doubt that’s an issue for my use case. Edit: from some googling it looks like encoding is encoding, whether it’s used for recording or rendering footage. In that case the same quality arguments the article is making should apply for recording too. I only did a cursory search though and have not had a chance to test so if anyone knows better feel free to respond

avidiax 9mo ago
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.
zten 9mo ago
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.

amelius 9mo ago

Nowadays, I just ask an LLM to give me the ffmpeg command that I need. No need to know anything about the video file anymore. (Of course if you're hosting billions of videos on a website like YouTube it is a different story, but at that point you need to learn a _lot_ more e.g. about hardware accelerators, etc.)

effnorwood 9mo ago

They are very hot

jorl17 9mo ago

I thought it was a good read, although with a couple of mistakes and a somewhat (IMO) childish sense of entitlement. This reads a bit like something a young teen who is heavy into tech wrote. I'm sure I could have authored something with the same overall tone and vibe when I was younger (perhaps not same quality, though!). Either way, it's a very decent read! The idea that YCbCr is only here because of "legacy reasons", and that we only we discard half of chrominance because of equally "legacy reasons" is bonkers, though.

zerocrates 9mo ago
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.
arch1t3cht 9mo ago
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.

socalgal2 9mo ago

Tangential but, at least for me, I find lots of video creators making 2-3 gig videos for no noticable difference in quality for me re-encoding them to 1/4th the size or less. My impression is, their audience equates file size with quality so the bigger the file the more "value" they got from the creator. This is frustrating because bigger files means hitting transfer limits, slower to download, slower to copy, taking more space, etc...

stavros 9mo ago
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.
liampulles 9mo ago
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.

arch1t3cht 9mo ago

Original post author here. It seems like the main criticisms I am getting for this article are because it's escaped past its main target audience, so let me clarify a few things. This post was born out of me hanging out in communities where people would make their own shortened edits of TV series and, in particular, anime, often to cut out filler or padding. Many people there would make many of the mistakes mentioned in the post, in particular reencoding at every step without knowing how to actually control efficiency/quality. I spent a lot of time helping out individual people one-on-one, but eventually wrote the linked article to collect all of my advice in one place. That way I (or other people I know) can just link to it like "Read the section on containers here," and then answer any follow-up questions, instead of having to explain from scratch each time. > It seems really weirdly written. / ranty format So, yes, it does. It was born out of one-to-one explanations on Discord. I wouldn't be surprised if it may seem condescending to a more advanced reader, but if I rant about some point to hammer it down it's because it's a mistake I've seen people make often enough that it has to be reenforced this much. I wouldn't write a professional article this way. The other point many people seem to get hung up about is the "hate" on VLC. Let me clarify that I do not "hate" VLC at all, I just don't recommend it. VLC is only mentioned once in the entire page, exactly because I didn't want to slot in an intermission purely to list a bunch of VLC issues. I felt like that would qualify more as "hate." That said, yes, pretty much anyone I know in the fansubbing or encoding community does not recommend VLC because of various assorted issues. The rentry post [1] is often shared to list those, though I don't like how it does not give sources or reproducible examples for the issues it lists. I really do want to go through it and make proper samples and bug reports for all of these issues, I just didn't have the time yet. Let me also clarify that I have nothing against the VLC developers. VideoLan does great work even outside of VLC, and every interaction I've had with their developers has been great. I just do not recommend the tool. [1] https://rentry.co/vee-ell-cee https://rentry.co/vee-ell-cee

rldjbpin 9mo ago
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/ http://fixounet.free.fr/avidemux/

liampulles 9mo ago

I remember using Gordian Knot to create avi files from my DVDs back when XviD was the pragmatic method for encoding videos, and the whole goal was to get movies under 700mb so that you could write them to a CD. Avisynth and community filters were largely geared towards undoing all sorts of crap done to an image because artifacts that were relatively unnoticeable on a general CRT television were quite apparent on a computer monitor, as well as to then prepare the video to look good once it has been highly compressed with XviD or DivX. These days I'm much more inclined to try and transparently encode the source material, tag it appropriately in the media container, and let the player adjust the image on the fly. Though I admit, I still spend hours playing around with Vapoursynth filter settings and AV1 parameters to try and get a good quality/compression ratio. I have to say that the biggest improvement to the experience of watching my videos was when I got an OLED TV. Even some garbage VHS rip can look interesting when the night sky has been adjusted to true black. Given the increasing abilities of TVs and processing abilities and feature sets of players, I'm not much persuaded to upgrade my DVD collection to Blu-Ray. Though I admit some of that is that I enjoy the challenge of getting a good video file out of my DVDs. I partially disagree with the use of ASS subtitles. For a lot of traditional movies, using SRT files is sensible because more players support it, and because it's often sensible to give the player the option of how to render the text (because the viewing environment informs what is e.g. the appropriate font size).

vivzkestrel 9mo ago

would be nice if someone like epic spaceman actually broke down how videos are encoded, stored, processed and how encoding algorithms work visually, i am bad at understanding things by reading about them