Hi,

I'm now using DNx SDK release 2.3.5.43.  Release notes for the 2.3.4 release say:

10/12 bit-depth support is added for DNX_HQ/DNX_SQ/DNX_LB (1272/1273/1274) compressions

However, the DNX_GetInfoFromCompressedFrame() never returns 10 or 12 in the depth field. :-(

I call DNX_CreateEncoder with the following:

(gdb) p compParams
$3 = {
  structSize = 64,
  width = 960,
  height = 720,
  compressionID = DNX_SQ_COMPRESSION_ID,
  colorVolume = DNX_CV_709,
  colorFormat = DNX_CF_YCbCr,
  subSampling = DNX_SSC_422,
  depth = 10,
  PARC = 0,
  PARN = 0,
  CRCpresence = 0,
  VBR = 0,
  alphaPresence = 0,
  losslessAlpha = 0,
  premultAlpha = 0
}

I encode a frame and immediately after I call DNX_GetInfoFromCompressedFrame() on the encoded frame and get:

(gdb) p compressedParams
$4 = {
  structSize = 64,
  width = 960,
  height = 720,
  compressionID = DNX_SQ_COMPRESSION_ID,
  colorVolume = DNX_CV_709,
  colorFormat = DNX_CF_YCbCr,
  subSampling = DNX_SSC_422,
  depth = 8,
  PARC = 0,
  PARN = 0,
  CRCpresence = 0,
  VBR = 0,
  alphaPresence = 0,
  losslessAlpha = 0,
  premultAlpha = 0
}

Is this a known issue?

Thank-you,

Eric Vinet
Autodesk

Just tried with DNxSDK 2.4.2 and this issue is still present.

Hello Eric,

This is not a bug but expected behavior, according to documentation distributed with SDK:

"...Starting with SDK 2.3.4 it’s no longer needed to down-convert the original 10 or 12-bit content to 8-bit prior to submitting it to the codec for DNxHR HQ/SQ/LB (1272/1273/1274)....Intermediate decode results will be processed at maximum bit depth and will not be clipped to 8-bit prior to converting them to the delivered format, improving the decoded quality for these encodings.
Note: These measures only improve the signal processing chain, using higher precision for intermediate results. They do not touch the internal quantization granularity of the codec. SBD field in bit-stream (7.2.3 of ST 2019-1) still is set according to tables C.1-C.2 in ST 2019-1..."

That's why DNX_GetInfoFromCompressedFrame() returns depth = 8

A bit more details:

SMPTE ST 2019-1 (VC-3) defines a decoder standard. To be super-precise it defines a minimum precision decoder standard that compliant decoders need to fulfill. The encoder is not covered by the standard and variations of the encoded bitstream will and do exist.
Avid DNx is not identical to VC-3. It is a codec which creates a VC-3 compliant bitstream on encode and satisfies and exceeds the VC-3 decoder compliance tests (minimum precision requirements). In other words: It is fully VC-3 compliant. 
The 10/12-bit support of Avid DNx is tied to proper bit depth signaling outside the bitstream, in the bitstream file wrapper. The SBD field in ST 2019-1 defines the input design bit depth for which the minimum precision IDCT rules and quantization of the DCT coefficients have been specified.
A compliant codec only needs to ensure that the range for the DCT coefficients is retained as defined by the SBD, but it can exceed the input/output, as well as the DCT processing precision without violating the standard’s compliance requirements. The bitstream created from an input with a higher bit-depth than the Design Bit Depth can significantly differ from that created with a minimal spec compliant encoder due to the higher precision, providing a better representation of the frequency spectrum than an implementation using a DCT which just complies with the minimum requirements. This is part of the freedom allowed for encoders under the standard definition.
The decoder only must ensure a certain minimal precision requirements when compared to the results of the reference decoder of a given bitstream. The reference decoder uses a float DCT and any DCT supporting a higher precision than the designed minimum requirements will pass this. A higher processing precision allows the decoder to faithfully accept sub-integer fractional precision in the results, which accommodate the higher precision of 10 and 12 bit inputs, as long as the used DCT exceeds the minimum processing bit depth required for these input bit depth.
The Avid DNx SDK is exploiting this to avoid premature clipping of the input/output precision, retaining a high fidelity in the respective output results. To be standard compliant it still needs to place the SBD values required by the standard in the bitstream to avoid that other compliant decoders will fail.
However the Avid DNx SDK will only reproduce results matching the SBD if the bitstream wrapper also signals this bit depth.

Thanks,

Viktor

Hi Viktor, thanks for the detailed explanation. So, should I undestand that from the DNx SDK user's perspective, this DNx feature really augments the range of possible values in the DNX_UncompressedParams_t and not that of the DNX_CompressedParams_t (as I was led to believe in my original post)?

Also, as the DNx stream won't keep the original user bit depth (e.g. 10 bit), where does AVID recommend storing this metadata in a MXF file wrapper or a QuickTime file wrapper?

Thanks,
Eric 

Hello Eric,

The SBD field in the bitstream (and depth field in DNX_CompressedParams_t you see after GetInfoFromCompressedFrame() call) ultimately governs the precision of the quantized DCT results, also called the design bit depth. Ultimately it is just a quantization factor and is not really directly related to the input bit depth. Prior versions of the SDK (before 2.3.4) did, however, clipped the decoded results to this bit depth, which is not strictly necessary. The relevant bit depth for processing is the one that was passed to the codec.

Eric V:

Also, as the DNx stream won't keep the original user bit depth (e.g. 10 bit), where does AVID recommend storing this metadata in a MXF file wrapper or a QuickTime file wrapper?

MXF: Component Depth in Picture Essence Descriptor according to G.2.26 in ST 377-1. It is worth noting that in the picture essence descriptors in ST 377-1 the bit depth field describes the precision of the input – it cannot describe any codec/bitstream internal representations.

QuickTime: please refer to the post (sampleBitDepth)

Thanks,

Viktor