Question About System Setup

[Tom Daigon]

Yo’re welcome. Good luck! Let us know how things work out.

Tom Daigon
PrP / After Effects Editor
HP Z820 Dual 2687
64GB ram
Dulce DQg2 16TB raid
http://www.hdshotsandcuts.com

[Tim Kolb]

Configuration-wise, you have a couple of issues.

1. Your graphics card pretty basic…depending on its configuration (in the general graphics card universe that card could range from 512MB of DDR2 to 1 GB of DDR3 RAM…the Mac OEM version is in the middle with DDR3 (faster) RAM, but only 512MB…which is below PPro’s minimum spec. the scaling functions within the PPro environment are picked up by the GPU when the GPU is utilized.

2. H264 is often a single-threaded decoder…so faster cores (instead of more cores) tend to have the most effect on CPU based decoding speed, though I run CPUs that clock slightly slower than yours and I don’t have any issues with DSLR footage.

I do exactly the kind of interview editing you refer to…shooting 1080 and edit 720 and simulate 2 shots…and I have no issues (and I often do these on green screen as well). Keep in mind that data rates of DSLR footage aren’t really big enough to stress harddrives all that much…with aggressively compressed formats, the bottleneck is typically at the CPU, where the processing happens.

ProRes is a much easier decode (much bigger files that require less processing) so transcoding to ProRes would make the process smoother for you in the short term, but I have a feeling that a GPU that PPro could actually utilize would have a fairly immediate effect as well.

TimK,
Director, Consultant
Kolb Productions,

Adobe Certified Instructor

[Angelo Lorenzo]

Tim, correct me if I’m wrong, but I believe Premiere Pro uses a custom decoder for MOV h.264 and bypasses Quicktime for performance reasons. Is this also single threaded?

——————–
Angelo Lorenzo

Need to encode ProRes on your Windows PC?
Introducing ProRes Helper, an awesome little app that makes it possible
Fallen Empire Digital Production Services – Los Angeles
RED transcoding, on-set DIT, and RED Epic rental services
Fallen Empire – The Blog
A blog dedicated to filmmaking, the RED workflow, and DIT tips and tricks
Can your post production question fit in a tweet? Follow me on Twitter

[Tim Kolb]

Yes, Adobe does bypass the QT wrapper for several codecs, and H264 is one of those…(BTW, thank you Adobe!)

…and Adobe does do some innovative things with different media handling to be sure. I know there are certain circumstances where they do some creative things with different decoding schemes and they may have something they do with H264 in the way of utilizing multiple threads…

However, most of the stand alone H264 decoding schemes are pretty serial, and I know that during the testing I was doing during an assignment with NVIDIA during the CS6 development cycle, the computers that were faster H264 encoders were always based on clock speed over core count. (RED Cinema’s decoder is a single thread wide too…keeps those RED Rocket cards selling…)

During some training I did with CS6 for the US Military, we found that dual core 13″ MacBook Pros that clocked out over 3 GHz were doing pretty well editing DSLR and GoPro footage (both H264 derivatives)in Premiere Pro CS6… that said, I don’t think I’d recommend cutting a feature on one…

TimK,
Director, Consultant
Kolb Productions,

Adobe Certified Instructor

[John-michael Seng-wheeler]

[Tim Kolb] “RED Cinema’s decoder is a single thread wide too”

Which is why Premiere runs multiple instances of the decoder (On windows it’s called ImporterREDServer.exe) at once, one for each virtual core. I asume it feeds frames sequentially to each.

I had two shots each with a bad frame in from a Red One once. I first found the problem ’cause AME would crash rendering the dailies to MPEG-2 for the director to have on DVD. When I went through the footage in Premiere, if I tied to play past the bad frame everything would lock up for a while and then one of the copies of ImporterREDServer.exe would crash and I’d keep on editing. It would still work until I got down to about six copies left, at which point everything got weird and premiere would crash, leaving the rest of the ImporterREDServer.exe programs running. If I then restarted Premiere I’d have one per core again plus all the orphaned ones from before… This Craziness was all with Premiere CS5.

[Tim Kolb]

[John-Michael Seng-Wheeler] “Which is why Premiere runs multiple instances of the decoder (On windows it’s called ImporterREDServer.exe) “

Right. This is a good example of what I was alluding to, though I rarely throw RED out there as an example as it can’t be encoded and also has any number of unique aspects that often makes it an exception instead of a rule…

I typically see about 16 instances running when I run at full decode. They all shut down and go away when i quit the session, but they stay in RAM and use about 10MB a piece during the session, even if I’m no longer handling RED files. Like many pieces of software, it sounds like a corrupt file messes it up.

Nobody can encode RED files of course, but since we are usually exporting and creating frames as we go on a timeline export to long GOP format like H264, maybe the encode itself creates the speed ceiling so a faster clock helps more than adding cores beyond the render/export processes ability to use them…? All I know is that another system with dual Quads was exporting test files notably faster than my dual Hex core system and the main difference was CPU clock.

The way Adobe has been going however, I suspect many of these processes will continue to use system resources more effectively. It’s a matter of time.

TimK,
Director, Consultant
Kolb Productions,

Adobe Certified Instructor