When I wrote my article comparing how Final Cut, Adobe Premiere Pro and DaVinci Resolve use Apple silicon cores during export (link), it got me thinking about how FCP uses CPU cores in general.
The reason this is relevant is that the biggest imponderable in configuring a new computer is deciding how many cores are really necessary for the work we need to do. This is an attempt to find out.
I looked at four typical areas for video editing:
I also looked at multicam editing playing three and nine streams.
I’m using a 2021 16″ MacBook Pro, with an M1 Pro SoC. I’m running Final Cut Pro v10.6.2 and used Applications > Utilities > Activity Monitor to measure all core activity.
NOTE: AppleInsider reported that Activity Monitor may not accurately report core usage (link). I have no way to know whether AppleInsider is correct.
The short answer is that, when using Apple Final Cut Pro, import, editing and export principally use the two efficiency cores. Rendering, and to a lesser extent multicam, used performance cores. However, nothing I did pushed any core to 100%.
My main takeaway is that adding more and more CPU cores won’t make most editing tasks faster, though it will speed rendering. This also implies, but I couldn’t test, that the perceived differences between editing with an M1 Pro, M1 Max or M1 Ultra won’t be that significant because FCP is not using all the cores available on my M1 Pro for most tasks.
NOTE: Larger frame sizes, faster frame rates or more cameras in a multicam clip require more performance from the CPU. I didn’t test at any clips larger than 4K.
BEFORE WE START
(Base CPU loads with FCP running, but not doing anything.)
Here, I started Final Cut, but haven’t opened any libraries or loaded any media. This displays the background activity on my computer, most of which is running on the two efficiency cores (green box). I’ll refer to this as the “base loads” on the CPU cores.
NOTE: The eight performance cores are on the right.
(Top: Base loads. Middle: Import. Bottom: Import about ten seconds later.)
Here are the results of importing about three dozen clips. I measured CPU loads twice to see if there was much difference. There wasn’t. I only took single screen shots for the rest of my tests.
Importing is so trivial that the CPU loads for importing are almost exactly the same as the base loads when FCP isn’t doing anything. Remember, importing isn’t doing anything with media, it’s simply importing the path name for each media clip, which is a tiny text string.
(Top: Base loads. Bottom: Timeline playback.)
In this example, I’m playing an edited and fully-rendered dramatic 1080p two-minute project consisting of four video layers and eight audio layers.
There is a slight elevation in two performance cores, with three other performance cores are making slight contributions. Still, the computer is not working very hard. At all.
(Footage courtesy: Amy “Catfox” Campion (www.AnticsPerformance.com))
Here’s the ProRes 422 project I used for the render example. Background rendering was turned off so I could control when rendering started. The effects included transform effects, feathering and color grading.
(Top: Base load. Bottom: Rendering.)
Rendering used every performance core (red box), but not to the max. The efficiency cores remained the same, indicating they were not used for rendering but, rather, tending to other background operations on the computer.
NOTE: I did a quick look at GPU activity, which you’ll find at the end of this article.
(Top: Base load. Bottom: Export without rendering.)
Next, I exported the ProRes 422 project that I used for the render test to create a ProRes 422 movie. Since it was already rendered, I wanted to see what cores were involved in exporting.
Again, the first three cores were virtually the same as the background load. Exporting was handled – very, very easily – by the remaining performance cores.
(Top: Base levels. Middle: Export without rendering. Bottom: Export with rendering.)
I then exported this project while transcoding it to ProRes 4444. This transcoding required re-rendering every pixel. Just as with rendering, the efficiency cores attended to other processes, while rendering for export used the CPUs almost exactly the same as rendering by itself.
The efficiency cores showed about the same load regardless of whether rendering was needed or not. In other words, exporting does not challenge the CPU. Rendering challenges the CPU. However, exporting does use the all the performance cores to some degree.
(The start of a nine camera multicam clip. Footage courtesy: Hollyn/Jordan Productions (www.2reelguys.com)
Apple makes a big point, whenever it introduces a new M1 SoC, to stress the benefits it provides to multicam multi-stream playback. So, to check the differences I created two multicam clips, one with three streams and one with nine.
The codec for these multicam clips was XDCAM-EX, not ProRes. So this example did not take advantage of the ProRes encoder/decoder built into Apple silicon.
NOTE: To avoid problems with storage bandwidth, I transferred all the source clips to the desktop before importing them for playback. The internal drive on the MacBook Pro is much faster than my external RAID, which benefits performance for multicam editing.
(Top: Base load. Middle: Multicam with 3 cameras. Bottom: Multicam with 9 cameras.)
Multicam playback with three cameras woke up all cores, but the system handled it easily. With nine cameras, all processors became more active, though the main differences were in the four performance cores on the right. Still, there was lots of headroom for more streams or larger frame sizes.
Again, the efficiency cores were about the same, indicating the multicam defers to the performance cores.
A QUICK LOOK AT GPU ACTIVITY
(GPU Activity with Final Cut Pro. Higher bars indicate the GPU is working harder.)
Activity Monitor does not provide a very detailed look into GPU activity, so it is impossible to know how many cores are working. For this quick look, I ran the tests outlined above, this time monitoring the GPU History window. Here’s what’s happening at each of the numbers.
Clearly the GPU cores are busy whenever rendering is required. However, I was surprised at how much the GPUs were used simply to play back a fully-rendered project.
Video editing is something computers have done for many years, using CPUs which were far less capable than those in Apple silicon. However, I was still surprised by how much work these two efficiency cores could accomplish, albeit with a bit of help from one performance core.
As expected, the real benefit to more cores was in render speed. As frame sizes and frame rates increase, more cores gets the work done faster. Not with higher quality, just faster. Adding more multicam clips also increased the load on performance cores.
This is relevant as I debate with myself which version of the Mac Studio computer to buy. I want the M1 Ultra. But, what these results show is that while I may want it, I certainly don’t need it. An M1 Pro or M1 Max SoC handles video editing extremely well with power to spare.
As you can imagine, there are LOTS of different ways to create projects and each NLE will have different results. In fact, there are far too many options for me to test. However, you can measure results for yourself – including GPU usage, which I didn’t check – using Applications > Utilities > Activity Monitor, then monitor:
Let me know what you find out in your own tests.
NEW & Updated!
Edit smarter with Larry’s latest training, all available in our store.