The next step is to set the horizontal offset, or convergence.  This is much more complicated than the vertical alignment, because the difference in the images that causes the depth effect also prevent the separate angles from ever matching perfectly.  The part of the image that is desired to be viewed at screen depth should be aligned, while anything that should be in front of or behind the screen will appear offset, if it was shot correctly.  This offset is what gives the view the illusion of depth.  By altering the convergence, one can change how “close” the image appears to the viewer, so this is a creative decision, and should take into account the depth of the other shots in the sequence.  By changing the convergence over the course of a shot, the illusion of motion can be created as well.

Another issue that may need to be dealt with, especially if the content was shot with a beam splitting rig, is a color difference between the left and right images.  This is usually handled the same way as color correction is in the standard post production process, but once again, can be somewhat automated in newer high end software.

There are a few other more advanced processing steps that can be taken to further refine a stereoscopic image for natural and easy viewing by the audience.  These include ghostbusting, which attempts to eliminate crosstalk between the left and right images in high contrast areas, and floating windows, which make objects that cross the edges of the screen seem less jarring to the viewer.  Over the past few years, I have used many of these techniques to manually process stereoscopic video, using standard 2D video tools, like Adobe After Effects.  We are finally beginning to see dedicated stereoscopic features being developed for these applications, that help streamline that process, without requiring extremely expensive dedicated stereoscopic software toolsets.

The solution that I use for my stereoscopic work is Cineform’s Neo3D, which allows 3D content to be processed through a fairly standard post production workflow.  They also have a creative way of supporting stereoscopic content, that allows stereoscopic finishing work to be done during any step in the process, even concurrently on a separate system if desired.  This process uses the same active metadata workflow that they have made available for color correction for the last few years.  All of the stereoscopic adjustments, as well as the muxing of the left and right streams is done on the fly by the decoder, so changes don’t have to be permanently rendered into the media, and the target application receives a premuxed single stream of video.  This allows certain 2D apps that have no integrated support for stereoscopic post, to be utilized for 3D editorial, and still give editors a live stereoscopic preview.  I discussed the options for connecting 3D preview displays, as well as some of the display options available, in earlier articles in the series.  I am sure the process will continue to evolve as new products are developed to simplify the workflow.

Twixtor is a plug-in from ReVision Effects that allows you to change the frame rate of your footage thru motion compensated frame blending.  While it can be used to add frames for slow motion effects, I have found that I get much better results when removing frames, such as when dropping from 30fps to 24fps.  Regardless of the specific settings, Twixtor takes a lot of time to render.  In our first tests on 8-Core Xeon systems, processing one minute of source footage required one minute of render time.  Now with Intel’s new Nehalem based CPUs, and recently their even newer Gulftown 6-core chips, we have seen that reduced by about fifty percent, to a half hour per minute of source footage, which is still a long time, but feels great compared to where we were a year ago.  Since our footage re-link process is based on frame counts, we have to process our entire source clips in order to take advantage of that level of workflow automation, even if we are only using the last ten seconds of a 14 minute take.  Obviously there are ways around this, but we currently have more render time available to us than man hours, and it gives us more flexibility later on anyway, so we just let it go.  We took advantage of every night and weekend during creative editorial to Twixtor every clip that made it into the rough cut, and now we just have to link to that bank of processed footage to conform our cuts in CS4.  The fact that all of Canons DSLRs now support 24p should alleviate most of the frame rate and Twixtor issues in future projects.

Besides frame rate issues, Canon DSLRs present another unique challenge, in regards to color space and bit depth.  Many professional video codecs store the color values in the range between 16 and 235, of the 256 possible 8bit options.  (The reasoning for this is fairly complicated, and relates primarily to legacy analog video signal issues)  This limits pixels to 220 levels for each color in most 8bit codecs, but the MOV files from the Canon DSLRs use the entire 256 possible options (0-255) for each color.  This increases the number of possible values for each three color pixel by over 50%, (220^3 vs 256^3) but also means that converting your DSLR footage into most other 8bit formats will result in one of two issues: either the extreme values will be clipped, losing detail in the highlights and the shadows, or all of the dynamic range will be squeezed into the reduced sample-space, meaning certain intermediate values are going to be merged together if you edit in an 8bit codec.

Clipping was the most likely possibility in most existing applications prior to the release of Quicktime 7.6.2 in mid 2009.  Previous to that point, Quicktime displayed Canon clips incorrectly (clipping the values beyond 16-235) but after that update was released, most applications that used Quicktime to decode DSLR footage, were able to access the entire dynamic range of the source clips.  This support is not a foregone conclusion though, since DSLR files could be imported with a more generic MPEG4 decoder without Quicktime, and still be displayed incorrectly.  Even with properly calibrated import processes, compressing the 255 possible values for each color channel into the limited 220 values that most 8bit video formats offer, will lead to a loss of precision, and a potential increase in color banding, especially if you plan to color correct the footage later.  A 10bit video format will offer four times as many possible legal color values, and will be able to store all of the original image data with precision to spare.  Once you have color corrected your footage, and any visual effects are complete, an 8bit distribution format may be sufficient for most uses, but any image processing that takes place on the original files before you apply the “look” that you want, should definitely be processed in at least 10bit color space to preserve as much of your original image information  as possible.

When editing DSLR footage in Avid, DNxHD is the recommended intermediate format.  DNxHD files can be encoded in either HD 709 (16-235) or RGB (0-255) color space, but any DNxHD files encoded in RGB are converted to HD 709 upon import into Media Composer, regardless of the original output setting.  Therefore any DNxHD MOV files generated elsewhere for ingest into Avid should be exported at 16-235 to match Avid’s target color space, for a lossless “Fast Import.”  On the other hand, when importing DSLR footage into Avid, you should select “Computer RGB (0-255)” as the SOURCE color space, in the “File Pixel to Video Mapping” options.  (Rec. 709 is always the TARGET color space for DNxHD MXFs in Avid)  While importing with the 0-255 setting retains the full dynamic range, it still squeezes the entire range into the 16-235 gamut.  That loss of precision should not be as significant as viewable dynamic range for an offline edit, but if you planning to export your Avid sequence as your master without a separate conform, you should consider using a 10bit codec in Avid, like DNxHD 175x.  That will allow you to maintain both the original dynamic range and the bit depth, at the expense of higher storage space requirements.

Once you have a re-linked timeline of high quality 24p footage, there are still a few more steps that can be taken to cleanup the footage.  Dead pixels should be the first thing on the list to deal with.  Dead pixels can be caused by physical debris on the sensor or lens of the camera, or by an electronic malfunction with one of the photo-receptors on the CMOS sensor.  The result is the same regardless of the cause, with one of more pixels locked at a static value throughout the shot.  The simplest way to fix this is to cover the effected pixels with information from the surrounding area.  One procedural way to fix this is to duplicate the layer of footage in an AE comp, and mask out a similar section nearby and cover it.  (If you have a horizontal row of three dead pixels, mask the three pixels above them on a second layer, and then drop the top layer down one to cover the spot)  In most cases the duplicated data will be totally invisible, but be sure to QC the result.  If you are Twixtoring your footage to a different frame rate, fix the dead pixels before applying the rate change, otherwise the motion compensation process will cause the dead pixels to move around, making them much more difficult to remove in a procedural fashion.  The next step is to look for any rolling shutter artifacts, caused by the slight difference in time between when the top and bottom of the frame are sampled.  This difference in time can manifest itself in a number of interesting ways, including distortion, with the top of the frame seeming to “lead” the bottom.  It can also cause horizontal bands of brightness with quick flashes of light only being recognized by part of the sensor.  The Foundry has a plug-in called Rolling Shutter that can help reduce the image distortion caused by motion of the camera on smoother shots.  The horizontal bands have to be removed manually in a VFX process if you want to get rid of them, borrowing data from the preceding or following frames if needed.  The Canon DSLRs also exhibit some moiré and other aliasing issues due to the way they sample the low resolution video from the high resolution sensor.  The only way to really get rid of those artifacts is to selectively mask and blur the effected sections of the frame.  Lastly, if you are using Twixtor, QC the output for corrupt frames caused by the interpretation engine being unable to guess the proper motion of the moment in the shot.  If re-rendering with different settings doesn’t help, covering the bad frame with an original frame of footage from that moment usually solves the single frame issues.  Luckily the most difficult sections of footage to calculate motion compensate for, are usually segments of where using frame dropping conversion instead is undetectable, since the extreme motion should hide any stutter caused by the missing frames. (This is coming from a guy who is processing a lot of handheld combat footage)  Once these steps, as well as the rest of your visual effects work, are finished, you are ready to export and color, which should be similar to most other workflows at this point.

Canon DSLRs name each video file “MVI_####.mov” where “####” is a constantly incrementing 4 digit number.  It is easiest to identify individual cameras if each one is shooting a totally different series of numbers. (Like CamA = 1000′s, CamB=2000′s, etc.)  While there are no options in the Canon menus for manually setting the starting file number, there is way to trick the camera into starting at any number you want.  Reset the counter to zero in the menu, and then return the setting to Continuous.  Take a picture, and then use your computer to rename the JPEG file on the card to the desired number.  (In this case: 5000)  Put the card back in the camera and take another picture.  Verify that it incremented from there. (IMG_5001)  Format the card or remove it, and your camera will continue incrementing from that point. (So my next shot, will be IMG_5002, or MVI_5002 if you switch to video mode.)  You can reset it to any four digit number you want, and it will increment from there, unless you shoot with a card from another camera, without reformatting it first.  In that case, the camera will increase the file number if necessary, above any files already on the card.  The Canon 1D MarkIV has a few more options for filename prefixes, but the objective is the same, to create a uniquely identifiable series of filenames for each camera on your shoot.

Doing this will make it much easier to sort through your files, since you will be left with a separate numbered sequence of files from each camera.  I was recently on a two week shoot with twenty Canon cameras, and by setting their initial numbers 500 apart, (Since four digits gives you 10K possibilities, divided by 20) it was easy to sort the resulting files, even though due to logistics, I got some of the files many days after they were shot, and out of order.  If you set the clocks on the cameras accurately, the timestamps on the files will make it easier figure out which files are different angles of the same take.  Even with all that, I still had duplicate file names on that project, with 5600 files for that shoot, so renaming to a better convention will be important on most large projects.

Having a good naming convention for your media files can save a lot of time and trouble.  The info that needs to be contained within the file name will vary depending on the nature of the project.  For the Navy Seal movie I setup a convention that included Scene, Setup, Take, and Camera.  The next project I worked on was more of a documentary type shoot, with no script or scene numbers, so the file name was composed of Date, Camera, and an incrementing shot number.  The important things to keep in mind are: order the info intelligently for searching, keep place values consistent for sorting, (Use leading zeros) and make it unique within the first 8 characters for EDLs.  For the movie, 005A_02b.mov is: scene 5, first setup, second take, camera B.  If I want to see the other camera angles for this take, they should be nearby if the footage is sorted alphabetically.  And if I want to find other takes from that setup, I shouldn’t have to scroll too far. If during onlining I am looking for a specific clip based on the name, I go to the proper scene folder, and scroll down to the right setup, and start looking from there.  Now if you want to include descriptions in your filenames, put them after the unique identifiers up front.  This is because sorting descriptions alphabetically is relatively useless, but you can still search through them with regular OS tools, as long as the description is somewhere in the filename. (10_E_026_BigExplosion.mov)  And if your software at some point in the process truncates the name, there should still be enough info in the first 8 characters to identify the exact source file.

During the process of renaming, it is a good idea to keep a log of what you have done in case you make a mistake, and it forms a basis for content logging as well.  I do this with a simple Excel spreadsheet that records: Original Name (MVI_####), New Asset Name, Description, Comments, as well as CameraName, Date, FrameRate, or any other data that might be relevant depending on the project.  I also sort out the bad takes and delete the .THM thumbnail files during this stage. (The THM files are actually JPEGs that can be opened if you rename them, but I have never found any practical use for them)  Once I have this list of what I want the files to be renamed to, to fit the filename convention for the project, I convert the log into a renaming batch file.

To do this, save a copy of your log sheet as a “Text (Tab Delimited)” file from Excel. Then delete every column except the original name and the new asset name, and insert blank columns before, in between, and after those two columns. Fill each of those three columns with a unique character, like #, $, and %. Save your file and close Excel. Open the file in Notepad, and press CTRL+H to bring up the replace window. Replace “#([TAB]” with a command and the path to your media files. (“REN D:\ProjectName\Footage\”) Replace “[TAB]$[TAB]” with “.MOV[SPACE]” unless your log included file extensions, in which case just replace that with [SPACE]. Replace “[TAB]%” with “.MOV” unless your log included that, in which case replace it with nothing. (In WinXP the only way to insert a [TAB] into the Replace dialog box is to cut and paste one from the document, with CTRL+V.)  You should be left with a text file with a series of commands that each look something  like this:
REN D:\ProjectName\Footage\MVI_0001.MOV 057_T12A_NewClipName.MOV
Save this document and rename the file extention to .bat, and double click on it to run the batch.  This should assign new names that match your log to each of your files, and make it much easier to sort through your footage, if you designed your naming convention well.

The other thing you can do with you footage log is generate an ALE, so that if you are editing in Avid, your log notes can be linked to your clips within the program.  I will go into those details, and other tips for editing DSLR files in Avid, in my next post.

So once the lenses issue was dealt with, were left with a selection of AVCHD encoded MOV files.  AVCHD is a processing intensive format that does not playback or edit very well.  While Quicktime would play the files, it clipped the blacks and the whites at incorrect levels.  16 and 235 were being stretched to 0 and 255 on decode, lowering the dynamic range.  This was caused by Quicktime incorrectly interpreting one of the header fields on the file.  The solution to this was to use CoreAVC to decode the files when converting into a different, and ideally more edit friendly, compression format.  Shortly after this workaround was developed, Apple released a Quicktime update (7.6) that fixed this particular issue entirely.

Beyond the clipping issue, there are other tricks to maximize the dynamic range of the 5D.  The picture style is used to control the way that the camera converts the 14bit RAW still into an 8-bit JPEG.  The same picture profile settings are applied to the 8-bit recorded video.  This allows you to do things to get the maximum detail out of the available 8-bits of color depth.  The first few projects I worked on that used the 5D, we used a custom picture profile that I got from Stu Maschwitz’s ProLost blog, High Gamma 5.  We did a number of comparison tests, and while High Gamma 5 gave us a wider total dynamic range, for our feature film, we eventually decided to use Neutral, one of the default Canon presets.  Neutral gave us a file that was closer to the final look we were going for, and with only 8bits of color depth, burning in your look, at least to a degree, should result in better picture quality at the end of the day.

Every file the camera records is named MVI_####.mov, with an auto-incrementing number, and no real override options.  That makes things simple on tiny projects, with one camera since each file has a unique name.  On larger projects, and ones that use more that one camera, (We usually have 15) file management can be a bit more work, to keep things straight throughout the post production process.  Our solution was to rename each MOV file with a unique 8 digit identifier as the new filename, and store the key to the original card and filename in a database.  This allows each clip to have a consistent name throughout the process, to show up on EDLs as a tape name or clip name as desired, without truncating unique values after the 8th digit for certain formats.  By the time we are done ,we usually have a source MOV, an Avid MXF, and an online Cineform AVI, all with the same content and file name.

Next up was the framerate problem, at 30p.  The first few projects I did with 5D we posted at 29.97, so the issue was solved with a simple reinterpretation of the framerate, when converting from the source AVCHD into an editing codec, and tweaking the audio .1% to match.  Unfortunately 29.97 footage doesn’t intercut with film very well, and won’t print back for theatrical masters either, so sometimes a 24p workflow is required.  For 24p projects, the conversion solution is much more complicated, involving motion compensated frame blending.  After extensive testing we concluded that this was best done with the Revision Effects Twixtor plugin for AE, or using Optical Flow in FCS Compressor on OSX.  Having a PC centered workflow, I favor the AE based solution.  With render times at around an hour per minute of source footage, it is impractical to convert all of the source footage on large projects, which necessitates an offline edit.  Since we don’t have timecode and keycode, relinking for the online requires a bit more creativity.  We have found some interesting options that are unique to Premiere Pro CS4, related to the way it links EDLs to existing source footage that make this much simpler than our first tedious tests, which involved manually rebuilding projects at 24p back in Premiere Pro CS3.  The new CS4 version can convert the TC-In on an EDL to a framecounted In-point of an existing media file, with makes the onlining of 5D footage a relatively simple automatic process after a few find-replace edits (.mov to .avi in our case) to the EDL.  In the future, it looks like Canon is going to support 24p recording on all of their DSLR offerings, so all of these crazy 30p workarounds will soon be an obselete thing of the past.

Although it is much better in rough environments than most other electronics, Canon DSLRs do have their weaknesses.  I have operated a 5D in temperatures of 20 below zero, and in the desert at over 120 degrees fahrenheit.  While we had no issues in the cold, where solid state recording has a huge advantage over tape, there are some issues at higher temperatures.  The camera sensor itself is a large piece of silicon, that generates a lot of heat on its own, and when combined with a high external temperature, in the worst cases is shuts off the camera.  You probably have to be over 150 degrees to get to that point, leaving the camera in a black metal box in direct sunlight for an extended period of time, but we have seen it happen.  A much more frequent problem, that is harder to detect, is that as the sensor begins to overheat, there will be much more video noise in the recorded picture, especially in the darks.  This is probably due to a higher latent voltage on the chip as its electrical resistance changes with the temperature increase.  This has only been a problem for us when shooting with the same camera for many hours in a hot environment, and our solution is usually just to swap the camera bodies for one that has not been used in a while.  This obviously requires having multiple cameras on set, which isn’t always an option on lower budget projects.

The last issue, that we are still finding new ways to deal with, is rolling shutter.  Having a large format CMOS sensor, DSLRs are subject to rolling shutter, or inconsistencies between the top and bottom of the frame.  I have spent the last few months working on a project that put the 5D into some of the most intense situations.  As a fairly lightweight device, it is subject to more jitter and shake than a larger camera with more inertia, and with the camera moving, the rolling shutter results in the recorded picture being slightly geometrically skewed, depending on the direction of the motion.  We also shoot high speed objects, like helicopter rotor blades, which are known to cause strange artifacts in certain instances.  So far we have been lucky with that, and haven’t found any of those types of issues in our footage.

The type of rolling shutter artifact we are struggling with the most, is gunfire muzzle flashes, especially at night.  In the dark, the flash blows out the imager, but the flash does not last as long as even a single frame.  So with the rolling shutter, the top half of a frame will be totally blown out, with the bottom part looking normal, because the flash had subsided by the time that part of the chip was sampled, or vice versa.  Setting the shutter speed lower than the frame rate causes it to screw up more of the frame or frames, and setting it higher causes it to narrow the flash into a distinct horizontal band in the footage, neither of which is desirable.  One thing we have found that helps is setting the shutter on the 5D to 1/30th.  (We usually set it to 1/50 to get similar motion plur to film shot with a 180 degree shutter)  With the 30p framerate, the flash either affects an entire frame, or matching parts on two subsequent frames.  (Bottom part of one frame, and the reverse area on the top of the next one)  This gives us an entire over exposed frame if we stitch the two parts together.  This can be hand cut back into footage that has been brought from 30p to 24p by manually selecting frames.  It remains to be seen if this solution can be scaled practically to our entire movie.  The best way to avoid this issue is to avoid recording gunfire at close range in very dark environments.  The farther you are from the muzzle flash, and the more ambient light there is, the less it is going to flare out your camera, minimizing the degree of the resulting rolling shutter artifact.

So that should convey some of the challenges are in faced in using DSLRs for filmmaking, especially on large scale projects, but it is by no means an exhaustive list.  As the tools evolve to suit the cameras, and the cameras evolve to suit the tools, many of these issues will become much easier to solve and require fewer workarounds.  The AVCHD decoding issue was solved by a new release of Quicktime, the manual lense control was solved with a new firmware release from Canon.  The 30p conversion process is the next issue I see becoming a thing of the past, if Canon can get a 24p recording option onto the 5D.  I am looking forward to that day, but in the mean time I have 2TB of 30p footage, divided into 5,000 shots, to cut into a 24p film, so I have a lot of work ahead of me.

Dual 3.0 Ghz 5365 Clovertown Intel Xeon Processors (8-Cores)
8GB Ram (Once I get a 64bit OS)
QuadroFX 4600 Graphics Card (To power my 30″ LCD)
2x300GB 15k RPM SAS Drives (125MB/s each)

The XW8400 is currently one step behind the new top of the line XW8600, but the PCI-X slots, wider 3rd party support, and much lower price, weighted in its favor.  I will be doing some tests and benchmarks in the near future, so stay tuned for the results.  I am also curious to see if the Quadro4600 properly allows fullscreen overlay output in Prospect2K’s CineformRT Premiere mode, fixing the Geforce8 overlay problem.

I got a ridiculously good deal on everything, since I waited nearly a year for the perfect opportunity, but I now have a few extra parts that I am not sure how to best utilize:

I already had all the disks I needed, with a 74GB 10k rpm SATA drive for OS and 4x 500GB SATA RAID5 for Data. My Raid5 is only getting 60-80MB/s with the integrated Intel Matrix storage controller, which is less than I was hoping for, but my data will be secure. If I continue to use the Raid5, I won’t have any place for my new, SAS drives worth $1000 bucks apiece. Alternately I could replace my Raid5 with a single 1TB disk for quantity storage with less security, and use the SAS disks in Raid0 for high-speed capture storage.

So that leaves me with a problem/question that I am looking for creative solutions to:
I need a good external enclosure for either 2 SAS drives, or 4 SATA drives. With SAS, the key factor I would be looking for is speed, and with SATA, the key factor would be security. Drobo comes to mind for the SATA drives, but is there a cheaper option with the same level of security, or better bandwidth?  Anyone know any good ways of externally connecting two SAS drives in Raid0?

Anyhow, export and render benchmark results to come, specifically with Premiere, AE, RedCine, and Cineform, plus a few FPS benchmarks for fun.

Surely the biggest issue at the moment related to consumer electronics would be the Blu-Ray vs. HD-DVD competition.  It looks like Blu-Ray has a majority of the market, and recently more companies have been dropping HD-DVD in favor of Blu-Ray.  As a consumer who doesn’t yet own an HDTV, and is not interested in paying $30 or more per movie, it doesn’t really effect me as much as it could, but I have been rooting for Blu-Ray from the side lines.  I have a Blu-Ray burner, and Adobe Encore CS3 supports Blu-Ray authoring, and I also just think the technology is better.  50GB on a dual layer disc, more capacity in the future, it is just superior all the way around, higher priced or not.

 A number of manufacturers are offering 120Hz LCD screens.  This technology is advantagious in a number of ways.  24p content will look smoother at 120Hz, as each frame is flashed 5 times, instead of alternating 2 and 3 refreshes on current 60hz screens.  Certain 3D TVs combine 120Hz with internal polarization to provide multiple image streams that can be separated with passive filters.  My primary application for this would be stereoscopic 3D video display, but there is also talk of future gaming consoles offering each player a dedicated fullscreen view.  Instead of 3D glasses, you would have Player 1 glasses and Player 2 glasses, each filtering out the other’s view.

Westinghouse is showing off their 8MegaPixel 4x1080P display, which I see being useful to all those new Red enabled 4K film-makers.  3840×2160 isn’t technically 4K, but it is close, and for $15K, what a bargain.  No indication of how they intend users to input to it, most likely through two channels of dual-link DVI.

Dell is developing a 16×5 wide monitor under the Alienware brand, targeted at gamers, but it might make for an interesting NLE workspace at 2880 pixels wide.  On a related note, Dell updated their 30″ LCD to the 3008WFP, which added analog inputs, HDMI, and the new DisplayPort, which is currently useless.

Intel’s new Skulltrail platform is what I call clever marketing of an existing product.  It is a dual socket design, identical to the professional Xeon workstation platform.  The only real addition for the consumer is overclocking capability.  I will take my 5000 series Xeon workstation instead thank you.

On that note, Apple released the details for its long awaited refresh of the MacPro lineup.  No surprises there at all.  8 cores at 2.8-3.2 Ghz, 1600MHz FSB, video options are ATI HD2600XT or faster Nvidia 8800GT, in a reversal from last release where ATI was the faster upgrade option.  Same case, 4 drive bays, now with SAS options, 4TB SATA max.  Nothing there was unexpected.

Intel also released more info on its upcoming consumer level 45nm CPUs, both desktop and mobile, but nothing much of interest in the specific details.  Maximum clockspeed still hovers around 3GHz.  Blame AMD for no serious competition in that regard.

The most significant feature that it adds is native support for Panasonic’s primary recording formats, DVCPro50 and DVCProHD.  Interestingly, the update does not support capture of these formats from tape, which requires purely a software solution, since Firewire is the primary I/O mechanism.  It does allow DVCPro AVIs created elsewhere to be imported and used though.  The ideal workflow that Adobe is trying to support with this update is the P2 workflow, primarily from the HVX-200 camera.  “Capture” from P2 cards is an OS level file copy, so regular capture settings are not required.  The P2′s native wrapper is not AVI, but MXF, so this wrapper is now supported in Premiere Pro 3.1.  My hope is that they extend this MXF support to include native XDCam files in the next revision, whenever that may be.

Other improvements from the update include fixes for the Project Trimmer, which did not handle WAV files correctly in CS3, and a bunch of random little fixes which aren’t worth noting, but that I definitely appreciate having.  Adobe has not added features to Premiere with an update between releases since it added HDV support in version 1.5.1 back in February of 2005.  At that point, their HDV solution was licensed from Cineform, very similar to their AspectHD, which was the most popular HDV editing solution for Premiere Pro at the time.  It bears noting that Matrox has supported P2 MXF files in Premiere for over a year with their AXIO line of products, and in a way similar to Adobe’s recently released solution.  Hopefully that trend increases the possibility of my desired native XDCam MXF support, similar to Matrox’s solution, becoming a reality in the near future.  Until then, I will be testing out the fixed project trimmer to free up lots of “extra” disk space, and playing back my P2 cards and DVCProHD captures without necessarily needing to use an AXIO system.