"Just send me a ProRes": a translation guide
What people mean vs what they need vs what the spec says. ProRes is not one thing. H.264 is not 'web quality.' Here's what everyone's actually asking for.
The email says “just send me a ProRes.” Which ProRes? ProRes 422? 422 HQ? 4444? 4444 XQ? ProRes RAW? At what resolution? What frame rate? What colour space? With or without an alpha channel? ProRes is not a quality setting. It is a family of codecs, and the name alone tells you almost nothing about the file.
“Just send me a ProRes” is the delivery equivalent of “make it pop.” It communicates intent without precision, and the gap between intent and precision is where expensive re-deliveries happen.
The ProRes family is five (or six) codecs
ProRes isn’t a codec. It’s a family of codecs with dramatically different characteristics:
- ProRes 422 Proxy. Tiny files for offline editing. Not for delivery.
- ProRes 422 LT. Lighter version of 422. Sometimes acceptable for broadcast.
- ProRes 422. The workhorse. Broadcast delivery standard.
- ProRes 422 HQ. Higher bitrate. Master quality. What most people probably mean.
- ProRes 4444. Adds a fourth channel (alpha). Up to 12-bit. VFX delivery.
- ProRes 4444 XQ. Highest quality. 12-bit. The one nobody asks for because nobody knows it exists.
| Flavour | 1080p | 4K | Typical use |
|---|---|---|---|
| 422 Proxy | 45 Mbps | ~150 Mbps | Offline editing |
| 422 LT | 102 Mbps | ~365 Mbps | Broadcast / lightweight delivery |
| 422 | 147 Mbps | ~530 Mbps | Standard broadcast delivery |
| 422 HQ | 220 Mbps | ~795 Mbps | Master quality / archival |
| 4444 | 330 Mbps | ~1,190 Mbps | VFX plates / alpha channel |
| 4444 XQ | 500 Mbps | ~1,800 Mbps | Highest quality / HDR mastering |
When a client says “ProRes,” they usually mean 422 HQ. But if you’re delivering VFX plates, they might mean 4444. And if they’re working on an M1 Mac and playing back in QuickTime Player, they might not realise that “ProRes” means something different at every quality level.
The file size difference is real. A minute of 4K ProRes 422 HQ is roughly 7.5 GB. The same minute in ProRes 4444 XQ is over 20 GB. If someone asks for ProRes and you deliver 4444 XQ, you’ve given them the best quality and the worst transfer time, and they’ll wonder why their Dropbox is full.
”H.264 is web quality”: no it isn’t
This might be the most persistent misconception in post-production. H.264 is a compression standard, not a quality level. It can produce a 2 Mbps stream for YouTube or a 200 Mbps master that’s visually indistinguishable from ProRes. The codec is the language. The bitrate, profile, and level determine the quality.
The confusion comes from where people encounter H.264. Most of the H.264 they see is heavily compressed web video: YouTube, Vimeo, streaming platforms. So H.264 becomes associated with “lossy web stuff” and ProRes with “professional quality.” But that’s a usage pattern, not a technical limitation.
H.265 (HEVC) adds another layer of confusion. It’s roughly twice as efficient as H.264 at the same quality, but “twice as efficient” means the files are smaller, not that the quality is lower. A 100 Mbps HEVC file often looks as good as a 200 Mbps H.264 file. This matters enormously for camera originals: modern cameras that record in HEVC internally are producing excellent masters in half the file size.
The reason professional workflows still prefer ProRes and DNxHR over H.264/H.265 is not quality; it’s decode performance. H.264 and H.265 use temporal compression (they describe the difference between frames rather than each frame independently), which means scrubbing to an arbitrary frame requires decoding a chain of dependent frames first. ProRes and DNxHR are intraframe codecs where every frame stands alone, so random access is instant. For editing, that distinction matters more than any bitrate comparison.
DNxHR: the other professional codec
DNxHR is Avid’s answer to ProRes. It fills exactly the same role (intraframe, high-quality, designed for editing) and comes in its own family of quality tiers: DNxHR LB, SQ, HQ, HQX, and 444. The quality tiers roughly parallel the ProRes family, and the workflow advantages are identical.
The difference is ecosystem. ProRes is Apple’s format and historically required macOS to encode (though that’s less true now). DNxHR is Avid’s format and works everywhere. If your post house is Avid-based, they’ll ask for DNx. If they’re on a Mac-based Premiere or Resolve pipeline, they’ll ask for ProRes. The technical merits are near-identical. It’s a question of which decoder their pipeline already has.
When someone asks for “ProRes or DNx,” they’re really asking for “an intraframe codec I can edit natively.” Give them whichever one matches their NLE.
Container vs codec: the box and the language
This is where things get tangled for people outside post. A .mov file is a container. A .mp4 file is a container. Both of them can hold H.264 video. The extension on the file tells you what kind of box it’s in, not what language the video speaks.
ProRes lives in .mov containers. DNxHR can live in .mov or .mxf containers. H.264 can live in .mov, .mp4, .mkv, or .ts containers. When a client says “send me an MP4,” they’re asking for a container. When they say “send me a ProRes,” they’re asking for a codec. When they say “send me a ProRes MP4,” they’re asking for something that doesn’t exist. ProRes doesn’t go in MP4 containers.
This isn’t pedantry. If you send a .mov file to a system that only accepts .mp4, the fix might be as simple as re-wrapping the container without touching the video, a process that takes seconds and doesn’t degrade quality. But if the recipient doesn’t know the difference, they’ll assume the file is broken, re-encode it at a fraction of the original quality, and blame you for the result.
The practical delivery checklist
A codec is not a specification. It is the beginning of one. “Send me a ProRes” fills in one parameter out of ten. The other nine are where rejections happen.
When someone asks for a file and the spec is vague, every one of these parameters needs a value:
1. Codec and quality tier. Not just “ProRes,” which ProRes? Not just “H.264,” at what bitrate? The difference between ProRes 422 and 422 HQ is roughly 50% in file size. The difference between 422 HQ and 4444 is an entirely different chroma structure. If they cannot answer, suggest ProRes 422 HQ for master delivery and H.264 at 50+ Mbps for review.
2. Resolution. “4K” means 3840x2160 to broadcasters and 4096x2160 to cinema people. Those 256 missing pixels will cause a DCP build to fail. Pixel aspect ratio matters too: square pixels (1:1) for HD and UHD, or something else if the project is anamorphic.
3. Frame rate. 23.976 fps and 24.000 fps are different frame rates. The 0.1% difference causes audio drift over the length of a feature. In NTSC territories, “24p” almost always means 23.976. In cinema (DCI), 24 means 24.000. The same ambiguity exists between 29.97 and 30, between 59.94 and 60. Never round the frame rate.
4. Colour space. Three components must all be specified: primaries (BT.709, BT.2020, DCI-P3), transfer function (BT.1886, PQ, HLG), and colour range (legal or full). A file encoded in BT.2020 PQ played back on a system expecting BT.709 will look desaturated and flat. A file tagged as legal range but encoded as full range will have crushed blacks and clipped highlights. These are exactly the kind of metadata fields nobody checks until delivery day.
5. Transfer function. Often bundled with colour space, but it is a separate parameter. A file graded for a 2.4 gamma display (BT.1886) will look different on a system expecting PQ (ST 2084) for HDR. SDR and HDR are not flavours of the same thing. They require different mastering, different monitoring, and different metadata. If nobody specifies, Rec. 709 with BT.1886 transfer is the safest assumption for broadcast, and sRGB for web.
6. Audio layout. A 5.1 mix delivered as six discrete mono tracks is not the same as a single 6-channel interleaved track. The receiving system may interpret discrete mono tracks as six separate stereo pairs. Channel order matters: SMPTE order for surround is L, R, C, LFE, Ls, Rs. Beyond the mix format, the delivery spec needs to state which channels carry what. A common broadcast layout puts the stereo programme mix on channels 1-2, music and effects on 3-4, dialogue stem on 5-6, and descriptive audio on 7-8.
7. Sample rate and bit depth. 24-bit, 48 kHz PCM is standard for professional video delivery. The spec needs to say so explicitly, because 16-bit audio still exists, 96 kHz recording sessions exist, and 48.048 kHz pulldown workflows exist.
8. Container. ProRes belongs in a QuickTime MOV container. ProRes in an MP4 container is technically possible (FFmpeg can do it) but practically broken. Many players and NLEs will not open it. .mxf for broadcast and Avid workflows. .mp4 for web distribution. Match the container to the destination, not to preference.
9. Timecode. Start timecode matters: 01:00:00:00 is the most common broadcast convention, but some deliverables require 10:00:00:00 or a specific programme-start time. For 29.97 and 59.94 fps content, the spec must state drop-frame or non-drop-frame. Drop-frame timecode skips frame numbers (not actual frames) at specific intervals to keep the display synchronised with wall-clock time. Non-drop-frame counts sequentially. Most US broadcast requires drop-frame. Most film post uses non-drop-frame. If the start TC is wrong, every edit note, subtitle cue, and QC report references the wrong frames.
10. Naming convention. Automated ingest systems parse filenames to route content. A file named final_v2_FINAL_really_final.mov will fail ingest at any facility with automation. The naming convention typically requires structured fields: programme title, season, episode, codec, frame rate, audio configuration, version, date. No spaces, no special characters, maximum length. Ask before rendering.
Five ways files get rejected
These are composites of real failures. Every one of them involved a file that was technically a valid ProRes.
Wrong colour space tagging. A production delivered ProRes 422 HQ graded in DaVinci Resolve with BT.2020 primaries, but the export settings tagged the file as BT.709. The broadcaster’s QC system flagged the colourimetry as out-of-spec because the pixel values exceeded the legal BT.709 gamut. Entire programme rejected. Turnaround: 48 hours.
Wrong frame rate entirely. A facility delivered a 23.976 fps programme when the broadcaster required 29.97 fps for playout. Not a re-wrap. A standards conversion. Turnaround: one week.
Swapped audio channels. A post house delivered eight channels of audio with the M&E and dialogue stems swapped. The broadcaster’s automated playout pulled the wrong channels for their international feed. Caught in QC only because someone listened.
Missing bars and tone. A streaming platform’s automated QC rejected a delivery because the file started at frame 1 of programme content. The spec required 60 seconds of bars and 30 seconds of black before programme start. The content itself was technically flawless. The rejection was procedural but non-negotiable.
Resolution rounding. A production delivered 3840x2160 (UHD) when the spec called for 4096x2160 (DCI 4K). Two numbers that both get called “4K.” The DCP build failed. Re-render the entire programme.
Delivery specification template
Every field below has caused a rejection at some point. Fill them all in. Share the completed spec before the edit starts, not after the render finishes.
DELIVERY SPECIFICATION
======================
Programme: [Title]
Episode: [S01E01]
Version: [TX / Textless / Trailer]
VIDEO
-----
Codec: Apple ProRes 422 HQ
Container: QuickTime (.mov)
Resolution: 1920x1080
Frame Rate: 25 fps (progressive)
Pixel Aspect Ratio: 1:1 (square)
Colour Primaries: ITU-R BT.709
Transfer Function: BT.1886 (2.4 gamma)
Colour Range: Legal (64-940 10-bit)
AUDIO
-----
Codec: Linear PCM (uncompressed)
Sample Rate: 48 kHz
Bit Depth: 24-bit
Layout:
Ch 1-2: Stereo Programme Mix
Ch 3-4: Music & Effects (M&E)
Ch 5-6: Dialogue Stem
Ch 7-8: Commentary / Descriptive Audio
Loudness: -24 LUFS (EBU R128)
TIMECODE
--------
Start TC: 01:00:00:00
Frame Rate: 25 fps
Format: Non-drop-frame (N/A for 25 fps)
STRUCTURE
---------
00:58:00:00 - 00:59:00:00 Colour Bars + Tone (-18 dBFS)
00:59:00:00 - 00:59:50:00 Black
00:59:50:00 - 01:00:00:00 Slate / Countdown
01:00:00:00 Programme Start
[Programme End] 2 seconds black
FILE NAMING
-----------
Format: [Title]_[Episode]_[Version]_[Codec]_[Date].mov
Example: TheShow_S01E01_TX_ProResHQ_20260315.movAdapt the specifics to the project. The point is not that every delivery uses these exact values. The point is that every delivery needs values in every field. Next time someone says “just send me a ProRes,” send them a version of this template with blanks and ask them to fill it in. It takes five minutes. A re-delivery takes two days if lucky and a week if not.
The five minutes it takes to confirm these details will save the five hours it takes to re-render and re-upload when the spec was wrong. And if the answer is truly “I don’t care, just send me something,” go with ProRes 422 HQ in a .mov, Rec. 709, with a stereo mix on tracks 1-2. That is the safe default. It is what “just send me a ProRes” almost always means.