Hello! DNx codec supports embedded alpha for DNxHD/HR compressions. How the feature is used, depends on specific application. Only embedded alpha is avaialble in MXF OP1a. In MOV some applications also might store DNx+alpha in old-style dual frame form. To understand what's going on, could you please share with us (if possible) samples with DNx

Hello Steve, Avid DNxHR is a resolution independent codec, it supports 4096x2304 rster size for any HR compression (inluding HQX). Avid DNxHR SDK also does not have any limitation to decode/encode HQX with 4096x2304 raster size. Thanks, Viktor

Hello, DNxHD80 this is compression ID 1259 (thin raster - bit-stream always stored as 1440x1080). As a DNxSDK user you have two options: - Set uncompressed rgt property as DNX_RGT_NativeCompressed and supply codec with 1440x1080 image. - Set uncompressed rgt property as DNX_RGT_Display and supply codec with 1920x1080 image. In this case SDK itself does

Hello, [quote user="Kestiu"]So my question is - is it simply a DN x HR problem of not being able to handle Interlaced media? [/quote] According to SMPTE 2019-1:2016 all DNxHR profiles are progressive exclusively. However, depending on your workflow in Media Composer, interlaced media might be encoded into DNxHR after some kind of de-interlacing

Hello Eric, [quote user="Eric V"] - Timecode - Material, Source and Original Source Package UIDs - Tape/Reel name Is the plan to augment the SDK to support these fields? [/quote] Timecode - yes, this is planned for the next DNxSDK release Material, Source and Original Source Package UIDs, Tape/Reel name - no plans to support. The DNx MXF interface

Hello Mike, According to "What's New" documentation, DNxHR support was introduced in Media Composer 8.3 (see Media Composer 8.x documentation , page 5). So, DNxHR SQ should work in MC 8.5. Thanks, Viktor

Hello Eric, According to documentation distributed along with SDK: ...Starting with SDK 2.3.2 according to SMPTE ST 2019-1 to avoid confusion and retain full backward encoding compatibility, a VC-3 encoder shall use the HD profile encoding, whenever applicable, instead of the (otherwise identical) RI profile. It means SDK allows to setup encoder with

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

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

Hello, [quote user="Vijeta"] Can you provide more insights? Is this API thread safe?[/quote] DNxSDK API is not thread safe. You can use: one codec instance with multiple threads per instance if you are interested in min latency multiple instances with resonable number of threads per instance to achive max throughtput If you want to share one