The interest in HDSLR production and post shows no sign of waning. Although some of this information will seem redundant with earlier articles (here and here), I decided it was a good time to set down a working recipe of how I like to deal with these files. To some extend this is a “refresh” of the Round II article, given the things I’ve learned since then. The Canon cameras are the dominant choice, but that’s for today. Nikon is coming on strong with its D7000 and Panasonic has made a serious entry into the large-format-sensor video camera market with its Micro 4/3” AG-AF100. In six months, the post workflows might once again change.
To date, I have edited about 40 spots and short-form videos that were all shot using the Canon EOS 5D Mark II. Many of the early post issues, like the need to convert frame rates, are now behind us. This means fewer variables to consider. Here is a step-by-step strategy for working with HDSLR footage, specifically from Canon 5D/7D/1D HDLSR cameras.
Conversion
Before doing anything with the camera files, it is IMPERATIVE that you clone the camera cards. This is your “negative” and you ALWAYS want to preserve it in its original and UNALTERED form. One application to consider for this purpose is Videotoolshed’s Offloader.
Once that’s out of the way, the first thing I do with files from a Canon 5D or 7D is convert them to the Apple ProRes codec. Yes, various NLEs can natively work with the camera’s H.264 movie files, but I still find this native performance to be sluggish. I prefer to organize these files outside of the NLE and get them into a codec that’s easy to deal with using just about any editing or compositing application. Generally, I will use ProResLT, however, if there is really a quality concern, because the project may go through more heavy post, then use standard ProRes or ProResHQ. Avid editors may choose to use an Avid DNxHD codec instead.
I have tried the various encoders, like Compressor or Grinder, but in the end have come back to MPEG Streamclip. I haven’t tried 5DtoRGB yet, because it is supposed to be a very slow conversion and most TV projects don’t warrant the added quality it may offer. I have also had unreliable results using the FCP Log and Transfer EOS plug-in. So, in my experience, MPEG Streamclip has not only been the fastest encoder, but will easily gobble a large batch without crashing and delivers equal quality to most other methods. 32GB CF cards will hold about 90-96 minutes of Canon video, so a shoot that generates 4-8 cards in a day means quite a lot of file conversion and you need to allow for that.
MPEG Streamclip allows you to initiate four processes in the batch at one time, which means that on a 4, 8 or 12-core Mac Pro, your conversion will be approximately real-time. The same conversion runs about 1.5x real-time (slower) using the EOS plug-in. The real strength of MPEG Streamclip is that it doesn’t require FCP, so data conversion can start on location on an available laptop, if you are really in that sort of rush.
Timecode and reel numbers
The Canon camera movie files contain little or no metadata, such as a timecode track. There is a THM file (thumbnail file) that contains a data/time stamp. The EOS plug-in, as well as some applications, use this to derive timecode that more-or-less corresponds to TOD (time-of-day) code. In theory, this means that consecutive clips should not have any timecode overlap, but unfortunately I have not found that to be universally true. In my workflow, I generally never use these THM files. My converted ProRes files end up in separate folders that simply contain the movie files and nothing else.
It is important to settle on a naming strategy for the cards. This designator will become the reel ID number, which will make it easy to trace back to the origin of the footage months later. You may use any scheme you like, but I recommend a simple abbreviation for location/day/camera/card. For example, if you shoot for several days in San Francisco with two cameras, then Day 1, Camera 1, Card 1 would be SF01A001 (cameras are designated as A, B, C, etc.); Day 1, Cam 2, Card 1 would be SF01B001; Day 2, Cam 1, Card 3 would be SF02A003 and so on. These card ID numbers are consistent with standard EDL conventions for numbering videotape reels. Create a folder for each card’s contents using this scheme and make sure the converted ProRes files end up in the corresponding folders.
I use QtChange to add timecode to the movie files. I will do this one folder at a time, using the folder name as the reel number. QtChange will embed the folder name (like SF01A001) into the file as the reel number when it writes the timecode track. I’m not a big fan of TOD code and, as I mentioned, the THM files have posed some problems. Instead, I’ll assign new timecode values in QtChange – typically a new hour digit to start each card. Card 1 starts at 1:00:00:00. Card 2 starts at 2:00:00:00 and so on. If Card 1 rolled over into the next hour digit, I might increment the next card’s starting value. So Card 2 might start at 2:30:00:00 or 3:00:00:00, just depending on the overall project. The objective is to avoid overlapping timecodes.
Renaming files
I never change the names of the original H.264 camera files. Since I might need to get back to these files from the converted ProRes media at some point in the future, I will need to be able to match names, like MVI_9877.mov or MVI_1276.mov. This means that I won’t remove the movie file name from the ProRes files either, but it is quite helpful to append additional info to the file name. I use R-Name (a file renaming batch utility) to do this. For example, I might have a set of files that constitute daytime B-roll exterior shots in Boston. With R-Name, I’ll add “-Bos-Ext” after the file name and before the .mov extension.
In the case of interview clips, I’ll manually append a name, like “-JSmith-1” after the movie name. By using this strategy, I am able to maintain the camera’s naming convention for an easy reference back to the original files, while still having a file that’s easy to recognize simply by its name.
Double-system sound
The best approach for capturing high-quality audio on an HDSLR shoot is to bring in a sound mixer and employ film-style, double-system sound techniques. Professional audio recorders, like a Zaxcom DEVA, record broadcast WAVE files, which will sync up just fine and hold sync through the length of the recording. Since the 5D/7D/1D cameras now record properly at 23.98, 29.97 or 25fps, no audio pulldown or speed adjustment should be required for sync.
If you don’t have the budget for this level of audio production, then a Zoom H4n (not the H4) or a Tascam DR-100 are viable options. Record the files at 48kHz sampling in a 16-bit or 24-bit WAVE format. NO MP3s. NO 44.1kHz.
The Zaxcom will have embedded timecode, but the consumer recorders won’t. This doesn’t really matter, because you should ALWAYS use a slate with a clapstick to provide a sync reference. If you use a recorder like a Zaxcom, then you should also use a slate with an LED timecode display. This makes it easy to find the right sound file. In the case of the Zoom, you should write the audio track number on the slate, so that it’s easy to locate the correct audio file in the absence of timecode.
You can sync up the audio manually in your NLE by lining up the clap on the track with the picture – or you can use an application like Singular Software’s PluralEyes. I recommend tethering the output of the audio recorder to the camera whenever possible. This gives you a guide track, which is required by PluralEyes. Ideally, this should have properly matched impedances so it’s useable as a back-up. It may be impractical to tether the camera, in which case, make sure to record reference audio with a camera mic. This may pose more problems for PluralEyes, but it’s better than nothing.
Singular Software has recently introduced DualEyes as a standalone application for syncing double-system dailies.
Your edit system
As you can see, most of this work has been done before ever bringing the files into an NLE application. To date, all of my Canon projects have been cut in Final Cut and I continue to find it to be well-suited for these projects – thanks, in part, to this “pre-edit” file management. Once you’ve converted the files to ProRes or ProResLT, though, they can easily be brought into Premiere Pro CS5 or Media Composer 5. The added benefit is that the ProRes media will be considerably more responsive in all cases than the native H.264 camera files.
Although I would love to recommend editing directly via AMA in Media Composer 5, I’m not quite sure Avid is ready for that. In my own experience, Canon 5D/7D/1D files brought in using AMA as either H.264 or ProRes are displayed at the proper video levels. Unfortunately others have had a different experience, where their files come in with RGB values that exhibit level excursions into the superwhite and superblack regions. The issue I’ve personally encountered is that when I apply non-native Avid AVX effects, like Boris Continuum Complete, Illusion FX or Sapphire, the rendered files exhibit crushed shadow detail and a shifted gamma value. For some reason, the native Avid effects, like the original color effect, don’t cause the same problem. However, it hasn’t been consistent – that is, levels aren’t always crushed.
Recommendations for Avid Media Composer editors
If you are an Avid editor using Media Composer 5, then I have the following recommendations for when you are working with H.264 or ProRes files. If you import the file via AMA and the levels are correct (black = 16, peak white = 235), then transcode the selected cut to DNxHD media before adding any effects and you should be fine. On the other hand, if AMA yields incorrect levels (black = 0, peak white = 255), then avoid AMA. Import “the old-fashioned way” and set the import option for the incoming file as having RGB levels. Avid has been made aware of these problems, so this behavior may be fixed in some future patch.
There is a very good alternative for Avid Media Composer editors using MPEG Streamclip for conversion. Instead of converting the files to one of the ProRes codecs, convert them to Avid DNxHD (using 709 levels), which is also available under the QuickTime options. I have found that these files link well to AMA and, at least on my system, display correct video levels. If you opt to import these the “old” way (non-AMA), the files will come in as a “fast import”. In this process, the QuickTime files are copied and rewrapped as MXF media, without any additional transcoding time.
“Off-speed” files, like “overcranked” 60fps clips from a Canon 7D can be converted to a different frame rate (like 23.98, 25 or 29.97) using the “conform” function of Apple Cinema Tools. This would be done prior to transcoding with MPEG Streamclip.
Avid doesn’t use the embedded reel number from a QuickTime file in its reel number column. If this is important for your workflow, then you may have to manually modify files after they have been imported into Media Composer or generate an ALE file (QtChange or MetaCheater) prior to import. That’s why a simple mnemonic, like SF01A001 is helpful.
Although this workflow may seem a bit convoluted to some, I love the freedom of being able to control my media in this way. I’m not locked into fixed metadata formats like P2. This freedom makes it easier to move files through different applications without being wedded to a single NLE.
©2010 Oliver Peters
digitalfilms 