-
FCP X hardware performance
-
I’m dangerously out of my technical chops depth in this, but a few weeks ago, I had a closing sequence in X that started with a white base clip – then had five text elements and three TIFF logos composited into a simple closing slate.
I had applied standard dissolves to the beginning and ends of all the elements wishing to simply dissolve up and down the entire static slate as a single element.
When I set it to render and went to get a drink, I got caught in a conversation and when I got back 30 minutes later, the title stack had progressed a whopping 2 percent!
If I’d been sitting trying to work live – I probably would have thought X had hung up – when in fact it was just taking forever to do it’s calculations.
I moved my cursor to the middle of the title, Exported the composite to a flat file, swapped it out in the timeline and got the exact same screen representation rendered out in under 7 seconds!
In trying to understand why, the only thing I can think of is that by stacking all those layers of titles, each needing to calculate a lot of pixel values – I sent the metadata calculation engine in X into a tizzy. I imagined the program calculating the pixel values of the first two layers, then adding another layer, and re-calculating the composite of the original mixed with that – followed by another layer and compositing THAT against the previous result… kinda ad nauseum.
Bottom line is that I’m now trying to keep this kind of “stacked composite” to a minimum when I can.
Again, I could be TOTALLY misunderstanding what’s going on under the X hood – but I do think there might be some issues when it comes to expressing everything as discrete metadata states and trying to keep not only the processing, but multiple levels of “undo” in the X metadata system.
Maybe somebody here knows more about how X generates it’s composites and why I saw such ridiculously long renders in something that once appeared so simple in Legacy. I know the quality of the resulting graphics appears to me to be much better than I was accustomed to seeing out of Legacy – but this still seems weird to me.
Just thought I’d mention it in case someone else runs into the same kind of massive slowdown.
FWIW.
“Before speaking out ask yourself whether your words are true, whether they are respectful and whether they are needed in our civil discussions.”-Justice O’Connor
-
[Bill Davis] “In trying to understand why, the only thing I can think of is that by stacking all those layers of titles, each needing to calculate a lot of pixel values – I sent the metadata calculation engine in X into a tizzy. I imagined the program calculating the pixel values of the first two layers, then adding another layer, and re-calculating the composite of the original mixed with that – followed by another layer and compositing THAT against the previous result… kinda ad nauseum.”
I don’t think this has anything to do with metadata. Text elements in FCP X are Motion projects. Even when nothing moves, the composite is just as complex from one frame to the next as if there were a lot of movement, so rendering takes a long time. If you have several layers of text elements overlapping each other, it’s the same as stacking several Motion projects on top of each other. The app gets very sluggish at this point and renders are excruciating. It sounds like you simply had to render 1 frame and then bring that back in as an element, so no more Motion complexity after that initial 1 frame hit. That’s why your solution was such an incredible time saver.
– Oliver
Oliver Peters Post Production Services, LLC
Orlando, FL
http://www.oliverpeters.com -
Makes sense, Oliver.
I keep forgetting that the entire titling suite in X is just a subset of the Motion code – so it makes perfect sense.
Thanks for the clarification.
“Before speaking out ask yourself whether your words are true, whether they are respectful and whether they are needed in our civil discussions.”-Justice O’Connor
-
“i7 and Xeon” comparison.
It seems, after a short ride on Google, that lots of people have done exactly this. Perhaps this –
https://www.cpubenchmark.net/high_end_cpus.html
– might be considered as fair as possible. The answer as ever seems to be you get what you pay for. Whether the extra speed vs the cost is worth it depends on the usage. Also, of course, in many applications, like PPro, the graphics card is important – and whether it’s worth spending on a Quadro card over a GTXxxx is another discussion.
B
-
Hey Oliver,
Funny, I did a similar test before reading your post just yesterday. I had a whopping 2 hr render with basic color correction and broadcast safe on 10 minutes of XDCAM footage. I compared render times between FCPX, 7, and Premiere CS6 on the same system.
Clip was a single 10-minute XDCAM EX 1920x1080i 29.97 clip.
In FCP7 and Premiere, I added a Broadcast Safe and Three-Way Color Correction (with a minor correction attached) filters. Here are my findings:
FCPX: 2 hrs
FCP7: 10 minutes (set timeline to render to Prores)
FCP7: 30 minutes (set timeline to render to XDCam)
Premiere: 20 minutes (set to render to I-Frame MPEG)
Premiere: 25 minutes (set to render to Prores)
Premiere: 25 minutes (set to render to XDCAM)My system specs:
Mac Pro 3,1
16GB RAM
Radeon 5870
RocketRaid eSATA card
LaCie eSATA drive
Kona 3
Lion 10.7.4Michael Garber
5th Wall – a post production company -
MB Looks is certainly very slow to render and export on my system as well, but I’m not getting any problems with any of the stock filters and corrections, even with CC, filters and cropping/resizing on shots I get better than realtime export of projects using XDCam, ProRes and AVCHD source material.
2×2.8 Quad core 2008 MacPro with 16GB RAM and Radeon 4870 card
Steve Connor
“The ripple command is just a workaround for not having a magnetic timelinel”
Adrenalin Television -
I get about 8-9 minute export time. What about your render time? My tests were on render times in the timeline.
Michael Garber
5th Wall – a post production company -
[Michael Garber] “I get about 8-9 minute export time. What about your render time? My tests were on render times in the timeline.”
FWIW – renders do not use the full resources of the machine. Exports do, hence faster processing and a reason to avoid renders if at all possible. Much like the Adobe approach.
– Oliver
Oliver Peters Post Production Services, LLC
Orlando, FL
http://www.oliverpeters.com -
Ah, great to know. Different way of thinking about it. Thanks for that.
Michael Garber
5th Wall – a post production company -
Thinking about this some more. I think with a faster system that can handle the effects in RT, then yes, this is a good thing. But what if you need to render something globally (in my case a simple broadcast safe) and you just want to play the timeline down without stuttering at full-res? In my case, I need to make sure all the interlacing is correct. I don’t want to have to export for 10 minutes. re-import. Find an error. Re-export, etc…
Anyway, this wasn’t meant to sound like an argument against your excellent advice. Just thinking out loud about why rendering is still good in a lot of cases.
Michael Garber
5th Wall – a post production company
Reply to this Discussion! Login or Sign Up