Erik Lindahl
Forum Replies Created
-
Well I think you want to break it down to:
A) Rendering a timeline
B) Exporting a rendered timeline
C) Exporting a non-rendered timelineAll of the above are to an intermediate media, be that ProRes or Uncompressed.
D) Export and encode a rendered timeline
E) Export and encode a non-rendered timelineAll of the above makes if some of an undertaking but the we might see where the potential speed wins or bottlenecks lay. For me, encoding with Compressor has traditionally been crap compared to a proper encoder like Telestreme Episode. But I do understand why one would export and encode to for example Dropbox directly from FCPX even if it means a hit in quality.
-
I don’t include any kind of compression in my renders. That wouldn’t give very accurate figures as the encoding to H264 might double the export time. Also it’s not a valid workflow in 90% of the cases.
-
It could very well be Motion being “the bad guy” in our findings. Using it for templates or filters makes the share-benifits nill.
I’ve just done a clean OS + FCPX install at home so I’ll give this a test and see what I find. My initial tests where also relatively complex in terms of filters / effects.
-
I’ll do some more tests, possibly later this afternoon.
My tests are consistent with the notion more CPU is available during a share vs render. However, some elements seem not to be that well accelerated utilizing more cores.
One major difference with my projects was the fact that the one that didn’t render faster during a share vs render used a lot of “adjustment” layers and custom filters from Motion.
-
[Bret Williams] “The moral of the story. Render your sequence before you export. Takes same amount of time as an export from an unrendered sequence, and when you’re done, you’ll actually have a rendered sequence.”
Hmm, that’s the exact opposite of my findings with FCPX.https://forums.creativecow.net/readpost/335/63387
The “Young” project, rendered in the timeline, went from 3 mins and 41 sec for a RENDER to 1 in and 59 sec for a SHARE. As you can see the other project I tested didn’t see the same boost so it does vary a bit from project to project and the type of effects or elements it hold. The “Young” project could during “share” use a lot more CPU-time where the other project didn’t for some reason.
My conclusion with FCPX is work in realtime as much as you can and use SHARE for your final export. Of course, at some point when you start doing minor tweaks to an edit a rendered timeline will be beneficial as only changes will need to be re-rendered. But in my case the SHARE render was done in half the time virtually compared to a timeline render.
-
One thing to consider is the fact that VLC and a lot of other display outputs – including Premier Pro CC – aren’t color managed, QuickTime X and FCPX is. This will make them look very very different on-screen.
I was banging my in head in regards to this doing a music video a year or so back. The sad fact is most deliverable web formats or players aren’t color managed. The problem at the moment isn’t really “Apple gamma shift” or “QuickTime gamma shift”. A lot of times it’s simply a display issue.
-
The issue with AE is a lot of stuff scales poorly or misbehaves with multi-instance rending. I’m not sure a massive 24 core machine is the solution in AE’s current state.
Where Adobe to magically solve this I’d agree. But currently… Not so sure. Some projects scale perfectly, others not very well at all. And this wouldn’t solve AE’s sometimes horrible GUI-performance.
AMD vs nVidia cards is more a non-issue unless you’re talking raytracing but that’s a very small part of most AE users usage I’d imagine and won’t fix anything for the OP sadly.
With this said I can say AE CC 12.2 feels a lot more “rapid” on a fairly maxed out 2012 iMac vs a 2008 MacPro probably due to much faster single-thread performance. I’d imagine a 2013 MacPro feels roughly like this iMac (perhaps the 12-core doesn’t as it’s got a somewhat lower speed, the others should scale quite well in single-thread).
-
It’s quite easy in AE to hit a 10-100X render speed. I did a presentation show that was around 3 mins that took 4 hours to render. Even straight in / out renders of material can take a hit. With 45 mins of material you’re easily talking hours. It really depends on your comp and system specs. As someone noticed, these kind of things will render faster in an NLE, given you might not have the same level of “finesse” there.
Still if you want to work in AE is recommend:
– 8-bit rendering
– Avoid motion blur where possible
– Avoid filters where possible
– Prepare footage where possibleFor example, scaling down all elements to their proper size, doing color correction and other finesse work in Photoshop before importing them to AE can save you X-times of rendering time.
Also, avoiding filters across the whole timeline will save a lot of time.
What FPS are you rendering in? This can also be a huge time-saver going 24-25 fps vs 30 fps or more.
-
One thing to keep in mind is that RAM-previews only use one instance of AE as of CC. This is due to, I think, the multi-instances buggy nature and quite slow initiaiation. Hence in a worst-case scenario you’re using maybe 10th of your machine. When doing renders it might be worth testing other setups for multi-rendering. 4-8 instances might be more efficient than say 12.
That said, single thread performance should be way better than the 2008 Xeons. I’ve noticed on our 2008 MacPro some things can “kill” the GUI-experience of AE. This tends to be certain filters and especially multiple instances of them. Color Finess is one of them I beilive. Other things can kill GUI-performance also. Perhaps semi complex 3D comps is one of them? This is due to an aintient architecture in AE where i believe the GUI-redraw thread is shared with the scene / comp redraw. This of course can cause a very nasty user experience (something Adobe REALLY should fix).
Never the less you should do some head to head tests perhaps. I can’t imagine anything being slower on the new MacPro aside from RayTracing IF your old machine had a nVidia card. You should also experiment with what might be the cause of slow-downs. I’ve in the past noticed some filters do it, forcing me to deactivate them until final renders. The sad part is that the renders don’t take crazy long, it’s just the filters kill the GUI-experience.
-
We have two Promise Pegasus R4’s in our shop – one serving as our disk for the fileserver, one serving as our media drive for an editing station. No issues what so ever.
The R6 of 2-series will basically give you better speed and more storage as well as TB2 pass-through. I’d recommend looking into how the drives are formatted as that can have huge impact on read / write speeds.
If you only use TB1 devices today (i.e an iMac) the Pegasus is cheaper than the Pegasus2.