[HN Gopher] What you need to know before touching a video file
___________________________________________________________________
What you need to know before touching a video file
Author : qbow883
Score : 252 points
Date : 2025-12-27 19:17 UTC (6 days ago)
(HTM) web link (gist.github.com)
(TXT) w3m dump (gist.github.com)
| webdevver wrote:
| 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 wrote:
| 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 wrote:
| 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 wrote:
| Really good quickstart guide
| gruez wrote:
| >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 wrote:
| 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 wrote:
| 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 wrote:
| Do you have any recommendations for literature on the
| subject of video encoding etc? I really want to learn more
| theory.
| dylan604 wrote:
| 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 wrote:
| This is a great write up. Thank you for sharing.
| EdNutting wrote:
| 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 wrote:
| 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 wrote:
| > 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 wrote:
| 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!
| howenterprisey wrote:
| 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.
| bcye wrote:
| Why is that?
| amlib wrote:
| 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...
| zdw wrote:
| 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.
| jamesnorden wrote:
| 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...
| EdNutting wrote:
| 13 years since that post and this is the first time I'm
| hearing of this long-past issue.
|
| Haters gonna hate I guess.
| hhh wrote:
| I still have this problem every day.
| nickthegreek wrote:
| It has never been very common for VLC to cause video
| corruption.
| EdNutting wrote:
| 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
| ryandrake wrote:
| 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
| gruez wrote:
| 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.
| jandrese wrote:
| 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.
| Forgeties79 wrote:
| 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.
| Jabrov wrote:
| What's wrong with VLC?
| Waterluvian wrote:
| 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.
| abanana wrote:
| 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 wrote:
| 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.
| wafflemaker wrote:
| 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).
| kwar13 wrote:
| Pretty good writeup but not sure why VLC is not recommended...?
| embedding-shape wrote:
| 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 wrote:
| technically correct is the best kind. who cares if it's
| obnoxious? take the opinions and agree or disagree with them.
| snakeboy wrote:
| 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 wrote:
| 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 wrote:
| 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.
| pomian wrote:
| 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!
| yaur wrote:
| 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.
| knowitnone3 wrote:
| the author never talked about power savings or cooling
| bills, they talked about quality so they are still correct.
| encom wrote:
| 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.
| mrguyorama wrote:
| 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?
| jaapz wrote:
| How can I disagree when they don't provide a reasoning behind
| why something is the better option?
| Etheryte wrote:
| 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.
| MallocVoidstar wrote:
| IIRC VLC used the wrong primaries for converting to RGB for a
| long time (years) even after it being reported to them as
| wrong
| gruez wrote:
| >even after it being reported to them as wrong
|
| Source?
| linolevan wrote:
| 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.
| ErroneousBosh wrote:
| 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.
| ffsm8 wrote:
| 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
| LiamPowell wrote:
| 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.
| eviks wrote:
| 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.
| ffsm8 wrote:
| 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.
| eviks wrote:
| 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
| zenmac wrote:
| The author did mention to use MPV, which is much much
| lightweight than VLC. Being using it as default for quite
| some times now.
| knowitnone3 wrote:
| 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.
| rfl890 wrote:
| VLC has always caused problems for me when seeking backwards
| (graphical glitches). mpv has never caused any issues in this
| regard.
| my65thaccount wrote:
| VLC and mpv literally use the same underlying codec
| library. (As well as ffmpeg.)
| eviks wrote:
| 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=...
| homebrewer wrote:
| 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.
| eduction wrote:
| And? It's a GitHub gist not an oreilly book. Context.
| g4zj wrote:
| 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 wrote:
| 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- wrote:
| the author can't stand how it simply re-encodes videos instead
| of extracting the video tracks and puts them in new containers.
| xp84 wrote:
| 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.)
| pandemic_region wrote:
| 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 wrote:
| 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 wrote:
| 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.
| happytoexplain wrote:
| 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 wrote:
| >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.
| littlestymaar wrote:
| > 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.
| dooglius wrote:
| 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 wrote:
| 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
| dotancohen wrote:
| 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.
| mywittyname wrote:
| The only current VLC issue I encounter regularly is the
| subtitles one. I'm a lite video user, so I'm not sure the
| technical details, but some subtitle formats render black-on-
| black in VLC, but work fine on Plex/TV.
|
| I've also encountered the odd "this video is corrupted" error
| that persists even after re-encoding. But I've never thought
| to troubleshoot to see if it's a VLC, and instead just get a
| different version.
| jlarocco wrote:
| 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.
| perching_aix wrote:
| 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.
| jlarocco wrote:
| And you think _everybody else_ should stop using it because
| you had problems?
|
| I'll make up my own mind on it.
| gpvos wrote:
| Where did perching_aix say that?
| perching_aix wrote:
| 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.
| knowitnone3 wrote:
| 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?
| aiahs wrote:
| 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.
| perching_aix wrote:
| 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.
| EdNutting wrote:
| 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.
| miladyincontrol wrote:
| 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.
| gpvos wrote:
| Do you have sources for that? As far as I know VLC has actually
| always been famous for supporting basically every format.
| mtVessel wrote:
| | I assume nowadays it's much better...
|
| It's not, but the Linux weenies won't hear of it. Maybe it's a
| great choice on Linux, but on Windows, it often renders things
| much worse than stock WMP (both legacy and modern). Videos with
| a lot of motion play especially poorly.
|
| But, yeah, it opens everything.
| jokoon wrote:
| 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 wrote:
| > to fastidious
|
| Do you mean "too fussy?"
| dylan604 wrote:
| 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 wrote:
| 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.
| perching_aix wrote:
| 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.
| dylan604 wrote:
| 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.
| memoriuaysj wrote:
| 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
| perching_aix wrote:
| 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.
| memoriuaysj wrote:
| 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.
| perching_aix wrote:
| 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).
| memoriuaysj wrote:
| 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
| weinzierl wrote:
| _" 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?
| perching_aix wrote:
| 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
| ErroneousBosh wrote:
| Topaz looks bloody awful. Instead of big blocky upscaled pixels
| you've got weird artifacty "oil painting effect" smeary blobs.
| craftkiller wrote:
| 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 wrote:
| > 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...
| fenwick67 wrote:
| 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
| mafuyu wrote:
| 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.
| memoriuaysj wrote:
| 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
| leni536 wrote:
| I found this explanation useful:
|
| https://youtu.be/uMSV4OteqBE?si=QCOL_2_VpE7tBdAu&t=83
| craftkiller wrote:
| Hah, that's exactly how it feels!
| weinzierl wrote:
| 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 wrote:
| > 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 wrote:
| 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 wrote:
| 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 wrote:
| It really is gone. You can predict what you think it might
| have been, but you can't know what it was.
| memoriuaysj wrote:
| 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
| weinzierl wrote:
| 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.
| ErroneousBosh wrote:
| No, it's not "restoring detail". The information is gone.
|
| It is predicting what the information might maybe have
| been like.
| latexr wrote:
| I usually use a shortcut in mpv to extract the screenshot. If I
| want to do it via the command-line: ffmpeg -ss
| 00:00:12.435 -i '/Users/weinzieri/videofile.mp4' -vframes 1
| '/Users/weinzieri/image.png'
|
| 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".
| perching_aix wrote:
| 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.
| netsharc wrote:
| 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 wrote:
| > 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.
| coppsilgold wrote:
| 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
| mmcclure wrote:
| 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.
| eviks wrote:
| > 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 wrote:
| 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 wrote:
| 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.
| jaapz wrote:
| > It is the Firefox of media players.
|
| So... the better option?
| SirMaster wrote:
| https://mpv.io/
| Drybones wrote:
| 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
| pseidemann wrote:
| The person is asking for the better option.
| savolai wrote:
| -1 tab containers
|
| Please elaborate on "features".
|
| Does chromium have non-google sync?
| Drybones wrote:
| Chromium based browsers have non-google sync. Vivaldi
| implements their own encrypted sync service and I believe
| Brave does as well.
|
| But I am talking about browser feature support, not stuff
| that can supplemented with an extension like a password
| manager.
|
| Firefox has poor support for modern web features
| including video processing and encoding which makes it
| very bad at web conferencing/video calls or in-page
| streaming.
|
| Firefox's developer tools and console is also much worse
| and missing important features.
|
| Other features Firefox is missing or has poor support for
| compared to Chromium are WebGPU, WebTransport, Periodic
| Background Sync, and parts of WebRTC. Plus various APIs
| for web serial, badging, and Web Share are missing
| partial or full support.
|
| Firefox still doesn't have functional HDR for images and
| videos including AV1.
| savolai wrote:
| Oh I thought you meant actual chromium browser.
|
| Those seem rather marginal features from my pov but of
| course once you need them, you need them, I guess.
| usefulposter wrote:
| Many HN readers won't be familiar with the fansub culture that
| this writeup originates from, so sharing a helpful resource in
| case anyone is interested in learning more:
|
| ENTRY LEVEL FANSUBBERS' BEGINNERS GUIDE:
|
| https://github.com/zeriyu/fansub-guide
|
| Hope this helps anyone interested in the ancient art of subbing
| Japanese animes!
|
| Be sure to read _every_ link thoroughly, and don 't worry,
| there are more link lists linked from the above link list.
|
| Arigatou gomenasai!
| ambicapter wrote:
| Wait, so this categorical dismissal of VLC is just coming
| from a specific fandom community?
| M95D wrote:
| The only one who cares, apparently...
| sho_hn wrote:
| To be fair, it's a fandom community with high requirements
| and standards toward video players and that really knows
| its stuff.
| nticompass wrote:
| 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.
| Drybones wrote:
| It still is, but it's not as recommended over MPV but I'm not
| as familiar with what it decodes and renders wrong in
| comparison, but it is still suggested over VLC in Anime
| circles.
| Lammy wrote:
| I still use K-Lite Codec Pack on all of my Windows systems:
| https://github.com/Microsoft/winget-
| pkgs/tree/master/manifes...
| perching_aix wrote:
| Yes: https://github.com/clsid2/mpc-hc
| BoppreH wrote:
| I'm also surprised by people's defense of VLC. It's a nice
| project, especially when it was created, but the bugs I
| regularly encountered were _numerous_ and in seemingly common
| use cases.
|
| Here's a post I made 4 years ago describing each bug, shortly
| before switching to MPV:
| https://www.reddit.com/r/VLC/comments/pm6y1n/too_many_bugs_o...
| jiggawatts wrote:
| > It is the Firefox of media players.
|
| Ironically, my main gripe about Firefox is that it has no
| support for HDR content and its colour management is disabled
| by default... and buggy when enabled.
| userbinator wrote:
| It works well enough, and I doubt the majority of VLC users are
| watching anime with it.
| zzo38computer wrote:
| 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.)
| WalterBright wrote:
| 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.
| hamonrye wrote:
| 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 wrote:
| 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.
___________________________________________________________________
(page generated 2026-01-02 23:00 UTC)