[Joe Marler]

[Tom Sefton] “all feel like the keyboard has been covered with treacle”

Premiere has actually gotten much faster at a few things like H264 export. It is currently much faster than FCPX at 10-bit HEVC export, so it’s not slower on every single thing.

But on the “high touch” and “common path” UI interactions (e.g. viewer update rate and lag time on JKL input) it can be quite sluggish, at least when tested on identical Mac hardware vs FCPX and Resolve. It is worse with some codecs than others.

When testing 4k 10-bit 4:2:2 400 mbps H264 All-I from a GH5, I examined the viewer (aka program monitor) update rate on a 10-core Vega 64 iMac Pro running Mojave 10.14.6 when fast forwarding at 4x speed in the timeline, with Premiere set on 1/4 resolution and the FCPX viewer on “better performance”. I don’t remember how I configured Resolve but it wasn’t anything special. This was done by shooting the screen during 4x FF with a camera at 240 fps and counting real-world update rate.

Resolve Studio 16.1.0.055: 28 frames/sec
FCPX 10.4.7: 20 frames/sec
Premiere Pro 13.1.5: 2 frames/sec

Some performance differences can vary based on minor things. Even though the above test showed Resolve had a quicker viewer update rate than FCPX, this was only during continuous playback. If you grabbed the playhead and moved it back and forth, FCPX was faster.

It’s ironic the Premiere playback engine is code-named Mercury. It’s like having a pet turtle named “Lightning”.

Years ago a database called FoxBase was famous for being super fast. The CEO would walk among his developers with a stopwatch on a lanyard around his neck and demand impromptu timed performance tests of their code. I suppose nobody at Adobe has ever done that.

Before Resolve got so fast, you could claim that FCPX was single-platform and their performance advantage derived mostly from that. However Resolve is multi-platform and it has become a real speed demon, but in general interactive use FCPX is still a little more responsive.

[Joe Marler]

[Hamdani Milas] “The first clip shows it’s rendered and there’s no red line above it. The second clip shows the red line above. (As does the animated title that follows) The second clip plays without issue.”

Thanks for the additional info. To my knowledge, in FCPX there is no documented or even “known but undocumented” red line. It’s not like Premiere where green means rendered, yellow means non-rendered but GPU-accelerable, and red means non-rendered and non-accelerable.

In FCP 7 there were multi-color render bars with several colors for various render states. Red meant “render required”. That does not exist in FCPX unless it is some kind of legacy or debug code which was somehow triggered.

I was thinking back over this statement: “the project render routine itself is hit and miss, I usually disable background-render, now and then select all and manually trigger a render but portions of the timeline often refuse to render leaving the usual white dots.”

In general it should always render on command. Exceptions: Optical flow retiming can sometimes get stuck and it won’t render. If background rendering is left enabled sometimes render files can build up and render tracking gets confused. To avoid this keep background rendering disabled, manually delete all render files then do a one-time render with CMD+A to select all clips and CTRL+R to render. You can then selectively render additional clips or timeline ranges as needed.

Deleting render files using the FCPX UI does not delete analysis files, thumbnails, peak or waveform files. Unfortunately there is no documented way to delete those, but if you set library properties to store cache in a separate folder they will be placed in an .fcpcache bundle. You can safely delete the entire thing if needed.

There are also some render file tracking issues which can adversely interact with certain built-in and 3rd party effects. This can cause render files to become invalid and require re-rendering, even though no edits have occurred. There are other scenarios where render files will not be used even if they exist and are valid. Details: https://www.fcp.co/forum/4-final-cut-pro-x-fcpx/31621-help-losing-renders-after-fcpx-close-or-project-switch

That may sound bad but in general the FCPX render system works quite well.

It is possible the huge number of plugins and kernel extensions on your system could be a factor. Unfortunately there is no easy way to troubleshoot this. Booting MacOS in Safe Mode does not allow launching FCPX because OpenGL acceleration is disabled. Also there is no “FCPX safe mode” to boot with all plugins disabled.

All current FCPX plugins except for Motion templates run within the process address space of FCPX. This means any bug in any plugin can crash or destabilize FCPX. Supposedly this will be improved in the future as plugin vendors move their products to FxPlug 4 which can enable out-of-process plugins, thereby preventing a plugin bug from crashing FCPX: https://developer.apple.com/documentation/professional_video_applications/fxplug?changes=latest_minor&language=objc

All of the above notwithstanding, in general FCPX is overall quite reliable, especially from the standpoint of data integrity. I have managed post production of several very large documentary projects using FCPX, some involving 150 4k camera hours and 100 multi-camera interviews. We never lost any data or even a single edit, despite various periodic glitches and crashes. I only wish Premiere was that reliable the years I used it.

I don’t think there is an unsolvable problem with FCPX but there’s obviously an architectural issue regarding plugins and MacOS kernel extensions that can impact troubleshooting. This can make it quite cumbersome and time consuming to pursue. If you have another machine or can boot MacOS from a separate drive and do a clean provisional FCPX install without any plugins, that might be a path forward. I realize steps like that are aggravating and time consuming.

[Joe Marler]

[Hamdani Milas] “…Sometimes the clips export okay, sometimes the juddery playback or even a stalled frame is reproduced in the exported file…all ProRes video files…2015 27″ iMac to Mojave 10.14.6 and also updated all Pro Apps including FCPX10.4.8…I usually disable background-render, now and then select all and manually trigger a render but portions of the timeline often refuse to render leaving the usual white dots….Also deleted all library and/or project render files to no avail – the red lines persist. There’s no apparent action in any aspect of the workflow that appears to induce the red lines nor can I find any reliable or repeatable way to eliminate them.”

Very interesting case. I have never seen this; it is rarely reported and there’s no clear answer. You have already done the normal troubleshooting steps.

Can you examine the characteristics of that clip and compare that to the timeline characteristics? Does the frame rate match? Is the clip or timeline interlaced? Has any retiming or optical flow been used on that clip? What are the clip attributes – IOW if you play it in Quicktime and do CMD+I, what does the movie inspector show?

What camera did the ProRes material come from? Blackmagic cameras can embed a separate project frame rate vs sensor frame rate and sometimes that metadata makes FCPX behave oddly, but nothing like this.

If there are clips which sometimes cause the problem and other clips which never cause the problem it might be worth examining those side-by-side using Invisor’s comparison viewer: https://apps.apple.com/us/app/invisor-media-file-inspector/id442947586?mt=12

You can also verify you are on the latest version of Apple Pro Video Formats. Starting with Mojave that is done in System Preferences>Software Update.

Re Disk Utility, it will only run in advisory or read-only mode on the system drive unless the Mac is booted in Recovery Mode: https://support.apple.com/en-us/HT201314

After running that if you have never rebuilt Spotlight Indexes you can do this on each drive: https://support.apple.com/en-us/HT201716

I formerly had a 2015 iMac 27 and after a few years it showed erratic behavior but nothing like this. It passed Apple diagnostics but at the Genius bar they ran overnight bench diagnostics and it finally failed, requiring a logic board replacement. But normally a hardware issue would cause a hang or crash not an anomalous UI element.

It’s not a very stringent test but you could try Apple diagnostics: https://support.apple.com/en-us/HT202731

[Hamdani Milas] “…The red line phenomena also applies to new libraries created from scratch in projects with all ProRes video media..”

This is especially troubling and could indicate some external commonality. E.g, a plug in, system config issue or an incipient hardware problem.

Is all media on locally attached HFS+ or APFS drives, nothing on NTFS, ExFAT or NAS drives?

You might check if any 3rd-party kernel extensions are installed by typing this command in terminal:

kextstat | grep -v com.apple

[Joe Marler]

[Oliver Peters] “Vega 56 card on an old Mac Pro tower, circa 2010-2012. “

Oliver, if you use the Vega 56 it would be interesting if you could do some simple tests about H.264 encode/decode performance. As you know the big issue with Mac Pros before 2019 is Xeon does not have Quick Sync so they are slow on H264 or HEVC. The 2019 Mac Pro is believed to use the T2 chip for this.

AMD GPUs have H264 hardware acceleration similar to Quick Sync, called UVD/VCE. It has multiple verions, and supposedly has not been used by MacOS or FCPX until (maybe) the most recent versions and only on certain platforms. Max Yuryev commented he thinks on some machines FCPX will use AMD Vega hardware acceleration, see 6:00 into this video: https://youtu.be/r2S6o4aml5Y

If there is any way an older Mac Pro could be upgraded with a late-model AMD GPU which MacOS and FCPX use for H264 acceleration this would be a big improvement.

Some contents or functionalities here are not available due to your cookie preferences!

This happens because the functionality/content marked as “Google Youtube” uses cookies that you choosed to keep disabled. In order to view this content or use this functionality, please enable cookies: click here to open your cookie preferences.

[Joe Marler]

[jon eastty] “I deleted all plugins like FxFactory and ColorFinale (I don’t use them anyway) and it’s still happening. Do you think I should upgrade to Catalina?

Also, it happens with every project now, not just one or one set of clips. I’ve tried re-importing and using different drives that have different projects on them always with the same result. I followed your advice and did the h.264 codec export file and it still crashed. Any ideas?”

Are you on FCPX 10.4.8 or 10.4? If not my first suggestion is to upgraded to FCPX 10.4.8, Compressor 4.4.6 and Apple Pro Video Formats 2.1.1. That should run OK on Mojave. All my machines are now on Catalina and run OK but if you have any 32-bit utilities or codecs those will not run on Catalina. In general upgrading to Catalina should not be required to troubleshoot a problem like this. However if you think you can safely do that, go ahead.

Before considering Catalina you can check for any 32-bit apps in About This Mac>System Report>Software>Applications, then sort on the right column 64-bit and look for any apps which are 32-bit. Those will not run on Catalina. Note this column only appears on Mojave and earlier, not on Catalina.

With FCPX 10.4.8, Compressor 4.4.6 and Pro Video Formats 2.1.1 installed on Mojave, if it still crashes when exporting one small clip with no effects, please post only the stack trace of the crashing thread, not the entire crash log. If it does not crash, then add a few clips, then add a few effects until it starts crashing and then examine the last item you added.

If you have not already done so, reset FCPX preferences and consider what other steps listed here are appropriate: https://support.apple.com/en-us/HT203477

[Joe Marler]

[jon eastty] “When I share to vimeo it stops after a few seconds and displays this:

The operation couldn’t be completed. (com.apple.Compressor.CompressorKit.ErrorDomain error -1.)…”
FCPX Version: 10.4
Mac OS X 10.14.6
2015 MBP 13, 2.6Ghz i5, 8GB, Iris Graphics 6100 1.5MB

Can you try exporting that to a local file then uploading to Vimeo in a separate step?

The crash log shows many plugins. Unfortunately with the current FxPlug 3.x architecture, all plugins run within the address space of FCPX so any bug in any plugin can crash the process. Supposedly this will be improved in the future as plugin vendors move their products to FxPlug 4 which can enable out-of-process plugins, thereby preventing a plugin bug from crashing FCPX: https://developer.apple.com/documentation/professional_video_applications/fxplug?changes=latest_minor&language=objc

For now your only option is update all plugins, esp. sophisticated ones like Color Finale. You are apparently running version 2.0.5.2 and version 2.1 is now available. Also update any plugins obtained through FxFactory as well as the FxFactory app itself. If there are any you no longer use, remove those.

There have been many updates and improvements to FCPX (and Compressor) since the version 10.4 that you’re running. While there is no guarantee the new versions will prevent the problem, it might be wise to update. Save the current version of /Applications/Final Cut Pro.app by renaming it before upgrading, also save any libraries. That gives the option of an easy rollback in the unlikely case of a problem on the new version.

Also verify you are running the latest version of Apple Pro Video Formats. Starting with Mojave this is updated in System Preferences>Software Update.

Make sure you have at least 15% free space on all disk volumes, and they are all HFS+ or APFS not ExFAT or a network drive. A network drive is OK but when troubleshooting it’s often best to use local drives.

You can help isolate whether the problem happens in the render phase or encode phase by fully rendering the timeline before exporting. First disable background rendering in FCPX preferences, then delete all render files via File>Delete Generated Library Files>Delete Render Files>All. Then select all timeline clips via CMD+A and do a one-time render via CTRL+R. If that completes OK, export to a local file using this preset:
File>Share>Master File>Settings, Format: Computer, Video codec: H.264 Faster Encode, Resolution: 1920 x 1080 (or as preferred)

If that still crashes on export when running 10.4.8, then examine if it happens on any clip or just your timeline. If only the timeline, make a snapshot duplicate of it, open that project and strip all effects via Edit>Remove Effects, then re-render the timeline and export. If that works, make another snapshot but remove effects from 1/2 of the timeline, then 1/4, etc. until you find the clip and the effect causing it.

[Joe Marler]

[Nikhil Agrawal] “I am using FCP 10.3.4 (Also tried 10.4, same issue) on MAC os 10.13.6. Bought in 2013 (released on november 2012)… Model iMac 21.5 inch core i5 2.7”

There have been several reports of older versions of FCPX running on older versions of MacOS which suddenly began crashing during export. We don’t know the cause, although one user apparently traced his to an updated file in /System/Library/PrivateFrameworks/MobileDevice.framework

In that case he recovered the previous version of that file from backup and the crashes went away.

The resolution of the other cases is unknown because they are still happening or if resolved, the people don’t post the solution or they never post enough information to pursue it.

Logically it might be caused by some type of software update, such as the above file which might be part of iTunes. But we just don’t know.

The fastest approach is update to the latest possible versions of MacOS and FCPX on your current hardware. These have many fixes and starting with FCPX 10.4.7 it’s considerably faster. The only issue I’m aware of is a narrow problem with playback of certain HEVC codecs on 10.4.7. As always with any upgrade make sure you have good backups, and especially save the current versions of Final Cut Pro.app in /Applications and any FCPX libraries.

If it is fixed in an update, then you will have saved tremendous amounts of time trying to debug a problem. If it’s not fixed you won’t generally be any worse off. However – Catalina does not support 32-bit apps or utilities so if upgrading from an old version for purposes of troubleshooting, don’t go beyond Mojave.

That said, on the current versions you can try these steps:

– Disable background rendering in FCPX Preferences>Playback>Background render (clear check box).
– Delete all render files: File>Delete Generated Library Files>Delete Render Files>All
– Select all clips in timeline with CMD+A
– Do one-time render of all clips in timeline with CTRL+R. State if that hangs or crashes.
– If render phase completes OK, then export using these settings: File>Share>Master File>Settings, Format: Computer, Video Codec: H.264 Faster Encode, Resolution: 1920×1080
– When doing the above export, pick a different output location in a different folder than you previously used.

If it still crashes please post the call stack of the crashing thread. Do not post the entire crash log just the thread that crashed.

Other standard troubleshooting steps:

Be certain you are not running the Chrome browser or any browser based on Chrome. It is poorly behaved and saturates the VideoToolBox framework, causing FCPX to become unstable. We had one reliable report where complete removal of Chrome was required to stop the problem.

Be certain you have at least 15% free space on all hard drives. Insufficient drive space can cause FCPX or any other app to behave unpredictably, and render/export takes a lot of disk space.

Be certain that all hard drives are locally attached and HFS+ formatted, not ExFAT nor NAS drives.

Make sure you are running the latest version of Apple Pro Video Formats. Prior to Mojave this is updated via the Mac App Store. Starting with Mojave it is updated in System Preferences>Software Update. To inspect the current version, do About This Mac>System Report>Software>Installations, then scroll down to Pro Video Formats and note the highest installed version number. On Catalina it is 2.1.1, I don’t remember the highest on previous MacOS versions, maybe 2.0.7.

[Joe Marler]

[Nikhil Agrawal] “I am stuck on the same thing from last 3 days and have explored many articles, desperately need help”

We need to know the specifics: what version of FCPX, what version of MacOS, the year and model of Mac, and the specifics of the codec. Also state the problem history: when did it start, did this coincide with any known update, etc.

To get the codec specifics play it in Quicktime Player and do CMD+I, then post that information.

[Joe Marler]

This was apparently caused by /System/Library/PrivateFrameworks/MobileDevice.framework, which had been recently updated. Problem was apparently resolved by restoring a previous version using Time Machine.

[Joe Marler]

[Greg Ball] “Just let them shoot their own response to you on their iPhone or Android device.

Maybe send them a lav microphone that plugs into an iPhone. The give them some pointers for shooting. Give them some lighting basics as well. “

I agree with this. Assuming it is a late-model iPhone or Android, the video quality is quite good — given proper lighting and framing. They can shoot HEVC which at 1080p is very small, even for a long interview or instructional talk.

The app DoubleTake by Filmic can shoot two simultaneous angles on an iPhone 11, e.g, telephone and wide, albeit currently limited to 1080p:
https://apps.apple.com/us/app/doubletake-by-filmic-pro/id1478041592

There are lots of inexpensive iPhone tripods or gorilla pods which facilitate placement and framing.

Audio is very important. I’ve used this Rode SmartLav+ and it worked fairly well: https://www.bhphotovideo.com/c/product/1059342-REG/rode_smartlav_smart_lav_lav_mic_for.html/

Of course sending that accessory kit (no matter how small and inexpensive) might work OK for a single site but if doing many remote interviews at different sites it might not be practical.