Avid DNx (codec)

Avid DNx is a lossy mezzanine codec specifically engineered for compositing and post-production workflows, offering reduced storage and bandwidth requirements compared to uncompressed video. The codec is based on SMPTE ST 2019-1 (VC-3). Originally named Avid DNxHR ("Digital Nonlinear Extensible High Resolution"), it extends and generalizes the Avid DNxHD codec's HD scope to also cover UHD, as well as custom resolutions and color spaces. Unlike other popular codecs like H.264 or AV1 it is not intended to be used as a distribution codec. In 2025 "Avid DNxHD" and "Avid DNxHR" were unified by Avid under the "Avid DNx" acronym.

Avid DNx was originally introduced as Avid DNxHD in 2004 as a proprietary Constant Bitrate (CBR) codec, supported in Avid products like Avid MediaComposer. It was standardized by SMPTE (Society of Motion Picture and Television Engineers) in 2008 as SMPTE ST 2019-1 (VC-3),^[1] covering HD resolutions in YCbCr color encoding and specifying encapsulation of the resulting streams in MXF ^[2] and MOV (QuickTime File Format) containers.

The 2014 revision of SMPTE ST 2019-1 (VC-3) added encoding directly in the RGB color model, allowing the codec to store graphic content without the need to convert to YCbCr representation, either externally or internally, as typically required by other codecs such as Apple ProRes.

On September 12, 2014, Avid Technology, Inc. announced the DNxHR (High Resolution) codec as part of a broader "Avid Resolution Independence" announcement at their Fall 2014 Avid Connect event, which was held during the IBC 2014 conference in Amsterdam, Netherlands.^{[3] [4]}

DNxHR was formally standardized with the publication of the 2016 revision of SMPTE ST 2019-1 (VC-3), where DNxHR corresponded to the newly introduced Resolution Independent (RI) profile. It extended the resolution coverage from HD to support any resolution between 2x2 and 16384x16384 pixels, most importantly including support for the emerging 2K, 4K and 8K resolutions, as well as adding support for an optional alpha channel (lossy or lossless) and Variable Bitrate (VBR) encoding.^[3]

In 2021 Avid DNxHR was added as production codec to the SMPTE ST 2067 suite of standard documents covering the IMF (Interoperable Master Format),^[5] allowing the codec to be used in modern post-production environments.

In 2022 SMPTE published an amendment to SMPTE ST 2019-1 (VC-3), which extended the support for the alpha channel into the HD profile.^[6]

At the IBC 2025 conference in Amsterdam Avid announced a rebranding of DNxHD and DNxHR to "Avid DNx", to eliminate the confusion around supported resolutions and bit depths arising from the continued and often misleading use of the HD and HR acronyms^{[7] [8]} .

The publication of the 2026 revision of SMPTE ST 2019-1 (VC-3) adds two new RGB compression levels (HQ and SQ), which were previously released by Avid under the acronym "Avid DNx GX".^{[9] [10]} This revision also renamed the "RI" profile to "HR", bringing this in line with industry practice, which is based primarily on use of Avid DNx. It also generalizes the custom bitrate support to CBR mode (previously only supported in VBR mode, to stay compliant with 2016 revision of SMPTE ST 2019-1).

In 2026 the Academy of Television Arts & Sciences awarded Avid Technology an Emmy Award for the development of Avid DNx.^[11]

Avid DNx is a fully compliant implementation of SMPTE ST 2019-1 (VC-3). It supports 5 primary compression levels, corresponding to different bitrate ranges and compression quality levels, as found in SMPTE ST 2019-1 (VC-3).

Avid DNx can carry any color coding and supports all bit depths between 8 and 16 bits for filler and lossy alpha.

• 444: 4:4:4 and RGB, highest quality and bitrate, lossless alpha support (VFX work and Cinema delivery).
• HQX (High Quality eXtended): 4:2:2 and 4:2:0, less aggressive quantization than HQ if needed for multi-generation workflows (High-end broadcast production and delivery)
• HQ (High Quality): RGB, 4:4:4, 4:2:2, 4:2:0, high end format for standard broadcast usage (none or few multi-generation work, specifically sports and advertising)
• SQ (Standard Quality): RGB, 4:4:4, 4:2:2, 4:2:0 , standard broadcast production usage (everyday broadcast production)
• LB (Low Bandwidth): 4:2:2 and 4:2:0, Proxy format for post-production work, replaced during finishing with a higher quality content representation (rough cuts and non-VFX work)

Table reproduced from , showing format support in Avid DNx. The bitrate range reflects the range available when using custom bitrates. The upper limit corresponds to the compressed size of the Level specified in SMPTE ST2019-1.

Users first select a Level based on the high-level quality aspects (aggressiveness of the quantization matrix). Within this Level they can then select any target bitrate within the specified Bitrate Range.

Up to the 2026 revision of SMPTE ST 2019-1 this adjustable bitrate feature required the use of the VBR flag. The 2026 revision generalized this to also cover CBR bitstreams.

The codec is available in a free version at developer.avid.com ^[12]

"Avid DNx", "Avid DNxHD", "Avid DNxHR", "DNxHD" and "DNxHR" are trademarks owned by Avid Technology.

The last of the patents associated with SMPTE ST 2019-1 (VC-3) runs out on January 18, 2027. However, as the codec has been continuously evolved, Avid holds several other patents which are either specific to the Avid DNx encoder (not covered by the standard) or to processing Avid DNx bitstreams. ^{[13] [14]} These will not run out before 2045.

Avid DNx is primarily supported through the Avid DNx SDK, published and licensed by Avid Technology. The SDK is the only complete implementation of the standard. Reference decoder software (un-optimized) is also available through SMPTE . The SDK supports all major platforms (Windows Intel, Windows ARM (Neon), Windows ARM EC, Linux Intel, MacOS ARM (Neon)).

In software VC-3 is also supported by FFmpeg. However this implementation is known to be incomplete, supporting primarily the HD resolutions of the original 2008 version of the VC-3 standard, frequently refusing operations for options introduced later (including most of the DNxHR options) and does not comply with the Avid DNx encoder specifications.

Hardware implementations of Avid DNx are available from several vendors, like for example Atomos.^[15]

Avid DNx is supported by all major editing applications, including Avid Media Composer, Adobe Premiere Pro, Blackmagic Design Resolve and Apple Final Cut Pro. Avid DNx is currently licensed to a wide range of application providers. ^[16]

Avid DNx is widely used in cinematic and high-end broadcast productions, which have specific post-production requirements. It was the first video codec specifically engineered to serve the needs of editing/post-production workflows.

Most video codecs today are used for consumption/distribution (streaming). This drives their primary architectural traits: They are designed to deliver the best possible quality at the least transfer cost (bandwidth) for sequential access by many viewers at the same time. They go to great technological lengths to achieve these generally adversarial goals, making them so complex that sustained use can only be maintained by using dedicated hardware, and usually only one stream at a time.

What they are not designed to deliver are fast random access, sustained high quality through many encoding/rendering generations, and the ability to update individual frames. They are designed for consumption, not further processing. Distribution codecs represent an end-point of a delivery infrastructure, while editing codecs need to serve the exact opposite end, the start and the entire length of the production pipeline.

In 2004, developers Katie Cornog, Dane Kottke and Michel Rynderman ^{[17] [18]} realized that the traits that made codecs a good distribution choice made them a poor editing choice. Production/Editing codecs should provide near instantaneous random access, be able to support many streams in parallel for compositing scenarios, offer superb quality over many editorial generations as the input gets more and more refined in the production process, and be easily implemented and supported in software on standard computing platforms without the need for specialized and expensive hardware. They decided to define a codec which would explicitly put production needs before efficiency considerations, overcoming the performance limitations presented by distribution codecs when used in an editing environment.

The DNxHD codec built on the comparatively simple foundation of the original JPEG image codec. The codec is the archetype of lossy, DCT-based codecs, which forms the mainstay of modern, MPEG-based codec technologies. It uses a single quality parameter which defines how much signal quality loss is deemed acceptable. The parameter makes the quality predictable, but not the resulting compressed size (bitrate): The Variable Length Coding which controls the compressed size depends strongly on the complexity of the content, resulting in each frame varying widely in size after compression. When applied to a stream of images (called frames in video terminology) this results in what is known as a Variable Bit Rate (VBR) bitstream.

While this is perfectly acceptable in photographs, it presents a massive obstacle for a production video codec, which needs to deal with long streams of such frames. If each frame has a different compressed size, this necessitates the use of a frame index, which lets the decoder know exactly where within the stream the corresponding frame can be found. Not only does this make the handling complex and expensive, it also imposes strong inhibitions on the resulting video files:

During live event recording, an editor can access a frame only once the corresponding index is available. This introduces long latencies until the captured content can be accessed and processed further.

The content of a specific frame gets frequently altered during editing: Content may be cropped, scaled, rotated, color-corrected or generally be subjected to effect processing. All these operations will result in a different compressed frame size if the content is re-compressed (rotoscoping), making it impossible to replace the frames in an existing file (in-place edits): To exchange a single frame, the entire file needs to be re-written.

Typically an edited program consists of many short segments called clips or cuts, which are assembled on a timeline that controls the serial playback. During the editing process these clips/cuts, which come from different source files, are cut, trimmed and re-arranged in their playback order.

When finished, the assembled result usually needs to be written into a single output file. With linear media like film and tape, this put a time-consuming finishing step at the end of the editing process, as the material also had to be assembled linearly, one frame after another. VBR-coded media inherit this time-consuming linear finishing characteristic, as the position of a frame depends on the (compressed) size of all preceding frames in the program.

DNxHD changed this fundamentally by replacing the single JPEG quality parameter with many such quality parameters across a single frame. This allows the encoder to control the compression on 16 x 16 pixel areas known as macroblocks. The Avid DNx encoder controls both the local quality and the local bit cost of each macroblock using the local quality parameter. The sum of the local bit costs then forms the compressed frame size.

The encoder needs to adjust the compression parameters based on the local complexity of the image to achieve a Constant Bit Rate (CBR) encoding, while simultaneously balancing the distribution of the quality parameters such that it maximizes the overall quality of the image.^{[19] [14]}

When distribution codecs refer to CBR coding they usually refer to a constant average bitrate, which is controlled and adjusted over the space of multiple subsequent frames. They do this primarily to allow network bandwidth predictability, so that broadcasters or streaming providers can ensure that a specific network bandwidth budget will be large enough to carry a specific number of streams while guaranteeing interruption free service. Accurately addressing individual frames, as required in editing, is not a stated objective in this context.

Such bitstreams allow an encoder considerable coding leeway, as the overshoots/undershoots in one frame can be compensated later in other frames, as long as the average stays within the budgeted limits. However, this also implies that the positions of a specific frame within the bitstream can only be roughly predicted and needs to be parsed from the bitstream unless there is a frame index. A frame index can only be maintained while the essence is "at rest", i.e. held in a file. While the bitstream is transmitted the bitstream can only be accessed via parsing.

Video streams based on DNxHD do not require an index to access a specific frame, as the position of each frame is known in advance and can never change (even if the content itself changes). The CBR specification found in SMPTE ST 2019-1 (VC-3) prescribes an exact compressed frame size for each frame, thus defining a "true" constant bitrate bitstream which eliminates the need for maintaining an index.

The CBR requirements can be met by letting the encoder "undershoot" the target frame size and padding the remainder of the frame to the predefined target frame size. This allows VBR encoders to disguise themselves as a CBR encoder by accepting a lower quality than what would be possible if the available compressed frame size were fully used. The Avid DNx encoder is usually able to satisfy the constant compressed frame size requirement without any padding, exceeding the VC-3 specification (due to the inherent efficiencies of the VLC encoding extremely simple images may collapse in compressed size below the permitted frame size. In these cases making use of padding is still unavoidable).

The constant compressed frame size also makes it possible to predict the position of future frames during live captures, or to process frames residing in different sections of the finished editing result in parallel, avoiding the sequential processing bottleneck. Thus, through the CBR modification, the DNxHD codec overcame the main obstacles encountered in editing/production workflows. The definition of five quality Levels of distinct bitrates also allows editing systems to create the resulting bitstreams via simple binary copy operations without the need to engage in expensive (time and quality) decode/re-encode operations. DNxHD thus allowed editors to work with compressed material the same way they were used to working with uncompressed essence.

The definition of DNxHD addressed the needs of the digital television revolution associated with the introduction of the HD standard. Beginning in 2014, Shailendra Mathur and Markus Weber started to generalize the concepts introduced with DNxHD to create DNxHR, evolving the codec to address the production needs of the post-HD era, making the codec resolution (4K and beyond), bit depth (color components using more than 8 bits) and color definition (Wide Color Gamut) agnostic and thus ultimately HDR compatible^[20] . To address the wider compositing needs this also included the introduction of an alpha channel into the codec.^[4]

These changes first manifested themselves in the 2016 revision of the SMPTE VC-3 standard, which was followed by another revision in 2026 to also address the growing needs of the animation/rendering community by also incorporating the DNx GX (Graphics eXchange) RGB-based codec variant into the standard. While based on SMPTE ST 2019-1 (VC-3), Avid DNx's specification, specifically for the encoder, significantly exceeds the provisions of the standard. It implements many quality-enhancing measures and functions like compressed bitstream merging or fast transcode modes, which are outside the immediate scope of the core codec but exploit the codec's specific traits to save processing time and prevent unnecessary generational quality loss during production. ^[12]

The I-frame format used by the codec encodes each frame independently. Unlike distribution codecs like H.264 or AV1, which rely on inter-frame (GOP codecs) compression technologies and which very efficiently reduce the bandwidth required to transmit high-quality content to end users in streaming applications, the codec requires significantly more storage space to achieve the same encoding quality. This is an explicit tradeoff accepted in production, because it allows the codec to maintain quality in specific operations found frequently in post production:

• Each frame can be individually and instantly accessed. Only a single frame needs to be retrieved and decoded, allowing the fastest possible reaction to random access user actions as found in editing applications, when searching for a specific frame where to introduce a cut or position an effect (scrubbing). GOP codecs require considerably more overhead and introduce decoding latency, because accessing a single frame requires decoding multiple frames, although a lot of these negative impacts can today be countered by ample caching.
• In the default CBR mode SMPTE ST 2019-1 (VC-3) has exact frame size requirements: Each frame must be exactly the same compressed size within the bitstream. This enables features not possible with other production codecs like e.g. Apple ProRes, which only offers VBR operations:^[21]
  • All frames in the bitstream can be accessed without the need to use and maintain an expensive frame index, further improving random access speed.
  • Frames can be modified and/or replaced in an existing bitstream without the need to re-encode parts or the entire bitstream. In file-based broadcast workflows frames can still be changed in the file shortly (seconds) before they go "on air", if, for example, a face needs to be made unrecognizable through barring or blurring. For GOP-based or VBR codecs either the entire file or at least the part following the modification needs to be recreated because of the resulting change of compressed frame size. In GOP-based codecs an additional constraint becomes a major inhibitor: Frames can only be modified as part of a group of pictures (entire GOP), and Open-GOP structures may even require entire segments, spanning multiple GOPs, to be re-encoded.
  • Bitstreams can be rendered in parallel: Because the final position within the bitstream is fully predictable before the frames have been encoded, the bitstream does not have to be encoded sequentially. Different areas of the bitstream can be encoded in parallel without having to resort to intermediate storage solutions with a subsequent stream-merge operation.
• The absence of an encoding latency allows frames being accessed for decoding/playback immediately after encoding. Paired with the CBR characteristic this allows instant, random access and variable speed replay, as frequently found in live sports productions.
• If the number of production formats is limited, the final edited sequences can be finished without going through a decode/encode cycle, merging the final bitstream in compressed form. This frequently eliminates the expensive image processing requirements, avoids a digital generation loss (quality) and reduces the overhead to a binary copy workflow.
• Even if the production formats are not exactly matching, Avid DNx allows either maintaining a binary copy or a minimal re-encode, which can be achieved within the codec itself, avoiding many quality degrading codec elements without having to go through the (much longer) editor pipeline.

The low complexity of the codec when compared to GOP codecs, allows using a SW-based decoder, even had 4K and 8K resolutions, without the mandatory need to resort to HW-assisted decoding support. HW decoders are frequently only optimized for sustained linear real-time playback of a single stream, limiting their use in non-linear editing applications: Editing requires stable, concurrent playback of at least two streams (single-track dissolve), more streams if multi-layered compositing is being used and many concurrent streams for multi-camera editing scenarios (alternate shot angles), as frequently used in professional cinematic productions, where time directly translates into operating expenses:

For low budget or personal productions time and limited storage space are usually the most effective cost-reduction factors, while in professional productions time-to-market frequently outweighs all other concerns. For professional applications being able to edit on virtually any computing platform without the need for expensive, dedicated studio equipment with virtually no wait limitations is usually deemed vastly more cost effective, as personnel waiting for hardware is usually more expensive than re-usable hardware investments.

In cinematic productions, specifically if VFX heavy, a single finished shot frequently goes through many processing generations, with content frequently getting exchanged multiple times between specialized finishing applications. The exchange usually happens in file form, requiring multiple encodings of the content and preservations of associated production metadata. Reliance on the professional market focused MXF file format, which stresses the importance in professional productions, complements the encoder design, which was specifically designed to provide high multi-generation resistance.