As producers for two TV shows for the Pursuit Network, Robbie Coblentz and team had a comfortable workflow with FCP 7, with just one drawback... it took a ton of time to encode everything to a single format prior to editing. Enter Adobe's new hardware settings for PP CS6 which allow third-party cards like Blackmagic Design and AJA to work much better. Read on for the pros and cons of one week with Adobe Premiere Pro.
We produce two TV shows for the Pursuit Network
. Our SOP has been to take everything provided by the field producers, compress it to ProResLT 1920 x 2080 29.97, drop it into FCP, and roll. Encoding everything to a single format prior to editing turned out to be a critical step because it eliminated a lot of rendering, temporal, and spatial goofiness -- and just made FCP 7 work a lot better.
…But it took a ton of time.
Enter Adobe's newest version in the NLE space -- Premiere Pro CS6.
We are on Mac Pros
-- either 4,1 or 5,1 machines. The 4,1 units are 8-core and the 5,1's are 12-core. They are fast, slick machines that chew through almost anything… Anything, that is, except the funky, prebuilt hardware-specific settings in Premiere CS 5.5. That
was the main reason we only dabbled in last year's PP model.
, Adobe's new hardware settings that make third-party cards from Blackmagic and AJA work much more better. Much, much, much better. It was time for us to look at Premiere Pro again.
Premiere Pro UI -- a general workspace. Click for larger view.
We are running 4 MacPros in separate edit bays with either AJA or BMD hardware. All machines are connected to a MacPro FinalShare 40 TB media server via either 1-gig or 10-gig ethernet. Project files are kept on a separate server, hooked up via 10-gig ethernet. All edit bays can access all media or project files via AFP protocol sharing.
An editor/producer (pre-editor) organizes and cuts together hours of footage for each 28:30 episode of each series. The pre-editor does a rough cut, then a final tune for timing. They'll finish with a color and audio pass. Next, a supervising producer will pull up the project in a different edit bay to finalize timing, color and audio levels. All edit bays have Flanders Scientific monitors and JBL active cabinets.
Edit C, home of the show "Carnivore," has a Blackmagic Design Decklink Studio, 12-core MacPro and a hacked CUDA-aware GeForce GTX 570. Edit B, where our coordinating producer works, has an AJA LHePlus in a 12-core MacPro and no CUDA video card.
NVIDIA GeForce GTX 570 card from our system info. We use a GT120 to push our monitors for FCP Quartz compatibility and use the 570 for CUDA acceleration only.
The Kona LHePlus is selected for Transmit.
OUR FIRST ATTEMPT:
We started editing our first show with most of the assets in ProResLT anticipating a FCP 7 edit. We started without a CUDA card, using the new software-based approach to the Mercury Playback engine.
We brought over a two-camera synced sequence from FCP via XML. The cuts and media translated flawlessly, with one issue. The top layer camera set the sequence to "red." The layer was a pre-transcoded "b" camera interview from a Panasonic GH2. The bottom layer was a pre-transcoded "a" camera interview from a Panasonic AF100. Both cameras were 1080 29.97 ProResLT files. Clip info was identical when inspected via properties in PP. The sequences were ProResLT 1080 29.97.
You remove the top layer, and the sequence goes to "no render needed." Add the transcoded GH2 footage back, and here comes red.
Now for the funny part.
If you recreate with a new sequence, allow PP to autoset the sequence settings to the first clip -- ProResLT 1080 29.97 -- then manually add the GH2 footage into the exact same location on the sequence on top of the transcoded AF100 footage, the bar goes green, not red. Bizarre.
So the XML-ed sequence, which appeared identical to the in-Premiere created one, treated the footage differently. Weird.
Halfway through the show edit, I violated every engineering rule and added a GeForce GTX 570 card from macvidcards.com
. It's a stock GTX 570 with an EFI flashed to enable early boot screens.
We popped it in, installed the NVIDIA retail drivers, CUDA drivers (note: two separate installs) and hacked the Adobe CUDA file to add the card to the blessed list. We cranked up the machine and boom! Here was the CUDA goodness I had read about.
The GTX 570 moved "red" barred stuff (may need a render to play with no dropped frames) to "yellow" (should play with a few dropped frames, but probably no dropped frames) and "yellow" to "green" (will play with no dropped frames). Wow!
Not only did it move the render bar, but it made needed renders go faster.
Timelapses. Even though they had no render bar above them in sequence, timelapses played with dropped frames. Our solution? Throw a must-render filter -- like Magic Bullet "Looks" -- on the clip and make PP render it out. It's a quick fix.
Show 1 mostly contained identical-sized ProResLT with some native MTS files thrown in. It had a smooth edit before CUDA, but it was faster after the CUDA install. After lock in Edit C, it goes to Edit B for final approval, color correction and export.
We opened the project in Edit B and were greeted with a warning box referencing hardware that was used in sequence that wasn't available on the machine.
Work with sequences that any of your machines can use. We had used a sequence that referenced BMD hardware. We made a customized sequence that was hardware agnostic and based on 1080 ProRes LT 29.97. It worked on all our computers regardless of the video card installed.
After we worked through that problem, we got a second box that said the previous machine also used a CUDA card for Mercury and CUDA wasn't anywhere around. We had to delete our previews files when it auto switched to software Mercury playback. When we did that, we had a lot of red bars reappear. Yuck.
Make sure you have a CUDA card in each workstation if you are passing projects back and forth. GTX 570 #2 is on order for Edit B.
Quality control went well and the export to ProResLT was painless except for the phantom 2-gig limit across the network. You don't know about that? Neither did I.
When exporting from PP, either directly or handing it off to Adobe Media Encoder, make sure the file is under 2 gigs if you are pushing it to a network volume. Files that are over 2 gigs in size cause the export to fail if they are sent to a network volume. Set your big exports for a local volume.
So here are some of our pros and cons one week into our experience with Adobe Premiere.
- Adobe cross-suite integration. Every one puts this at top of the list, and rightly so. Being able to render in AE directly in the timeline is awesome. The same is true with PSD layer-effects translating over without having to render out to PNGs beforehand.
- The snappiness of the ap. It just feels like a modern NLE, especially on a 12-core machine. Hover scrub is responsive. The playback head moves quickly. It loads pretty fast. It feels fast, which we are seeing as a productivity boost in one of shows.
- Mercury playback. This is good and bad, depending on the machine. The Geforce GTX 570 works great with the latest NVIDIA and CUDA drivers and really speeds up the responsive of the edit process. It does not perform as well on my Thunderbolt 17" MBP or on a non-CUDA equipped machine (see below).
- Transmit. It's still a little green (again, see below), but it is so much better than their previous offering in this area. Before, you had to pick a certain type of sequence settings to edit to get Mercury playback benefits, then copy into a hardware-specific sequence type to play out to video. No more. Now you set the sequence and forget it.
- Drop it in and it plays... to a point. PP is going to bog down with multiple MTS layers stacked with color correction, blurs and the like. You can drop to 1/2 or 1/4 resolution -- ala AfterEffects -- and get more realtime in those situations, but the true format agnostic underpinnings are there. I would love an adaptive function that tells PP to move between Full, 1/2 and 1/4 resolution automatically to give me a usable product on screen without having to manually toggle the switch. But it's amazing to intermix MOVs, MXFs and MTS clips in one sequence.
- Transmit audio glitches. The most annoying thing to us is the distortion and fuzz-out you occasionally get on audio as you switch between clips in the viewers, or from viewer to program monitor in sequence. The audio will sound like a bad death metal band with amps set to 11. This happens on AJA and BMD hardware with the latest PP update and hardware drivers. We also are seeing it with an AJA IO Express, BMD Decklink Studio and AJA Kona LHePLus.
I did the dance from the Creative COW forums (http://forums.creativecow.net/thread/98/879499) and that seemed to help a bit. From the thread referenced above:
"I fixed these problems (99% of the time) by calling AJA Support. He had me not only set the OSX system preferences output to "optical digital out" but also the INPUT to "optical digital in." He said BOTH need to be set this way. Then in CS6 audio hardware preferences set to "built in output." Then set the CS6 Playback default player to "Adobe Player" and the audio device to the "AJA Kona(your flavor here).
"One final thing is that he had me do is delete my AJA preferences in the "user>library>preferences folder. Basically all of the"com.aja.xxxx" files.
"Once I did all of this and did a reboot everything has worked very nicely."
PP's preferences are almost Microsoft-like in their placement and confusion. You have three different panels that govern the audio. Couldn't Adobe streamline it a bit? (It's still better than Media Composer's plethora of preferences, though.)
- Mercury Playback via OpenCL on my Thunderbolt MacBookPro 17". It doesn't work. At all. It drops frames. It drops audio via the computer speakers or through the connected AJA IoExpress. We went back to software only for Mercury. That made it passable. We really hoped it would work. Mercury CUDA on the tower rocks.
Overall, I feel really good about Premiere Pro CS6. It's pretty quick from a FCP 7-centric workflow perspective, and it plays well with our video hardware and SAN system.
Cutting a show natively without transcoding, and then passing it back and forth between edit systems with identical CUDA video cards. We will see how it handles this in a stressed environment with files due for network in two weeks. This should be fun.