DNxHR is a family of intra-frame, lossy video codecs developed by Avid for editing, finishing and mastering at resolutions beyond HD, including 2K, UHD, 4K and 8K. Among video codecs, it belongs to the group of mezzanine or intermediate codecs: formats designed not for distribution but for smooth, high-quality work in post-production, where frames must decode quickly and survive repeated processing.
DNxHR extends the earlier DNxHD, which was limited to HD frame sizes. Its profiles range from a lightweight proxy level to a 12-bit 4:4:4 level for high-end finishing, and it is widely supported by editing, grading and compositing software on Windows, macOS and Linux. It is commonly seen as the main cross-platform counterpart to Apple ProRes.
How DNxHR compresses video
DNxHR uses intra-frame compression: each frame is encoded independently, without reference to neighboring frames. The encoder splits the image into blocks, applies a discrete cosine transform (DCT), quantizes the coefficients and entropy-codes the result. This approach is technically standardized as SMPTE VC-3, which also covers DNxHD.
Because no frame depends on another, a decoder can jump to any frame instantly. This is the key difference from long-GOP codecs such as H.264 and H.265, which store most frames as differences from keyframes and must reconstruct a whole group of pictures before showing one frame. Intra-frame coding produces much larger files, but scrubbing, trimming and multicam playback are far lighter on the processor.
DNxHR is resolution independent: unlike DNxHD, which offered fixed bitrates for specific HD formats, DNxHR profiles define a quality level, and the actual bitrate scales with frame size and frame rate. The same profile can therefore be used for a 2K project, a UHD deliverable or an 8K master.
DNxHR profiles and their properties
DNxHR is organized into five profiles, each a fixed balance between quality and data rate. The bitrates below are approximate values for UHD at about 30 fps and scale roughly in proportion to pixel count and frame rate.
| Profile | Bit depth and sampling | Approximate bitrate | Typical role |
|---|---|---|---|
| DNxHR LB | 8-bit 4:2:2 | About 150 Mb/s | Offline editing and proxies |
| DNxHR SQ | 8-bit 4:2:2 | About 450 to 500 Mb/s | Standard-quality editing |
| DNxHR HQ | 8-bit 4:2:2 | About 700 Mb/s | High-quality 8-bit mastering |
| DNxHR HQX | 10-bit or 12-bit 4:2:2 | About 700 Mb/s | Grading, HDR and broadcast masters |
| DNxHR 444 | 10-bit or 12-bit 4:4:4 | About 1.4 Gb/s | Finishing, VFX and RGB masters |
The most important dividing line is bit depth. LB, SQ and HQ are 8-bit, which is adequate for many deliverables but can show banding in gradients after heavy grading. HQX and 444 are the profiles of choice for log footage, HDR and color-critical work. DNxHR 444 also supports an alpha channel in some implementations, which helps when exchanging graphics.
DNxHR compared with other codecs
DNxHR is best understood by comparing it with the codecs it competes with or complements. Each format solves a different problem in the chain from camera to editing to delivery.
| Codec | Compression type | Main purpose | Relation to DNxHR |
|---|---|---|---|
| DNxHR | Intra-frame DCT | Editing and mastering | Reference point |
| DNxHD | Intra-frame DCT | HD-only editing | Predecessor with fixed HD formats |
| ProRes | Intra-frame DCT | Editing and mastering | Closest equivalent with similar tiers |
| H.264 | Long-GOP | Distribution and camera recording | Often transcoded to DNxHR for editing |
| H.265 | Long-GOP | Efficient distribution and HDR delivery | Much smaller files, heavier decoding |
| AV1 and VP9 | Long-GOP | Web streaming | Final delivery, not editing |
In everyday practice, ProRes and DNxHR are near equivalents in quality per bitrate. The choice is usually driven by ecosystem: ProRes encoding is most native on macOS, while DNxHR is natively encoded by Avid tools and by many applications on Windows and Linux. Both are accepted by most broadcasters and post houses, though delivery specifications should always be checked.
Containers and workflow use
DNxHR is usually wrapped in MXF or MOV containers. MXF OP-Atom stores video and each audio channel in separate files and is native to Avid Media Composer, while MXF OP1a and MOV keep video and audio together and are preferred for exchange between applications.
| Task | Recommended profile | Reason |
|---|---|---|
| Proxy editing of 4K or 6K camera files | DNxHR LB | Small files, smooth playback |
| Edit-friendly transcode of H.264 footage | DNxHR SQ or HQ | Fast decoding without quality loss visible |
| Grading log or HDR footage | DNxHR HQX | 10-bit or 12-bit gradation |
| Final master for archive or VFX | DNxHR 444 | Full chroma resolution |
| Web delivery | Not DNxHR | Use H.264, H.265 or AV1 instead |
A common workflow transcodes long-GOP camera files to DNxHR at ingest, edits with those files and exports a DNxHR master, from which compressed distribution versions are generated. Some cameras and external recorders can record DNxHR directly, which removes the transcode step entirely.
Limitations and common mistakes
DNxHR is an excellent working format, but its large file sizes and fixed quality tiers create practical constraints.
- Storage underestimated: an hour of UHD DNxHR HQX at about 700 Mb/s needs roughly 300 GB.
- 8-bit profiles for log footage: SQ or HQ can band after grading; use HQX instead.
- Wrong container: OP-Atom files may confuse applications that expect a single file per clip.
- Using DNxHR for delivery: viewers and streaming platforms expect compressed distribution codecs.
- Upgrading quality by transcoding: converting compressed 8-bit footage to HQX does not add real detail or bit depth.
In everyday language
Video files from phones and many cameras are packed very tightly, which saves space but makes them hard work for a computer to edit. DNxHR is a way of storing video that is packed more loosely: every frame is saved as a complete picture.
That makes files bigger, but editing becomes smooth, like flipping through a photo album instead of rebuilding each page from notes. Editors use DNxHR while they work, then convert the finished film to a smaller format for viewers.
Seen in the real world
A post-production team on Windows workstations receives 20 hours of UHD H.265 footage for a documentary. Playback in the timeline stutters, especially with several layers. The assistant editor transcodes everything to DNxHR LB proxies for the edit, which play smoothly on every workstation.
When the edit is locked, the colorist conforms the timeline to the original camera files and grades it. The finished film is exported as a DNxHR HQX 10-bit master in MXF OP1a, which the broadcaster’s delivery specification accepts. From that master, the team creates H.264 and H.265 versions for online platforms. The intermediate codec kept editing fast and the master retained the gradation needed for later versions.