Final Cut Pro X: Can You Render Faster?

Recently, David asked:

“When exporting media, would ProRes 422 have a speed advantage over ProRes 422 LT?”

I was fascinated by this question, because I haven’t look at the speed differences between different versions of ProRes before.

However, I need to break this into two parts:

• Do different versions of ProRes render faster?
• What should we use for master file output?

THOUGHTS ON OUTPUT

Where possible, I always recommend exporting a master file at the highest quality possible. It is easy to convert a high-quality file into something smaller. It is impossible to convert a small file into high-quality.

• If you are working with RAW, HDR or Log files, export ProRes 4444
• If you are working with files created on the computer, i.e. After Effects or Motion, export ProRes 4444 with alpha
• If you are working with SD or HD media, export ProRes 422

The only exception to this rule is when getting a clip posted quickly is more important than quality. In which case, export a compressed file – H.264 or HEVC – and post that. However, as soon as possible after you get your story posted, go back and export a high-quality master file and save that for the future. Just in case…

Even though using a lower quality codec as the final export of a master file doesn’t make sense, there’s still a great deal of value in David’s question!

Since we can change render settings at any time, wouldn’t it be cool if we could choose a codec that renders faster for initial editing, then switch to a high-quality codec just before final output?

So, for this article, I wanted to see what the speed differences were between the different ProRes render options in Apple Final Cut Pro X. And, truthfully, the results surprised me!

A SIDE NOTE ON ADOBE PREMIERE PRO CC 2019

I originally planned to compare render speeds between FCP X and Premiere. But, as I got into my tests, I realized that would be like comparing oranges to ducks. They each approach rendering from a different point of view.

• Final Cut renders everything that doesn’t match the project settings, regardless of whether the computer can play the clips natively or not. This allows slower machines to handle larger, more complex files and edits, but at the cost of more storage space and time spent rendering. This additional time is hidden by FCP rendering in the background.
• Premiere doesn’t render unless it is unable to play a sequence. This means that you need a beefier system for Premiere than for Final Cut, but Premiere doesn’t require extra storage space for render files. It also means that exports take longer because rendering occurs during export.

There’s no “right” approach – but it is important to know the differences.

NOTE: Here’s an article comparing export speeds using different ProRes codecs in Premiere.

SOME BACKGROUND

Before we launch into the tests, let’s define a few terms:

• Render. This calculates a new video (or audio) clip from an existing clip, or clips, based upon the effects, transitions or titles applied to it. Rendering creates new video to match the project settings, not the settings of the source clip.
• Final Cut only renders when it needs to. If you don’t apply any effects, titles or transitions to a clip AND the project settings match the clip settings, no rendering occurs.
• A render file includes all clips and effects for each frame in the timeline into a single clip. In other words, multiple files are combined into a single, rendered file.
• Most importantly, FCP X renders in the background. This allows you to edit while rendering is going on. However, this also means that render times will vary depending upon other work your computer is doing. (We’ll see the ramifications of this in our tests below.)

By default, render files are stored in the Library, though you can change their storage location using Library > Properties.

NOTE: Here’s a video that explains how.

Faster CPUs and/or multiple cores will render faster. Faster GPUs may render faster, depending upon the codec; ProRes takes advantage of the GPU. However, faster CPUs or GPUs don’t achieve greater quality, just greater speed.

SPEED TESTS

For these tests, I’m using a 2017 27″ iMac. Different computers will render at different speeds, so, in these tests, look at the relationships between render speeds, not the actual speed itself.

All files were stored to the internal SSD, here’s the speed of my storage. (As you’ll discover, rendering does not max out the speed available from the SSD, which means that this storage bandwidth is more than sufficient.)

For a source file, I took one of my recent webinar masters:

• ProRes 4444 (source)
• 1280 x 720 at 30 frames per second
• And edited it to be precisely 45 minutes in the timeline

To this I applied a single effect: scaling the entire image 50%. This forced FCP X to render the project. All tests were run with the same file, with the same effect. I deleted render files between tests.

NOTE: Applying more, or different, effects will require different render times. Scaling renders reasonably quickly, which is why I picked it.

One last note. Render speeds slow down when FCP X is not the foreground application or when the computer is doing other work. For these tests, I left FCP X as the foreground application and avoided doing other work with the computer. (I, ah, read a book…)

Here are the results:

NOTES

• All times are expressed as minutes:seconds.
• All media and render files were stored on the internal SSD.
• Timed with a stop watch, as determined by watching the Background Tasks window.
• I ran four tests of ProRes 422 LT just to see if any two render times matched. They didn’t. So I only ran three tests for the remaining versions.

SYSTEM PERFORMANCE

RAM

This computer only had 8 GB of RAM, however during rendering for ALL versions of ProRes, rendering was easily handled within 8 GB of RAM.

• Cache is the amount of memory dedicated to holding frequently used files.
• Swap is when RAM is insufficient and the computer needs to temporarily shuffle data out of RAM and onto the SSD. While this expands the total amount of storage, swapping also slows things down. No version of ProRes required swapping to the hard disk.

CPU

The CPU was fully occupied.

• System refers to operations controlled by the operating system.
• User refers to operations – such as FCP X – controlled by the user

You never want the CPU to be 100% occupied, some reserve is necessary to respond to mouse and keyboard actions.

GPU

The GPU was fully involved most of the time. Note the fall-off at the end, we’ll talk more about this below.

STORAGE

Final Cut transferred data from storage between 125 – 150 MB/second. Because it needed to process (i.e. calculate) the data in the file, it transfers data more slowly than if it were simply copying the file. In this screen shot, it is reading ProRes 4444 source files and created ProRes 422 LT.

WHAT DOES ALL THIS MEAN?

Final Cut supports these codecs for rendering. I thought that the more compressed files – such as ProRes 422 LT – would render more quickly than larger formats.

But, as you can see from my tests, that really isn’t the case. In fact, every time I ran these tests, rendering took a different amount of time! This points out a key fact: render speed is dependent on what else your computer is doing at the time. While I tried to not run any other applications, the computer is ALWAYS doing something in the background.

There really isn’t a whole lot of difference between the three ProRes 422 codecs. The first time I ran this test, they were within eight seconds of each other.

ProRes 4444 takes roughly 17% longer to render than any of the three ProRes 422 codecs, I found this longer time to be consistent between tests.

Another trait I noticed in EVERY test was that as Final Cut got within 85% of completion, it slowed down. Rendering from 45-50% took 20 seconds. Rendering from 95-100% took 45 seconds. You can clearly see the slowdown in the GPU chart above, it started right at 85%. It is also visible in the CPU chart, though I don’t have a screen shot of it.

NOTE: While ProRes 422 LT, 422 and 4444 all slowed at 85%, ProRes 422 HQ consistently slowed at 70%. I don’t know why.

Also, while the three ProRes 422 codecs maxed out the CPU at 95-97%, rendering ProRes 4444 only pushed the CPU to 75% of capacity. Again, I don’t know why.

SUMMARY

So, what can we learn from this?

• First, ProRes 422 codecs seem to render faster than ProRes 4444.
• Second, while you are doing your rough cuts, switch to a smaller codec – ProRes 422 or ProRes 422 LT – not for speed, but to save storage space.
• Third, FCP X retains all render files, even if you are not using them. This means if you experiment with different render settings, all your earlier files are still stored on your hard disk unless you purposefully get rid of them.
• You can always switch to a higher-quality codec for final output. If the files don’t exist, FCP X will create them during the export itself. There’s no loss in quality if you switch render codecs.

NOTE: To get rid of unneeded render files, select the Project or Event you want to clean up, then choose File > Delete Generated Event Files. Then, choose Delete Render Files. If you delete the wrong files, don’t panic. FCP will simply recreate them.

I found this exercise fascinating, because the results were not what I expected. If you have plenty of storage space, render in whatever codec you prefer. If storage space is tight, render in ProRes 422 or 422 LT.

But, in practical terms, there won’t be any significant difference in speed.

---

Bookmark the permalink.