Creative Communities of the World Forums

The peer to peer support community for media production professionals.

  • Oliver Peters

    February 8, 2012 at 11:25 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

  • Carsten Orlt

    February 9, 2012 at 12:03 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

  • Oliver Peters

    February 9, 2012 at 12:47 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

  • Walter Soyka

    February 9, 2012 at 1:20 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

  • Jeremy Garchow

    February 9, 2012 at 1:22 am

    What about another test?

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

  • Oliver Peters

    February 9, 2012 at 1:59 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

  • Oliver Peters

    February 9, 2012 at 2:00 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

  • Jeremy Garchow

    February 9, 2012 at 2:51 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.

  • Oliver Peters

    February 9, 2012 at 3:12 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

  • Jeremy Garchow

    February 9, 2012 at 3:49 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.

Page 2 of 4

We use anonymous cookies to give you the best experience we can.
Our Privacy policy | GDPR Policy