Apple and RED surprised everyone yesterday with updates that allow you to re-wrap the native .R3D files as a .mov and then bring them into Final Cut Pro instead of converting the clips to ProRes or editing the proxies. The first thing that I wondered is how much of a time savings would this be since you are not transcoding to new media, merely copying the .R3D to your Capture Scratch folder as the re-wrap occurs. Here’s an unofficial speed test on the difference in conversion times using a MacPro 3 GHz Quad-core machine pulling the .R3Ds from an internal drive and creating the new media in networked fiber-channel storage.
Our test subject, a 212 MB 2K .R3D file running approximately 33 seconds:
Image may be NSFW.
Clik here to view.
Using the FCP Log and Transfer tool and transcoding this file to ProRes HQ took 2 minutes and 42 seconds.
The same clip importing through the Native setting of the Log and Transfer tool:
Image may be NSFW.
Clik here to view.
This method took only 4.5 seconds. This is an obvious difference here as the re-wrapping of the .R3D into a QuickTime is doing what was expected; basically a file copy from your source drive into your FCP Capture Scratch folder. Again, this was to be expected as it has been seen in the demos of this workflow that have occurred recently as well as what is described in the RED white paper that comes in the download from RED support to allow this new type of operation in FCP. But if you haven’t read the white paper then now you know! The file size between the .R3D file and the re-wrapped RED QuickTime files is the same, 212 MB:
Image may be NSFW.
Clik here to view.
So that’s the good news; the native re-wrapping of .R3D files gives editors a very fast and self-contained option to quickly get RED files into the edit without having to worry about the flakiness of the non-self contained proxy files. The bad news? They are still just as processor intensive as the proxy files. As I play around with these files, back to back with proxy files, I don’t see any performance advantages at all. To be fair, the RED white paper states that “RED QuickTime media is processor-intensive to work with in
Final Cut Pro” and that is true for the proxy files as well. A single stream of RED media can be played back quite well but as soon as you begin to pile on transitions and layers and titles you see real performance hits. Get a multiclip of any real size in the timeline and attempt multiclip playback and things grind to a halt. This has always been my problem with the proxies from the beginning. They are fine for small, quick, simple edits but when you begin doing the things that editors try to do at speed then the performance isn’t there. But it is a step in the right direction so something is better than nothing. Now if only we can get that native Adobe Premiere Pro workflow going and compare …..
