H.264 footage

[Alan Okey]

[Shane Ross] “BUZZ!!! Wrong answer. No no no no no no no no no no no no no… Never do this. This has GOT to be painted in BIG BRIGHT RED letters on the top of every forum out there:

H.264 IS NOT AN EDITING CODEC.

It is a shooting and delivery codec, but it should NOT be used for editing. It is highly compressed thus taxing on computer processors.”

As much as I am in total agreement with you on this, I fear that it’s a losing battle. I’m actually surprised that there haven’t been more snarky “but Premiere Pro can do it” comments about this.

My fear is that a large number of people (especially those shooting on DSLRs) see this as an example of FCP being old and not in sync with the times rather than understanding or agreeing with the fundamental reasons why h.264 isn’t an ideal codec for editing. My gut feeling is that sooner or later all NLEs will adapt to deal with h.264 footage natively (despite its shortcomings) due to overwhelming consumer demand. It doesn’t mean that we have to be happy about it or that it’s the most elegant technical solution, but I fear that’s the way things are headed.

Dealing with this issue feels like trying to bail out a sinking boat with a teacup as giant waves pour in over the sides.

[Dennis Radeke]

[Alan Okey] “My fear is that a large number of people (especially those shooting on DSLRs) see this as an example of FCP being old and not in sync with the times rather than understanding or agreeing with the fundamental reasons why h.264 isn’t an ideal codec for editing.”

I’d love to hear your opinions on why H.264 isn’t an ideal codec, but I would surmise that there are two. First, because H264 is a temporal codec that editing it can be difficult. Second, H264 is not a 4:2:2 colorspace. Are there others?

[Alan Okey]

Additional reasons:

– h.264 is a lossy codec that doesn’t hold up well over successive generations of decompression/recompression

– the high CPU overhead required for decoding/encoding makes h.264 a poor performer for multi-stream (multicam) editing. A codec that requires less CPU overhead will allow for a greater number of simultaneous streams of editing when disk bandwidth is not a bottleneck. That’s why Uncompressed formats aren’t CPU hogs – there’s little CPU overhead involved.

When Apple engineered ProRes, they could have built upon long-GOP h.264 had they thought it to be a good foundation for a production codec. They didn’t, despite the fact that they were wholeheartedly behind h.264 as a delivery codec. Even Avid veterans recommend transcoding to DnxHD instead of using AMA. I trust that both companies had good reasons to develop their production codecs as they ultimately did.

h.264 excels at what it was designed to be – an efficient codec for delivery, achieving excellent image quality at low data rates. It was never designed to be a production codec, as its high overhead makes it much more difficult to work with. There’s a reason that Premiere needs a beefy GPU to edit h.264 smoothly.

I’m not convinced that simply throwing more horsepower at a problem is the most efficient solution. Perhaps a smarter use of GPU power would be to use it to accelerate the transcoding of h.264 into production quality codecs like ProRes. I’d love to see Apple leverage GPU power in this way. A Log and Transfer on steroids would be a great addition to FCP’s workflow.

If my understanding of h.264 is erroneous, please correct me.

[Dennis Radeke]

Thanks for your response and I’ll preface by saying that I’ll try to not come off as ‘snarky’.

[Alan Okey] “h.264 is a lossy codec that doesn’t hold up well over successive generations of decompression/recompression”

Potentially true. I would only add that if you a) handle the color well in the front end and have no need to worry about it until you create final output for your specific deliverables, then it isn’t that big of a deal. That is the approach of Premiere Pro.

[Alan Okey] “the high CPU overhead required for decoding/encoding makes h.264 a poor performer for multi-stream (multicam) editing.”

Adobe has demonstrated that a 64-bit multi-core, multi-threaded system can make editing multiple streams including multi-cam possible. For example, I can edit 2 streams of 5D footage at half-res on my laptop without even the benefit of an external drive. Imagine what the average iMac can do or the awesome 12 core Mac with a good amount of memory. I would say that this idea (H264 as a poor performer) is a holdover from old paradigms. I expect many will disagree and that’s okay.

[Alan Okey] “When Apple engineered ProRes, they could have built upon long-GOP h.264 had they thought it to be a good foundation for a production codec.”

I’ll just mention that Adobe does a great job editing ProRes too. I agree that all things being equal an INTRA-frame codec is a better overall editing experience. The flip side of this those is potentially exploding file sizes. It’s the same argument we’ve had for at least a decade and obviously both sides have merit.

[Alan Okey] “h.264 excels at what it was designed to be – an efficient codec for delivery, achieving excellent image quality at low data rates. It was never designed to be a production codec, as its high overhead makes it much more difficult to work with. There’s a reason that Premiere needs a beefy GPU to edit h.264 smoothly.”

Part 1 – Agree.
Part 2 – Agree, but the market and users have determined that editing H.264 IS important and therefore it matters who is providing solutions rather than what is optimal. When has creating content (or production in general) ever worked in an optimal fashion?!? 😉
Part 3- Premiere Pro doesn’t need a GPU at all to edit H.264 smoothly. My MBP, though it has an nvidia GPU, it does not help my performance of CS5 one bit. This is a common misconception. The GPU helps create a balanced system so that the user can be more productive and not beholden to renders.

Thanks for the dialog and input and I hope that this helps give more clarity for some users. Like many of the excellent pros on this forum that answer the same question many times, I feel responsible to point out that H.264 can be edited with relative ease even if it’s not designed to be a production codec.

With respect and no snarkiness…
Dennis

[Alan Okey]

Dennis,

Thank you for your thorough and well-reasoned response. It’s all too easy to become stuck in a rut if one’s assumptions are not periodically challenged.

To be fair, I don’t think that anyone has argued that h.264 is an ideal finishing codec. I can certainly see the value in the ability to edit a codec in its native format (within the context of a better quality finishing codec) if it can be done smoothly and reliably.

[James O’malley]

Hi Alan,

Cool post and responses…sorry for the late entrance.

Are you still converting or cutting now?

Are you going to master from Final Cut or a more precise pixel renderer like After Effects or better? Either way, I have some ideas for you.

Please advise if you are still looking for input.

James P. O’Malley
https://www.carnavalpictures.net

[Jesse Zesbaugh]

You can get away with doing simple stuff in FCP in h.264. Try it with out the background tasks running.
Well likely you have figured it all out by now.

But!

You might be able to get around compressor errors by dropping it all in a FCP timeline and exporting it if compressor is freaking out on you. It would all come out as one reel though. I wouldn’t know if this might cause quality loss. It’s what I would do though.

Good luck.

[Shannon Bedford]

Hi Shane, just getting back to our earlier discussion about converting with compressor.
I successfully converted and all went well.

I’m about to run another batch of conversions but have now upgraded to FCP7. You said that with FCP7 the setting to use is ProRes 422 LT. I still can’t see LT.

The options for ProRess give a choice of interlaced or progressive.
It says “for interlaced material” does that refer to the source footage being interlaced/progressive or is it referring to the final ProRes file?
How can I tell if my source H264 files are interlaced or progressive?
My final edit will be mixed up with some 1080i footage so I guess the final files should be interlaced?

You’ve been a great help so far, thanks.

S Bedford, Western Australia
FCP 6.0.6, Mac OSX 10.6.6
2 x 2.8 GHz Quad-core Intel Xeon
6GM 800 MHz DDR2 FB-DIMM

[Shane Ross]

ProRes LT and Proxy aren’t in Compressor. YOu can only get to those formats via the Media Manager. Compressor only has presets for 422 and HQ. Well, you can use one of those as a base and change the compressor setting to LT…customize it…then save that setting.

But MM will retain reel number and timecode. Compressor might not….most likely won’t.

Shane

GETTING ORGANIZED WITH FINAL CUT PRO DVD…don’t miss it.
Read my blog, Little Frog in High Def