(Page 1 of 1 pages for this article )

Filed under: GentryMedia Sister Sites •ProPhoto Coalition •

Native DSLR Editing in Premiere Pro CS5

Now that CS5 has officially been announced, launched, and available for download and purchase, I figured it was time to blog about one of my favorite features in Premiere Pro…Native DSLR editing.

A few months back, while on Press Tour in Singapore I purchased a Canon 7D. Having only worked with some 5DMKII footage (during our demo-asset creation phase) I was really psyched to ‘get my hands dirty’ and see what these cameras could do on the video side. And more importantly, really test the power and push the boundaries of the Mercury Playback Engine.

In this brief tutorial, I’ll show you (very quickly) how to take your DSLR footage, regardless of frame-size, frame rate or aspect ratio, and start cutting your vision together…in seconds. As with RED R3D, AVC-Intra and XDCAM-EX (among many others), we handle DSLR footage NATIVELY; those H.264 files straight from your Canon or Nikon cameras can be dropped into Premiere Pro, and you just, well, EDIT. No transcoding, no wasting time. And remember: Bridge CS5’s ‘Photo Downloader’ can be used to simply grab the video files from your camera’s media card. That’s how I do it (but you’ll see reading from cards directly too). Adding transitions, Color Correction, Keying, other effects…it all works the same. And the with amazing new 64-bit Mercury Playback Engine, you can work with these effects and playback without rendering.** Check it out…

DSLR Editing in Premiere Pro CS5 from Jason Levine on Vimeo.

(I’d recommend making it full-screen, as it was originally captured in 1920x1200; the video here, in VimeoHD, is presented in 720p)

I hope to do a little follow-up in the coming weeks on some additional DSLR workflows. In the meantime, if you want to learn more about the power of the Mercury Playback Engine (and the 64-bit capabilities of Premiere Pro) be sure to check out Karl’s latest Short & Suite episode.

And if you want to download the trial of CS5 Production Premium, click HERE.

Blog on…preferably, in 64-bit

**Mercury by itself is a software engine. As such, even on my MBP laptop (the newest model, 17” COREi7 w/8GB RAM) I’m able to typically add Fast Color Corrector (a 32-bit floating-point color effect), Sharpening and Levels and *still* get real-time playback, without any kind of rendering or GPU acceleration. For more info on leveraging Mercury with GPU-accelerated cards, watch the Short&Suite video above.

(Page 1 of 1 pages for this article )

Thanks for this movie and info, but I am still a bit confused about the acceleration aspect of Mercury.

From what I gather from the article above, Mercury is a software engine that accelerates video playback in Premiere, but can offer even more acceleration when coupled with a (select few) GPU card.

Is this correct? If so, why only offer GPU acceleration with such hi-end cards? If it is already working in software, why not a more “generic” GPU like the 8800s that are so common?

I was under the assumption that this was a high-end kind of thing and as such required a hi-end GPU. But if it is already working without GPU acceleration (as suggested here) then why require such beefy cards for ANY acceleration at all?

What exactly do I gain from adding one of the listed GPUs? Can someone provide a link to more detailed info? I really can’t afford to get a new GPU just to test this stuff out, but I can justify the cost if the speed benefits are tangible (esp for RED and DSLR footage).

Thanks!
Scott

Posted by .(JavaScript must be enabled to view this email address)  on  05/11  at  12:52 PM

---

Posted on behalf of Karl Soule, Adobe Technical Evangelist, Dynamic Media

Let’s see if I can break this down…

The Mercury Engine is a combination of technologies that take best advantage of today’s computer hardware. Everyone can take advantage of the 64-bit support and the multi-core optimization, which dramatically speeds things up on a wide variety of systems. I see very nice performance on my MacBook Pro with Mercury, with multiple HD streams, or native DSLR footage.

The GPU acceleration has tighter hardware restrictions because it needs to operate real-time, all the time. Our implementation of GPU acceleration is not just for rendering - it’s for real-time playback, and is one of the most demanding implementations of the CUDA architecture out there.

In testing, we noticed some GPUs could actually impair performance when compared to “software mode.” This mostly included older GPUs, which are still listed as “CUDA-enabled” on Nvidia’s site, but don’t have the performance of the newer, many-hundreds-of-cores chips. Their CUDA support works fine for other applications that use rendered acceleration, but did not provide the performance necessary for our real-time implementation.

In other cases, performance could start strong, but throttle back as the card got hot. Again, not a problem for rendered work, but a sudden drop in performance in a multiple-hour edit is unacceptable to today’s professional video editors.

GPU acceleration is also dependent on dedicated video RAM on the card, and currently requires a GPU with 768MB of RAM or higher.

The “approved” list of cards represents the cards that have undergone our thorough testing for performance and heat tolerance. More cards will be added over time.

Posted by Michelle Gallina  on  05/12  at  01:06 PM

---

Many thanks for that - it makes a lot of sense.

In the time between my original post and now I also stumbled across the Lynda.com “new is Premiere CS5” video, which breaks this down even further and gives examples.

Basically, the Mercury engine is always working and allows real-time playback of footage like R3D or DSLR natively. The GPU kicks in to help (if you have a supported one) when you use certain effects or ‘motion’ settings.

I now understand why the newest and higher-end GPUs are the only ones supported. I was just curious because I remember back in the days of the x800xt how much it sped up Magic Bullet - even way back then. Of course that wasn’t h264 or HD…

Thanks very much for the info!

Posted by .(JavaScript must be enabled to view this email address)  on  05/12  at  01:12 PM

---

Our pleasure, Scott. All the best!

Posted by Michelle Gallina  on  05/13  at  10:22 AM

---

Name:

Email:

Location:

URL:

Smileys

Remember my personal information

Notify me of follow-up comments?

Submit the word you see below: