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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

here you go

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

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

Compare to

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

I found this explanation useful:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

>Really good quickstart guide

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