With the wild success of HDSLR cameras from both Canon and Nikon, there is a renewed interest in editing H.264 media natively, using the video files that are transferred directly from the camera into your editing system. H.264 is the video format that these cameras use for capturing their images. Editing natively saves time because you don’t need to transcode your video. And H.264 files are very small, compared to other video file formats.
These are both good things, but there is a hidden cost to this that I want to talk about here.
DEFINITIONS: “Native” means to edit your project using the same video format that your camera shot. “Transcode” is geek for “Convert.” If you transcode your H.264 files into another format, say ProRes, you are no longer editing natively.
If speed in transferring files from camera to computer or small file size is the most important criteria in your professional life, editing H.264 natively makes sense. However, if render time, image quality, computer hardware costs, or integration with other video formats in the same project are important, H.264 is not the best choice.
The problem with editing natively is that you are now dealing with the significant limitations of H.264 video:
1. H.264 is mathematically intense. It takes some serious computer horsepower to decode its compression.
2. Because it is so mathematically challenging, it takes longer to render H.264 files than other formats.
3. H.264, as shot by HDSLR cameras, is an 8-bit format, which means that you are potentially compromising your effects and, especially, color correction and compositing with gradients.
4. H.264 does not integrate easily with other video formats.
We first ran into these issues when HDV burst onto the market. Using the MPEG-2 compression system, HDV also had long render times. Originally, we thought this was due to the difference in size between an SD image and an HD image. However, as time went on and we had a chance to work with other HD formats, the difference in render time could not be explained solely by the size of the image.
In fact, the slow render times were caused by the complexity of the MPEG-2 compression and its reliance on Long-GOP encoding. Apple came up with a solution to this in Final Cut Pro 6 (and later) by adding an alternate render setting, which allowed us to switch between rendering video files using their native MPEG-2 format, or using ProRes.
These settings made a big difference when working with HDV, XDCAM HD, XDCAM EX, and XDCAM HD 422. According to some tests I ran a while back, rendering HDV using ProRes on a MacPro was up to 40 percent faster than rendering in HDV natively.
But what does HDV have to do with H.264? Actually, quite a lot. Both of them use long-GOP compression.
Let’s say you are working on Final Cut Pro. Since FCP does not edit H.264 natively, you must transcode your video into a compatible format. For FCP 6 and 7 users, that means ProRes. For FCP 5 users, it means DVCPRO HD. All these transcode formats create files that are larger than the native H.264 files.
Now before there is great wailing and gnashing of teeth, there are several benefits to this transcoding approach. Both DVCPRO HD and ProRes are less hardware intensive than H.264. You don’t need a fancy graphics card and you don’t need as fast a computer to edit these transcoded formats.
Also, according to my engineering friends at Apple, when you transcode into ProRes, you move your video from an 8-bit container to a 10-bit container. (It’s actually a 16-bit container, which is even better, but let us not confuse things further.) While this doesn’t improve the quality of your initial images, it can significantly improve the quality of your rendered effects.
This gets really esoteric in a hurry, so here’s an analogy. Imagine you want to mix up a batch of drinks for some guests that suddenly dropped in. This means you need a lot of drinks in a hurry. But all you have is a one-cup measuring container. If you fill the cup to the brim, you can’t add many ingredients because liquid starts pouring over the sides. This limits the kinds of drinks you can mix. Or, you could only fill the cup half full. This leaves room for plenty of ingredients, but now it takes longer to mix drinks because you can only work with small quantities.
Either way, you can’t do what you want as quickly as you want to do it.
H.264 is an 8-bit video format. If you edit it natively, you start to lose image quality as you do color correction or composite gradients to create greenscreen keys. There just isn’t a lot of room to work. Transcoding to a higher bit-rate format solves these image quality issues.
Yes, ProRes files are larger, but they render faster and they have more room, so you can create great looking effects without losing any quality.
Now, let’s say you are working on the latest version of Adobe Premiere. One of the great new benefits of this program is that it supports the Mercury Playback Engine, which uses the power of your GPU (Graphics Processing Unit) to speed rendering.
The Mercury Engine is fast! Effects render so fast that you can play effects in realtime. But you still haven’t solved the issue of 8-bit vs. 10-bit. Plus, you need a really recent computer and a souped-up graphics card to take full advantage of the speed.
H.264 is an outstanding distribution format (Google’s attempts at trying to get us to convert to Web/M notwithstanding). It is an acceptable acquisition format. But it is not a good editing format when you care about image quality, render speeds, or lots of effects work.
Just something to think about as you plan your next project.
Larry Jordan is a producer, director, editor, and Apple-Certified trainer with over 30 years video production and post production experience. He is the author of five books on Final Cut Studio, along with Larry Jordan’s Final Cut Studio Monthly Newsletter; now in its sixth year of publication. He’s also a member of the Director’s Guild of America and the Producer’s Guild of America. Visit his website at
www.larryjordan.biz
.