[ This article was first published in the August, 2008, issue of
Larry’s Final Cut Pro Newsletter. Click here to subscribe. ]
Jonathan Kirsch writes:
I don’t work in HD (yet) so I’m not that familiar with it, but reading EditWell and your newsletter has got me thinking. I’ve read instances where people say they shoot uncompressed HD and bring it in to FCP as ProRes to edit in, then export it as uncompressed HD. How is that possible? Am I remembering what I read correctly?
Isn’t ProRes a form of H.264, which is lower quality than uncompressed HD? If so, once you capture in a low quality, how to you export to high quality?
My first guess is by recapturing everything in the uncompressed HD. Isn’t that a waste of time? It seems so many people who shoot, for example, HDV, edit in ProRes. Well, isn’t that a lower quality than the HDV? What am I not understanding?
Larry replies: Jonathan, these are great questions. There’s a lot of confusion about ProRes out there.
First, ProRes is NOT a form of H-264. It is a new codec, developed by Apple, that provides high-quality, frame-accurate editing. H.264 is a distribution codec for finished work. ProRes is an editing codec to provide very high-quality images without taking a lot of storage space.
Apple, and others, describe ProRes as visually loss-less. That means that while data is being removed during compression, the resulting images do not suffer from image degradation. Based on what I’ve seen, images which have been converted to ProRes and copied 10 generations show virtually no loss in image quality. Unlike, say, images copied in JPEG or HDV for 10-generations.
Uncompressed HD can requires up to 250 MB per second — far exceeding the ability of a single hard drive to support. ProRes needs less than 30 MB per second. While this is more than a single drive FireWire 400 or even 800 can comfortably support, this is well within the range of even inexpensive RAIDs.
Here’s a quick comparison between HDV and ProRes:
| HDV | ProRes 422 | Notes |
|---|---|---|
| 8-bit depth | 10-bit depth | 10-bit is better |
| GOP-compressed | I-frame compressed | I-frame is better and much faster |
| Rectangular pixels | Square pixels | Don’t need to convert pixel aspect ratios |
| Needs conforming before output | Doesn’t need conforming | Not conforming is better |
| 4:2:0 chroma-subsampling | 4:2:2 chroma-subsampling | 4:2:2 makes for better chroma-keys and color correction |
The currently accepted HD workflow for professional-grade work in FCP is: shoot in whatever format you want (HDV, XDCAM HD, DVCPRO HD) then transcode into ProRes during capture, or as soon thereafter as possible.
Edit your sequence in ProRes, then output to D5 or HDCAM for distribution. The output would require a capture card from Blackmagic Design or AJA to convert the ProRes into a release format.
If you are going to the web, editing native HDV is fine, though much slower. If you are planning on projecting your images to a large screen, keep in mind that HDV often has problems with images, or camera shots, that are moving quickly. Shooting in a different video format might be a wiser choice.
8 Responses to Understanding ProRes 422
The paragraph that starts with “HDV ProRes 422 Notes 8-bit depth 10-bit depth”, is beyond my comprehension. It makes no sense to me whatsoever. Did some punctuation get lost? It seems like sentences are run on.
The preceding sentence said this paragraph would be a comparison, yet I see no signs of comparison.
For example, take the copied text in quotes in MY first sentence, What words refer to which codec? What the heck is “GOP compressed”, a republican boil down? What the heck is “I-frame compressed”, if it comes from Apple should the “I” be “i” ? As far as conformance goes, it’s not clear to me which characteristics go with what.
Ken Ackerman
Ken, it’s a comparison table. Thanks for bringing attention to that. It’s fixed now.
Ken:
Um, yeah, in the version you read that paragraph was supposed to be a table. It is now a table again, and MUCH more readable. Sorry.
I-frame compression means every frame is complete unto itself. DV, DigiBeta, P2, AVC-Intra, HDCAM all use I-frame compression.
Long-GOP compression creates one complete image frame (an I-frame) followed by a whole of change documents, indicating where pixels move from one frame to the next. This yields FAR smaller file sizes, but lower quality.
Larry
It looks like it’s supposed to be a comparison table, but the table got lost.
I’ve been editing 1920×1080 footage in ProRes (HQ) for the last several years, always on a Firewire 800 bus with a single hard disk. Never had any issues with it, so I’m a bit alarmed at your statement “While this is more than a single drive FireWire 400 or even 800 can comfortably support…” No RAID was ever necessary for me to edit “comfortably” at that resolution.
Perhaps you were being overly cautious in your assessment of ProRes limitations, as I’ve always found your advice to be exceptionally well-informed.
>>Edit your sequence in ProRes, then output to D5 or HDCAM for distribution. The output would require a capture card from Blackmagic Design or AJA to convert the ProRes into a release format.<<
Huh? What happened to just exporting to QT off your timeline for distribution for the average project editor? That file can then, of course, be taken to compressor or Adobe Media Encoder to create whatever is needed for distribution. Why would the average project editor need to output to D5 or HDCAM?
All I-frames is NOT better, at least not always. GOP is one of the best compression wonders because, when used correctly, can reduce significantly the amount of data without visually affecting quality.
All-I is only useful when doing editing in a cheap or old machine, or when working with 4K or more…
Be more careful about what you state, or how do you say it.
Sergi:
Thanks for your comment, but I disagree. GOP-based codecs are more bandwidth efficient because they create smaller files. However, in order to achieve this they sacrifice image quality, color depth, and simplicity of playback.
The highest-quality GOP-encoded file may, at times, equal I-frame encoding, but never exceed it.
Larry