*First, I am not currently an FCP user for my primary editing tool.  This article was originally a post on the HDV forum that seemed to be helpful to some users on that forum.  The technical factors surrounding the handling of HDV in FCP have little to do with FCP itself and I have no intention of critiquing this, or any other editing system in this article.  –Tim Kolb)

HDV native editing is possible certainly, but as a rule any system that cuts HDV at X efficiency, cuts an I-frame only format (like MJPEG for example) at X+ efficiency and cuts a compression format that is I-frame and optimized to run on a computer processor at X++. The differences are variable, but the relative positions remain the same.

HDV is not an I-frame format of course, it is temporally compressed...but the part rarely mentioned is that MPEG as a compression technology was not designed to run on a PC or Mac processor...it was designed to run on a dedicated chip.PCs and Macs can run MPEG compressors and decompressors of course, but the instruction set isn't really structured to exploit a computer CPU's power at peak efficiency.

You also would want to consider that MPEG is asymmetrical in that it takes more power to compress than to decompress, which was by design as MPEG was designed as a distribution format, making it cheap to decompress for consumers and expensive and more difficult to compress...an acceptable system when content producers are doing the compression.

These factors combine to make editing MPEG a heavy load for most computers. Again, this doesn't mean that it can't be done...it's done by many pieces of software now and as the brute force power of computers continues to increase, it will continue to improve. It's a question, particularly with long form event work like weddings, of efficiency.

Some FCP users may have additional approaches to this, but the workflow options and implications that I'm aware of for FCP's most popular choices for editing HDV without an added card are

1. HDV native;
2. HDV footage on an uncompressed timeline;
3. Transcode to DVC ProHD, or decompress; and,
4. Ingest (and edit) as uncompressed.

 

The factors I've outlined have nothing to do with FCP's overall editing functionality, only the logistic implications of the workflows.

1.  HDV native
This approach has the advantage of a small filesize on disk. 2 hours at 25 Mb/s takes the same space as normal DV, about 24 GB. HDV footage is placed on the timeline and transitions and FX are previewed very fast..."real-time" is the assertion, but the resolution may drop during preview to accomodate the speed...not necessarily a big deal.

The big deal for an event videographer might ed up being the "conforming" time at the end of the process which takes some multiple of the length of the timeline to complete, variable based on your system muscle. "Conforming' would be the stage when the timeline needs to be recompressed to create the new GOP structure and render effects, etc., to be ready to output to HDV.

HDV native editing on any platform has other factors too. (I have some details on HDV native later...)

2. HDV on an uncompressed timeline
FCP can ingest HDV natively and edit on an uncompressed timeline, avoiding any recompression issues as the timeline itself is not attempting to maintain an HDV data rate. (Graeme Nattress brought this method of editing to my attention.)

The output of the timeline would then involve going out HD-SDI to a conventional HD format (probably not a normal event video workflow) or transcoding back to HDV or to SD DVD or whatever. The main advantages here would be maintaining the small HDV filesize on disk, not being restricted to HDV fixed data rates while cutting on the timeline, and restricting recompression (if needed for output back to HDV) until the end.

3. Transcode to DVC Pro HD
Ingesting and transcoding to DVC ProHD certainly will improve editing response time over HDV native, but any time you transcode to another codec, there are factors to consider.

Data rate is one consideration. DVC ProHD has four or five times the data rate of HDV so there would be more drive space required. When talking about long event timelines, this could be significant. On the other hand, it is significantly smaller than uncompressed.

Color subsampling is certainly another area. DVC ProHD's 4:2:2 trumps HDV MPEG's 4:2:0 certainly...so with no other factors involved, there would be no quality 'loss' (you can't 'improve' it of course) in color subsampling.

However, there are some other factors involved. HDV2 is not square pixel and (I'm not quoting camera sensors now, only picture sizes) is 1440x1080. DVC ProHD at 1080/29.97fps 'displays' 1920x1080 square pixel, but in reality only stores 1280x1080.

From a picture point of view, you are taking a 1440x1080 4:2:0 image and transcoding to a different codec that is 1280x1080 4:2:2.

If you are shooting HDV1 with a JVC, you actually start with a true, square pixel 1280x720 image at 4:2:0 color subsampling. Ingesting and transcoding to DVC ProHD 720p at 4:2:2 and five times that data rate (HDV1 is slightly less than 20Mb/s) seems like it should be a good idea, but DVC ProHD at 720p doesn't store 1280x720. It is storing 960x720 at 4:2:2.

None of this is to say that you shouldn't work with DVC ProHD as your edit format, but you need to test it and go into it with your eyes open.

The better response during editing may enable you to crank out your event projects quicker, justifying the larger file sizes. Any visual impact on the material may be minor and perfectly acceptable for your customer.

DVC ProHD is also a codec that was not originally designed to run on a computer. It was designed for a tape acquisition system, and therefore is a constant bitrate codec. While it runs better than HDV for editing response, a computer-based codec like that in an Avid should be even more effective. Outputting the DVC ProHD timeline would then require an HD-SDI output to an HD deck, or a transcode back to HDV MPEG or SD DV or DVD or whatever your deliverable is to be.

4. Ingesting and edit as uncompressed
Ingesting HDV and decompressing it to uncompressed is the highest quality option, but also the highest cost due to the filesizes simply being immense and the disk speed and size requirements being substantial. For a television spot, this workflow might pay off in quality benefits, but for a wedding or event this workflow would require more resources than it would be worth in my opinion.

*****

There is one more overall workflow approach which would involve purchasing an add-on card: transcoding to a proprietary format.

There are several manufacturers (AJA and Black Magic Design come immediately to mind, and there are others) who make HD-SDI video I/O cards that also come with proprietary compression systems that can provide high quality alternatives to HDV compression. 

Pros: Gentler compression can help protect image quality through the post process and the HD-SDI card can provide conventional HD monitoring.

Cons: More disk space will be required for the larger files and the disk drive subsystem will need to also be faster for responsive playback than you would need for HDV files, or even DVC ProHD.


HDV native editing
The claim that was widely made by many NLE manufacturers is that if you are "cuts-only" on an HDV native timeline, there is no re-compression. This is unfortunately impossible, at least as far as outputting the timeline back to HDV is concerned, if not at the moment that the editor makes the cut on the timeline.

Consider the factors of HDV compression of long GOP and CBR or constant (fixed) bitrate, applied to an edit sequence that might be considered typical in a broadcast or corporate environment:

(15 frame GOPs-Sony/Canon, assuming each cut represents new visual material)

The outpoint of first shot is frame 5 of the first GOP, and the next shot's inpoint is frame 11 of the next GOP. So the edit looks like this in frame numbers:

1 2 3 4 5/11 12 13 14 15 1 2 3 4 5 6....

Even though the frame 11 inpoint is not an I-frame, due to the edit to completely new visual material, the frame must be reconstructed from the original GOP basically in its entirety. This gives it the data size of an I-frame, even though it may be out of position within the original GOP to be an I-frame.

With a 15 frame GOP, the fixed data rate of 25 Mbits/s is based on seeing an full-size I-frame every 15 frames...and we've just created three I-frames (in size anyway) in 10 frame's time. We are quite simply above the data rate allowable for HDV2.

(JVCs 720p version of HDV is considered to be "HDV1" and uses a 6 frame GOP.)

The compressor...and not just any compression, but very aggressive HDV MPEG compression...needs to further compress the video to keep it under the data rate ceiling.

This doesn't address the issue of I-frame shift before output, which happens when you output an HDV timeline back to HDV. The I frames generated during acquisition have only a 1 in 15 chance of falling on an I-frame position in the output file....which results in recompression due to needing to juggle data. This adds countless predictive and bidirectional frames into I frames for output, while discarding most of the real image data contained in the original I-frames.

Whether or not all of this creates visual artifacts that you or your customer find unacceptable is your decision as a producer. Cost effectiveness and acceptable quality level mean different things and relate to each other differently in every situation.

And remember: editing HDV native as I've described it is not unique to FCP. Premiere Pro and Ulead, Vegas and Edius all have modes that can edit HDV natively and while they all have slight differences in how they handle HDV natively, they all have the same, basic hurdles to overcome.

As for examples of codecs that were developed for PC/Mac processing efficiency, the two that come most immediately to mind are CineForm's Aspect/Connect HD and CanopusHQ. Both these codecs are used as intermediate editing formats for HDV on the PC side of things and are very high quality.  Avid's proprietary codecs would also fall into this category in the cross-platform category, though Avid's original codec technology was designed to work on proprietary Avid hardware, and AJA and Black Magic (among others) have workflows designed to work with their products as well. CineForm's codecs are on the way for QuickTime on both Mac and PC, but very fast editing response that CineForm's codecs are responsible for within Premiere Pro on the PC may or may not be possible depending on how deep into the plumbing of FCP things can be tweaked by a third party vendor.

I'm sure that many users could offer nuances and variations to what's been offered here.  I'm only trying to lay out some basic parameters outlining the technical factors involved in the various methods of handling HDV through post production.

After all that...(whew!) the main point is that HDV native editing in FCP is certainly possible, but it has its advantages and drawbacks. Knowing precisely what those advantages and drawbacks are and how they affect your workflow are the key to making the best system decisions. 

-Tim Kolb

If you found this page from a direct link, please visit our forums or read other articles at CreativeCOW.net