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...
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!)
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.
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.
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. :)
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.
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.
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.
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.
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.
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.
Share - 1:19
Render - 1:49
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.
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.
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.
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.
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.