« Matrox releases Axio 4.0 for CS4! | Main | Adobe Beginner Classes Episode #13 project file »

NLEs: How native workflows help you save

…Or perhaps this entry could be titled, “A study of contrasts”

I recently received the latest issue of Event DV, which is an excellent magazine with some solid writers.  Each month they’ve got some excellent contributions from Photoshop wiz, Lance Gray and an editorial from Jan Ozer.

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. 😉

This month’s article was about how to edit AVCHD content.  If you’re curious to read the article, you can view it here.

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:

Step 1: open the Log and Transfer window – This is warning #1 to me as the word ‘transfer’ often means ‘transcode.’  In other words, change my pixels and make me wait.  More on this in a bit.

Step 4: capture the footage to ProRes 422 – For the uninitated ProRes is Apple’s codec that is used for converting DVCProHD, AVCHD, RED, XDCAMEX and XDCAMHD.  It’s a solid codec that scaleable (larger or smaller) and is in some ways an answer to Avid’s DNxHD codec.

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:

Adobe Step 1:Edit.

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.

Returing 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 have give an comment on this matter since I have lately been editing a lot of AVCHD material on premiere CS4.

I have to say that AVCHD is seriously CPU intensive. I have a what I considet top of the line PC workstation and it is still a hell editing AVCHD. Previews leave a lot to imagination and honestly you can only guess what the result is going to be. Many of the plugins just doest work with the codec – in the worst case scenario youll see the ruined footage only after rendering – while there seems to be no problems on the preview.
I will definately look for a solution to trenscode all AVCHD material into something else in the future.

[DR – I agree that AVCHD is CPU intensive, though I can edit without much problem on a decent desktop system. You can do a transcode process today via Adobe Media Encoder. All you have to do is create a watch folder within Adobe Media Encoder and then drag your media to it. The Mercury Playback engine in the future will also help make editing a much smoother experience.]

As some of the other commenters have alluded to, there is the issue of editing a long-GOP codec, as compared to an all I-frame codec. This is one area where ProRes, DVCProHD, DNxHD, etc. come out ahead.

That being said, native editing is a fantastic capability and something I’m missing in FCP, especially since I’m still using FCP5 without the ProRes option. Haven’t had a chance to start playing with Premiere Pro, but I look forward to it!

And lastly, for those worried about editing AVCHD (or HDV) and having the effects rendered with that codec, FCP (at least FCP 6) allows one to choose how effects are rendered. So regardless of what codec your footage uses, your effects could be rendered in ProRes even if the sequence is nominally in some other codec.

Thanks Dennis for your tips, tutorials, and insight! As a new-comer to the Adobe world, I’m enjoying hearing from the Adobe people themselves as I learn. Apple can’t beat that with a stick!

[DR – Thanks for your comments Matthew. I’m glad you like the tutorials – there are a lot that are there and more coming. don’t forget to check out tv.adobe.com for much more.

Regarding your comments – I agree that there are benefits to things like DVCProHD, ProRes and the like. Certainly, full frame codecs clearly give you a smoother editing experience today. What I find as a common misconception is that native editing of AVCHD is either a) impossible or b) necessarily a poor editing experience. I think the main jist of the entry is that neither of those is true.]

It’s all about words, isn’t it? I’m not sure I’d consider any AVCHD clips “untouched and unconverted”. There’s an awful lot of touching and converting being done by MPEG-4, the amount varying with bitrate.If i’m concerned about getting the best footage, I’m going to use an SDI feed straight into a computer and grab to some other codec, like Apple ProRes. So I don’t have any quality issues with going from AVCHD to ProRes (i lost quality at the source, but it was a decision that I made).

As for transcoding, transcoding is something that happens without my input. Sure, I have to wait until the transcode is done, but I don’t have to interact with the process at all. If I’m on a desktop, with plenty of power to burn, I catch up on email or work on writing or even review other footage while I wait. Then I’m able to layer that many more video tracks or add more effects at the end. If I’m stuck on a laptop, I get that much more work done because of the CPU and bandwidth constraints. If I edit the source footage, I’m losing little chunks here and there all throughout the editing process, little chunks of time that I can’t do anything with.

I’ve used both Premiere Pro and Final Cut and I like Premiere’s interface better, but prefer Final Cut’s performance, especially using ProRes. I do think Adobe needs to license or develop a codec like ProRes for Premiere, especially as people have to deal with so many varying formats. Transcoding can help a lot when you have a variety of cameras providing footage. I’m thinking especially of new dSLRs like the 5D Mk2 (I love mine) where you can get some really great results for certain applications, but you want to work it in with other footage and be able to apply familiar color-correction and image processing to clips.

As for hard disk space, it’s ridiculously cheap. It’s cheaper to buy more hard drives and stick them in a RAID array than it is to buy a new computer. Hard drive capacity is advancing far faster than CPU processing ability at the moment (that could change, but not overnight)

[DR – Matthew, thanks for the comments and well thought out.

Clearly AVCHD is heavily compressed. So is XDCAM EX, DVCPROHD, DNXHD, and even ProRes is compressed. These are all mainstream codecs that are used in production quite heavily today.

DVCProHD stretches pixels both horizontally and vertically because it’s sensor is something like 960×720 (or something like that). I haven’t heard anyone really complain about it in terms of image quality. Ditto on XDCAM EX which is only ~5MB per second. RED’s wavelet compression is very heavy.

The point is that how compressed something is isn’t necessarily an indication of the picture quality or it’s ability to be utilized in production.

As for Adobe licensing codecs – I think you miss the fundamental point and a significant advantage that Premiere Pro has over Final Cut Pro. That advantage is the ability to mix and match codecs on a timeline. In a single timeline, on my laptop I have played the following clips in real-time or near realtime.

ProRes 720p24, 720p60, 1080p30, Apple HDV, native P2 MXF, native XDCAMEX, DNxHD 145, AVCHD, RED 2k, DV, DVCPro50, .WAV, .JPG, .PSD (animated), QT with alpha channel, H.264 (web), .MPG (from a .VOB).

The timeline has as many as 4 layers simultaneously and played in realtime at that particular section.

With a native, resolution independent timeline, you most often do not have to render until you are ready to do so. That rendering will happen is a given in this day for many reasons, but the native workflow combined with Premiere Pro’s playback capabilities means you render on YOUR terms, not the softwares.

Hard disk space – absolutely right. It is ridiculously cheap. 😉

If you have CS4, I would encourage you to experiment with mixing and matching codecs and see what your results are. Please post here again if you do.

As a PS – we can edit the Canon 5D footage today and mix it with no problems!]

Native editing is a HUGE deal to me. I do both commercial and personal editing on AVCHD footage and using 1/10th of the hard drive space is a major bonus.

In fact, I’m still on a slightly slower machine so AVCHD footage isn’t quite seamless (I get some jumps, etc. during playback), but I still find the space savings (and other advantages of Premiere Pro, like integration with other suite apps) to be worth the sacrifice.

[DR – Thanks Brian for the validation. Adobe believes in a native workflow. My personal experience took me through painful days of trying to edit MPEG2 footage when it was very difficult to do so. Today, no one thinks twice about editing MPEG2 on any average laptop with an NLE. My times have changed!

I think that AVCHD will ultimately be that way as well. In the meantime, I think there is a valid decision for people to make on what is best. If someone can possibly put up with some editing shortfalls in short run, the benefits to a native, tapeless workflow are self evident.]

Certainly you are right, being able to edit immediately in an NLE is helpful in a time sensitive environment.

But even if FCP could play AVCHD files natively, there are still plenty of reasons why you wouldnt want to. Its just like HDV footage – the small size is great for harddrive space, but like you said makes playback tougher, and everytime you render something, you would be rendering it into that native format. So if your output media is supposed to be H.264 for HD viewing on Blu-ray or the web, then it would have gone through two compressions before the end. Into AVCHD first when an effect was applied and rendered and then to H.264.
In comparison, if you reencoded to ProRes on import, add an effect and render, and export, you’ve gone through three encodings. To ProRes, to ProRes again, and then to H.264.

Now, you’re saying, Alan, you’ve just made my point, BUT … because ProRes is a bigger file, and an almost nearly lossless format, the first conversion to ProRes from AVCHD is almost completely negligible. And the second adds very little compression as well, compared to quite alot of compression in the original scenario when recompressing to AVCHD.

So even if FCP could read AVCHD files (and I think it would be great if it could) I wouldnt use it that way on anything important unless I absolutely had to for time considerations.

[DR – Thanks for the comments. I was hoping to get some points of view.

To address your comments, I see what your trying to say, but your assumption is that bigger is necessarily better. By that assumption, you would assume that DV25 is a better codec than AVCHD in terms of image quality and for transcoding. Obviously, that isn’t true. Because AVCHD is based on a temporally aware codec and benefits from more research and the many codecs that came before it including MPEG2, it is a superior codec both in terms of image quality and in terms of reencoding. In the same vein, based on what you’re saying, the RED camera is not a good camera simply because it’s compression ratio is so high as compared to other digital film cameras like the Arri D-20, the Viper, etc…

Your second assumption is that AVCHD won’t hold up for re-encoding as compared to ProRes. On this, I can’t comment from experience because I haven’t really tried it much, but the format wouldn’t get very far in this day and age if it did have problems. Still, in principle I agree that a bigger source file does offer a better chance for a clean image. It is a potential advantage to a transcoded workflow. Before customers draw any conclusions though, they should test what image quality would be like on an output.

Thanks again for contributing…]

Copyright © 2017 Adobe Systems Incorporated. All rights reserved.
Terms of Use | Privacy Policy and Cookies (Updated)