Re:H.264 is magic (2016)
by zeroimpl on Thursday May 23, 2019 @11:13PM
(#19998160)
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)
[ Parent
| 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.
Re:H.264 is magic (2016)
by kevin_thibedeau on Friday May 24, 2019 @12:08AM
(#19998406)
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.
Re:H.264 is magic (2016)
by pingucrimson on Friday May 24, 2019 @10:12AM
(#20001692)
This. Subsampling is kind-of the most primitive method of "lossy compression" there is.
Re:H.264 is magic (2016)
by brandmeyer on Friday May 24, 2019 @08:58AM
(#20000962)
Chroma subsampling is a natural way to leverage the information content produced by Bayer filters in most cameras.
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
Re:H.264 is magic (2016)
by plorkyeran on Friday May 24, 2019 @03:14AM
(#19999192)
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
Re:H.264 is magic (2016)
by WAHa_06x36 on Friday May 24, 2019 @07:11AM
(#20000295)
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.
Re:H.264 is magic (2016)
by WAHa_06x36 on Monday May 27, 2019 @04:42AM
(#20020459)
"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.
Re:H.264 is magic (2016)
by ComodoHacker on Friday May 24, 2019 @03:24AM
(#19999238)
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