Give Me h.264 Editing or Give Me Headaches

Apologies to Patrick Henry. One of the rumors floating around concerning Final Cut Pro 7 (and QuickTime in Snow Leopard) is that it will support native h.264 editing (via Philip Bloom). Depending on your point of view you may have read that and thought “F-ing awesome! About time!” or “Oh, great. Fantastic, another codec that shouldn’t be used for editing.” Both reactions are appropriate, because as with nearly everything, this is both good and bad. This new workflow might save time and headache, or it could end up being more of both.

The Good

Not too long ago, a camera came on the market that offered inexpensive acquisition of full-raster 1080p video on a full-frame sensor using 35mm lenses. You know which camera I’m referring to. (Hint: It’s the Canon 5D MkII.) The images from this camera are great – shallow depth-of-field, great glass, decent color. Though problems arose with the format Canon chose for their QuickTime files: h.264. In Final Cut Pro, users had to either put up with dropped frames and poor performance, or transcode the footage to a more friendly format.

I firmly believe that anything that makes life easier is generally good. With native h.264 editing, users can now pull the QuickTime files straight off the camera and begin cutting. Just like that. No transcoding, saving on hard drive space and (potentially) time.

The Bad

Most editors will be able to say that they’ve seen this before with HDV. At first, Apple allowed editing of HDV footage by transcoding it to the Apple Intermediate Codec, otherwise, editing was just plain awful. Then they allowed native HDV timelines. Like this announcement, some rejoiced, others sighed… heavily.

The problem with natively editing with codecs like HDV and h.264 (both variants of MPEG compression) is that they’re not meant for intermediate use. And many (myself included) would argue that they shouldn’t even be acquisition formats. Now, with editing natively in those formats, footage is being compressed on acquisition, compressed on timeline renders, and more than likely, compressed again on output, with another potential compression when uploaded to sites like YouTube and Vimeo (which is where a lot of these pieces end up). That’s a lot of compression.

My hope is that Final Cut Pro will at least allow for ProRes rendering on h.264 timelines the way it does with HDV and XDCam EX footage. But that is still only a stopgap measure. The greater problem may be lack of understanding as to why the old way (transcoding to a more robust codec) is really the better way.

An Aside: Misunderstanding

It’s anecdote time. A documentary friend of mine who shoots and edits is in love with his HDV camera (one of the Sony prosumer ones, I believe). And with good reason. He could affordably shoot in HD, and in 24p as well. Well, really 24p with pulldown in a 1080i stream. Now, some of what he shoots goes directly to web and is on tight deadlines. He shoots, ingests his footage as native HDV 1080i. Edits in a native HDV 1080i timeline. Then waits. Then wonders why it’s taking so long for the “conforming to HDV” process. Then wonders why there’s this weird interlacing going on, especially when he down-converts the edit to DVD or lower res QuickTimes. This is all despite several conversations we’ve had as to the nature of HDV & long GOP MPEG-2, how the camera is actually recording 24p, and that videos on the web are progressive, not interlaced.

Now, this is a great shooter, a great editor, and an all-around good guy. He’s just not an engineer and doesn’t know all the technical details. This is what is lost on many people: post production is half creative fun, half engineering and technical voodoo. Democratization of technology is great and it allows many people to work creatively when they couldn’t before. But because of that, the details are obfuscated and many don’t know why what they’re doing isn’t necessarily the best way or is sometimes causing them more problems.

It’s a Sliding Scale

In the end, it will most likely only be the professional editors who even notice and/or complain about this new workflow in FCP, provided it is even true. We just have to remember that Final Cut Studio is an inexpensive product that can arguably scale from DV editing on a MacBook to full on feature editing on a network of loaded Mac Pros. It’s not just pros using Final Cut Pro. And if this new workflow makes life just a little easier for the hobbyists/amateurs/photographers/moms/students/anyone, then it’s probably a good thing. Though it doesn’t hurt to educate someone should they ask for help or have questions.

Native R3D Support in Final Cut Studio

According to ProVideo Coalition, a recent update to Final Cut Studio now supports R3D files. At least, the same way it handles P2: re-wrapped as QT files.

We could always transcode to ProRes or work with proxies, but this now gives us the ability to work with the full 12-bit RGB data. This will be especially usefull in Color ((While I’m still relatively new to color grading and Red in particular, apparently DPX didn’t even support this. Which means we can really pull more highlight data.)).

There are a few caviats, such as being Intel-only, still no ability to work with full 4k (just the 2k data), and no Raw or Redcode timeline, since these are still read-only. Still, I’m very, very happy to gain the ability to work with the raw data instead of transcoded ProRes files or the proxies.

[Thanks John.]