[Joe Marler]

[Cal Thorley] “I use XAVC-I and that’s been the one PP actually does seem to get on OK with”

You generally shouldn’t have major performance problems with XAVC-I — IF that’s the only codec you’re running. You previously mentioned using mixed codecs including 4k H264 from GoPros or drones. Those are highly compressed and difficult to edit.

When problem solving it’s important to “divide and conquer”. As a test remove all BMD video hardware, external audio hardware, and any associated drivers, use only XAVC-I, and try the same project or editing steps which previously caused problems. If that works, then add either the H264 material or BMD hardware — one step at a time, carefully testing and examining performance at each stage.

If it is slow with XAVC-I and no BMD hardware, then examine what effects are being used.

First disable background rendering in FCPX Preferences. Then delete all cache files with File>Delete Generated Library Files>Delete Render Files>All. Then select your timeline clips with CMD+A and do a one-time render with CTRL+R. Examine the performance then.

If it’s still problematic, make a snapshot duplicate of your project (aka timeline), open that and strip all effects using Edit>Remove Effects. If that is fast, then repeat the process but strip effects from 1/2, then 1/4, then 1/8 of the timeline — each time rendering the timeline with CMD+A and CTRL+R — until you locate the problematic region and what effects are in use.

Some compute-intensive effects like Neat Video can slow things down, no matter what codec is used. There are also some cases where certain combinations of effects preclude FCPX from using cached render files. If you ever see a case where a fully rendered timeline (ie no render dots) is sluggish, it could be that situation.

Excluding any issue from effects or BMD hardware, certain material will be sluggish to edit on any Mac. This includes 4k H264 from a GoPro or DJI drone, Sony 4k XAVC-S or XAVC-L, Panasonic 4k 10-bit 4:2:2 All-Intra from a GH5, S1, S1H, etc, 4k 10-bit 400 mbps HEVC from a Fuji X-T3, etc. Panasonic’s 8-bit 4k H264 is considerably smoother, esp on a 2017 or later iMac which uses Intel’s upgraded “Kaby Lake” version of Quick Sync.

The latest version of Premiere on the same Mac hardware is much slower at those difficult codecs, esp. regarding lag time to JKL input. Resolve Studio 16.2.3 is generally equal to FCPX or even faster in some cases. But even Resolve on a 10-core Vega 64 iMac Pro will struggle on the difficult codecs.

For a brief shining moment around 2010 it seemed like Adobe’s Mercury Playback Engine on then-current hardware was going to eliminate any need to transcode material to a mezzanine codec. Then 4k arrived along with a bewildering variety of Long GOP codecs, some of which can bog down almost any machine. This is further exacerbated by the diverse “zoo” of hardware acceleration techniques – Quick Sync, UVD/VCE, NVDEC/NVENC, T2 — each of which has multiple versions with varying capabilities, used in various ways by each NLE.

[Joe Marler]

[Cal Thorley] “…2017 5K 4.2i7 with the Radeon 8gb GPU and 24gb ram…I don’t need 4 streams of 4k backwards but the ability to edit 4k with a mix of native XAVC, H.264, and ProRes is more my deal. Does my setup sound like it’d do that with FCPX? And not just 2 min clips. Hour long timelines if need be.”

I have the same machine, and have edited large documentaries pulled from 130 4k multi-camera interviews, mostly 4k XAVC-S.

While FCPX is a lot faster on XAVC than Premiere is, that is simply a difficult codec. XAVC-S and XAVC-L are Long GOP and just difficult to decode. XAVC-I is faster and smoother. Of course ProRes is lightning fast.

In general XAVC Long GOP needs transcoding to proxies for the smoothest performance — even on FCPX. The FCPX proxy system is somewhat fragile since the original disk volume and pathname is burned into the library and there is currently no relink. However it is usable. You can also externally transcode and re-link to manually-created proxies, then re-link back to the full res material for final export. Anything like that should be carefully tested before committing.

I have the latest versions of Premiere and Resolve Desktop, but mostly use FCPX. Resolve has been greatly improved in recent versions and is nearly as fast as FCPX on certain things.

FCPX is very strong at skimming through lots of media and content organization. But you must understand the overall design philosophy and intended workflow. You don’t throw a bunch of stuff on the timeline, rather carefully curate the material in the Event Browser, marking rejects, favorites and keywords. Then you use the database & query features to pull the clips you need. Only *then*do you put those on a timeline.

The magnetic timeline has its own behavioral characteristics and it’s important to understand the overall design intent, not try to wrestle it into submission.

The previously-listed video tutorials are a good place to start.

[Joe Marler]

[Kasey Gay] “But I decided to try deleting a section where I had layered up a few effects and had the image spinning on Z axis with he help of a plugin. Cut that out and haven’t crashed since. “

Unfortunately plugins run within the FCPX address space and any bug in any plugin can hang or crash FCPX. In the future this will hopefully be fixed 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

[Joe Marler]

[Jiri Fiala] “I wanted to retain as much easy re-connectability from the original tree folders (stored in the broadcast facility) as possible,”

You cannot reconnect to already-imported tree-format media since the only allowed import is via copy within library or other designated location specified by the FCPX library inspector>Storage Location>Modify Settings>Media.

During the import FCPX will reorganize and often rename the files to a sparse group of folders. To handle filename collisions it will append (fcp1), etc. to some files. After that, any link to the original tree-format media tree is gone — the data has been restructured by FCPX during the ingest.

Once the “copy”-style import is done, the files should be within the library or designated storage location. If you abort the copy (which is easy to do — just moving the cursor may pause it, as shown in the above video), then all media has not been imported, but is split between the partial content in the library and the import source.

In that case the solution NOT to consolidate, but as shown in the above video: re-connect the media source, select the red/black clips or those with a camera icon on them, then do File>Import>Reimport from Camera/Archive.

People frequently encounter problems with this area. IMO it’s best to bypass these issues by re-wrapping tree-format media with EditReady2 and import with “leave files in place”. It is faster, less confusing, maintains a small “lean” library, and gives you (not FCPX) control over your media folder structure and filenames.

Also do not copy the bare video files out of the media tree and import those. In some cases like Sony XAVC-S you can get away with it. In other cases like AVCHD it will cause major I/O performance problems.

[Joe Marler]

If media is imported from a camera card (or on-disk camera folder tree) and the import does not finish, you may see red/black clips and the error “referencing media on the camera”. Ben Halsall discusses this in the below video.

The reconnect and consolidation may have caused duplicates due to the previous clips already imported. E.g in Finder if you start a folder copy, then abort it, then re-do it, there will be duplicate clips.

For tree-format media which disallows import with “leave files in place”, my suggestion is re-wrap that with EditReady2, then import with “leave files in place”. The re-wrap does not transcode so it’s very fast: https://www.divergentmedia.com/editready

This also allows you to retain control over the on-disk file structure and file names. With copy-style ingest, FCPX manages that (either inside the library or in a designated storage location), and it will rename the files and use its own folder structure.

When importing with “leave files in place”, I strongly recommend first renaming the files to ensure they are globally unique. This avoids other problems which can happen if loading an XML. It also makes subsequent management of the dataset easier, since each filename is unique across all endeavors. My team does this by appending a 5-digit unique, incrementing serial number to the camera filename.

“Final Cut Pro X Tutorial: Fixing Missing Clips on the Timeline – Import Issue Fix”: https://youtu.be/NRNoReJbVoA

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]

Here are two methods:

(1) Export FCPX .fcpxml (not FCP7 XML) and translate to Premiere XML with X2CC (aka X27). If done on the same machine, the project (inc’l multicam) should load immediately with no red clips. If the source and destination machines have different disk names and media paths, a relink in Premiere will be needed: https://intelligentassistance.com/xtocc.html

(2) Export FCPX .fcpxml, (not FCP7 XML) import to Resolve, then export AAF and XML (which also requires a render and encode), then import that to Premiere. The procedure is described on this page under “FCPX to Premiere”: https://www.premiumbeat.com/blog/how-to-migrate-timelines-between-video-editing-applications/

The above-mentioned issues with source/destination disk names and media paths also exist.

[Joe Marler]

[Harry Deansway] “The problem is the multicam, anything edited in multicam on FCPx shows up as red in Premiere once converted. So the only solution is to re edit in FCPx removing the multi cam (how do I do that?)”

I just tested XtoCC (aka X27) on an FCPX 10.4.8 multicam project and the translated XML loaded OK in Premiere 14.2.0. As previously stated, the multicam clip from FCPX is “flattened” to the active angle, but it appears as an editable item in Premiere, including external audio.

This was on Catalina 10.15.5, XtoCC ver 1.2.21, and using FCPX XML ver. 1.7.

https://intelligentassistance.com/xtocc.html

[Joe Marler]

[Harry Deansway] “I edited a project on FCPx which I am trying to share with an editor who works in Premiere. The FCPx edit is done in multi cam and that appears to be hindering the conversion. “

XtoCC will supposedly flatten multicams to the active angle. Other things may not be translated; see the docs: https://assistedediting.intelligentassistance.com/Xto7/help/XtoCC%20-%20Help.pdf

https://intelligentassistance.com/xtocc.html

Another approach is exporting an fcpxml to Resolve, then export an AAF from that to Premiere: https://www.premiumbeat.com/blog/how-to-migrate-timelines-between-video-editing-applications/

Cross-NLE workflow can be cumbersome and frustrating. If you plan and test the workflow ahead of time, you can limit the editing constructs to those which more readily transfer.

[Joe Marler]

There would rarely be a reason to send ProRes files to a mobile device. They are very large and the small screen size makes it hard to see any difference.

One possible reason is if the source material was 10-bit or higher. H264 is generally 8-bit, so you’d be losing bit depth which might theoretically appear as banding on gradient scenes such as blue sky. But there’s a better solution than ProRes for that.

HEVC supports 10-bit encoding but currently FCPX does not use hardware acceleration for 10-bit HEVC encoding on any Mac, even the new Mac Pro. Exporting 10-bit HEVC from FCPX or Compressor is super slow. It is faster on Handbrake and Premiere and the latest Resolve update is lightning fast (on the same Mac hardware and MacOS version) so it’s not a hardware or OS problem. You could export ProRes from FCPX then transcode to 10-bit HEVC with Handbrake or Resolve. The resultant file would be about 1/2 the size of H264 and quality quite good, although that varies with the specific HEVC encoding parameters.

If using the FCPX export preset Master File>Computer>H264, the bit rate is relatively high and quality is very good for H264. There is little quality difference between the “Faster Encode” and “Better Quality” settings, so it’s often better to use Faster Encode.

[Joe Marler]

[Joby Anthony Jr] “My IT guy actually sent me an article on the issue, so it’s documented out there somewhere (sorry, don’t have the article to link to).”

The Outlook flickering problem is fixed in Catalina: https://support.microsoft.com/en-us/office/imac-screen-flickers-when-using-outlook-for-mac-f0b5212f-9c1c-4af2-920b-b131911087bf