[Tim Kolb]

The key is that PPro doesn’t capture “as” anything…it brings everything in natively. In FCP you have HDV transcoded to ProRes. In PPro, you don’t transcode it, you use it in its original form.

I wouldn’t bother converting your ProRes files…I’d just use them.

I think you’d find that PPro is far less fussy about editing mixed media on a timeline than FCP is…

TimK,
Director, Consultant
Kolb Productions,

[Tim Kolb]

Well…when it comes to general application H264, Adobe Media Encoder is getting better and better, but QT Pro still makes H264 output files that seem more widely compatible for whatever reason…

That said, I’ve been using AME to output Apple TV H264 and iPhone targeted H264 files for the last year or so and that seems to work out…

Now…

Your Quadro card choice sounds excellent…You should have very good timeline preview performance.

The problem here is that you should see a difference between encoding from the previews and encoding from the source files and re-executing the effects based on what you’re telling me about the content and effects of your timeline…in fact it should be relatively significant.

No matter what processor you are running, running an encode from the rendered previews should eliminate a lot of processor work for the encode…particularly with the long GOP MPEG4 and MPEG2 source media you’re using, and the effects just make it that much more odd.

Something is wrong with this picture.

Anything else significant going on with this project? There is simply something we’re missing here…

TimK,
Director, Consultant
Kolb Productions,

[Tim Kolb]

[Keith Moreau] “I hope my posts are not disparaging of Premiere Pro.”

I think it was the “I think PPro needs the equivalent or even on the Mac platform” statement that grabbed me actually.

There seem to be many that imply that whatever differences there may be in speed or processing power between the Windows and Mac platform is solely Adobe’s issue and that they better “get with it”…

I’m not advocating for Windows (there are aspects of Windows I absolutely detest…and aspects of Apple’s OS that I think are brilliant) or saying that nobody should criticize Premiere Pro…(ask Adobe…I get in my share of “suggestions”) and I’m certainly not saying everyone should dump their Macs and get a Windows machine.

All I’m trying to do is to illuminate some of the roadblocks Adobe has on the Mac side of things at this moment. I think for the most part, they work around a lot of it pretty well, but I think some development on Apple’s side will help immensely.

While your machine may not be new, it shouldn’t be terrible. I’m not an expert into what was installed in what Mac when, so I don’t know if you have 8 hyper-threading (16 logical) cores, or just 8 physical cores. I also don’t know what the relative threading limitations may be for applications as you go back in time in hardware and OS. Can Media Encoder use all 8 cores in that processor? Under your particular OS version? If it isn’t using all 8 cores, then I can see where that won’t help much in the speed dept.

The “clustering” you’re referring to sounds like multiple iterations of the Compressor application opening to work on a job… Depending on how well Compressor utilizes multiple threads, maybe multiple application processes is the only way they harness all the CPU cores?…it’s what we used to do with Canopus ProCoder back in the day before it could multithread…

If you have a CUDA-compatible display card, The CUDA cores will help with certain things like scaling, etc., but video codecs (decode or encode) aren’t written to run on GPU cores…they’re all CPU. If you’re a little limited in the CPU dept, that won’t help either.

All that said…what format are you compressing to? What is the edit timeline like…number of clips…number of effects…?

Also…what is the type of media you are using and the sequence settings you are using it on? Is there some inherent scaling on every clip? Pixel aspect change? You should see some difference in encode time if you have lots of effects by rendering, and sourcing from, the preview files…whatever they may be…because those effects just simply don’t have to be recalculated.

I’d like a clear idea of your total configuration, media, sequence settings, encoder output specifications, etc…there has to be some piece of info that will shed some light on the situation that we’re missing.

TimK,
Director, Consultant
Kolb Productions,

[Tim Kolb]

Max Quality is most useful when outputting a down-resolution encode.
(1080 to 720 or HD to SD, etc). It certainly does slow down the process, however in my experience it creates a very high quality result.

Depending on how many clips are in your timeline, I would go into the Media Encoder preferences and tell it to not use Metadata at all…that might help.

When you tried the P2 files, how did you do that? You didn’t load FCP-ingested P2 files did you? That would mean you’re still using QT on the front end…which i am quite certain is part of the choke.

FCP, ProRes and Compressor are compatible with 32 bit QT and PPro CS5 is making an adaptation to even be able to use a codec/media architecture that is 32 bit in a 64 bit environment.

I don’t think that using a reference file will help anything as you would still be accessing the same QT files at some point…and I’d bet that QuickTime has some culpability in this as I have an older Windows machine that seems to perform better than what you’re describing, even with QT files, though Adobe had to write some more proprietary ways to handle 32 bit QT on the Windows side…I’m not positive they even have the latitude to do that on the Mac side.

I think Mac users really do need to note that this isn’t Adobe’s problem alone by any stretch. I Apple users might ask why the computer company that exclusively went 64 bit in its own proprietary computer platform just a couple months short of a decade ago with Cheetah has only really just started on moving its media architecture forward (QTX), and even that still relies on a host of legacy 32 bit components at this point. (Keep in mind that I am a former exclusive Mac user as that was the “media savvy” computer for a long time…)

Getting equal performance for a 64 bit media application between Mac and Windows requires Apple to advance their platform too…Adobe has had 3 full version releases and 9 significant update patches since the last time Final Cut had a major code revision. (They’ve added lots of very nice features…no question, but universal binary and dropping AE plugin support was the last major restructure.)

Hopefully “Lion” will make some advances for Apple in some of these areas…if a really substantial QT overhaul is included.

Of course, if they do advance QT, it’s hard to say whether they’ll give Adobe any time to prepare as the corporate arm-wrestling match continues…

(sigh)

TimK,
Director, Consultant
Kolb Productions,

[Tim Kolb]

[Liam Sanderson] “However doesn’t really explain my problem, unless you think one of my hard drives just isn’t performing as it should.”

I guess I thought that was clear, yes…I wonder if your harddrives are performing in the problem systems.

TimK,
Director, Consultant
Kolb Productions,

[Tim Kolb]

Have the harddrives been tested for relative performance?

Harddrives are manufactured with only slightly more consistency than the small plastic toys they put in cereal boxes these days.

TimK,
Director, Consultant
Kolb Productions,

[Tim Kolb]

Well…the recompression thing has been addressed here, so I’ll summarize…PPro doesn’t “compress” anything. Unlike other software packages, the sequence settings are basically so a user can quickly reference what they’re using and set it up. The sequences are a setup for frame rate, frame size (including pixel aspect) and audio…that’s it. PPro works with whatever codec is on the machine.

Your “HDV” timeline was set up for the framesize, not the codec.

Preview files (when you define an area and ask PPro to “render work area”) are defined by you. You could have your HDV timeline render previews of several types…it’s not rendering HDV for previews in any case.

When you export to your frame sequence (I’d ask your “Nuke” facility if they would rather have DPX frames…I suspect they would), the idea is that PPro is going back to the original media to create the output file. That’s the reason why sequences are codec agnostic. In Premiere Pro, your media doesn’t undergo any interim processing other than whatever effects you do, in the process of editing, even with mixed formats on the timeline.

I’d have probably set up a 720p25 sequence and edited the material that way…everything that was at 720p would be handled at it’s native framesize and overall image quality would suffer much less on the 1080 HDV being reduced than on the 720p stuff being enlarged.

The GoPro stuff is H264 and PPro handles it fine…I have a handful of these cameras. I’d leave that media at 60p myself, and if you want that video to be used as “overcrank” on your 25p timeline, just right click on the clip in the project panel and modify-interpret footage and tell it that the clip is 25fps, and you’ll have every frame as the clip will playback at 25 instead of 60 (without a reinterpretation, the clip will play back at the proper length/speed on your 25p timeline…real-time speed dropping out the extra frames).

So…basically you’re set to go. I’d check on the DPX thing though…Nuke works well with DPX frames, and not to worry because the output you create will be drawn from the original footage unless you select “use previews” in the Media Encoder settings.

TimK,
Director, Consultant
Kolb Productions,

[Tim Kolb]

[Keith Moreau] “I did some tests using Prores LT as the preview file format, rendered the entire sequence so there was a green bar throughout the timeline, rather than yellow or red bars, and did encodes both using these preview files and without the preview files.

I found that there was no significant difference in the encode time either using preview files or not, even when I exported using the sequence’s format – in this case Prores LT”

Well…now you’ve changed the game somewhat by setting up your sequence this way. It’s not a bad thing, but I’m assuming the source material was ProResLT? When the preview files are also ProResLT, there would only be whatever you’d gain from pre-rendering effects, so I would guess the effects that you used in the sequence are either pretty minor, or they’re effects that are easily executed by the background PPro application that frame serves to the Media Encoder…

ProRes is a nice, light decode for most systems, which is nice, but I would bet that the fact that it, like most of QuickTime, is still 32 bit and that the 64 bit Adobe applications have some sort of an “adaptive” code fix somewhere in the background that enables CS5 to work with QT at all probably does create some additional processing over using the FCP>Compressor workflow where everything is 32 bit and it’s still completely compatible with the codec.

I might suggest, strictly for testing purposes, that you set the preview codec to DVCProHD P2. Yes, it’s a loss in color precision from ProRes, but you’ll be using a codec that is not dependent on QT and then I would be curious what type of performance you see…

As nice as ProRes is, keep in mind that while Mac ported to a 64 bit OS years ago…the NLE package and the media architecture really hasn’t changed much. I think that most software manufacturers embrace the Mac as a user interface of course, but making software that increases in capability as fast as the customer base would like while still supporting a file architecture that is nearly 20 years old at it’s core, is a real challenge.

Moving to 64 bit while trying to make 32 bit codecs work is no picnic either I’d bet.

TimK,
Director, Consultant
Kolb Productions,

[Tim Kolb]

PPro will set up a sequence of any frame size and rate.

Set up a custom sequence setting in “desktop” mode. Then verify what filetype the playback app needs and exprt it.

I work with all sorts of odd framesizes in PPro. I think this type of work is one area where PPro shows particular prowess over its competitors.

AE can certainly do the job as well…no question. But if PPro is what you’re most comfortable with, I can’t see a reason not to use it.

TimK,
Director, Consultant
Kolb Productions,

[Tim Kolb]

Jeff’s right on the mark here.

The problem isn’t in PPro CS3 or the behavior would be identical for all machines.

Keep in mind that PPro looks at several factors to determine whether or not media can play in realtime on a given system. It’s not some. “Switch” that is flipped to the wrong position.

Something about the hardware environment in those problem systems is causing a clear performance handicap.

TimK,
Director, Consultant
Kolb Productions,