Premiere Pro 6 to 5.5 frame grab comparison

[Erik Lindahl]

Adobe’s solution is to work with whatever you want.

Well I’m not quite sure about that as an 8-core MacPro barely can playback ProRes in Premier Pro CS 5.5 not to mention extremely flacky video output support (yes, FCPX is even worse but I’m not in that sinking ship yet! :)). A G5 almost handles this better in FCP7…

Reading and rendering ProRes is fine in PrPro from my experience but the actual preview in the canvas looks like garbage. I’ll try to post a screen later today.

But, with A/V foundation it’s possible to overcome the limitations of the .mov container? How does DaVinci solve this issue at the moment as it’s quite speedy at ready and writing for example ProRes? Is it stuck in 32-bit land still perhaps? Also, if .mov is a such a poor container format what should one use in a offline / online workflow in the CS-world when jumping between different applications?

In FCP-land, excluding X, it’s very straight forward – QuickTime all the way and it works good.

EDIT: Thanks for all the replies but he way.

[Walter Soyka]

[Erik Lindahl] “But, with A/V foundation it’s possible to overcome the limitations of the .mov container? How does DaVinci solve this issue at the moment as it’s quite speedy at ready and writing for example ProRes? Is it stuck in 32-bit land still perhaps? Also, if .mov is a such a poor container format what should one use in a offline / online workflow in the CS-world when jumping between different applications?”

The ProRes problem has nothing to do with the QuickTime .MOV container itself. It’s a larger issue. Here’s my understanding of how this all works.

“QuickTime” is a word that somewhat confusingly refers to several things: the MOV container format, the player application, and the multimedia framework that other developers can use to build their apps.

Adobe uses their own internal multimedia framework called MediaCore to read QuickTime MOV files and decode them when possible. This can natively decode material with codecs like Animation, PNG, and Motion JPEG.

However, proprietary codecs like ProRes and DNxHD only have decoders available natively for the QuickTime framework. This means that any application wishing to read ProRes must use QuickTime libraries (as Adobe seems to) or license it from Apple (as Avid seems to, but only on the Mac platform).

If your application is 32-bit, there’s no speed penalty for using the 32-bit QuickTime libraries (as with Resolve). However, a 64-bit app like Premiere Pro does incur a speed penalty, because it can’t use the 32-bit QuickTime libraries directly. Instead, it uses local client/server communication with a 32-bit helper process. The 32-bit helper uses the QuickTime libraries to read and decode the file and pass the decompressed images back to MediaCore, and this communication is the bottleneck that is impacting performance.

The AV Foundation API is nowhere near as mature as the QuickTime API was, and it’s not cross-platform, either. AV Foundation is new in Lion; FCPX running on Snow Leopard uses an internal, private version of the framework. It seems that Apple has implemented ProRes encode/decode on AV Foundation, so for now at least, they enjoy a benefit that no one else does.

Walter Soyka
Principal & Designer at Keen Live
Motion Graphics, Widescreen Events, Presentation Design, and Consulting
RenderBreak Blog – What I’m thinking when my workstation’s thinking
Creative Cow Forum Host: Live & Stage Events

[Jeremy Garchow]

[Erik Lindahl] “an 8-core MacPro barely can playback ProRes in Premier Pro CS 5.5 not to mention extremely flacky video output support “

My 8core can playback ProRes in CS5.5, but I have to turn the video out off. The video out is what is slowing it down due to how the capture card has to interact with PPro. Hopefully, Adobe is aware of this and perhaps CS6 will bring improvements. Who knows.

[Erik Lindahl] “Reading and rendering ProRes is fine in PrPro from my experience but the actual preview in the canvas looks like garbage. I’ll try to post a screen later today.”

I guess I just don’t see the same thing.

[Erik Lindahl] “But, with A/V foundation it’s possible to overcome the limitations of the .mov container?”

See Walter’s post. It’s not about the container per se (although that has something to do with it) its how the program has to decode the information. Right now in Adobe and other apps, it’s limited to the now defunct Quicktime API. Avid gets around this by letting you work with the QT ProRes files via AMA, but then it also allows you to rewrap the ProRes to MXF and then works natively within Avid’s own system. A great solution.

[Erik Lindahl] “Also, if .mov is a such a poor container format what should one use in a offline / online workflow in the CS-world when jumping between different applications?”

There’s no question that Adobe is aware a good DI option is needed for Premiere. If you read back in to this thread, you will see that it has been mentioned that they are aware of it, but can’t say anything more about it. So we have to wait a little longer to see what shakes out. See here: https://forums.creativecow.net/readpost/335/28524

I am a big fan of the MXF container, even though it has it’s oddities. But, it is a universal container, designed to hold media, and I think that if the MXF format could be opened up in some way (which is odd as it’s an open source project, but has been “proprietized” over and over). For example, in my testing PPro CS 5.5 works great with camera original MXF contained material, even without CUDA.

https://en.wikipedia.org/wiki/MXF

Jeremy