On Thu, 29 Aug 2024 08:20:22 +0000 Andrea paz via Cin <[email protected]> wrote:
Aside from how CinGG works, from what I understand YT recompresses the original video even if it is set similarly to the way they compress. In short, YT's compression goes over whatever settings we make, whatever programs we use (from https://support.google.com/youtube/answer/4603579?hl=en: "Note that YouTube always re-encodes videos to optimize their playback quality"). So compression on compression leads to banding. Ideally, you should start with a poorly or uncompressed original so that YT compression leads to better results (less banding). The downside is that a poorly compressed file (Prores, DNx, ...) is about 10 times larger than an h264...
I understand the fact youtube re-encodes everything it gets. But, h264->h264 re-encoding usually makes your video more blockly. The "color banding" is a different thing. Yes, it makes these blocks more visible, but it's a different problem. Sometimes color banding has a fundamental cause of "not enough colors in 8bit pallete". Tom Scott has a great explanation of this: https://youtu.be/h9j89L8eQQk And sometimes color banding comes from crappy video processing, which is my case, unfortunately. What I'm trying to do is to eliminate the last step of color palette compression, which is being performed by youtube during 8bit (full/jpeg/pc range) to 7.77bit (limited/mpeg/tv range) conversion. To do this, I need to make sure a video I upload to youtube is already in 7.77bit. Therefore, youtube will re-encode my h264 and add more blocks, but at least it won't compress the color palette.