-
PPro CC – zooming out of a timeline kills performance, CPU load skyrockets
I’ve run into a really weird problem in PPro CC. If I’m zoomed way in on a timeline the performance and GUI responsiveness is great but the further out I zoom the worse it becomes. If I zoom all the way out of a 10 minute timeline PPro beach balls for 5-10 seconds every time I give it a command. Hit play, 5-10 second lag before footage plays. Click on the Viewer, 5-10 second lag before the Viewer becomes active. Just doing nothing while zoomed all the way out a timeline and my CPU load is 100% (if not higher) but if I zoom all the way in the CPU load drops to 2%.
It’s happening in all my projects so far (and on two different machines) so I don’t think it’s a corruption issue. Most of my footage is 2 camera multi cam (EX3’s or FS700) synced with 3 or 4 tracks of second system sound. Everything runs fine at first but the more edits in the timeline the more it degrades. One of the machines is an ’09 Mac Pro (2.26 8-core, 24gig RAM) running Mountain Lion and the latest version of CC. Footage is on one of the internal drives (not system drive) but I don’t think that’s the culprit as my performance problem seems directly related to my timeline zoom level.
Anyone run into this before?
-
14 Replies
-
XDcamEX and AVCHD are long GOP formats that need to buffer up to play. It sounds like the software must be trying to buffer in relationship to how much timeline you have viewable in the panel…which is a bit wacky, but I wonder if you’d see the same amount of slow down if you didn’t have two different heavy-load decode schemes trying to buffer up an entire timeline simultaneously?
I don’t do long projects as a rule, so I don’t really have a complex timeline to test this on Windows to see if the behavior is the same…it’s a curious behavior though.
TimK,
Director, Consultant
Kolb Productions,Adobe Certified Instructor
-
[Tim Kolb] “I wonder if you’d see the same amount of slow down if you didn’t have two different heavy-load decode schemes trying to buffer up an entire timeline simultaneously?”
I was thinking that too. I have some timelines with just a single cam, some with 2 cam multicam and one with 3 cam multicam and the the one with the 3 cam multicam exhibits the problem the worst. The weird thing is I’ve spent years cutting XDCAM EX footage natively (sometimes 2 or 3 cam multicam) on similar hardware with FCP7 and never had a problem like this.
Zooming out on my 10min timeline in PPro (which for me is short form) brings things to a crawl but I can zoom in/out on a 90min timeline in FCP7 under similar conditions (XDCAM EX multicam, similar spec’d machine, etc.,).
At first I thought it might be a memory leak but my RAM use stays pretty constant (about 3-4gigs) and I have plenty still free.
-
Two items that are in play here…
First MPEG2 (XDcamEX) is far easier to decode than MPEG4 (H264 or in this case, AVCHD)…it’s just simply not as complex.
Second, Premiere Pro is working with a sequence that is wide open for decode…in FCP7, you could set up a sequence with the specific video decode settings (and of course you’d have to rewrap the XDcamEX footage as “mov” making it unusable outside of FCP…)and everything else renders…
In Premiere Pro, the application is looking down the timeline to see what you’ll be playing back and it may be spawning 2, 3, or more decoders to buffer the material up, and in the case of MPEG Long GOP, the frames are encoded and decoded out of order, so the buffer has to work in increments of 12, 20 or whatever # of frames…and in some cases where a decoder is a single-threaded operation, Adobe is spawning multiple iterations of the same decoder to occupy multiple CPU threads to be as efficient as possible…
So…while it does seem like a peculiar behavior to change buffering method based on the timeline’s zoom factor…comparing FCP7 and Premiere Pro CC responsiveness is difficult as the flexibility to do all the stuff that PPro can do doesn’t exist in FCP and does come at a cost, and systems with 5 year old CPUs will definitely show their age when any H264 format is used on the timeline…the same CPU setup on Windows would likely behave similarly.
TimK,
Director, Consultant
Kolb Productions,Adobe Certified Instructor
-
I don’t think I was clear in a previous post. There is footage shot in AVCHD from an FS700 but the majority of the footage is XDCAM EX from a pair of EX3’s.
I agree that PPro is having a ‘look around’ to preemptive decode the surrounding footage because it doesn’t know where I’m going to jump to, but just having the timeline open (and not even playing) shouldn’t cause the whole program to lag/beach ball on every mouse click. If I have more than 15 or seconds ‘exposed’ in my timeline then then lagging starts becoming noticeable. 30 seconds exposed and it becomes very laggy.
So I did some experimenting with one of my problem sequences:
Rending the timeline in an all I-frame codec – no perceivable change.
Bring all broll on V2 down to V1 (so all video is only on V1) – no perceivable change.
Flattening the multicam video clips – no perceivable change.
Flatten the multicam audio clips – big change (for the better).
It seems like playback of the multicam timelines/nests is the source of the problem.
I took my now 100% multicam free seqence and copy/pasted it four times into the same timeline (so I now have a 40min long sequence) and everything is running/responding with only a fraction of a second of lag.
I’m happy I figured out what was going on, but it’s a really bummer because everything I’m working on right now is 2 camera multicam w/sync sound.
-
Oh…that explains a lot actually. I wasn’t picturing a lot of audio tracks…are there adjustments/filters on all of it?
If you select “render audio when rendering video” in the preferences, at least rendering a preview would render a single track of preview audio as well.
MPEG audio is typically “conformed” creating uncompressed audio tracks from the clips to enable more responsive editing than you would have if only using the muxed audio inside the MPEG file.
The issue -may- be that your conformed audio is on a drive that isn’t fast enough, or is full…or is the system drive…the conformed audio files are going to wherever your preferences-media-media cache files are targeted.
It also never hurts to use the “clean” media cache database button from time to time if things seem inexplicably clunky.
TimK,
Director, Consultant
Kolb Productions,Adobe Certified Instructor
-
I’ll give rendering the audio a try and see if that relieves some of the pain.
Both the audio and video (including media caches) are on a Pegasus RAID so that should be plenty fast (I also did clean the caches recently).
I’m going to keep poking around as I have time, but I really feel like there is something not working out as intended with the multicam clips/nests.
Thanks for the suggestions, Tim.
-
…don’t take any of my input as trying to justify the playback lag in relation to timeline zoom thing as -not- peculiar…
I’m just looking for anything that could help or improve performance.
…it’s still weird.
TimK,
Director, Consultant
Kolb Productions,Adobe Certified Instructor
-
I had the same issue. And the (strange) solution had nothing to do with what was in my timeline, and 100% to do with my audio settings in Preferences. Try changing your audio output settings around…
-
Hmmm…that’s interesting.
Andrew…are the audio settings consistent between your source video, your sequence, and any external device (video I/O card, etc) you have?
TimK,
Director, Consultant
Kolb Productions,Adobe Certified Instructor
-
For me chaining my Audio Hardware preferences to Built-in Line Output and changing Buffersize to max (4096) made everything FAR faster.
Reply to this Discussion! Login or Sign Up