Hacker News Reader

Comment by zeroimpl | Hacker News Reader

Chroma subsampling is a terrible idea in the digital era. You should just assign a different compression factor to the chroma channels instead. I don't understand why we keep using this system of discarding 75% of the color data BEFORE applying the lossy compression algorithm. (Well I do know of one argument - apparently it reduces the amount of CPU time required to compress and decompress the data, but I think that's a pretty lame reason)

View on HN

> You should just assign a different compression factor to the chroma channels instead [of subsampling chroma].

The good news is that we don't need to change the H.264 standard for this.

Supposing that:

- most of the already deployed embedded H.264 decoders support 4:4:4 profiles

- non-chroma-downsampled input content is available

Then, it's only a matter of changing encoder implementations to do exactly as you say.

I'm pretty sure there is plenty of 444 content. Movies are likely filmed/edited at 444, they are provided to theaters at 444, but they are generally only made available to consumers at 420.

I believe the reason is that most hardware decoders sold to consumers do not support anything above 420. As Blu-rays and such are all currently 420, the chip makers don't have much incentive to support 444. It's a shame because your TV fully supports 444, and the difference can be huge on some content.

There is a physiological reason that you can't resolve the chroma at the same resolution as the luminance.

But even after you decide to allocate << 50% of your information bandwidth to chroma, there may still be ways to use that allocation than are more effective (perceptually) than 2x downsampling.

This. Subsampling is kind-of the most primitive method of "lossy compression" there is.

Chroma subsampling is a natural way to leverage the information content produced by Bayer filters in most cameras.

https://en.wikipedia.org/wiki/Bayer_filter

Chroma subsampling is nice because it lets you "delay" some of the upsampling to later device in the pipeline, like your GPU outputs YUV4:2:0 and your monitor hardware does the chroma upsampling. If you don't want that, use 4:4:4. This feature you're talking about where you assign different compression factor to different color planes is already implemented in x264:

https://en.wikibooks.org/wiki/MeGUI/x264_Settings#chroma-qp-...

Fully agree. Seeing all the color conversion errors it can lead to also.. In the future it would be more simple for everyone to always use 4:4:4

x264 supports encoding 4:4:4 (i.e. no chroma subsampling) video. There's some very obvious cases where it produces better results, but it's typically just slower with no upside.

The GP is talking about using 4:4:4 but having lower bitrates for chroma channels than luminance

That is still slower than subsampling.

But it can produce a result which looks better at the same bitrate. It’s not all about speed.

"but it's typically just slower with no upside" was the original statement.

Good point. When compressing a full video to a size target, I've always felt the 1080p, squashed version was still better than the 720p, less-squashed version.

Subsampling actually is a form of quantization, which in turn is a form of lossy compression.

A bad form of it given that you already have the ability to reduce bitrate per channel on the encoder side. It leads to a lot of issues like pixel format conversion and decoders incompatibilities for example

Reply on news.ycombinator.com