What you need to know before touching a video file(gist.github.com) |
What you need to know before touching a video file(gist.github.com) |
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.)
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.
I can't say I've experienced either of the ones mentioned, but I have had trouble in the past with output resolution selection (ending up with a larger file than expected with the encoding resolution much larger than the intended display resolution). User error, of course, but that tab is a bit non-obvious so it might be fair to call it a footgun.
The author's POV is that the handbrake is a lossy conversion and often people use it in cases where they could have used a different tool that is lossless.
My uses of handbrake are that I always want a lossy conversion so no issue. A good example is anytime I make screen capture and want to post it on github. I want it to be under the 10meg limit (or whatever it is) so I want it to be re-encoded to be smaller. I don't mind the loss in quality.
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.
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?
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.)
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.
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!
> 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!
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.
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.
But yes, as the other reply says, I am aware of this distinction, and I make a point not to use the word "codec" at any other point in the article. and explain in a lot of detail how much the encoder matters when it comes to encoding in some format. I mention the term to make people aware that it exists.
But, you're right, I will clarify this a bit more.
ffmpeg -ss 00:00:12.435 -i '/Users/weinzieri/videofile.mp4' -vframes 1 '/Users/weinzieri/image.png'
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.
video has certain temporal statistics which can allow you to fit the missing information
only true blurred white noise is impossible to recover
This is actually possible:
https://en.wikipedia.org/wiki/Deconvolution
If you have a high-quality image (before any compression) with a consistent blur, you can actually remove blur surprisingly well. Not completely perfectly, but often to a surprising degree that defies intuition.
And it's not a prediction -- it's recovering the actual data. Just because it's blurred doesn't mean it's gone -- it's just smeared across pixels, but clever math can be use to recover it. It's used widely in certain types of scientific imaging.
For photographers, it's most useful in removing motion blur from accidentally moving the camera while snapping a photo.
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.
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.
(nb they did often use their own demuxers instead of libavformat)
I think people of a certain age picked up that the things inside video containers were "codecs" when we all had to install "codec packs." The things inside those packs were literally codecs — encoder/decoder libraries.
But when AV software of the time (media players, metadata taggers, library software, format conversion software, etc) needed to let you choose which audio or video bitstream format to use for encoding [i.e. pick a codec plug-in library to pass the bitstream through]; or needed to tell you that you needed to install codec plug-in X to play file Y, they would often equivocate the codec with the AV bitstream format(s) they enabled the encoding/decoding of. Especially when the software also had a separate step or field that made reference to the media container format. It was not uncommon to see a converter with a chooser for "output format" and another chooser for "output codec" — where the "codec" was not a choice of what library plug-in to use, but a choice of which AV bitstream format to target. (Of course, relying on the assumption that you'd only ever have one such codec library installed for any given AV bitstream format.)
---
Heck, this is still true even today. Go open a media file in VLC and pop open the Media Information palette window. There's a "Codec Details" tab... and under each stream, the key labelled "Codec" has as its value the name of the AV bitstream format of the stream. I just opened an M4A file I had laying around, and it says "MPEG AAC audio (mp4a)" there.
My understanding of why VLC does it that way [despite probably decades of pedants pointing out this nitpick], is that there's just one codec library backing pretty much all of VLC's support for AV bitstream formats — "libavcodec". Players that rely upon plug-in codec libraries might instead have something like "MPEG AAC audio (libavcodec)" in this field. But since VLC only has the one codec, it's implicit.
Even though, to be pedantic, a media-info "Codec" field should just contain e.g. "libavcodec"; and then there should be a whole second field, subordinate to that, to describe which of the AV bitstream formats supported by the codec is being used.)
---
I also recall some old versions of iTunes using the word "Codec" to refer to AV bitstream formats in metadata and in ripping settings. Not sure if that memory is accurate; current versions seem to skirt the problematic nomenclature entirely by making up their own schema. Modern Music.app, on a song's "File" tab, gives the container format as the file's "kind", and then gives some weird hybrid of the AV bitstream format, the encode-time parameters, and the originating software, as an "encoded with" field.
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
It is predicting what the information might maybe have been like.
I get that what you're describing can statisically "unblur" stuff you've blurred with overly-simplistic algorithms.
I can provide you with real-world footage that has "natural" motion blur in it, if you can demonstrate this technique working? I'd really like to see how it's done.
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.
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...
All other players lost their plot when they tried to steer users into some madness pit of millions tweaks and configurations that somehow excites aughors of those players and some cohort of people who encode videos that way.
I istall vlc very single time, because this is a blunt answer to all video playing problems, even if its imperfect. And walked away from ever single player who tries to sell me something better asking to configure 100 parameters I've no idea about. Hope this answers the question why VLC won.
So... the better option?
Depends on what you care about.
For me, Firefox really lacks in handling of very large amounts of tabs and a lot of features that I specifically use Vivaldi for. Does that mean Vivaldi is the best? Yes and No, it depends on what you care about.
Is Firefox still a good browser? As far as I know, yes. But I don't use it much at all because it doesn't give _me_ what I want and need.
And yes, I do actually need a large amount of tabs open at the same time very regularly due to the depth of references I work against in my line of work. That's on top of saving lots of bookmarks and syncing them via nextCloud.
You like Firefox? Great, keep at it.
You want to see features that aren't necessarily elsewhere? Consider trying Vivaldi and seeing if it's great for you or not.
Let's not act like browser selection is binary, because it isn't, and it really hasn't been since netscape navigator was new. And even then it's up for debate.
Disliking Google Chrome proper is one thing, but Chromium is superior in every way. Rendering, features, speed, memory management
I even encounter this in professional a/v contexts! If VLC can read and decode your stream, that's a good sign that most things should able to view it, but it absolutely should not be trusted as any measure of doing things correctly/to spec.
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.
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!
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.
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).
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.
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)!
If folks want to get involved, there's also a chat community that's pretty active: https://video-dev.org.
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
Why? I only know Topaz and I always thought it had its narrow but legitimate uses cases for upscaling and equalizing quality?
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
The reasons stated against upscaling were that (re-)encoding video files should generally be done in a way that preserves as much of the original information and intent as possible. AI upscalers add information where there is none, thus modifying the video in a way that goes against that goal.
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.
Do you mean "too fussy?"
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?
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).
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...
Unless one lives in a country where the internet is slow and/or hard drives are expensive, I think the audience does not care.
My hypothesis is that they use a really high quality value, and that there are diminishing returns there.
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
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
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.
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.
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).
Grump grump grumpity grump. Same experience with every dashcam I've bought over the years.
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.
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.
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".
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.
[1] Technically the term codec refers to a specific program that can encode and decode a certain format.
This indeed just seems to jump-in in the middle and give a bunch very specific recommendation. I have no idea if they're good or bad recommendations but this doesn't seem like the way to teach good procedures.
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
There's a reason why VLC isn't used in broadcast stuff and ffmpeg is.
So no, I'm not just going to take an opinion without more information. I don't change my mind just on say so.
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.
mpv is okay but its complete reliance on command line flags and manually written config files makes it a bore.
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 :)
[1] https://www.reddit.com/r/glitch_art/comments/144vjl/vlc_star...
Haters gonna hate I guess.
A lesson to learn in that.
Lol
???
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.
Yes, that was in the 2000s though. During the 2010 VLC started falling behind because its shortcomings overweighted its capabilities.
So at least from those times
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.
I don't doubt that there's some obscure, elite videophile hate towards it, but I'm hardly going to stop using it because a few random internet strangers hate on it.
My own anecdotal experience with VLC was that while every update fixed something, they also broke something in return - and these updates were common. This got annoying enough at some point for me to hop ships, and so I switched to mpc-hc and never looked back.
I've since also tried (and keep trying) the to-me still newfangled mpv, but I'm not a fan of the GUI or the keybinds. I know it can be customized, but that's not something I'm interested in doing. I know there are alternative frontends as well, but I checked and they're not to my liking either. So I mostly just use it for when mpc-hc gives out, such as really badly broken media files, or anything HDR.
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.
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.
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.
(Lots of corner cases apply and VLC developers do assist ffmpeg, host a conference, etc.)
This was probably not the most accurate explanation, but hopefully it's enough to point you in the right direction.
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...
For what it's worth, the display I liked best was a monochrome terminal, a vt220, Let me explain, a crt does not really have pixels as we think of them on an modern display, but they do have a shadow mask which is nearly the same thing. however a monochrome crt(as found in a terminal or oscilloscope) has no shadow mask, the text of those vt220 was tight, it was a surprisingly good reading experience.
If so, try this: https://gregbenzphotography.com/hdr-gain-map-gallery/
Clicking the "Limit to SDR" and "Allow Full HDR (as supported)" should show a significant difference if you device supports HDR. If you don't see a difference then your device doesn't support HDR (or your browser)
For these images, there's a specific extension to JPEG where they store the original JPEG like you've always seen, and then a separate embedded gain map to add brightness if the device supports it. That's for stills (JPEGs) though, not video but the "on the wire difference" is that gain map
I'm not an expert but for videos, ATM, afaict, they switched them to 10bits (SDR is 8bits), and added metadata to map that 10 bits to values > "white" where white = 100nits. This metadata (PQ or HLG) can map those 10 bits up to 10000 nits.
1. A larger color space, allowing for more colors (through different color primaries) and a higher brightness range (though a different gamma function)
2. Metadata (either static or per-scene or per-frame) like a scene's peak brightness concrete tonemapping settinsg, which can help players and displays map the video's colors to the set of colors it can display.
I actually have a more advanced but more compact "list of resources" on video stuff in another gist; that has a section on color spaces and HDR:
https://gist.github.com/arch1t3cht/ef5ec3fe0e2e8ae58fcbae903...
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
> 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
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.
Let's just say we were encoding a list of numbers. So we get a keyframe (an exact number) and then all frames after that until the next keyframe are just deltas. How much to add to that keyframe number
keyframe = 123
nextFrame += 2 // result = 125
nextFrame += 3 // result = 128
nextFrame -= 1 // result = 127
The "spec" or "codec" only defines that each frame is encoded as a delta. it doesn't say what those detlas are or how they are computed, only how they are applied.
This is also why most video encoding software has quality settings and those settings often includely the fact higher quality is slower. Some of those settings are about bitrate or bitdepth or other things but others are about how much time is spent looking for the perfect or better delta values to get closer to the original image as searching for bettter matches takes time. Especially because it's lossy, there is no "correct" answer. There is just opinion.
Soooo with everyone getting used to creative names instead of descriptive names over the past decade or two, I guess "codec" just became a blob and it just never crosses peoples' minds that this is right there in the name: COding/DECoding. No ENCoding.
So that's a swing and a miss I'm afraid. But I'm very interested to hear what do you think a "coder" library does in this context if not encode, and why is it juxtaposed with "decoder" if not for doing the exact opposite.
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
Makes a lot of sense in retrospect, to the extent it bothers me I haven't figured it out myself earlier.
Its main claim to fame is that it "plays everything," and it rose to prominence in the P2P file sharing era. During this time, Windows users often installed so many "codec packs" that DirectShow would eventually just have an aneurysm any time you tried to play something. VLC's media stack ignored DirectShow, and would still play media on systems where it was broken.
We're past that problem, but the solution has stuck around because "installing codecs will break my computer, but installing VLC won't" is the zombie that just won't die.
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.
Source?
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.
Seeking is surprisingly difficult. Many container formats don't support it at all, because they don't have indexes, and so it's easy to mess up playback or lose A/V sync by trying it. Constructing the index is about as hard as decoding the entire file too.
[1] https://github.com/mpv-player/mpv/wiki/libavformat-mkv-check...
I've also seen many reports of it lagging or choking on complex subtitles, though I haven't had the time to investigate that myself yet.
Either way, it's not as simple as "both players use libass." Libass handles the rasterization and layout of subtitles, but players need to handle the color space mangling and blending, and there can be big differences there.
And the first party ones available there are for testing, with missing features :/
We do not have this kind of problems with VLC.
- 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.
> single best media player out there ... VLC is not recommended.
> Hanging out in subtitling and video re-editing communities, I see my fair share of novice video editors and video encoders, and see plenty of them make the classic beginner mistakes when it comes to working with videos.
Seriously, you quoted pretty much the only sentence in the whole article that's about plain playback, and even in that bullet point, the following sentence mentions hardcoding subtitles.
> It turns out that reading the (f.) manual actually helps a lot!
The non-recommendation of VLC vs mpc/mpv is literally for playback as I quoted! MPC also doesn't do any encoding, yet it's recommended
> the following sentence mentions hardcoding subtitles.
And that sentence starts with "Apart from simply watching the video" to tell you the same thing the previous sentence told you - that comparison where VLC was not receommended was about playback, not editing
hardware encoders (like the ones in GPUs) typically work realtime-ish, so they do minimal exploration of encoding space
you also have the one-pass/two-pass thing which is key for unlocking high quality compression
I’m not super knowledgeable about modern video players- I do like Infuse, which is in the App Store.
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...
It's nowhere near enough codes, especially in darker regions. That's one reason 10-bit is so important, another is that h264 had unnecessary rounding issues and adding bit depth hid them.
If you want a MPV-based player GUI on macOS, https://github.com/iina/iina is quite good.
[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.
I'll make up my own mind on it.
Let's be kind. Clearly not what either of us were thinking or intended to convey.
The point was that the rest of the article wasn't and if you unironically can't tell that, then you should seriously train your reading comprehension.
Being faster, prettier and using less memory[1] is pointless if the browser won't let me block all ads.
I mean, it's like comparing a turd sandwich made with expensive exotic bread, and a cheese sandwich made with cheap grocery store break.
Sure, the one has great exotic bread, but I don't want the turd it comes with.
So, yeah, it actually doesn't matter how much prettier, faster or smaller web pages are with Chrome, at least FF lets me (currently) block almost anything.
---------------------------------------
[1] Chrome beats out FF in exactly one of those, and it's not the memory or speed. Turns out ads take up a lot of RAM, and slow down pages considerably.
Please elaborate on ”features”.
Does chromium have non-google sync?
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.
Those seem rather marginal features from my pov but of course once you need them, you need them, I guess.
Firefox does WebRTC fine. AV1 works, simulcast works, calls and streaming work. Chrome still leads on performance tweaks and extra APIs, but “very bad” is just wrong.
DevTools aren’t “much worse.” Different, less popular, sometimes better (CSS, network). Chrome wins mainly because everyone targets it first.
API gaps are real but the list is sloppy. WebGPU and WebTransport exist in Firefox now, just behind on advanced bits. Periodic Background Sync barely matters. WebRTC support keeps closing the gap.
Missing stuff like Web Serial, Badging, fuller Web Share? True, and mostly intentional.
HDR is the weakest claim that actually holds. AV1 decode exists, but HDR support still feels half-done.
TL;DR: Firefox lags Chromium in breadth and polish, not in core modern web capability. Calling it bad for video or modern apps doesn’t match reality.” ’