DNxHR exporter

By default (auto setting in levels in exporter) Resolve exports and flags DNxHR 444 profiles as limited range.
This is somehow not the best setting. DNxHR 444 files are RGB based, so more correct setting would be full range.
Another reason is also fact that Premiere is hard coded and always expects full range for 444 files (and limited for 422) and there is no way to overwrite it. This means any DNxHR 444 file exported from Resolve with auto setting will import badly into Premiere and look washed out.

As a side note. Premiere exports all 444 files as full range and 422 as limited. There is a bug though and 422 files are flagged as full range. Because Resolve reads flagging it will import those files incorrectly (washed out). Fortunately Resolve has manual range overwrite, so once you set it to Video then everything will be fine.

2nd side note.
When it comes to ProRes then this always should be limited range (both apps always expect by default limited range for 422 and 444 files). Full is possible in Resolve but always should be treated as special case and manually overwritten to full after import. There is no flagging in ProRes headers to tell app what setting was used, so this always will be blind guess (some app hard coded behaviour).

DNxHR 444 files are RGB based, so more correct setting would be full range.

It would be nice if BM could step in and settle once and for all if DNxHR444 exported files are indeed encoded as RGB or YUV. If not RGB then Video levels are correct.

FFMPEG/FFprobe output suggests that we are always getting YUV (just as with ProRes444), but confirmation would be much appreciated. Just tried it and this is what I got:

Input #0, mov,mp4,m4a,3gp,3g2,mj2, from 'dnxhr444-12.mov':
Metadata:
major_brand : qt
minor_version : 512
compatible_brands: qt
encoder : Blackmagic Design DaVinci Resolve Studio
Duration: 00:00:05.00, start: 0.000000, bitrate: 353861 kb/s
Stream #0:0(eng): Video: dnxhd (DNXHR 444) (AVdh / 0x68645641), yuv444p12le(tv, bt709/bt709/unknown), 1920x1080, 352321 kb/s, SAR 1:1 DAR 16:9, 24 fps, 24 tbr, 12288 tbn, 12288 tbc (default)
Metadata:
handler_name : VideoHandler
encoder : DNxHR 444 12-bit

ffmpeg is not necessarily reliable source of information. It can decode internal codec format to any pixel format depending how it was coded. It's not always 'native' pixel format. For years it decoded ProRes 444 at 10bit precision only where in reality it's 12bit (it's fixed now).

Here is different source of information (these are DNxHR private frame headers):

Compression ID (4 bytes)
002EE4C Compression ID: 1270 (0x000004F6)
002EE50 Coding Control B (1 bytes)
002EE50 FFE, Field/Frame Count: Yes - Progressive
002EE50 SSC, Sub Sampling Control: 2 (0x2) - (2 bits) - 4:4:4
002EE50 CLR, Color Volume: 0 (0x0) - (2 bits) - BT.709
002EE50 CLF, Color Format: Yes - RGB

I'm not 100% sure though . I'm sure last time I tested it (quite a time ago) ffmpeg was showing RGB pixel format for Resolve files. Maybe BM changed it or my memory is bad.

update:

Found some more precise info:

struct AvidDNxHRDescriptionExtension {

UInt32 idSize; // 32

OSType extensionType; // 'ADHR'

UInt32 version; // '0001'

UInt32 compressionID;

// 0: 4:2:2 Sub Sampling

// 1: 4:2:0 Sub Sampling

// 2: 4:4:4 Sub Sampling

UInt32 subSamplingControl;

// 1: 8-bits per sample

// 2: 10-bits per sample

// 3: 12-bits per sample

UInt32 sampleBitDepth;

// 0: Bitstream is encoded using the YCBCR format rules and tables

// 1: Bitstream is encoded using the RGB format rules and tables – only Compression IDs 1256, 1270

UInt16 CLF; //Color Format

// 0: ITU-R BT.709

// 1: ITU-R BT.2020 - Non-constant Luma mapping

// 2: ITU-R BT.2020 C – Constant Luma mapping

// 3: Out-of-band – Color volume described out-of-band

UInt16 CLV; // Color Volume

// 0: Alpha channel not present

// 1: Alpha channel present

UInt16 ALP; //Alpha flag (RI-only, shall be 0b for HD rasters)

// 0: Alpha has not been applied to video channels

// 1: Alpha has been applied to the video channels prior to encoding

UInt16 PMA; //Pre-multiplied Alpha

};

so if CLF is set to 1 (RGB) it means "Bitstream is encoded using the RGB format rules and tables – only Compression IDs 1256, 1270". Does it mean RGB based? Still not 100% sure

More from AVID forum (AVID developer):
"About second question. DNx444 stores RGB encoded data, while all other DNx compressions store YCbCr. With DNxSDK you can obtain uncompressed video in any colorspace. To do so you need to set m_colorSpace value to the desired colr sapce and set a valid m_colorComponentOrder."

if DNxHR444 exported files are indeed encoded as RGB

It was for me in Studio 17b7 for Windows.