Final Cut Export takes ages when magnetic mask is already calculated!

Further study shows there is a progressive linear degradation in exported frames per second proportional to clip length. This happens on rendered or non-rendered timelines. It may be related to a mask validation system by which FCP examines the entire clip's worth of analysis records to make decisions about the current frame.

This is normally not a problem since most timelines don't have 10+ minute unedited clips. However some instructional or event videos may have long clips. If magnetic mask is applied to a clip over 5-to-10 minutes long, render performance, export performance and to some degree editing performance will degrade.

Magnetic Mask relative render/export performance cases on a 30-minute timeline composed of varying clip lengths:

For a timeline composed of one 30-minute clip, vs a timeline composed of six 5-minute clips, the 30-minute timeline will render or export 5.4 times slower.

For a 30-minute timeline composed of three 10-minute clips, the timeline will render or export 2.7 times slower than a 30-minute timeline composed of six 5-minute clips.

If the timeline is fully rendered to cache, the magnetic mask will nonetheless be recomputed for export. That might be a separate issue involving cache management.

For clips 5 min or shorter, if magnetic mask is applied, the effect is very fast, and may not require rendering for good editing performance. The full timeline export performance will be much faster if magnetic mask is used on 5-minute or shorter clips -- even if the total timeline length subjected to magnetic mask is the same. Editing performance will also be faster.

For timelines consisting of long instructional or event material, you can simply blade the clip every 5 min, apply the mask and analyze it. I've seen no mask-tracking discrepancies at the boundary of a "through edit."

Jeroen, I have downloaded it and can easily reproduce the problem. It's not just slow; something is malfunctioning. See the attached trace from XCode Instruments of a 4.6-second hang. During this interval, the main FCP thread 0x8250e that runs the UI was blocked. Examination of the GPU threads 0x826db and 0x826dc shows they were having some problems with missing synthesized data. Worker thread 0х85115 was also affected by this.

Thanks for reporting this and taking the time to organize and upload the scenario. This helps the entire user community. I'll dig deeper into this tomorrow.

Just to clarify, you only need a "through edit", IOW blade the clip leaving the vertical dotted line. Then apply Magnetic Mask separately to each section, and analyze them separately. This often makes it so fast you don't need to render the timeline to get smooth playback.

If you change your mind about the blade point, you can select both sides of the dotted line and do Trim>Join Clips. Or you can enter "trim mode" with the T key and slide the edit point left and right.

I'm still doing more tests, but it appears that a 5-minute segment duration works well. If you had a 20-minute clip of (say) a lecture, that would only require 3 "through edits", then you'd apply and analyze the magnetic mask on the 4 segments. The time required to do that is well worthwhile, because it makes playback and export performance vastly faster.

I tested 7-minute segments on my M1 Ultra and that seemed to work OK, but it likely varies between machines. In general I'd suggest blading the clip at about 5 min intervals, and if that doesn't work, try 4 minutes.

I have only investigated this performance issue when using magnetic mask on a single layer. However if using the magnetic mask built into color effects such as wheels or curves, in many cases you only need a single masked layer over a non-masked background layer because there are separate controls for "inside" and "outside" of the mask. IOW you don't necessarily need to apply the magnetic mask on the bottom layer and cut that into segments.

To reiterate, this greatly improves playback and export performance, and may avoid the need to render the timeline to cache to obtain decent editing performance.

I will continue investigating the underlying cause and when I have enough info will file a formal bug with Apple using the Feedback Assistant MacOS app.

I am investigating some performance issues in this general area. What other effects are on the clip? Are you also using a shape mask? Specifically, are you using FCP built-in video noise reduction or third-party Neat Video noise reduction? Are there other clips above it? Is it a simple clip or a compound or multicam clip? Is it retimed or is it running at 1x speed?

Jan, I tried many different tests using FCP 11.0 Magnetic Mask on MacOS Sequoia 15.1.1, and I cannot reproduce what you describe. I tried a ProRes 422 clip with ProRes 422 output, with H.264 output, an H.264 clip with H.264 output. I tried single-pass H.264 and multi-pass H.264. They all exported at the expected quick speed, not taking the extra time required for recalculating the mask.

I tried applying the Magnetic Mask as a stand-alone effect and as part of the Color Wheels effect. After the mask analysis ran, I tried exporting that without rendering the timeline to cache and after rendering it to cache (CMD+A, CTRL+R). Neither made any difference. They all exported at the expected speed, which was pretty fast.

I also tried two layers, applying the Magnetic Mask on the top layer so the bottom layer showed through the non-masked area. That also made no difference.

I think we need some more details about what year and model of Mac you have and what version of MacOS you are running. We also need the exact procedure when you apply the Magnetic Mask. IOW is it just the mask by itself and no masked effect? Is it applied as part of some effect such as Color Wheels? Are you retiming the clip to run at a different speed? Does the frame rate of the clip match the frame rate of the project?

Hi Joema,

I have a similar project that's causing me headaches. It also has magnetic AI on one track.

Video is very simple, two tracks of video, magnetic AI on 1 track, 2 cross desolves at the end.

Hardware: MacBook M1 Pro 16 Gb ram. Content is on an external SSD.

Export settings:

Format: Computer

Video Codec: H264 Multi Pass

Resolution: 1920 x 1080

Color space: Standard - Rec. 709

Audio Format: AAC

Action: Save only

If you want, I can try and make the entire project available to you, it is about 60 GB.

Working on getting a ZIP file to you containing 77 GB. So bare with me. Compression is ongoing.

Is there a preferred way for me to share the download link with you?

This is the progress I am seeing. Entire edited project is like 49 minutes long.

04:55 PM 0%

05:25 PM 14%

06:50 PM 32%

10-09 PM 45%

Here it is: https://f003.backblazeb2.com/file/appforce1-share/Render-Peter-Friese.zip

All 76.1 GB of it. Let me know once you downloaded it. Everything should be there.

[This is a Direct Download Link]

Jeroen, I am still working on this difficult problem. I have spent lots of time studying this and believe it is related to an interaction between the FCP cache manager and the Motion runtime engine. I'll try to post an update tomorrow.

Tnx for the update. Curious to learn what the problem and hopefully the solution will be. :)

I've been on many days long bughunts myself over the years. I remember one time me and two colleagues spent 3 weeks working on one bug to just understand what was going on through tracing everything.

I also did not use Motion. Just 2 tracks with the person track overlaid on the slides track.

my sample project sounds pretty much the same to what you have. So should be good in recreating our mutually discovered issue. 👍

Jan/Jeroen: the Motion runtime underlies all FCP effects. It appears the runtime engine HGRenderExecUnit is doing cache lookups for already-analyzed Magnetic Mask frames. For unknown reasons, it is failing to use valid render cache, so this forces the code path to some time-consuming cache validations using MD5 calculations. Those threads likely hold locks or other synchronization objects that block the main UI thread from updating frequently. I'll try to file this bug today.

Ironically, the speaker in the test video that Jeroen sent is discussing Swift Concurrency :)

I compared the profiled code execution of magnetic mask functions on varying length timelines. Even on fully analyzed, fully rendered timelines, there's a mask validation system that apparently examines the entire timeline's worth of analysis records to make decisions about the current frame. This causes a progressive and possibly non-linear performance degradation as clip length increases. It will take a lot more work to run the tests to plot the performance curve of the varying clip-length cases.

However, as a workaround, you can cut a long clip into sections, each a few minutes duration, and then run the mask effect on them separately. Despite the extra steps, that makes the mask runtime performance fast, even when not rendered to cache. It also makes the full timeline export much faster.

Magnetic mask is a great feature and works better than any rotoscoping effect I've used. However, the mask validation logic may need some optimization to avoid the progressively increasing computational overhead on longer clips. I will continue investigating this.