The Canon 5D Mark 2 (and the 7D and a fair number of current video-capable DSLRs) record the footage using the H.264 codec. I’ll leave it to others far more qualified than I as to the merits and lack thereof of this decision by the manufacturers. For owners of the cameras wishing to use them for video it means you have some work to do after you shoot.
H.264 is often referred to as “distribution codec” — in other words it is optimized for end display rather than other purposes. Of interest to the photographer this translates to “it is really lousy for editing”.
Because of the preponderance of its use in DSLR (and other) cameras I’ll predict that future editing suites will start to ingest H.264 footage directly, perhaps converting it quietly to some intermediate format — but until that time you’ll want to do this yourself before you edit your clips.
For about the past year, when I have a set of 5D clips for editing I’ve been transcoding them to Apple ProRes. This is a high quality codec that works well with the editing tools. It also eats up disk space like they have shares in Seagate. I’ve heard of some folks using the XDCAM codec with a fair degree of success. I’ve heard plenty of other people say “disk space is cheap” (which it is), but it isn’t free and it adds up quickly.
On Macintosh there are two tools that I have tried and used and I thought I’d share a few bits about them. I edit using Apple’s Final Cut Pro Studio, which includes a transcoding swiss army knife called “Compressor”. If you don’t have the budget for FCP Studio (and, as you will see, even if you do) you should look at “MPEG Streamclip” which has a number of great features including the ever popular price tag of free. There are numerous excellent tutorials on each of these tools — just google around.
I’ve been using Compressor to transcode my 5D footage to Apple ProRes 422 pretty regularly because it has a really cool feature: droplets. You can create droplets that correspond to specific Compressor settings and destinations, then either drag the input files to the droplet (or control-click to open the file(s) with the droplet. As Emeril says.. “Bam!”
With the most recent release of Final Cut Studio (FCP 7) Apple introduced some additions to the ProRes codecs. Originally there were two variations, the normal or standard quality (at 147 Mbps) and the high quality codec (at 220 Mbps). For most of us this roughly translates into taking a lot of disk space and taking up an enormous amount of disk space. Unless you are producing a high-end film with lots of compositing (or have specific technical issues with the footage around grading) the HQ version was overkill. For most of us, producing videos for the web or DVD, even the standard quality ProRes was over the top. Enter ProRes 422 LT and ProRes 422 Proxy. The LT codec tries to find a balance between quality and space at 102 Mbps while the ProRes Proxy dives down to 45Mbps and is suited for editing on laptops. (Note that even at 45Mbps that’s 9X what Vimeo and YouTube HD are accepting videos at.)
I have yet to play with the Proxy codec extensively, but the LT codec looked very appealing and I wanted to explore some issues I had with the MPEG Streamclip program so I ran a few tests. MPEG Streamclip has the reputation of being very fast – and in a few tests I was running I never saw this. The devil being in the details of course. I also noted a gamma shift in MPEG Streamclip footage which bothered me. Again, it was worth looking at a bit closer.
First the “gamma shift” problem. Here is the output of the same video clip transcoded by Compressor (on the left) and MPEG Streamclip (on the right) as displayed by Quicktime Player:
It’s pretty obvious that the MPEG Streamclip footage is darker. Apparently this is caused by a small difference in the Quicktime file metadata. Compressor adds a “gamma” tag that MPEG Streamclip does not. The result is that Quicktime Player displays them differently. Here’s the fun part: Final Cut Pro doesn’t look at this gamma tag, or does it differently. The result is that the footage looks the same. Here is a short Quicktime video of the same clip alternating between Compressor and MPEG Streamclip:
[qt:/video/2009-transcode-comp.mov 640 360]
Maybe a more well-trained eye can spot a difference, but I can’t. So when it comes to editing it appears to me that the resulting clips are equivalent. Whew!
With quality out of the way, that leaves just space and time to consider. I processed 16 5DMk2 H.264 clips totaling 7 minutes of footage and consuming 2GB of disk space.
Depending on the project I often try to save disk space by converting the footage from the native 1080p to 720p (times are min:sec):
To ProRes 422 LT 720p via Compressor: 12:44 and 2.3GB
To ProRes 422 LT 720p via MPEG Streamclip: 14:52 and 2.3GB
To ProRes 422 LT 1080p via Compressor: 17:17 and 4.5GB (2.2X original)
To ProRes 422 LT 1080p via MPEG Streamclip: 10:54 and 4.5GB
Kinda eye-popping counterintuitive results there. If you want to save disk space by downsampling to 720p, use Compressor. If you want fast conversions the use MPEG Streamclip with no resizing.
For disk space comparisons, the standard quality ProRes 422 at 1080p would take 6.9GB (3.5X original files, MPEG Streamclip transcoded them in 11:46) .
My test configuration was pretty mundane and this was not an attempt to get the best performance out of either tool, but rather to see how they performed “out of the box”. Source and destination files were to the same drive (as you would on a laptop). Compressor has ways of using multiple systems to distribute the encoding and improve the performance. MPEG Streamclip has the ability to run multiple transcodes at once. If you have a lot of fast CPUs in your system, this can certainly help. I have a quad-processor MacPro and neither program would drive the system to full CPU capacity. By adding increasing the MPEG Streamclip to 2 simultaneous tasks I was able to trim some time off the transcoding and saw the system CPU utilization approach 80%. Adding a 3rd task didn’t do anything to increase utilization. Those of you with 8-CPU boxes would likely see a benefit from using these features to take advantage of parallelism in your system.
I mentioned ProRes 422 Proxy and I think I will dig into this a bit more. It has a data rate of 45Mbps. The Canon 5D Mark 2 with the current firmware clocks in around 38Mbps – but I don’t know if this is an apples to apples comparison. MPEG Streamclip transcoded the test files to ProRes Proxy at 720p in about 14 minutes and the resulting files were just 1.1GB (half of the original) and the full 1080p transcode took about 10 minutes and the resulting files were 2.2GB (slightly larger than the originals). I, quite honestly, didn’t see much of a difference between the full ProRes standard quality and the Proxy transcoded files with the 5D footage, so this deserves a bit more investigation to understand exactly what kinds of scenes are being compromised. If the typical delivery is going to be 720p web video (or an SD DVD) and you are doing minimal grading and editing, using the ProRes Proxy format may turn out to be a perfect editing format and you can always reconnect to higher quality versions (standard or LT) if you need them. Certainly something worth investigating further.
