problem with the encoded file itself (DNxHR), or YouTube?...

I'm upscaling some gaming footage, from 1920x1200 to 4K (MXF OP1A DNxHR 444 10-bit; this is overkill as I believe 8-bit would suffice, but I like to overshoot since I don't know exactly what I'm doing quite yet).

Generally speaking, I have not manipulated anything in the Color tab in Resolve.

Problem: when I upload the finished product to YouTube, and YouTube is done processing it, it appears a bit too "colourful" or saturated overall (at all resolutions). What I mean is, it's a bit darkish/rich in colour; Basically, it's not like it appears in Resolve itself, and doesn't look good. I need it more washed out, like the original source footage, and what I see in Resolve.

I can't really test it on its own (separate from YouTube), or rather, I don't know how, because my only media player is VLC, and I'm fairly certain that has a known issue with making colours appear off (overly saturated) in this type of file.

encoded in 1080p (MP4 264):


encoded in 4K (MXF DNxHR 444 10-bit) (playing in 1080p for fair comparison):


Any help would be appreciated.

Honestly, at this point, I don't even know if I've simply been staring at this video and its frames for too long, and my judgement is sort of off.

DNxHR 444 is Full Level.

Use DNxHR HQX 12 bit and see if it behaves the way you want to.

Or force Video levels in the deliver page.

DNxHR 444 is Full Level.

Use DNxHR HQX 12 bit and see if it behaves the way you want to.

Or force Video levels in the deliver page.

Interesting.

If 10-bit is considered Full Level, what is 12-bit considered?

Also, if you could elaborate between 10-bit versus 12-bit, and more specifically, 444 versus HQX, would be really helpful in my research.

DNxHR 444 is Full Level.

Use DNxHR HQX 12 bit and see if it behaves the way you want to.

Or force Video levels in the deliver page.

Interesting.

If 10-bit is considered Full Level, what is 12-bit considered?

Full/video levels are not about bit depth. It is the mapping of black and white points for a given range. For example, 8-bit video is 0-255 in RGB. Full level means the luminance range is mapped 0 for black and 255 is white. In video level, 16 is black and 235 is white. 10-bit video level is 64 and 940 respectively.
The actual pixel value is not changed, just how it is decoded and displayed.

DNxHR 444 is Full Level.

Use DNxHR HQX 12 bit and see if it behaves the way you want to.

This seems to have worked.

Is it the HQX part that "fixed" it, or the 12-bit part?

DNxHR 444 is Full Level.

Use DNxHR HQX 12 bit and see if it behaves the way you want to.

Or force Video levels in the deliver page.

Interesting.

If 10-bit is considered Full Level, what is 12-bit considered?

Full/video levels are not about bit depth. It is the mapping of black and white points for a given range. For example, 8-bit video is 0-255 in RGB. Full level means, the luminance range is mapped 0 is black and 255 is white. In video level, 16 is black and 235 is white. 10-bit video level is 64 and 940 respectively.
The actual pixel value is not changed, just how it is decoded and displayed.

Struggling to understand, but this is most helpful anyway.

Now I have to take another drink! Read these:

"Grading for Mixed Delivery: Cinema, Home, and Every Screen in Between" by Cullen Kelly
https://blog.frame.io/2019/10/14/gradin ... -delivery/

and

"How to Deal with Levels: Full vs. Video"
by Dan Swierenga
https://www.thepostprocess.com/2019/09/ ... l-vs-video

and I think both cover the issues and the solutions very well. These videos also cover it:

Understanding color management is also helpful:

"Color Management for Video Editors"
https://jonnyelwyn.co.uk/film-and-video ... o-editors/

The above articles will explain why things change on different displays, different playback engines, and the importance of calibration and color-managed outputs.

I generally try to export a second or two of SMPTE Bars at the head of the project, and I import the file back into Resolve to check it on scopes to verify all the levels are correct. Using calibrated displays is a must -- without that, you have no idea what you're looking at. We also accept that the basic picture is going to change a little bit on different devices, because that's life.

Now I have to take another drink! Read these:

Thnx for these. I'll definitely look at it all, but I can't guarantee it will "click" right away or anything.

Is it the HQX part that "fixed" it, or the 12-bit part?

Its the Data Levels : Video that "fixed" it. I think you can force Video Levels on DNxHR 444 too. There's a levels section in the deliver page under the Advanced Settings.

Is it the HQX part that "fixed" it, or the 12-bit part?

Its the Data Levels : Video that "fixed" it. I think you can force Video Levels on DNxHR 444 too. There's a levels section in the deliver page under the Advanced Settings.

Thought so, but then why do 12-bit? Why not 10-bit HQX?

Is it the HQX part that "fixed" it, or the 12-bit part?

Its the Data Levels : Video that "fixed" it. I think you can force Video Levels on DNxHR 444 too. There's a levels section in the deliver page under the Advanced Settings.

Thought so, but then why do 12-bit? Why not 10-bit HQX?

You can do whatever flavor you wish. It all depends on what your source file is. If its 10bit then don't bother with 12bit. For me, its usually RAW from cinema cameras so 12bit retains more color.

If it ends up on Youtube it doesn't really matter since Youtube trashes it anyway.

You can do whatever flavor you wish. It all depends on what your source file is. If its 10bit then don't bother with 12bit. For me, its usually RAW from cinema cameras so 12bit retains more color.

If it ends up on Youtube it doesn't really matter since Youtube trashes it anyway.

Ignoring YouTube being the final format, and speaking generally: if my source video is 8-bit, then even 10-bit is overkill and pointless, right (as far as bit-depth goes)?

I've just been out of the loop for a while and so I'm making sure I haven't forgotten the basics.

YouTube automatically transcodes any video uploaded in an H.264 master file and creates multiple versions of the same video in various streamable formats.

Anything beyond that, such as additional rendering or uploading extra files, is unnecessary and wastes time for the rendering, upload time, YouTube's transcoding time, and storage space (if you keep a backup and don't transcode them to smaller files).

The key factor to consider is resolution. Videos uploaded at 1440p or 4K often look better when played back on YouTube at 1080p. This was due to YouTube using different encoding methods for videos at 1080p and below compared to those above 1080p. While I’m not sure if this is still true today, it was the case for many years.

Ultimately, what matters is that your video is high quality, looks clean and sharp locally. That's it.
All streaming versions are derived from YouTube’s own "master" file. Everything else is overkill.

On top of that, YouTube will butcher it anyway for the streamed version of these files
Less for those who have YouTube premium which can offer a higher bitrate for certain channel.

Unless someone is a massive creator with millions of daily views, like MrBeast, or specific channels, only a select few channels can upload and stream 8K videos, in HDR, ect. These creators often have access to additional features and a different process that prioritizes their content in terms of quality and capabilities.

For 98% of other YouTube users, the only thing that really matters is uploading a good-quality video file with a resolution higher than 1080p.

even 10-bit is overkill and pointless, right (as far as bit-depth goes)?

I always encode in 10-bit, even if all my sources are 8-bit. I read something about this years ago :

So why does a AVC/H.264 10-bit encoder perform better than 8-bit?
When encoding with the 10-bit tool, the compression process is performed with at least 10-bit accuracy compared to only 8-bit otherwise. So there is less truncation errors, especially in the motion compensation stage, increasing the efficiency of compression tools. As a consequence, there is less need to quantize to achieve a given bit-rate. The net result is a better quality for the same bit-rate or conversely less bit-rate for the same quality: between 5% and 20% on typical sources.

I often reuse/re-edit these backup files, so the slightly larger file size of an H.265 10-bit format doesn’t require much extra rendering time or storage space.

There's really no downside to encoding in 10-bit today, unless someone is using very old hardware for encoding or needs to play the video on a device that can't properly decode an H.265 10-bit file. In such cases, it's better to create a separate copy in H.264 8-bit format from the 10-bit file, rather than limiting the export quality just because one device can’t handle it.