[ This article was first published in the January, 2011, issue of
Larry’s Monthly Final Cut Studio Newsletter. Click here to subscribe. ]
I want to share with you something I discovered while working with an AccuSys RAID that totally surprised me. This has NOTHING to do with the RAID itself, but having the RAID made it possible for me to discover this.
Video editing is the most difficult thing we can do on a personal computer, because it requires really top-notch gear and editing software to all mesh perfectly in order to get any work done.
But what REALLY pushes your system to the limit is multicam editing. Working with more than two or three streams of simultaneous video truly separates the weak from the strong, from a hard drive point of view.
So, I decided to test this RAID by editing some 720p/60 P2 (DVCPROHD) footage with it. I was using FCP 7.0.3 and OS X 10.6.5.
NOTE: A quick technical note. DVCPROHD requires a data transfer rate from your hard disk to your computer of about 15 MB/second per video clip in order to display video in real-time. So, two streams of P2 video require about 30 MB/second. The key number to watch in the charts below is the READ number.
FireWire 800 drives can deliver up to about 80 MB/second of data; which means they are limited to about five streams of HD video. In practical terms, they may play less, depending upon the video format and other performance characteristics of the hard drive.
So, I created a multiclip containing 10 DVCPROHD clips, edited it into the Timeline, and started to switch between shots during playback by clicking the appropriate image in the Viewer.
NOTE: All the images match because, for simplicity, I took one image and duplicated it. These are all separate video files, not aliases pointing to the same file.
ONE CLICK and I got the dreaded “Dropped Frame” warning. (I hate this thing!)
Sigh…
So, I scaled back the number of clips in the multiclip to six, and everything worked perfectly.
But, what’s the sense of spending all the money to buy a fast RAID if it only does six streams of HD video.
NOTE: And if THAT isn’t a snobbish sentence, I don’t know what is. Imagine what you would have paid ten years ago to edit six real-time streams of HD video. You would have KILLED for the chance. Today, pffft…, can’t be bothered.
Then, as I was about to give it up as a bad job, a little voice in my head said: “Larry, what happens if you edit using keyboard shortcuts?”
So, I selected Tools > Keyboard Layout > Multi-camera Editing. This allows me to use the numeric keyboard to switch between cameras.
Six streams of 720p60 HD worked perfectly. (Which I would expect, since it worked in the Viewer.)
But TEN streams of 720p60 HD also worked perfectly, provided I use the keyboard shortcuts. And this I did NOT expect. I would have expected the same performance from the keyboard shortcuts as I would in the Viewer.
So then I tried 16 streams of 720p60 HD video. Worked PERFECTLY using keyboard shortcuts!
Even though running 16 streams requires Read speeds of 231 MB/second from the RAID; far more than I could get from a single drive.
Hmm… Time to get serious about this.
I transcoded 22 clips of 1920×1080 60 fps AVCHD into ProRes 422. ProRes 422 requires 17.4 MB/sec, at a minimum, for real-time playback of a single 1080p HD stream. The images are gorgeous, but the files are not small.
I linked all 22 clips together, turned off the display of six tracks (because a multiclip in FCP only displays 16 tracks at one time).
NOTE: There’s that snobbery again… ONLY 16 tracks of real-time full-res HD clips…! Sheesh…
There they are. (Thanks, Joe Centeno, for the video!)
WOW! 271 MB/sec. Playing smoothly and editing perfectly — and I was editing to a new shot about once a second, with ZERO dropped frames. Perfect playback!!
Holy Smoke!
So, here’s the key thought. The next time you are editing multicam work, make it a point to use the keyboard shortcuts. You’ll be stunned at how much easier this is and how few dropped frames you experience.
Also having a fast RAID is critical when you start editing more than four streams of video.
NOTE: Here’s a short video tutorial, available in my store, that shows how to create and edit Multiclips using the Viewer, keyboard shortcuts, and buttons.
Last month, I wrote that I had discovered a technique that allowed me to get up to 16 ProRes 422 HQ clips playing and editing at the same time in a multiclip.
Mitch Jacobson, author of the excellent book – Mastering Multiclip Techniques – wrote to challenge some of my report.
I read your latest newsletter and immediately jumped to the multicam trick. I have tried all the things you did in your article and have no luck playing back more than 5 ProRes 422 clips at a time…even on a super fast RAID.
I am on a 2008 MacPro Intel 3,1 -8 core with 8 gigs of RAM and a I’m using a ATTO r380 card and a super fast SAS/SATA RAID. I’m in Leopard 5.6.8 and FCP Studio 3. I’ve tried the RT sequence settings, reinstalled the FCP Studio, did tech tests on my system and even called in several experts to double check my work.
I believe that there may be a relationship to the length of the clip and the computer’s ability to sustain read times. How long are your test clips? I have tried 2 sec, 5 min, 20 min and 1 hour clips with gradually better results. An 8 angle ProRes 422 multiclip that has 20 minute clips plays back 165 MB/s fine but a one hour version of the same multiclip chokes after 30 seconds. Do clip lengths play a role in the computer seek times and affect processor speed???…hmmm.
Do you know of other people getting 16+ angles of ProRes?
Anyway, sorry for the long winded note. You have impeccable timing as usual and have struck a nerve! Any further insights are greatly appreciated as I am starting a new show with MTV and would love to get to the bottom of this asap.
Larry replies: Mitch, as I mentioned in my reply, by the time I got your note, I had already sent the RAID back to the manufacturer, so I was not able to test this further.
However, as I wrote last month, I was easily able to get 16 ProRes 422 HQ clips to play and edit in a single multiclip.
For the record, I’m running on a 2009 MacPro, OS X 10.6.6, 8 GB of RAM. The RAID was connected via a mini-SAS connection to an ATTO card, but I forgot to write down which one.
Still, my clips were all about 1:30 in length – it was all I had to work with in that format. If performance is based on clip length, which I have not heard before, then, that could be a potential issue.
Then, Bob Zelin sent me a follow-up on this issue.
I am the tech working with Mitch Jacobson on his issues, and read your article with great interest. I have just spoken with AJA about all of this, and they made the following suggestions.
They said that often, its not the speed of the drive array, but whether the CPU processors in the MAC can keep up. If you are getting dropped frames when running multiple streams of video in multiclip, AJA suggested to observe the Activity Monitor CPU tab, and see if it’s peaking out – because if your computer can’t keep up with the number of streams you are requesting, then you will get drop frame errors. AJA also suggested to go to VIEW>External Video, and turn external video off, because the AJA card also requires CPU processing.
As Mitch has suggested in his email to you, AJA said that for multiclip, System Settings > Playback Control video quality should be Dynamic (not High), and Frame Rate should also be Dynamic (and not full).
Larry replies: Bob, I agree with AJA on the RT Settings – and an easier way to set them is using the RT menu in the top left corner of the Timeline.
Also, keep in mind, that for my 16-clip multiclip, I was NOT getting dropped frames. Everything was playing perfectly, as long as I cut between shots using the keypad and not clicking on clips in the Viewer.
If other readers have opinions on this, let me know and I’ll share them here.
UPDATE – MARCH 9, 2011
Uli Plank adds:
Regarding the different results you and Mitch Jacobson observed, I suspect the machine.
He was using the 2008 model and you are on a 2009. We have seen massive differences between DaVinci Resolve on a 2008 model and the 2009. The older one can’t handle 10 bit reliably, while the other one can without a hiccup. Every else was the same (cores, I/O card, RAID, RAM, GPU). So, without having tested your tasks, it could well be the internal throughput, which has obviously been improved massively between models.
Larry replies: For those that don’t know, Uli Plank is a long-time contributor to this newsletter and professor at the Institut für Medienforschung in Braunschweig, Germany. I have always admired his technical knowledge.
Uli, thanks!
