Speed test

[Bill Davis]

I kinda remember reading back in the early days that when you Share from an un-rendered storyline – the major difference is that if you do a Render All – X makes focused use of ALL the computer resources essentially suspending background tasks and putting all the available cores in play.

IIRC, a simple “in-progress render might not do that unless you do it “hands off” so there’s nothing else polling your system.

So there would be a difference between rendering while working compared to rendering on command.

FWIW.

Know someone who teaches video editing in elementary school, high school or college? Tell them to check out http://www.StartEditingNow.com – video editing curriculum complete with licensed practice content.

[Bret Williams]

I had hands off of X when rendering, except the few times I’d cmd+tab back to it to see the background progress window. If I moved the mouse it’d pause momentarily. Which explains the roughly 20-30 sec difference. It probably should’ve just taken 16min to render.

But I was definitely using other resources. I was surfing the COW during all three tests. Just to make it fair. 🙂

[Erik Lindahl]

[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.

[Bret Williams]

Very interesting. But bizarre. I’d love to see more tests and perhaps a screenshot for complexity sake. But our results seem to defy logic. You also left off the export from a rendered sequence test. That’s the most important one. If that is faster than your export from an unrendered sequence, then at least we’ve narrowed down what’s going on. Perhaps it will use render files if they’re there, and if not, perhaps some types of projects/fx are accelerated by the GPU only in a share function, not a render.

[Erik Lindahl]

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]

I understand. And I’m trying to find the logic between your results and mine. “The Mystery of X.” (Say it like you’re in mass.)

I thought my results were pretty clear, and felt representative of my general feelings. Render- 16min. Share unrendeted-17:30. Share rendered 1:30.

I used this sequence as an extreme because it was such an intensive render the results would be clear vs a short sequence with nothing but color correction. And when a share of a rendered seq takes 1/2 RealTime, vs 5x RT for a non-rendered sequence it seemed pretty clear but your results negate the clarity for sure.

So what is the deciding factor? I have lots of Motion templates in there. Maybe they’re not accelerated on share, so a render or a share are roughly the same. Maybe a simpler sequence uses the GPU on share but not on render. If love to figure it out.

In any case, for my projects with all the layered graphics and templates, you’ve got to render particular sections just to get playback obviously.

[Erik Lindahl]

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.

[Bret Williams]

True. But the big question is whether it uses the render files or not for output. And from my tests I can’t gather any answer but that it does. If you have a timeline that exports faster from unrendered vs rendered then that blows that theory.

[Bret Williams]

A new test. A 6min cuts only rough cut. The majority of clips have only color correction, but have up to 5 color correctors on the clips including multiple masks. In general, they still play in RT but with the occasional dropped frame. 1080 30p ProRes 422, exporting (“share”) to single pass 720 30p h264.

UN-RENDERED SEQUENCE
Share – 1:19
Render – 1:49

RENDERED SEQUENCE
Share – 1:13 (I’d say that’s within the margin of error to say it was the same, but still a hair faster)

So it’s all still baffling. A rendered sequence still exports faster than an unrendered sequence, but not enough to write home about. And the render of a sequence in this example takes longer than a share of an unrendered sequence. Which speaks volumes in a basic sequence like this. But in a sequence full of layers and graphics, the result is DRASTICALLY different, with renders and shares from an unrendered seq taking 5-10 times LONGER than a share from a rendered sequence.

I don’t know why, but if you’re doing a heavy graphics project that won’t play nice in RT, then I guess a render would be in order anyway. But if your sequence plays in RT anyway, don’t bother.

???

[Claude Lyneis]

I think anything with motion files takes a long time to compress. I do sports videos and using a two pass compressor seems to give much smoother motion on playback than a single pass.