FORUMS: list search recent posts

Speed test

COW Forums : Apple Final Cut Pro X

<< PREVIOUS   •   VIEW ALL   •   PRINT   •   NEXT >>
Bret Williams
Speed test
on Mar 5, 2014 at 5:44:30 pm

I was under the impression that exporting didn't use the render files in X like it did in legacy. Perhaps things have changed or I misunderstood.

It definitely does. I did a little export and render test of a 3:15 1080 30p ProRes 422 sequence.
Starting with a fairly complex (lots of graphics and layers) sequence, I exported to 720 30p h264 on a 2012 iMac, both from a rendered sequence and completely unrendered sequence.

From RENDERED sequence: 1min 25sec
From UNRENDERED sequence: 17min 20sec

Yikes! Definitley used the render files.

I then rendered the sequence to see what the time was just for rendering...
16min 23sec

Now, taking into acct the 3rd test pauses momentarily whenever you touch the mouse, I can do the math. The export from unrendered equals pretty much exactly the same as rendering PLUS export. Sure would be nice if it left you with a rendered sequence after export.

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.

And for those wondering how a 3min sequence gets exported to h264 in 1min25sec, you need an iMac and you need to use single pass. The iMac has hardware accelerated h264 compression on single pass CBR. Looks 99% the same as a 2 pass VBR file to me.

Here's the sequence- (geez, look at all the vertical wasted space!)



Return to posts index

Bill Davis
Re: Speed test
on Mar 5, 2014 at 5:54:06 pm

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.


Return to posts index

Bret Williams
Re: Speed test
on Mar 5, 2014 at 5:58:10 pm

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. :)


Return to posts index


Erik Lindahl
Re: Speed test
on Mar 6, 2014 at 9:03:42 am
Last Edited By Erik Lindahl on Mar 6, 2014 at 9:05:05 am

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

http://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.


Return to posts index

Bret Williams
Re: Speed test
on Mar 6, 2014 at 1:08:39 pm

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.


Return to posts index

Erik Lindahl
Re: Speed test
on Mar 6, 2014 at 1:27:19 pm

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.


Return to posts index


Bret Williams
Re: Speed test
on Mar 6, 2014 at 1:37:53 pm

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.


Return to posts index

Erik Lindahl
Re: Speed test
on Mar 6, 2014 at 1:42:10 pm

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.


Return to posts index

Bret Williams
Re: Speed test
on Mar 6, 2014 at 1:48:59 pm

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.


Return to posts index


Bret Williams
Re: Speed test
on Mar 6, 2014 at 2:44:26 pm

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.

???


Return to posts index

Claude Lyneis
Re: Speed test
on Mar 7, 2014 at 8:36:58 pm

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.


Return to posts index

Erik Lindahl
Re: Speed test
on Mar 8, 2014 at 7:58:57 pm

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.


Return to posts index


Claude Lyneis
Re: Speed test
on Mar 8, 2014 at 9:04:28 pm

I only compress as the final step, if the destination is the web or some other format. If I understand correctly that is a necessary step, but maybe I am missing something.


Return to posts index

Bret Williams
Re: Speed test
on Mar 9, 2014 at 1:58:24 pm

Maybe I'm missing something. So when Eric renders something there's no compression involved . He's shooting uncompressed and rendering uncompressed? Anyway, I have to render stuff all the time. Yes RT is good in X, but a couple layers of texts and effects and it's unplayable of course. At the end of the day I export an h264 for the client. Usually I just share directly to the Dropbox folder and walk away. Then I can send a link from my phone once it uploads.


Return to posts index

Erik Lindahl
Re: Speed test
on Mar 9, 2014 at 6:52:56 pm

Well I think you want to break it down to:

A) Rendering a timeline
B) Exporting a rendered timeline
C) Exporting a non-rendered timeline

All 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 timeline

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


Return to posts index


Bret Williams
Re: Speed test
on Mar 9, 2014 at 8:59:40 pm

I have done tests with episode for DVDs in the past and any gain wasn't worth it. And compressor (or X - it's the same thing) looks pretty good even at hardware accelerated single pass. 99% of exports are for client approvals any way.


Return to posts index

Erik Lindahl
Re: Speed test
on Mar 9, 2014 at 10:06:10 pm

We primarily do H264 or WMV which either rules Comprssor out or in the past it's had chockingly worse quality and features sadly.


Return to posts index

Bret Williams
Re: Speed test
on Mar 9, 2014 at 10:08:44 pm

Huh. Ive gotten great results with flip4 mac and compressor. One client always wants high end wmvs for their master. Haven't done it in awhile though.


Return to posts index

<< PREVIOUS   •   VIEW ALL   •   PRINT   •   NEXT >>
© 2017 CreativeCOW.net All Rights Reserved
[TOP]