Mezzanine codecs — ProRes, DNxHD, DNxHR, and the editorial workflow tier

Mezzanine codecs are the intermediate-tier video codecs used in editorial and post-production workflows — Apple ProRes, Avid DNxHD, Avid DNxHR. They sit between the camera-original codecs (uncompressed, RAW) and the delivery codecs (H.264, HEVC, AV1) in the production pipeline. They're designed for editorial flexibility (fast random access, multi-generation re-encoding without quality loss, broad post-production tool support), not bandwidth efficiency. For pipelines that bridge editorial workflows to streaming distribution — sports, news, post-production-heavy premium streaming — mezzanine codec handling is essential. This page is the engineering reference.

#What mezzanine codecs are

Mezzanine codecs (also called "intermediate codecs" or "post-production codecs") have specific characteristics:

• Intra-only encoding — every frame is independently encoded; no inter-frame prediction. Random access is instant; cuts are clean.
• High bitrate — typically 50-700+ Mbps for HD, multiplied for higher resolutions.
• Low compression — lossy but visually transparent at typical bitrates; multi-generation re-encoding doesn't accumulate visible quality loss.
• High color fidelity — typically 10-bit or 12-bit; 4:2:2 or 4:4:4 chroma sampling; preserves grading flexibility.
• Editorial-friendly — widely supported in editing tools (Avid, Premiere, Final Cut, Resolve); fast scrubbing performance.

By comparison, delivery codecs (H.264, HEVC, AV1) prioritize bandwidth efficiency over editorial flexibility — heavy inter-frame prediction makes random access expensive, multi-generation re-encoding accumulates quality loss, and the codecs are tuned for low bitrates relative to the visual quality they produce.

#Apple ProRes

Apple ProRes is the most widely-used mezzanine codec in editorial workflows. Released 2007; multiple profiles for different bandwidth/quality targets.

ProRes profiles (typical 1080p59.94 bitrates):

• ProRes 422 Proxy — ~45 Mbps. Smallest. For offline editing, low-resolution proxies, broadband delivery from set.
• ProRes 422 LT — ~102 Mbps. Light. For broadcast-grade editing at lower quality.
• ProRes 422 — ~147 Mbps. Standard. The most-used profile for general editing.
• ProRes 422 HQ — ~220 Mbps. High quality. For broadcast contribution and premium editing.
• ProRes 4444 — ~330 Mbps. 4:4:4 chroma + alpha channel. For VFX/compositing workflows where alpha matters.
• ProRes 4444 XQ — ~500 Mbps. Highest quality. For premium VFX and grading workflows.

ProRes is wrapped in MOV containers typically; some workflows use MXF wrapping for broadcast contribution (ProRes-in-MXF).

ProRes for HDR: ProRes supports 10-bit (ProRes 422, 422 HQ, etc.) and 12-bit (ProRes 4444, 4444 XQ) — sufficient for HDR mastering. ST 2086 mastering metadata is preserved.

ProRes RAW — different family; an intra-only RAW codec for camera-original capture rather than mezzanine. Don't confuse with the standard ProRes profiles.

Licensing: ProRes is Apple-licensed for encoding (decoding is free). FFmpeg's prores and prores_ks encoders are available but officially produce non-Apple-validated output. For pipelines requiring strict Apple ProRes compliance (premium broadcast contribution, Apple iTunes Producer delivery), licensed Apple-validated encoders are required; for general production use, FFmpeg's encoders produce acceptable output.

#Avid DNxHD

Avid DNxHD (Digital Nonlinear Extensible HD) is Avid's mezzanine codec for HD content. Released 2004; predates ProRes by 3 years; widely used in Avid Media Composer workflows.

DNxHD bitrate variants (1080p59.94):

• DNxHD 36 — 36 Mbps, 8-bit. Offline / proxy.
• DNxHD 80 — 80 Mbps, 8-bit. Standard.
• DNxHD 100 — 100 Mbps, 10-bit. Broadcast quality.
• DNxHD 120 — 120 Mbps, 8-bit. High quality.
• DNxHD 145 — 145 Mbps, 8-bit or 10-bit. Premium HD.
• DNxHD 175 — 175 Mbps, 10-bit. Premium broadcast contribution.
• DNxHD 220 — 220 Mbps, 10-bit. Highest HD quality (analogous to ProRes 422 HQ).

DNxHD is typically wrapped in MXF (Avid OPAtom or OP1a) for editorial workflows; some workflows use MOV wrapping.

DNxHD is HD-only — 1920×1080 maximum. For higher resolutions, DNxHR is the successor.

#Avid DNxHR

DNxHR (Digital Nonlinear Extensible HR) is Avid's mezzanine codec for resolutions beyond HD — the modern UHD/4K editorial workflow codec from Avid.

DNxHR variants:

• DNxHR LB — Low Bandwidth. Offline / proxy. Variable resolution.
• DNxHR SQ — Standard Quality. Most-used. 8-bit or 10-bit; up to 4K.
• DNxHR HQ — High Quality. Premium editorial. 8-bit or 10-bit; up to 4K.
• DNxHR HQX — Higher Quality eXtended. 12-bit; supports HDR.
• DNxHR 444 — 4:4:4 chroma; for VFX and compositing workflows.

DNxHR bitrates depend on resolution and variant; at 4K the high-quality variants exceed 1 Gbps. Wrapped in MXF or MOV per workflow convention.

DNxHR is Avid's answer to ProRes for higher resolutions. Both serve similar workflow roles in editorial; tool ecosystem and customer convention typically determines the choice.

#When mezzanine codecs are right

Mezzanine codecs are the right format for:

Editorial / post-production storage — files actively being edited, color-graded, composited. Editorial tools work natively with mezzanine codecs; using delivery codecs for editorial slows everything down.

Broadcast contribution feeds — broadcasters distributing content to their distribution chains. ProRes 422 HQ or DNxHD 175 in MXF is typical.

Inter-facility transfer — handing content between post-production facilities. Mezzanine preserves quality through the handoff.

Archive masters — long-term storage of finished masters at high quality for future re-mastering. Not as common as full-quality archive (ProRes 4444 XQ + uncompressed audio); a real mid-tier choice.

Live broadcast contribution — live encoders in the contribution chain often emit mezzanine-quality streams for transmission to network operations centers.

For these cases, mezzanine codecs are the operational answer.

#When mezzanine is wrong

Mezzanine codecs are the wrong choice for:

Streaming delivery — bitrate is too high; bandwidth costs are prohibitive. Use H.264, HEVC, AV1 for streaming.

Long-term consumer-facing archive — the bandwidth cost adds up. Compress to delivery codecs for consumer-facing archive; keep mezzanine masters in cold storage.

Mobile / low-bandwidth distribution — bandwidth is too high.

Web-embedded video — bandwidth is too high; players don't natively handle mezzanine codecs anyway.

For these cases, delivery codecs are the answer.

#Mezzanine codec selection guide

For pipelines choosing among mezzanine codecs:

Editorial tools matter: if your post house is Avid-centric, DNxHD/DNxHR matches the workflow. If it's Final Cut / Premiere / Resolve, ProRes is the cultural default. The codec choice typically follows the editing tool ecosystem.

Quality target informs profile: ProRes 422 (or DNxHD 145) for general editorial; ProRes 422 HQ (or DNxHD 220) for premium broadcast contribution; ProRes 4444 (or DNxHR HQX) for VFX workflows requiring 4:4:4 or alpha.

HDR considerations: 10-bit minimum (ProRes 422 family, DNxHD 100/175/220, DNxHR SQ at 10-bit and above). For premium HDR with grade-side flexibility, ProRes 4444 or DNxHR HQX (12-bit) preserves the most range.

Resolution scope: ProRes scales to all resolutions (HD, 4K, 8K). DNxHD is HD-only; DNxHR is for HD and above. For mixed-resolution pipelines, ProRes is operationally simpler.

Container conventions: ProRes is typically MOV; DNxHD is typically MXF (Avid OPAtom for Avid editorial; OP1a for finished delivery). Pipelines that bridge editorial and broadcast handle both wrappers.

For most 2026 streaming pipelines that do touch editorial, ProRes 422 HQ in MOV or MXF is the most common mezzanine codec encountered.

#File sizes and storage planning

A practical reality: mezzanine codec files are large.

1080p59.94 in different codecs (1 hour):

• H.264 streaming (5 Mbps): ~2 GB.
• HEVC streaming (3 Mbps): ~1.3 GB.
• ProRes 422 (147 Mbps): ~65 GB.
• ProRes 422 HQ (220 Mbps): ~100 GB.
• ProRes 4444 XQ (500 Mbps): ~225 GB.

4K59.94 in different codecs (1 hour):

• HEVC streaming (15 Mbps): ~7 GB.
• ProRes 422 HQ (~440 Mbps at 4K): ~200 GB.
• ProRes 4444 XQ (~1 Gbps at 4K): ~450 GB.

For pipelines storing mezzanine masters, the storage budget is meaningful. Cold-storage (S3 Glacier or equivalent) is the typical archive tier; warm-storage (S3 Standard) for content actively being edited or recently delivered.

For pipelines transferring mezzanine content between facilities, network bandwidth matters — a 1-hour 4K ProRes 4444 XQ file is 450 GB, which is hours over a gigabit link.

#ffmpeg encoding

ProRes 422 (FFmpeg native):

ffmpeg -i input.mov -c:v prores_ks -profile:v 3 -pix_fmt yuv422p10le \
  -c:a pcm_s24le output.mov

-profile:v 3 is ProRes 422 HQ; profile 2 is 422; profile 1 is 422 LT; profile 0 is 422 Proxy; profile 4 is 4444; profile 5 is 4444 XQ.

DNxHR HQ:

ffmpeg -i input.mov -c:v dnxhd -profile:v dnxhr_hq -pix_fmt yuv422p \
  -c:a pcm_s24le output.mxf

-profile:v dnxhr_hq selects the HQ variant; alternatives include dnxhr_lb, dnxhr_sq, dnxhr_hqx, dnxhr_444.

DNxHD 220 (1080p):

ffmpeg -i input.mov -c:v dnxhd -b:v 220M -pix_fmt yuv422p10 \
  -c:a pcm_s24le output.mxf

DNxHD requires explicit bitrate (-b:v); the encoder doesn't infer.

Audio with mezzanine: typically uncompressed PCM (pcm_s24le for 24-bit, pcm_s16le for 16-bit) wrapped alongside the video.

#Decoding mezzanine

Decoding is broadly supported:

• FFmpeg — prores, dnxhd decoders both work. Used in most pipeline ingest stages.
• Avid Media Composer — native DNxHD/DNxHR decode.
• Apple Final Cut Pro / Compressor — native ProRes decode.
• Adobe Premiere / After Effects — both ProRes and DNxHD/DNxHR.
• DaVinci Resolve — both formats; commonly used in color-grading workflows.

For pipelines ingesting mezzanine-codec content for transcoding to streaming codecs, FFmpeg-based ingest handles the decode reliably.

#Pipeline integration

A typical editorial-to-streaming pipeline:

1. Editorial output — finished master in ProRes 422 HQ (MOV) or DNxHD 220 (MXF).
2. Pipeline ingest — pipeline accepts the mezzanine file as input; ffprobe characterizes (codec, container, color metadata, audio).
3. Decode and process — FFmpeg decodes the mezzanine, applies any required filters (resize, color conversion, deinterlace if applicable).
4. Encode to streaming codecs — produce H.264, HEVC, AV1 outputs at multiple ladder rungs.
5. Package — wrap encoded streams into HLS / DASH / CMAF.
6. Archive — keep the mezzanine master in long-term storage; stream from the encoded outputs.

The pipeline's job is the mezzanine → delivery transcoding. Quality preservation through this stage matters; the mezzanine encoded the finished editorial intent.

#Common mezzanine handling bugs

Bug 1: Color-space mishandling

Mezzanine codecs typically carry rich color metadata (Rec.709 SDR, Rec.2020 HDR, color-primary signaling). Mishandling the color metadata produces washed-out or shifted output. Verify color-space signaling end-to-end through the pipeline.

Bug 2: Audio sync issues with mezzanine multi-track

Mezzanine files often have multiple audio tracks (stereo + 5.1 + dialogue stems + music stems). Pipelines that don't explicitly map tracks may drop or rearrange audio incorrectly. Use explicit -map flags.

Bug 3: HDR metadata loss

Mezzanine files for HDR carry mastering-display metadata (ST 2086) and content-light metadata (MaxCLL/MaxFALL). These can be lost in transcode if the pipeline doesn't explicitly preserve them. For HDR workflows, verify metadata preservation.

Bug 4: Frame-rate mismatch

Mezzanine files often carry frame-rate metadata that doesn't match the actual frame rate (e.g., 23.976 fps frame rate marked as 24 fps). Verify with ffprobe; trust actual frame rate over declared.

Bug 5: Closed caption preservation

Broadcast mezzanine files may have CEA-608/708 captions embedded. Pipelines that strip the captions in transcode lose them. For broadcast-source content, explicit caption extraction at ingest is the answer.

Bug 6: Non-standard mezzanine variants

Some commercial workflows use proprietary mezzanine codecs (Sony XAVC, Panasonic AVC-Intra, GoPro Cineform). FFmpeg supports most of these but quality and edge-case handling varies. For pipelines processing these, validate output before committing.

#Operational considerations

Things that matter for mezzanine codec handling in production:

• Storage planning — mezzanine files are large; storage costs are meaningful at scale.
• Transfer performance — mezzanine files take time to transfer; network capacity planning matters.
• Decoder version pinning — mezzanine codecs evolve (new ProRes profiles, DNxHR variants); pinning decoder version prevents silent quality regressions.
• Color management — mezzanine carries rich color metadata; preserve it end-to-end.
• Audio handling — multi-track mezzanine audio needs explicit pipeline configuration.
• Metadata preservation — HDR metadata, captions, time code, audio metadata; verify each survives the transcode.
• Quality verification — automated metrics (PSNR, SSIM, VMAF) on the transcode output; sample human QC for premium content.

#What MpegFlow does with mezzanine codecs

MpegFlow's FfmpegExecutor worker image includes the FFmpeg native ProRes encoders/decoders (prores, prores_ks) and the DNxHD/DNxHR encoders/decoders (dnxhd). The DAG runtime expresses mezzanine decode as part of the upstream FfmpegExecutor stage that consumes the source; cross-stage data flow wires the decoded output into downstream rendition stages for streaming-codec encoding. The partitioner persists each stage to job_stages with explicit dependency tracking and per-stage retry; sibling cancellation propagates fatal failures.

For ingest, an FfprobeExecutor stage characterizes the mezzanine source: codec profile (ProRes profile, DNxHR variant), color metadata, audio track layout, timecode track, captions if present. The probe output flows into the downstream encode stages so each rendition's parameters derive from real source characteristics.

For mezzanine output (rare in MpegFlow's typical customer mix but supported), the workflow YAML configures an FfmpegExecutor stage with the appropriate codec parameters — ProRes profiles from Proxy through 4444 XQ are exposed; DNxHD profiles 36 through 220 and DNxHR profiles LB through 444 are exposed. Output mezzanine encode runs as its own stage in the DAG.

For pipelines bridging editorial and streaming (sports, news, post-production-heavy premium streaming), mezzanine ingest → multi-rendition streaming output is the common pattern. Timestamp-preservation discipline at every stage boundary keeps timecode and audio sync aligned; HDR metadata flows through via explicit color-space handling at the encode stage.

The strict-broker security model handles mezzanine content like any pipeline payload — workers carry no ambient credentials; content access (which often involves large mezzanine files) flows through short-lived presigned URLs scoped per stage; access is disposed on completion. Mezzanine files are often premium-licensed content; the discipline applies regardless.

For customers building editorial-to-streaming pipelines with mezzanine codec input, the conversation typically focuses on storage planning (where do mezzanine masters live? Hot/warm/cold?), transfer architecture (how do mezzanine files get to the pipeline?), color-management requirements (HDR metadata preservation?), audio/caption preservation (multi-track audio? Embedded captions?), and quality verification (which automated metrics? Human QC sampling?). The pipeline mechanics for mezzanine decode and transcode are well-understood; the operational architecture around large-file handling and editorial workflow integration is where customer-specific work happens.

The general guidance: mezzanine codecs are essential for editorial workflows; delivery codecs are essential for streaming. Pipelines that bridge the two need to handle both. ProRes and DNxHD/DNxHR are the two families that matter in 2026; choose based on editorial tool ecosystem, quality requirements, and resolution scope. Don't try to use mezzanine codecs for streaming delivery (bandwidth) and don't try to use delivery codecs for editorial (workflow performance) — they solve different problems.