fbpx

It was a great day for Apple hardware, we also got an indication of the next version of Final Cut Pro.

Whilst writing up our article on the new Apple hardware that was announced today (check back often!) we came across this nugget of information buried in benchmark tests.

Testing was conducted by Apple in February 2022 using preproduction Mac Studio systems with Apple M1 Ultra, 20-core CPU and 64-core GPU, and 128GB of RAM, and configured with 8TB SSD. Prerelease Final Cut Pro 10.6.2 was tested using a one-minute picture-in-picture project with 18 streams of Apple ProRes 422 video at 8192x4320 resolution and 30 frames per second, as well as a one-minute picture-in-picture project with nine streams of Apple ProRes 422 video at 8192x4320 resolution and 30 frames per second. Performance tests are conducted using specific computer systems and reflect the approximate performance of Mac Studio.

 

So now we know, the next version of Final Cut Pro will be 10.6.2 and we would imagine it would be released around the same time of new iMovie that was shown. The new storyboard feature iPad version of iMovie will be released in March.

Is this the new version that was shown in the presentation?

apple mac studio fcp

 

 

 


Written by
Top BloggerThought Leader

I am the Editor-in-Chief of FCP.co and have run the website since its inception ten years ago.

I have also worked as a broadcast and corporate editor for over 30 years, starting on one inch tape, working through many formats, right up to today's NLEs.

Under the name Idustrial Revolution, I have written and sold plugins for Final Cut Pro for 13 years.

I was made a Freeman of Lichfield through The Worshipful Company of Smiths (established 1601). Though I haven't yet tried to herd a flock of sheep through the city centre!

Current Editing

great house giveaway 2020

2020 has been busy, the beginning of the year was finishing off a new property series (cut on FCP) for Channel 4 called The Great House Giveaway. I also designed and built the majority of the graphics as Motion templates. It has been a great success and the shows grabbed more viewers in the 4pm weekday slot than any previous strand. It has been recommissioned by C4 for 60 episodes, including prime-time versions and five themed programmes. The shows have also been nominated for a 2021 BAFTA.

Tour de france 2020
Although both were postponed to later in the year, I worked again on ITV's coverage of the Tour de France and La Vuelta. 2020 was my 25th year of editing the TdF and my 20th year as lead editor. The Tour was the first broadcast show to adopt FCPX working for multiple editors on shared storage.

 

BBC snooker the crucible

BBC's Snooker has played a big part in my life, I've been editing tournament coverage since 1997. I'm proud to be part of a very creative team that has pioneered many new ideas and workflows that are now industry standard in sports' production. This is currently an Adobe Premiere edit.

amazon kindle BF

Covid cancelled some of the regular corporate events that I edit such as trade shows & events. I was lucky however to edit, from home, on projects for Amazon Kindle, Amazon Black Friday, Mastercard and very proud to have helped local charitable trust Kendall & Wall secure lottery funding.

As for software, my weapon of choice is Final Cut Pro and Motion, but I also have a good knowledge and broadcast credits with Adobe Premiere Pro, MOGRT design and Photoshop.

Plugin Design & Development

I'm the creative force behind Idustrial Revolution, one of the oldest Final Cut Pro plugin developers. It hosts a range of commercial and free plugins on the site. One free plugin was downloaded over a thousand times within 24 hours of release.

I also take on custom work, whether it is adapting an existing plugin for a special use or designing new plugins for clients from scratch. Having a good knowledge of editing allows me to build-in flexibility and more importantly, usability.

FCP.co

Now in its 10th year and 4th redesign, running FCP.co has given me knowledge on how to run a large CMS- you are currently reading my bio from the database! Although it sounds corny, I am pretty well up on social media trends & techniques, especially in the video sector. The recent Covid restrictions has enabled live FCP.co shows online. This involves managing a Zoom Webinar through Restream.io to YouTube and Facebook. 

The Future

I'm always open to new ideas and opportunities, so please get in touch at editor (at) fcp.co. I've judged film competitions, presented workflow techniques to international audiences and come up with ideas for TV shows and software programs!

 

Log in to comment


ubernaut's Avatar
ubernaut replied the topic: #119358 08 Mar 2022 22:42
has anyone gotten the max to get anywhere near full utilization in FCP? i haven't gotten above 25%
funwithstuff's Avatar
funwithstuff replied the topic: #119359 08 Mar 2022 22:53
Nicely spotted re 10.6.2! While I have no inside information here, I would suspect that the new Storyboard mode isn't going to be in FCP, just like the Trailer mode never has been. Either way, it's hugely welcome because a lot of people need a creative kickstart and all the trailers have been done to death by every school that has access. Starting a project with a template and then transferring it to FCP can be a great way for novices to start out.
RGPphotog's Avatar
RGPphotog replied the topic: #119362 09 Mar 2022 01:09

has anyone gotten the max to get anywhere near full utilization in FCP? i haven't gotten above 25%

Yes, transcoding video to Pro Res (full CPU & GPU)  and rendering audio waveforms – especially with audio effects applied. 
ubernaut's Avatar
ubernaut replied the topic: #119367 09 Mar 2022 03:41
hmm i tried that and many other things but don't seem to be able to get the full benefit of this chip only a few items seem to be going full speed using a fresh setup more info here:

discussions.apple.com/thread/253386586

please let me know if you have any idea about what's hanging me up here. :)
RGPphotog's Avatar
RGPphotog replied the topic: #119369 09 Mar 2022 04:12
Perhaps could be the still image to video transcode doesn't utilize the media engines. Could also be where you are housing the project & assets. The internal system drive would be assumed, but if you're using external storage, their speed comes into play. try on internal storage.

For me, I'm transcoding h264 to ProRes. Masters are recorded by restroom.io in that format. It's a video podcast show. I'm actually editing for the audio podcast version, but I like the Multicam feature of FCP to edit the isolated audio tracks with. (recorded as separate audio files) That feature doesn't exist in logic. At least not that I could find.
ubernaut's Avatar
ubernaut replied the topic: #119370 09 Mar 2022 04:37
yes home movies folder, if your theory is correct compressor test should confirm the state of things still i think renders should also be faster with 32 core SoC GPU with 16 times as much memory. i will check compressor and give updates thanks for your thoughts. :)
joema's Avatar
joema replied the topic: #119376 09 Mar 2022 16:28

discussions.apple.com/thread/253386586

...please let me know if you have any idea about what's hanging me up here. :)

Your main stated issue is less-than-expected perf. improvement when comparing a late 2013 MacBook Pro (2.6 Ghz 16GB/1TB, 750M) to an M1 Max MBP when exporting ProRes 422 material to H264.

Maybe you are focusing on CPU graphs, which do not always accurately reflect performance. E.g, when encoding if FCP hands off frames to hardware acceleration, that is not counted as CPU usage. It appears that iStat Menus attributes hardware video acceleration to the GPU, even though it is totally separate. Does it do that for all codecs, or some codecs? I don't know. Unfortunately there are no rules about such things and no perf. tool I'm aware of selectively monitors all combinations of hardware video acceleration separate from the CPU or GPU.  There are cases where the hardware is working at full speed but the monitoring tools do not give you visibility on that. The only way to be totally certain of performance is doing timed tests under controlled conditions.

For situations like this, it's important to differentiate between render vs encode performance. Even if the timeline is fully rendered there are various situations in FCP where it may not use those render files to expedite export. This blurs the assessment of what is really causing the slowdown: a general render perf. issue, a specific render perf. issue caused by certain plugins or their order in the Fx stack, a issue with encode perf. during export or an I/O issue when exporting high-bitrate files like 4k ProRes 422.

While you can time render perf. when doing a CTRL+R on selected timeline clips, the time required can vary greatly depending on the Fx and their order in the stack. E.g, if you have an Fx that processes a sliding window of several frames (Neat Video, Flicker Free, etc) that will force recomputation of all Fx above that in the stack for each frame in the window. Thus it is best to put those Fx 1st in the stack, ideally only using one.

The only truly reliable way to segregate render vs export performance is export the timeline as ProRes 422, then re-import that and export it with all Fx baked in using the final codec such as H264. If reading 4k ProRes 422 and exporting to 4k ProRes 422, on M1 Max it is easy to hit an I/O limit if the disk is not an SSD with over about 2 gigabytes/sec bandwidth. If exporting to H264 that is much smaller, involves more compute time (even if hardware accelerated) and you'll rarely hit an I/O bottleneck.

I don't have an older x86 MBP but I have a 10-core Vega 64 iMac Pro and an M1 Max MBP 16. I did several tests with both running Monterey 12.2.1, FCP 10.6.1 and Resolve Studio 17.4.5. Both machines have extremely fast external 4-drive Thunderbolt SSD RAID-0 arrays, and media is on those with export files on the internal SSD.

Summary: in general FCP is very fast and for certain workflows the perf. improvements on M1 Max can be significant. Usually FCP on M1 Max handles most "difficult" codecs much smoother than the iMac Pro. The fastest FCP M1 Max transcoding case is creating 50% ProRes Proxies from 4k ProRes 422. It is incredibly fast, with peak I/O rates of over 1.3 gigabytes/sec. However -- there are several cases where FCP has some performance problems.

One of these has been long known, which is extremely slow 4k 10-bit HEVC export if using the built-in HEVC export preset to a .M4V file. That unfortunately continues on M1 Max. While it is 1.5x faster than an iMac Pro, it is nonetheless 25x (!!!) slower than Resolve Studio 17.4.5 on the same M1 Max machine, exporting with the same HEVC parameters. That's not new to M1 Max, Resolve is about 20x faster than FCP on iMac Pro when exporting to 10-bit HEVC, if FCP is using the built-in preset. However -- if you simply export that to Compressor and create a custom preset with the same resolution, bit depth and bit rate, it is fast. Apple obviously needs to fix that.

There is a known FCP performance bug on M1 Max (maybe all Apple Silicon) where creating 50% H264 proxies from 4k originals is abnormally slow. All other H264 proxy resolutions are fast and creating ProRes Proxies is extremely fast.

If you are using plugins like Neat Video, the latest versions have significantly improved performance on Apple Silicon. If you are using 3rd-party audio plugins, if not updated to Apple Silicon some of those may work in an x86 container process under Rosetta. There could be performance or reliability issues with that.

Other tests below:

** 4k/23.98 ProRes 422 export to 4k/23.98 "fast" H264, I get the following numbers for a 60 sec clip with no Fx **
(all pre-rendering and caching disabled in all cases)

iMac Pro, FCP 10.6.1: 29.3 sec
iMac Pro, Resolve Studio 17.4.5: 29.2 sec

M1 Max, FCP 10.6.1: 18.9 sec
M1 Max, Resolve Studio 17.4.5: 17.4 sec

** 4k/23.98 ProRes 422 export to 4k ProRes 422 (no Fx) **

iMac Pro, FCP 10.6.1: 8.9 sec
Resolve Studio 17.4.5: 2.9 sec

M1 Max, FCP 10.6.1: 3.6 sec
Resolve Studio 17.4.5: 1.9 sec
Castiel's Avatar
Castiel replied the topic: #119380 09 Mar 2022 19:55
Curious about that image , how are they doing AV out to a studio display ( no HDMI input), and at the same time spreading the FCP interface across two monitors .
RGPphotog's Avatar
RGPphotog replied the topic: #119381 09 Mar 2022 20:06

Curious about that image , how are they doing AV out to a studio display ( no HDMI input), and at the same time spreading the FCP interface across two monitors .

support.apple.com/guide/final-cut-pro/co...61bc/10.6/mac/11.5.1

The Pro Display XDR can be set under AV Output. Must be assumed that this new Studio Display can do the same. 
ubernaut's Avatar
ubernaut replied the topic: #119386 09 Mar 2022 22:45
i think we are talking abut two things here render and transcodes. using compressor to test should rule out compositing effects on transcoding but it still doesn't explain why the rendering should go the same speed these are fairly simple projects just stills with ken burns and a title layer. surely the 32 core gpu (which does appear to go at 100% utilization) should be faster than 750M no?
joema's Avatar
joema replied the topic: #119415 11 Mar 2022 18:54
I just did about 30 different tests of various titles, Ken Burns affects on still images, with and without chroma keying, all with and without pre-rendering. Comparing my 10-core iMac Pro to my M1 Max MacBook Pro 16, both running Monterey 12.2.1 and FCP 10.6.1, both using the same media files and same project file via XML. I tested render time, export to H264, and export to ProRes 422 with both rendered and non-rendered timeline.

In general the M1 Max was significantly faster than the iMac Pro. However performance measurement can be tricky due to the unpredictable way FCP uses render cache. This can vary based on what Fx, what order in the stack, machine state, when FCP was re-launched, etc. For details see this and related posts: www.fcp.co/forum/4-final-cut-pro-x-fcpx/...der-files-for-export

If you can trim down your problem scenario to a few files, inc'l project XML, and upload them to me I'll examine those. Make sure it's using no 3rd-party Fx. If it is, verify you can reproduce the problem without those. Afterward just drop them here: www.transferbigfiles.com/dropbox/joema
ubernaut's Avatar
ubernaut replied the topic: #119418 12 Mar 2022 02:10
can i just give you a library file containing my test projects with generated files removed? should be pretty small i do not use 3rd party effects. :)
joema's Avatar
joema replied the topic: #119419 12 Mar 2022 02:14

can i just give you a library file containing my test projects with generated files removed? should be pretty small i do not use 3rd party effects. :)

Yes that is OK, I have fiber internet.
ubernaut's Avatar
ubernaut replied the topic: #119420 12 Mar 2022 02:18
sent thanks! :)
joema's Avatar
joema replied the topic: #119421 12 Mar 2022 02:51

sent thanks! :)

There is definitely an issue there. Both render to cache and export to ProRes 422 are much slower on my M1 Max than my iMac Pro. Tomorrow I will test other machines and examine it further.
ubernaut's Avatar
ubernaut replied the topic: #119422 12 Mar 2022 02:52
well at least i'm not crazy :P thanks again for looking into it. :)
lucidcg's Avatar
lucidcg replied the topic: #119425 12 Mar 2022 15:06
Another .x update...bummer. Is Apple ever going to do a major revision to version 11? Charge for it and bring some major improvements.
joema's Avatar
joema replied the topic: #119430 12 Mar 2022 22:04

well at least i'm not crazy :P thanks again for looking into it. :)

Here are some tentative findings, although more work is required to nail it down:

- The core problem is not simply that it's slower on M1 Max, although that is one issue.
- Both rendering your timeline to cache or exporting it to ProRes 422 (or anything else) seems abnormally slow on both x86 and M1 Max. E.g, your 30 sec timeline takes about 1 min to render on my iMac Pro and about 2 min to render on the M1 Max. Export to 1080p/60 ProRes 422 likewise takes about 1 min on the iMP and 2 min on the M1 Max, with no difference whether the timeline is rendered or not.
- The problem is worsened by the 60 fps timeline, although it still shouldn't be that slow. If you simply switch the timeline to 23.98 or 25 fps, it will render and export about 2x faster. That is simply a workaround; there's still something wrong.
- Successive simplification of the timeline reveals the root problem involves the title. Is that a custom title you built in Motion? However....
- Even using the built-in FCP title "Lower Third Basic" shows similar behavior.
- The problem includes both slow render, slow export and failure to use pre-rendered cache. That is likely related to the problem I listed previously. See those links for details of my interaction with Apple Pro Apps support. That study involved FCP effects, but I then suspected titles could also be related, however I didn't test those.
- In that previous investigation, there were "well behaved" and "poorly behaved" Fx from a cache standpoint. It appears the same situation may exist with titles. E.g, your title and the built-in "Lower Third Basic" make the timeline render slowly and (worst of all) prevent any re-use of cached frames to expedite export. By contrast the built-in "Basic Title" renders and exports faster but still triggers the "no reuse of cache" behavior. I haven't had time to run tests on many other titles. Lower Third Basic and Basic Title only cause this if they have user-entered title text; the default text doesn't cause it.
- The built-in FCP titles and certain built-in Fx are actually Motion templates. Motion may use some type of interpretive execution engine which in some cases cannot be cached (ie compiled) ahead of time. It's possible those cases somehow prevent re-use of cached render segments in the timeline. I don't know if that's a bug or an unavoidable aspect of the internal design. The impact can be huge, e.g, you could have compute-intensive Neat Video on a bunch of clips, then add a simple title which (unbeknownst to you) prevents re-use of render cache. You then pay the penalty for Neat Video every export, since the Motion-implemented title behavior apparently prevents cache re-use on export. This happens even if no "render dots" are visible on the timeline.
- No matter whether the cache issue is a bug or by design, just rendering or exporting a simple timeline should not be 2x slower on an M1 Max vs an iMac Pro. That is possibly a code optimization issue. I will investigate further.
ubernaut's Avatar
ubernaut replied the topic: #119432 12 Mar 2022 23:44
yes, these are simply modified FCP titles not custom motion ones although they have been migrated from older versions of final cut pro x libraries not sure if that would have any impact. it does seem we are getting close to an answer here. i supposed precomposing or rendering the titles would isolate them as the problem.
joema's Avatar
joema replied the topic: #119433 13 Mar 2022 00:48

i supposed precomposing or rendering the titles would isolate them as the problem.

That is correct. If you could do that, it would eliminate the current problem.

Obviously that should not be required; it is a workaround. I think the underlying issue involves the Motion runtime engine. Assuming that 95% of built-in FCP Fx are Motion-based, there are two separate cases:

- Fx can be rendered to ProRes 422 cache and re-used for export, so the Fx does not need recomputing.

- Fx is rendered to ProRes 422 cache but is blocked from re-use for export (and also all layers and Fx within the same timeline range), so all in that range must be recomputed.

In addition to the cache problem the computation itself of certain Motion-driven Fx is apparently less efficient on Apple Silicon than x86. So those two problems feed on each other.
ubernaut's Avatar
ubernaut replied the topic: #119434 13 Mar 2022 01:53
all of that makes sense, also seems to explain why HEVC exports were in line with my expectations. hopefully, it means at some point there be an update that just makes the renders at least faster. sounds like the export cache issues you've been trying to get recognition of will be a harder battle. :/
ubernaut's Avatar
ubernaut replied the topic: #119725 30 Mar 2022 23:46
were you ever able to figure out exactly which effect in the title stack was causing this?
joema's Avatar
joema replied the topic: #119729 31 Mar 2022 15:12

were you ever able to figure out exactly which effect in the title stack was causing this?

Unfortunately I'll be working on a different project for at least a week, and cannot continue examination of the above problem until after that. However my testing to date implies many (if not most) of the built-in titles prevent re-use of existing render cache to accelerate export. 

To review, there are three separate issues:

1 - Various built-in FCP effects and many (if not most) built-in titles will prevent use of FCP render cache to accelerate export. I suspect this involves the Motion runtime engine which implements these effects and titles. 
In this case when the timeline is rendered to cache, the timeline runs smoother, so the cache is properly used for that. However it is not used for export, and all Fx & titles must be recomputed from scratch. This is most apparent if exporting to ProRes 422 on a fast machine with SSD drives. If you are exporting to H264 it may be less obvious since encoding itself can be a bottleneck.

2 - Some combinations of titles or Fx may prevent use of render cache, even to accelerate timeline operations. After background render or manual render to cache via CTRL+R, No render dots appear on the timeline, yet timeline operations are still slow. I have less info about the specifics and it will take more testing to better define this.

3 - Some built-in FCP Fx and titles are significantly slower to render on an M1 Max machine than x86 machines which should be slower than M1 Max. Comparing a 10-core Vega 64 iMac Pro to an M1 Max MacBook Pro 16, this varies by effect. Some effects such as Neat Video render about 2x faster on the M1 Max. This implies some inefficiency or bottleneck in the some Motion-implemented titles and effects which are unique to Apple Silicon.

In general Apple Silicon Macs are fast and overall I'd rather use my M1 Max than the 10-core iMac Pro. However even before Apple Silicon, there have been some long-standing issues with FCP render cache, and now there are apparently some new issues with runtime efficiency of the Motion engine for some tasks, unique to Apple Silicon.

It will be interesting to re-test these cases when FCP 10.6.2 is released.
ubernaut's Avatar
ubernaut replied the topic: #119730 31 Mar 2022 15:19
yeah, no rush and thanks for your insight on this hoping it will be as easy as removing some element of the title effects to speed things up while we wait for the real fix to #3. :) unfortunately, it's a bit tough for me to test on my end since my old mac is basically decommissioned at this point.