For sheer processing power FCP wins hands down!

For NLE performance comparisons to be meaningful, the render cache state must be known or held to a consistent condition. Also any effects applied must be the same, yet that is difficult because the user-facing appearance of an effect does not correlate to how much work is done.

E.g, if you apply video noise reduction to a clip on FCP and one to Resolve, it might seem the uncached Resolve playback is slower. But the Resolve NR effect is much more sophisticated than the FCP NR effect.

FCP traditionally has shipped with background rendering enabled by default. FCP has a straightfoward single-level render cache system. Resolve has a much more sophisticated multi-level caching system: timeline, Fusion, nodes, etc.

For any H.265 playback comparison to have the slightest chance of being comparable, the render cache on both FCP and Resolve must be totally disabled, and no effects should be used. If the goal is examination of H.265 playback, that cannot be evaluated with effects in use, because then you'd be evaluatig effect processing, not H.265 decoding.

If the goal is effect processing, then the procedure is use a ProRes 422 clip to avoid decoding overhead, plus have all render cache disabled.

The fact that in real-life H.265 playback you might use effects doesn't mean you test them all enabled. That might be one final test after you did all the other component tests.

This illustrates why proper testing is difficult and time-consuming, which is why it is rarely done well.

Years ago FCP playback of Long GOP formats like H.264 was much faster than Resolve. But for several years, Resolve H.264/H.265 playback and also export encoding has been basically similar to FCP.

More recently FCP got segmented encoding of Long GOP formats, so that Macs with multiple encoders like Max and Ultra can under certain conditions run those in parallel on segments of the output and invisibly combine those to a single output file. But it only does that under certain conditions, such as timelines or average clip lengths of certain size, because otherwise the segmentation and concatenation overhead could result in worse performance than using a single encoder.

For playback, the only M-series chips with multiple Long GOP decoders are the Ultra models. It currently appears they aren't used for segmented decoding of a single stream, but only in cases of multi-stream playback such as multicam.

Unlike Windows, on macOS there are no performance counters for encoder/decoder use, even in Xcode Instruments, so it is very difficult to determine what it's doing. But with enough time spent in methodical testing, this can be deduced, but it's tedious.

I think Resolve may use a similar segmented encoding system on Max and Ultra Macs, but I haven't tested that.

I just tried a 5 min 4k/23.98 HEVC 10-bit 4:2:0 clip exported to the same format w/o effects, using FCP 12.3 on M1 Ultra Mac Studio, macOS Tahoe 26-6-2, and it took 26 seconds, or 5.2 elapsed seconds per 60 seconds of material.

I then tried it on Resolve Studio 21.1 and it also took 26 seconds, also about 5.2 elapsed seconds per 60 seconds of material.

I then turned off FCP's "Allow export segmentation" in File > Share > Export File > Settings, and that improved the export performance to about 23 seconds. So it appeared in this case trying to use export segmentation was slowing down FCP a little.

So they were both about the same performance in this scenario using default settings. I didn't look around and see if there was a documented or undocumented method to turn off export segmentation on Resolve. This only applies to Max/Ultra machines, which are the only ones with multiple hardware encoders.

If I were doing a formal test, I'd turn off Spotlight indexing and Time Machine.

To avoid variation due to macOS system cache, I'd do the command "sudo purge" before every run (cold), or else run everything warm.

For longer exports (more than 10s of GB) to external SSDs, SLC write cache can become exhausted and cause unpredictable variation. Exporting to the internal Mac SSD normally does not cause that, but it introduces other uncertainties.

I can't speak for Resolve, but on my M1 Ultra Mac Studio in FCP I can take at least 8 4K 60fps HEVC video clips (MOV wrapper), scale them all down to fit somewhere on a single frame, have a large (much bigger than 4K) scrolling still PNG backdrop underneath it all, several PNG logos underneath each video clip to show what said clip is, drop shadow effects on the PNG logos and videos (which are combined into a compound clip so I only need to have one instance of the effect) and it all still plays back in the timeline (also at 4K) without rendering at 60fps... on Better Quality. I never ever use Better Performance I can't stand that.

I don't think I'll need an M5 any time soon, but when I get my next Mac Studio in 6 to 8 years it will definitely be the Ultra version of the M12 or whatever is out by then.

(Image at 50% size because I don't think y'all need nor want a 4K screenshot attached here)

Funny enough though, if I use AUTO MASK on even a single clip, unrendered playback performance takes a HUGE hit.

I edit 4K multicams from half to a full hour long all the time. Titles, color grading, audio sweetening, never had any issues with speed. The exports are quick enough. I remember legacy FCP on Intel, when HD was brand new. It could take 3-4 times the duration of your timeline to export. When we could export a 1 hour timeline in 1 hour, that was a huge deal. Now I export a 30 minutes multicam in a matter of a few short minutes. My M1 Max is plenty for everything I do.

I was considering upgrading to a Mac Mini or wait for the new MBP later this year. But that's only to keep my system from getting too, too old. But no other reason. I don't see how anything faster can make my work go faster. It's as fast as I can do it now.

I also tested my M1 Max MacBook Pro 16, running the same versions. It exported the 5 minute 4k/23.98 10-bit H.264(HEVC) to the same format in 1 min 14 sec, which equates to 14.8 seconds elapsed export time per 60 sec of timeline.

There is no way the M1 Ultra should be 3x faster than that, even if the number of decode/encode units scaled linearly. I must be doing something wrong but I've checked it many times. Alas, I'll have to put this on the "to do later" list.

In general the decode side is viewed as difficult or impossible to speed up with multiple decoders for a single stream. It would have to split the incoming stream on a GOP boundary, and it would only work for "closed GOP" construction, not "open GOP." Closed GOP is when each GOP is self-contained and independent of others. Open GOP is when one GOP references another, which makes parallel decoding much more difficult. There is no utility that identifies this difference.

Maybe Apple figured out how to do this, or maybe I just made a mistake. I'll try to examine this later, but it will be a while.

Of course, it's all Apple's own secret sauce. BMD developers don't have access to things Apple does.

Different M chips have different encode/decode capabilities, depending on how many of the encoders are on the chip. Most have only one, some have two.

The only M-series chip that has more than one Long GOP decode engine is the Ultra. But that is only useful for multicam or other multi-stream input cases. Ian's case was a single H.264(HEVC) input file that the Ultra's dual decoders cannot benefit.

Each model of a given M-series generation has exactly the same Long GOP video engine design. The video engine on a base M1 is exactly the same as a single engine on the M1 Ultra, likewise base M2 vs M2 Ultra, etc.

That said, I just ran the same 5-minute 4k/23.98 10-bit HEVC export test twice on my wife's M4 MacBook Air, and it was a lot slower. In both runs it took 2 min 4 seconds, which equates to 24.8 elapsed export seconds per 60 seconds of timeline. That is not extremely far off from Ian's 32-second export of 60-sec 4k/23.98 HEVC on his M4 Mac Mini.

That is also a huge difference from the same clip exported with the same settings on my M1 Ultra Mac Studio, which was 23 sec with export segmention off and 26 sec with segmentation on, which equates to 4.6 or 5.6 seconds elapsed export time per 60 sec of timeline.

I do not understand why so much difference. There were no effects whatsoever on the timeline, and no rate conforming. It was a single 5-min 4k/23.98 10-bit 4:2:0 HEVC clip, exported in both cases using File > Share > Export File > Settings, Format: Computer, Video Codec: HEVC 10-bit, Resolution: 3840 x 2160.

Both my M1 Ultra Mac Studio and my wife's M4 MacBook Air were on macOS Tahoe 26.6.2 and both running FCP 12.3. Both import and export files were on the local SSD of each machine.

There is definitely something worth investigating here, but I'm busy on other work and I don't have time.

Ian: if you were exporting from FCP, how did you limit the export bitrate to 50,000 kbps? If you were using Compressor, that is a different code path than FCP. I don't think this had any difference since I used the exact same FCP-only export on both M1 Ultra and M4 MacBook Air.

This is a striking difference I cannot explain. I wish I had time to run these under Xcode Instruments and examine the code paths in both cases, but I'm too busy right now.

Ian, I'm not sure there's that much difference for this case. I suspect there is something different about our test scenarios. My wife has an M4 MacBook Air. If I have time, I'll test that.