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.