Event DV also has a recurring tutorial called Cut Lines which represents how to do things with Apple’s Final Cut Pro. It too is good, but I can’t help but often compare how things are done in Premiere Pro (call me biased. 
Author Joe McManus does a very good job of outlining the basic steps to editing content inside of FCP as well as outline one potential technical pitfall that he encountered.
There are a couple of things in the article that are not mentioned and I feel it is misleading. It is for this reason that I’m writing. Joe outlines 5 steps, but I’ve listed only the two most important ones below:
Okay. In contrast, here’s the edit workflow for Adobe AVCHD assuming that your media is plugged in or you have copied it over to the hard drive:
Now, to be fair, I think it safe to say that playing the ProRes clip in either Premiere Pro or FCP would be a smoother experience on my laptop than a native AVCHD clip. AVCHD is CPU intensive. I can play an AVCHD clip in real-time on my Mac laptop (very cool), but if you get into multiple layers, PIPs, etc., it will slow down. There’s the advantage of a transcoded clip. That being said, as with MPEG-2 before it, AVCHD will become easier to play and decode as computers continue to develop and get faster. Certainly, editing native AVCHD on a Mac tower is a good editing experience today as it is on a similar desktop PC.
Returning to the topic at hand, the two things that I think are not represented in the article are transcoding takes time and the size of the resulting files. On my Macbook Pro laptop, my clips were converted to ProRes in about real-time or a little more. Meaning Joe’s 6m18s clip would take about 6m18s to convert to ProRes. One of the real benefits of tapeless editing is that there’s no capture process. Even if the transcode process is faster than real-time what’s the advantage of tapeless formats if you can’t edit more quickly?
Secondly, there is the issue of storage. I took an AVCHD clip that was 23 seconds long and had an original file size of 18.4MB (I know - REALLY small!). When I converted it to ProRes with the default settings the clip size was 347MB or almost 19 times greater in file size! If we extroplate the math out to Joe’s original AVCHD clip, the size was probably about 302MB in size. Contrast that with the 5.51GB that he lists in the article. Unlike him, I don’t find that particularly acceptable, given that the original file size was so much smaller.
I don’t claim these findings to be scientific, nor am I bashing Apple, Final Cut Pro, Joe or Event DV. Far from it in fact. Look back at the first line I wrote - A study of contrasts. If your goal is to preserve your original media and get your job done quickly, I feel Premiere Pro does a better job of that today than the example that Joe outlined in his excellent tutorial. Its sometimes a lack of awareness that makes us continue to do what we’ve done in the past. Not knowing of something better, we think that what we’ve got is fine.
So, with all that said, what do you think? Does the size of the files matter to you with hard drives cheap? Does the smoother editing experience mean more to you now than having your image untouched and converted? What about metadata? Does losing the time for conversion to ProRes matter to you? I’d be curious for all points of view. Feel free to comment below.
I’ll make an unbiased defense for transcoding to an intermediate CODEC such as ProRes422 or, in my case, Cineform’s Prospect HD.
#1) To date, most of the acquisition CODECs used in cameras today really stink for NLE workflows. What’s good for cameras isn’t good for NLEs, at least not today or anytime soon in terms of affordability for a lot of folks. (We’ve heard about MJPEG (Motion JPEG)coming, eventually. That would be different as it should be good for acquistion and NLE workflows.
Like ProRes, Prospect HD uses the far superior (for NLE workflows or in-camera acquistion) wavelet based CODEC system. Prospect can transcode to a very CPU friendly 100Mbps data rate with no discernable hit on PQ. It replaces Premiere’s processing pipeline with its own and what’s more it doesn’t even give a crap what graphic card is installed. It doesn’t even use GPU acceleration!
It can transcode to various data rates less than 100Mbps or to uncompressed.
#2) While transcoding, it upsamples the I/O precision from the usual 8bit component video, which is the norm for most ‘prosumer’ cameas uo to 10bit!diately af
#3) When I had a corporate job immediately after the Sony PMW-EX1 was released, who was there with NLE support very quickly? Cineform, that’s who. Did I have to wait for Adobe? No.
With this fancy new Canon SLR that takes HD video, who is currently supporting it in Windows, or Mac for that matter? Cineform, that’s who.
Cineform has a pretty good workflow solution for Black Magic (I currently use an Intensity Pro) and Aja. They are working on external monitoring via the Intensity’s HDMI out, of PPro’s timeline too.
Personally, I think a lot of people would be doing themselves a favor by going to Cineform’s web site (or ProRes’s tech literature) and spending the time to pore over every bit of text they have there and wrap their minds around it. I fail to understand why transcoding is such a bete noire. So what if it takes a little extra time? You gain a lot of very compelling goodness.
With all of the uncertainty re RED’s workflow shortcomings, who was there with a viable solution? Guess who. In fact, had Cineform been able to get its code on a chip in time, it probably would have been chosen as the RED’s internal acquisition CODEC. The RED’s internal CODEC is a 100Mbps wavelet based CODEC, very akin to Cineform’s. Cineform’s CODEC was later chosen for Silicon Imaging’s 2K cam.
Now, Cineform has released a $129.95 version called Neo Scene for Win and Mac, to handle AVCHD or whatever else today’s cams want throw at it.
Hopefully Adobe will license Cineform’s technology, just fold it in, and let people assume it’s all ‘native’.
Posted by wsmith on 03/03 at 11:15 AM
Why can’t we just shoot in ProRes? Wishful thinking, I know.
Posted by ninjanels on 03/03 at 11:16 AM
I can ‘shoot’ in Cineform’s CODEC if I want to (and be tethered to a laptop. I can capture via the HDMI-in or component-in via my Intensity Pro, directly into Cineform’s CODEC.
Unlike with ProRes, I could do that on a Win or Mac system…
Posted by wsmith on 03/03 at 11:56 AM
Let me comment on the comments:
wsmith:
#1 - First, my article wasn’t there to attack non-native workflows per se, rather it was an attempt to underscore the differences and what I think are some inherent benefits of a native workflow.
While I agree that there are challenges with temporal based codecs such as MPEG2 and AVCHD, history has shown that hardware CPU’s catch up. As I pointed out in my post, no one ever mentions that they have a problem editing MPEG2. 10 years ago, though it was an entirely different matter.
On your comment on MJPEG - I thought we were glad to have left it long ago, but perhaps you’re referring to something else?
As for Prospect HD - while I haven’t used it much myself, I’ve only heard good things about it and I am also happy to say, there are products offered for Premiere Pro so that you can do your work with Cineform directly within the apps should you so choose. Furthermore, I agree that wavelet compression has come a long way, but I’d also point out that originally it was deemed challenging because hardware (CPU’s) couldn’t decode it fast enough. Times change.
GPU acceleration - not sure where this came from, but to be clear, AVCHD playback is not dependent on GPU playback. Adobe has been working on leveraging the tremendous power that the GPU offers, but currently it’s not involved with playback. So, Adobe doesn’t ‘give a crap either’ about what graphics card you have.
#2) 10 bit is nice, but again it increases the overall size of the file dramatically and most people don’t need it for the kind of work they do. I expect that 10bit and greater will become the norm over the next 5 or so years though.
#3) Adobe offered support for XDCAM EX format approximately 9 months after the release of CS3. I will point out that Avid just announced support this week, so it is a strong indication of our commitment to supporting codecs. But beyond the basics of supporting it, you’re again forgetting the advantages of a native workflow - no capture necessary (save time), no touching of the pixels and save space (more than 50% minimum with XDCAMEX)
As an aside the new Canon 5D mk2 can be edited in Premiere Pro CS4 with no additional software. An extra ‘perk’ of native editing if you will.
In closing, I think that the reason why people get uptight about a transcoding workflow is potentially twofold: First digital artists don’t like their pixels touched if they can help it. Second, storage may be cheap, but we find more ways to fill them up than ever before so if I can save space, I’ll do it.
Thanks for the comments and best wishes..
Posted by Dennis Radeke on 03/03 at 01:43 PM
Dennis, I used the word ‘defense’ loosely.
I do wonder why a technology such as Cineform’s doesn’t get the mindshare I think they should, despite people like Mr Ozer giving it its due as a viable solution.
I suppose many people think that if Adobe doesn’t have it built-in then it must be suspect. Kudos to Adobe’s marketing people on that.
I really have to wonder what these “inherent benefits of a native workflow” are.
I remember that HDV could, for quite a while, only be done in PPro by benefit of the licensed Cineform CODEC that was built-in as a HDV preset. I’m sure many people just considered that ability as ‘native’ in PPro. That’s because they didn’t have to pay extra. Adobe paid for it and included it.
On MJPEG: Blackmagic Design doesn’t seem to deprecated it one bit. They use that superior CODEC in their workflows.
On GPUs: Not used for playback but certainly
Cineform doesn’t offload such work to the GPU. That was my point in saying that Cineform doesn’t care what graphics card is installed.
Adobe has been very busy offloading processor intensive chores to the GPU and certainly does care what graphics card is installed. Am I really incorrect on that?
Re #2): 10 bit is nice. Period. Most people would prefer not to see ‘banding’. Most people would like to be able to do some basic color correction, etc. which is greatly improved in 10bit. Not to even mention far superior results when compositing graphics.
When Cineform gives me a 10bit workflow and in a visually lossless (soon to be mathmatically lossless) 100Mbit data rate that’s real easy on my less-than ‘Ferrari’ CPU, I’m sold! People do need 10 bit and I’m here to tell them that.
Re #3): 9 months to support the EX1? personally I don’t regard this as a “strong commitment to supporting CODECS.” I do regard Cineform as having a very real ability to support new cameras and hardware. Ability and commitment are obviously different things.
Again, aside from who supports what and who does it first, what are the ‘advantages of a native workflow’ I’m not seeing? I don’t regard waiting a bit during a transcode before I can edit as a disadvantage at all.
Not sure what kind of horsepower is required to edit the new Canon 5D mk2, multi-stream, in realtime. I have a friend who just got one and I intend to investigate. Does it upsample it to 10bit? Do we need a Ferrari CPU? An expensive graphics card?
People can touch my pixels all they want when they do such good things as Cineform does. On the issue of space: 100Mbit wavelet is visually lossless and visually comparable to uncompressed. Transcode at a considerably lower datarate and you’ll still have fabulous looking files, thanks to the vastly superior CODEC. Your correct; storage is cheap. What is a storage problem for cameras isn’t, and shouldn’t be considered a problem for NLEs.
I dare say that if Adobe were to adopt Cineform’s CODEC and replace its processor pipeline with Cineform’s, people would gladly suffer a little wait to ‘ingest’ (retire the T word) their sacred pixels and be quite happy compared to Adobe’s current ‘native workflow’ for AVCHD.
I rest my case.
Posted by wsmith on 03/03 at 09:51 PM
Mr. Gary Adcock has just posted an excellent review of ProRes on this site. It makes a very compelling case for transcoding to an intermediate CODEC. Many of the points I make re Cineform are true for why ProRes is so useful.
Note: In my first response I incorrectly stated that ProRes also uses a wavelet based compression scheme. Apparently I was incorrect on that. ProRes uses a DCT scheme. (I’m not on Mac so please forgive me for that).
I’ve asked Mr. Adcock if he might consider a similar look at Cineform’s CODEC. Insofar as Cineform is cross-platform compatible, it seems to have a distinct advantage in that regard.
But how well does it stack up against ProRes?
wsmith
ProRes: A Closer Look
Posted by wsmith on 03/04 at 12:48 PM
