The spec says ProRes 422. The file says Apple ProRes 422 LT. Somebody has to decide whether that is a match, and the honest answer is that it depends on who wrote the spec and whether they were being precise or casual.
ProRes is a family, not a codec. The members have different data rates, different chroma sampling and different bit depths, and the naming convention makes two of them look like variants of one thing when they are not.
The family, from smallest to largest
All of them are intra-frame — every frame is complete in itself, which is the reason the format exists. What changes between them is how much data each frame is allowed.
- ProRes Proxy — 4:2:2, 10-bit. Roughly 45 Mbit/s at 1080p25. Meant for offline editing on modest hardware. It is a working format, not a deliverable, and it looks like one.
- ProRes 422 LT — 4:2:2, 10-bit. Roughly 100 Mbit/s at 1080p25. Perfectly watchable. Frequently delivered by people who read “ProRes 422” in a spec and picked the entry in the export menu whose name starts that way.
- ProRes 422 — 4:2:2, 10-bit. Roughly 147 Mbit/s at 1080p25. The default assumption when a spec says ProRes without qualification.
- ProRes 422 HQ — 4:2:2, 10-bit. Roughly 220 Mbit/s at 1080p25. The common broadcast master format.
- ProRes 4444 — 4:4:4:4, up to 12-bit, with an alpha channel. Roughly 330 Mbit/s at 1080p25. Used where chroma matters: graphics, keying, anything with a matte.
- ProRes 4444 XQ — as above at a much higher data rate. Aimed at high-dynamic-range material.
Data rates scale with resolution and frame rate, so the figures above are only useful as ratios. What holds across resolutions is the ordering and the roughly 1.5× step between neighbours.
Where the naming causes trouble
“ProRes 422 LT” reads like a qualifier on ProRes 422. It behaves like one in an export menu, where the four 422 variants sit together in a list. So a supplier asked for ProRes 422 who picks LT has not obviously misread anything — they have picked something from the 422 group.
Whether that is acceptable is a real question with a real answer, and it depends on what happens next:
- If the file is played out once and never re-encoded, LT is visually fine for most content.
- If it goes through another encode — a broadcast transcode, an ABR ladder — the lower data rate compounds. Artefacts that were invisible in the master become visible in the derived versions.
- If it contains hard graphics, fine text or a lot of motion, LT falls over first in exactly those places.
The right fix is not to argue about it after delivery. It is to write the spec so that the answer is unambiguous, and then check it mechanically.
4:2:2 and what it costs
Chroma subsampling is the other axis, and it matters more than the data rate for a specific class of material.
4:4:4 keeps full colour resolution for every pixel. 4:2:2 keeps full colour vertically and halves it horizontally. 4:2:0, which is what most delivery codecs outside ProRes use, halves it in both directions.
For photographed material this is largely invisible, which is why 4:2:0 survives everywhere. Where it stops being invisible is anything with a hard edge between two saturated colours: titles, logos, graphics on a solid background, and green screen. A red caption on a blue field in 4:2:0 gets a soft, wrong-coloured fringe. In 4:2:2 it is better. In 4:4:4 it is correct.
This is the reason ProRes 4444 exists and the reason a spec that mentions graphics or keying will usually ask for it. If a delivery is titles over a solid background and it came back as 4:2:0, the person who wrote the spec was not being fussy.
Reading what a file actually is
ProRes writes its variant into the codec identifier, so a properly read file reports which one it is rather than just “ProRes”. The four-character codes are worth recognising if you ever look at raw stream data:
apco— Proxyapcs— 422 LTapcn— 422apch— 422 HQap4h— 4444ap4x— 4444 XQ
In practice you will read the human-readable name, and the thing to watch is that the name is specific. A tool reporting “ProRes” with no variant has not told you enough to check a spec.
What a file name proves
Nothing. Master_ProRes422HQ_v3.mov is a claim, and the number of times that claim is wrong is not small. Files get re-exported at a different setting and keep the name. They get transcoded for a review copy and the review copy gets delivered. Somebody duplicates a file to make a variant and edits neither the name nor the export preset.
The container knows what it is. The name is a label somebody typed.
Checking a folder rather than a file
Two files is a manual job. Thirty from four suppliers is not, and the failure is quiet: everything plays, everything looks broadly right in a viewer, and the mismatch only becomes expensive later.
FileLister reads the codec name for every file in a folder as it scans, alongside resolution, frame rate, bit rate and duration, and puts them in sortable columns. Sorting a delivery folder by codec is usually enough on its own — the odd one out is visible immediately.
For anything recurring, the check belongs in a filter set. A requirement of “video codec equals Apple ProRes 422 HQ” applied to every video in the folder gives a pass or fail per file, and the failures export with the reason beside them. It also settles the LT question permanently, because the requirement says exactly which variant is acceptable rather than leaving it to whoever opens the folder.
A note on what ProRes does not tell you
The codec is one field. A file can be correct ProRes 422 HQ and still be wrong: wrong frame rate, wrong dimensions, no timecode track, audio at 44.1 kHz instead of 48, loudness eight units off target. Codec is the field people check because it is the easiest one to read, which makes it the field least likely to be the actual problem by the time anyone looks.
Check it. Then check the rest in the same pass, because the marginal cost of the other eleven fields is zero once you are reading the file anyway.