FORUMS: list search recent posts

Render test

COW Forums : Apple Final Cut Pro X Debates

<< PREVIOUS   •   VIEW ALL   •   PRINT   •   NEXT >>
Oliver Peters
Render test
on Feb 8, 2012 at 8:42:40 pm

I just ran a render test with 4 NLEs and FCP X is definitely the slowest in-app renderer. The media was a 30 sec. ProResLT 1920x1080p/23.98 clip dropped onto a timeline with render set to ProRes. This includes working natively as ProRes inside the Avid NLE and render settings to ProRes in Premiere Pro.

The system was an 8-core 2.26 Mac Pro, 16GB RAM, ATI 5870 card, 2x7200RPM internal drives as RAID-0, OS 10.7.3.

I applied the same MB Looks 2 preset ("movie star") in all four NLEs. This preset combines Cosmo (MB's face smoothing effect), diffusion, vignette and 4 color correction tools in the chain.

The fastest render time was right at 2 min. for Avid.

FCP 7 - 2:43
FCP X - 3:14 (10.0.3 updated version)
PPro CS 5.52 - 2:29
Avid MC6 - 2:00 (actually the Symphony 6.0.1 software-only version)

- Oliver

Oliver Peters Post Production Services, LLC
Orlando, FL
http://www.oliverpeters.com


Return to posts index

Steve Connor
Re: Render test
on Feb 8, 2012 at 8:45:23 pm

I've noticed Looks isn't very quick in FPX at all.

Steve Connor
"FCPX Agitator"
Adrenalin Television


Return to posts index

Oliver Peters
Re: Render test
on Feb 8, 2012 at 8:59:57 pm

The point of using Looks was to use a filter that was identical across all NLEs. In all fairness to FCP X, its own internal filters work better and render faster than any of the third-party options and often most of the freebees people have built when a lot of function are rolled in. But, it's impossible to make a direct comparison between two different vendors' equivalent built-in effects. To me, if you want to do a lot with a wide range of plug-in filters, then use After Effects, because it does the better job than any NLE.

- Oliver

Oliver Peters Post Production Services, LLC
Orlando, FL
http://www.oliverpeters.com


Return to posts index


Marc Lucas
Re: Render test
on Feb 8, 2012 at 9:36:16 pm

I know you used the MB plugin so that the test would be fair across the board but would a simple render of a file from one codec to another be a better comparison of speed from the NLE? Different NLE may be better at different tasks so without testing multiple scenarios the a true reflection can't really be seen?


Return to posts index

Chadwick Shoults
Re: Render test
on Feb 8, 2012 at 9:40:55 pm

Yeah not a fair test. Each build of a 3rd party plugin is made differently for each application.

It's good to know looks doesn't work great in fcpx yet, but a better test would be something like a codec render like Marc said.

I'd love to know the results


Return to posts index

Oliver Peters
Re: Render test
on Feb 8, 2012 at 10:30:19 pm

[Chadwick Shoults] "Yeah not a fair test. Each build of a 3rd party plugin is made differently for each application. "

I disagree. It's a completely fair test for Looks. Since each build is different, then each build is also optimized for that application. In the case of Looks, 3 versions are installed - AVX for Avid, AE for Adobe and FxPlug for Apple. Of particular note is FCP 7 versus FCP X and those are basically using the same rendering engine.

I'll run another test later, comparing some internal effects. Codec renders are irrelevant, because most of the NLEs deal natively with the codecs. In this case, FCP 7 would be worse and a toss up among the other three depending on which codec you would be talking about. That could be completely skewed if I threw REDCODE in the mix, since as yet, there is no FCP X support.

Another thing that is hard to judge, is that both FCP X and Premiere Pro would render faster on export, because they then use full machine resources. Of course, then you have no render files to use during the edit. That's why, with FCP X, it's a good idea to avoid any in-app rendering if at all possible and let it render as part of the self-contained export.

- Oliver

Oliver Peters Post Production Services, LLC
Orlando, FL
http://www.oliverpeters.com


Return to posts index


Chris Northcross
Re: Render test
on Feb 8, 2012 at 9:41:09 pm

Almost was a deal-breaker for me. My first couple of projects were PAINFUL because the in-app render was so bloody slow. Even when I was working in proxy res.

I've come to learn that I don't HAVE to render even though my render bar tells me otherwise. Once I realized that, my render worries have decreased significantly.

"Whether you think you can or can't, you're right."


Return to posts index

Marc Lucas
Re: Render test
on Feb 8, 2012 at 9:51:29 pm

Thats what I have found I haven't really seen much of a different playing back when there is an orange render line there.


Return to posts index

Jim Giberti
Re: Render test
on Feb 8, 2012 at 10:08:59 pm

[Oliver Peters] "This preset combines Cosmo (MB's face smoothing effect), diffusion, vignette and 4 color correction tools in the chain."

On the Cosmo note Oliver. I've been trying to figure out how to deal with skin smoothing for my existing projects. I just got an email from Patrick Sheffield yesterday confirming that he was going to release a rewrite of EMA for FCPX. I've never used Cosmo, do you think it would be a good, immediate alternative?

One of my real, little frustrations with X development so far is the great and direct job they did with keying and masks in the Color Board, but I'm amazed that they don't provide a way to attach a blur filter to the key. So simple to do and such an essential part of the process.

In fact Im going to take this over to the techniques forum.


Return to posts index


Oliver Peters
Re: Render test
on Feb 8, 2012 at 10:36:10 pm

[Jim Giberti] "I've never used Cosmo, do you think it would be a good, immediate alternative"

It's fine, but there are a lot of options, in general. Neat seems to be everyone's favorite, though I don't know if there's an FCP X version. In the past, I've had nice results in FCP 7 for skin smoothing, by using blurs (gaussian and compound) as well as various settings in the CHV Silk & Fog filter. So, the bottom line is that I don't really feel strongly about Cosmo one way or the other. Just nice that it's included in Looks2.

- Oliver

Oliver Peters Post Production Services, LLC
Orlando, FL
http://www.oliverpeters.com


Return to posts index

Jim Giberti
Re: Render test
on Feb 8, 2012 at 10:43:27 pm

THanks Oliver,

I had built some nice trees for it in Color but going that route is so...32 bit, and kludgy. I got spoiled with Ema in terms of speed and render. This is something that I hope they'll add to the Color Board. It would be a nice option right beside the Mask and Key.


Return to posts index

Oliver Peters
Re: Render test
on Feb 8, 2012 at 11:25:42 pm

Just so everyone is happy ;-) I ran a second test of internal effects against internal effects. Same duration, media, codecs, etc. Test A (first number) is the built-in color corrector (FCP X Color Board, FCP 7 3-way, PPro Fast Corrector, Symphony Color Correction mode). Test B (second number) is the same correction with the addition of a transform effect (scale with Z rotation).

FCP X - :40 / 1:04
FCP 7 - :35 / :56
PPro - 1:14 / 1:17
Avid - :18 / 4:11

A couple of interesting things to note. The two tests in PPro are very close in times. Probably due to how Adobe handles the effects processing pipeline. These numbers might actually improve with an Nvidia card. I don't know why the Avid "B" number (CC+DVE) is so much longer, except that the DVE tool itself is considerably more powerful and includes many more features than the transform functions in the other apps. This would tend to explain a much longer time, though it clearly needs some optimization. Likewise, I think this would improve on a PC with an Nvidia card.

Since a big part of this test is to compare FCP 7 to FCP X, I would say that FCP X still renders more slowly. Close, of course, with internal effects that are optimized for the software. OTOH, I think the quality of the FCP X renders would be better, although I didn't really see that in these particular tests.

- Oliver

Oliver Peters Post Production Services, LLC
Orlando, FL
http://www.oliverpeters.com


Return to posts index


Carsten Orlt
Re: Render test
on Feb 9, 2012 at 12:03:36 am

Not to question any of your test, as I think they are very valid approaches.

Because it's curious that FCPx is slower, could it be it is because it always renders floating point (32bit)
And if this is the case and the others don't, would that make FCPx actually much faster (though of course not in real terms)

Kind of: Final Cut x is almost as fast as everybody else rendering in a much higher precision.

Of course you wouldn't always see the difference (as you don't always see it between 8bit to 10bit), but higher quality is better, right?

I'm guessing here. Any thoughts?

Carsten


Return to posts index

Oliver Peters
Re: Render test
on Feb 9, 2012 at 12:47:33 am

[Carsten Orlt] "Because it's curious that FCPx is slower, could it be it is because it always renders floating point (32bit)

That's definitely a possibility (see Avid comment below), although, I believe the same is true for Premiere Pro. Floating point applies to how the effects pipeline is processed when you have a chain of several effects. I'm not sure it's really a factor here at all and certainly shouldn't cause rendering to take longer. Only that the quality is better with multiple effects, particularly effects that change video levels, like a chain of 3 or 4 color correction filters.

[Carsten Orlt] "but higher quality is better, right?"

Depends on what you start with. In this case, the source footage was ProResLT, so anything higher means you wouldn't see much different.

I just also double-checked the render for Symphony by changing the render codec to DNx instead of ProRes. The render time for CC+3D DVE dropped to :30. Huge!

So the codec didn't seem to matter with just the CC effect or in the earlier test with Looks, but made a big difference when I used DNx for the DVE effect. Must have to do with how effects are routed around the software.

This means, those times should be around :18 / :30 if the rendering codec is the equivalent data rate version of DNx.

- Oliver

Oliver Peters Post Production Services, LLC
Orlando, FL
http://www.oliverpeters.com


Return to posts index

Walter Soyka
Re: Render test
on Feb 9, 2012 at 1:20:57 am

[Carsten Orlt] "Because it's curious that FCPx is slower, could it be it is because it always renders floating point (32bit)"

[Oliver Peters] "That's definitely a possibility (see Avid comment below), although, I believe the same is true for Premiere Pro. "

I agree that it's a strong possibility -- even if the integer and floating point pipelines are comparable in speed (which may or may not be true), processing 32-bit float instead of integer 8-bit potentially quadruples the memory bandwidth requirement.

Premiere Pro will also process in 32-bit float with a few caveats. From Sequence presets and settings [link]:
Maximum Bit Depth: Maximizes the color bit depth, up to 32 bpc, to include in video played back in sequences. This setting is often not available if the selected compressor provides only one option for bit depth. You can also specify an 8-bit (256-color) palette when preparing a sequence for 8-bpc color playback, such as when using the Desktop editing mode for the web or for some presentation software. If your project contains high-bit-depth assets generated by programs such as Adobe Photoshop, or by high-definition camcorders, select Maximum Bit Depth. Premiere Pro then uses of all the color information in those assets when processing effects or generating preview files.


Walter Soyka
Principal & Designer at Keen Live
Motion Graphics, Widescreen Events, Presentation Design, and Consulting
RenderBreak Blog - What I'm thinking when my workstation's thinking
Creative Cow Forum Host: Live & Stage Events


Return to posts index


Jeremy Garchow
Re: Render test
on Feb 9, 2012 at 1:22:54 am

What about another test?

Leave everything unrendered and export a self contained movie of the corresponding timeline codec.


Return to posts index

Oliver Peters
Re: Render test
on Feb 9, 2012 at 1:59:19 am

[Jeremy Garchow] "Leave everything unrendered and export a self contained movie of the corresponding timeline codec."

Go ahead. Knock yourself out. ;-) It's unimportant in my workflow. I've used it when needed - that's how I normally work - and it is faster than in-app rendering.

- Oliver

Oliver Peters Post Production Services, LLC
Orlando, FL
http://www.oliverpeters.com


Return to posts index

Oliver Peters
Re: Render test
on Feb 9, 2012 at 2:00:07 am

[Oliver Peters] " that's how I normally work"

in FCP X.

- Oliver

Oliver Peters Post Production Services, LLC
Orlando, FL
http://www.oliverpeters.com


Return to posts index

Jeremy Garchow
Re: Render test
on Feb 9, 2012 at 2:51:42 am

[Oliver Peters] "and it is faster than in-app rendering"

Well, that's the point, yeah? Speed testing and all?

In this sense, fcpx and premiere change the nature of what rendering means. Premiere especially as they don't use the qt specific reference file architecture. Ideally, to lose the least amount of generations in premiere, you don't use the preview files for export, but rather do a GPU accelerated transcode out of AME, which is faster than rendering, and uses the original media and Premiere decoders (you can of course choose to use Preview files if you want).

X seems to work somewhat similarly. Only somewhat, though.

How does Avid work? Can you export a reference mxf/qt? I can't remember, and haven't looked at mc6, shame on me.

I think this is important for non QT workflows, which is what even Apple seems to sort be in the middle of right now.

The removal of reference exporting is the first hint, I imagine.


Return to posts index

Oliver Peters
Re: Render test
on Feb 9, 2012 at 3:12:58 am

[Jeremy Garchow] " Ideally, to lose the least amount of generations in premiere, you don't use the preview files for export,"

That's not really correct. There are no generations. It's just that by rendering on export, you don't use a lower-quality preview render format. However, you can set that to be ProResHQ or 10-bit uncompressed or whatever you like. No quality loss whatsoever if you don't want there to be.

[Jeremy Garchow] "but rather do a GPU accelerated transcode out of AME, which is faster than rendering"

No. If you have already rendered previews, then exporting is faster if your target is the same format as the preview files, since no re-rendering is required. Anything that is GPU-accelerated applies in both "preview" rendering and in AME rendering.

The downside of the whole Adobe "native-codec" approach is often in the export step. I have a friend who does a lot with AVC-HD. You work natively in PPro with AVC-HD and then do a direct export to MPEG-2 for SD DVD and all of a sudden find out that this export of an hourlong program may take a day, thanks to the Long-GOP camera codec.

[Jeremy Garchow] "How does Avid work? Can you export a reference mxf/qt?"

Yes, you can export reference files, although I haven't checked the full status of that with MC6. Anything unrendered, though, has to be rendered before or during the export. Reference files have to all be the same codec, so AMA files tend to be the problem, because MC lets you mix and match frame rates, sizes and codecs in real-time. As we see, it's the same issue with FCP X.

[Jeremy Garchow] "I think this is important for non QT workflows, which is what even Apple seems to sort be in the middle of right now."

Yes, FCP X is a non-QT workflow, however, QT-wrapped media files are primarily the main files it understands. Internally, it's AV Foundations, which is why you can mix codecs in a Project without rendering for standard playback.

- Oliver

Oliver Peters Post Production Services, LLC
Orlando, FL
http://www.oliverpeters.com


Return to posts index

Jeremy Garchow
Re: Render test
on Feb 9, 2012 at 3:49:17 am

[Oliver Peters] "That's not really correct. There are no generations. It's just that by rendering on export, you don't use a lower-quality preview render format. However, you can set that to be ProResHQ or 10-bit uncompressed or whatever you like. No quality loss whatsoever if you don't want there to be."

It's my understanding that it's always a transcode. When using the preview files, even if it's ProRes or 10 bit, you are still transcoding to whatever your output codec is. Premiere does not take the already rendered preview files and combine them in to a final movie as legacy does, as that is a Qucktime specific function that premiere does not use when exporting.

So, in premiere, you have your media (which can be whatever flavor) and any effects, then the bit depth of your timeline.

You can use preview files which are mpeg2 by default, and you can change that codec if you want. Let's say its ProRes.

So, your redner (or preview) files are ProRes, then you want to export a final ProRes movie.

Instead of taking all of those disparate Preview files and simply passing them to the final ProRes export, AME will transcode those files to a new, self-contained ProRes file.

So, unlike FCP Legacy, that's one more render generation. Original > Preview File > new Final qt Encode as opposed to legacy which is original, render file > collected to final qt movie.

[Oliver Peters] "No. If you have already rendered previews, then exporting is faster if your target is the same format as the preview files, since no re-rendering is required. Anything that is GPU-accelerated applies in both "preview" rendering and in AME rendering."

That's not the way I understand it to work. I'll find the document. On export, adobe always creates new media, whether it uses the original + fx, or the pretendered Preview files, all of those get transcoded to the output codec.

[Oliver Peters] "Yes, you can export reference files, although I haven't checked the full status of that with MC6. Anything unrendered, though, has to be rendered before or during the export. Reference files have to all be the same codec, so AMA files tend to be the problem, because MC lets you mix and match frame rates, sizes and codecs in real-time. As we see, it's the same issue with FCP X."

Hmm. So avid sounds like it works like Legacy. Fcpx is different. There are no ref files, even if everything is rendered.

Let me do some searching, I'll dig up the premiere preview file stuff.


Return to posts index

Jeremy Garchow
Re: Render test
on Feb 9, 2012 at 3:59:44 am

Here you go: http://blogs.adobe.com/premiereprotraining/2011/02/red-yellow-and-green-ren...

From the doc that's worth noting:

Note: Rendering of previews is only for preview purposes. Preview files will not be used for final output unless you have Use Previews option checked on output—which you should not use except in the case of rough previews. Using preview files for final output will in almost all cases cause a decrease in quality. It can speed things up in some cases, so it may be useful for creating a rough preview in less time.

Jeremy


Return to posts index

Jeremy Garchow
Re: Render test
on Feb 9, 2012 at 4:32:47 am

Heres another.

Full post: http://forums.adobe.com/message/3939546

Relevant answer from Adobe: http://forums.adobe.com/message/3939546#3939546


Return to posts index

Walter Soyka
Re: Render test
on Feb 9, 2012 at 2:17:29 pm

[Jeremy Garchow] "Rendering of previews is only for preview purposes. Preview files will not be used for final output unless you have Use Previews option checked on output—which you should not use except in the case of rough previews. Using preview files for final output will in almost all cases cause a decrease in quality. It can speed things up in some cases, so it may be useful for creating a rough preview in less time."

Yes. Unless you're using uncompressed preview settings, Premiere Pro will add a generation of compression to preview files on output.


[Jeremy Garchow] "In this sense, fcpx and premiere change the nature of what rendering means. Premiere especially as they don't use the qt specific reference file architecture... The removal of reference exporting is the first hint, I imagine."

FCP Classic didn't use QuickTime reference exclusively, though. When outputting a self-contained movie with existing render files (which were by definition locked to the sequence codec), FCP could copy the data from one QuickTime file (the source clip or render file) into another (the output file) without a decompress/recompress cycle.

Interestingly, this problem has had a long-standing solution outside of QuickTime for decades -- image sequences. Almost no one in straight editorial uses them, but almost everyone in animation/effects does and many in finishing work do. I wish Premiere Pro supported image sequence-based previews, but I imagine that's a pretty niche feature request.

Walter Soyka
Principal & Designer at Keen Live
Motion Graphics, Widescreen Events, Presentation Design, and Consulting
RenderBreak Blog - What I'm thinking when my workstation's thinking
Creative Cow Forum Host: Live & Stage Events


Return to posts index

Jeremy Garchow
Re: Render test
on Feb 9, 2012 at 2:35:32 pm

[Walter Soyka] "FCP Classic didn't use QuickTime reference exclusively, though. When outputting a self-contained movie with existing render files (which were by definition locked to the sequence codec), FCP could copy the data from one QuickTime file (the source clip or render file) into another (the output file) without a decompress/recompress cycle."

We are saying the same thing, just differently.

I was referring to FCP referencing the rendered media and not reencoding it.

In the case of X I was talking about a true reference file (not self contained). X does not have ref files, which means rendering is less important and there's no gain. Render what you need to to preview your work, but don't render what you don't. It's all going to get transcoded in the export anyway, similar to premiere.

Adobe calls it smart rendering, and apparently it's QT specific.

What I don't know is if FCPX uses smart rendering. It seems to with the very informal export tests I've don to the same timeline "render" codec: http://forums.creativecow.net/thread/344/7721


Return to posts index

Walter Soyka
Re: Render test
on Feb 9, 2012 at 2:45:53 pm

[Jeremy Garchow] "We are saying the same thing, just differently."

That's been known to happen from time to time!


[Jeremy Garchow] "Adobe calls it smart rendering, and apparently it's QT specific."

At the moment, yes -- though I can't imagine a reason why Adobe couldn't write this into a future version of MediaCore. Whatever you call it (and I actually hadn't seen a name for this feature until an Adobe rep called it smart render), it's a great feature. Way better than "dumb render." Decompressing then recompressing every frame for output is for the birds.

Of course, by ditching the movie wrapper and its attendant APIs, you can "smart render" an image sequence with nothing more than Finder (or basic OS file I/O as in Smoke).

Walter Soyka
Principal & Designer at Keen Live
Motion Graphics, Widescreen Events, Presentation Design, and Consulting
RenderBreak Blog - What I'm thinking when my workstation's thinking
Creative Cow Forum Host: Live & Stage Events


Return to posts index

David Cherniack
Re: Render test
on Feb 10, 2012 at 1:14:39 am

[Walter Soyka] "Yes. Unless you're using uncompressed preview settings, Premiere Pro will add a generation of compression to preview files on output."

Which, (using a 10 or 12 bit uncompressed codec for previews), is exactly the optimum way to work with minimum loss on final output. But quite frankly, in my experience the use of most high bit rate codecs for previews yield undetectable loss on output in most situations.

David
AllinOneFilms.com


Return to posts index

Oliver Peters
Re: Render test
on Feb 9, 2012 at 2:47:53 pm

[Jeremy Garchow] "It's my understanding that it's always a transcode. When using the preview files, even if it's ProRes or 10 bit, you are still transcoding to whatever your output codec is. "

If the output codec matches the preview codec, then there's no transcode, AFAIK. This may only be a copy and rewrap. I think the documentation isn't clear. In the case of Avid, the functions are different, depending on whether you pick "same as source" on export. That's definitely a copy/rewrap, which is why their ProRes compatibility is now native and transparent. In the case of Adobe, there may be some differences between render, exports and originals, because they are having to encode to ProRes using the QT engine and are not doing it natively like Avid now does (and Apple, of course).

Here's a simple way to test if you really want to test it. Do the render and exports in Premiere Pro. Then pull the export and the original into After Effects and do a difference composite and see what you get.

- Oliver

Oliver Peters Post Production Services, LLC
Orlando, FL
http://www.oliverpeters.com


Return to posts index

Oliver Peters
Re: Render test
on Feb 9, 2012 at 2:51:20 pm

More info:

http://blogs.adobe.com/VideoRoad/2011/08/a-prores-workflow-end-to-end.html

- Oliver

Oliver Peters Post Production Services, LLC
Orlando, FL
http://www.oliverpeters.com


Return to posts index

Jeremy Garchow
Re: Render test
on Feb 10, 2012 at 2:39:00 am

[Oliver Peters] "If the output codec matches the preview codec, then there's no transcode, AFAIK. "

I hate to keep harping on this, but it doesn't. I know it doesn't, I have heard from the Adobe guys, it doesn't work that way.

The preview files are used, but they are decoded then reencoded to your export codec.

It does not work like FCP.

That's why Adobe says not to use them, unless you need extra speed.

As far as the ProRes end to end, the part about reencoding is conveniently left out.

Jeremy


Return to posts index

Tapio Haaja
Re: Render test
on Feb 10, 2012 at 8:53:55 am

Interesting test Oliver! I think testing to be fair you should turn on 32-bit floating point processing on all softwares. Or at least best possible quality because as we know FCPX is always rendering at 32-bit floating point. I don't know if it makes any difference but anyway.

Another thing I've noted is that some plugins (especially FxFactory plugins) are much slower in FCPX than in Motion. Especially user interfaces. for example UI of Moods plugin.

Best
Tapio Haaja

On-Air Promotion Producer
http://avseikkailuja.blogspot.com/


Return to posts index

Tapio Haaja
Re: Render test
on Feb 10, 2012 at 10:22:08 am

Oh... You had already spoken about 32-bit floating point issue. Should have read whole thread first properly... Sorry.

Anyway I find it interesting that if I render exactly same clip with some effect in Motion or FCPX there's usually big difference in rendering time. Sometimes slower sometimes faster. Because AFAIK Motion and FCPX are basicly sharing same rendering engine.

Best
Tapio Haaja

On-Air Promotion Producer
http://avseikkailuja.blogspot.com/


Return to posts index

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