[Joe Marler]

As a first step, try an export straight from FCPX, not using Compressor. Use this preset: File>Share>Master File>Settings, Format: Computer, Video Codec: H.264 Faster Encode, Resolution: 1920×1080.

Time the export, examine the quality, then upload to Youtube in a separate step. Do not use the integrated Youtube upload feature; it’s better to first evaluate the exported disk file, plus this gives understanding of how long export vs upload takes.

Despite the nomenclature, “Faster Encode” looks almost identical to “Better Quality”, yet it better leverages Quick Sync acceleration for encoding.

After doing the above, then consider whether render files can further improve export speed of multiple successive exports. If you have multiple exports or need to slightly adjust the edit each time, make sure timeline is fully rendered (IOW no render dots showing above the timeline). That enables FCPX to use the render cache for export vs re-computing the effects.

You can either use background rendering or manually render the timeline before doing multiple exports. This is not generally necessary but if doing multiple different exports or with slight variations it can save export time.

In general I favor having background rendering disabled, which is in FCPX preferences>Playback>Background render — disable that. The reason is FCPX will never delete old render files and they build up to a huge size, plus you often don’t need continuous background rendering. Instead delete all render files by File>Delete Generated Library Files>Delete Render Files>All. Then do one-time timeline renders as required by CMD+A to select the timeline, then CTRL+R to render.

Before a big series of exports, re-launch FCPX, render timeline as needed, then do export using above preset. Reason: there are a few cases where the render tracking system gets confused and will not use existing render files. Sometimes re-launching FCPX will correct that.

[Joe Marler]

Normally it shouldn’t take hours to generate waveforms. On my iMac Pro running 10.4.10 with media on a 4-drive OWC Thunderbay 4 in RAID-0 and the library/cache on the system SSD, I imported 466 .wav files which totaled 273 GB. This took about 15 min to complete waveform generation.

I then did another test of importing 686 .mp3 files totaling 16 GB. They were scattered throughout a 48TB OWC array; I located them by doing a Finder search on *.mp3, selected them then imported via drag/drop with FCPX set to “leave files in place”. That went through three phases:

(1) Validating 686 .mp3 files for import (5 min)

(2) Processing files for import (10 min)

(3) Waveform generation (22 min)

Total time from import start to completing waveform generation: 37.5 min.

Observing Activity Monitor’s IO tab during phase #1 and #2, it was doing a very high read rate of over 6,000 per sec. These were certainly cached reads using the MacOS “Unified Buffer Cache” which uses surplus RAM to cache disk I/O.

In my .wav import test, the average file size was quite large. During the .mp3 import, the average file size was smaller. In Activity Monitor’s IO tab if you compare read in/sec vs data read/sec, this gives a rough approximation of IO size. Likewise for writes. In general it appears FCPX does lots of small reads, then transitions to a phase where it’s doing lots of small writes, likely writing waveform and peak data to the FCPX cache.

If your library, FCPX cache and media are all on the same mechanical disk, those IO streams may interfere with each other, slowing the process. This is similar to copying multiple large files between two mechanical drives using Finder. It is normally faster to copy them sequentially vs in parallel.

During waveform generation, if the Event Browser is set to filmstrip mode, it will prioritize non-generated waveforms on screen. If you keep scrolling down during that process, it might conflict with background waveform generation. To avoid this consider putting the Event Browser in “list view” while waveform generation is happening. OPT+CMD+2 toggles between filmstrip mode and list view.

In general if you have a large production using thousands of clips, you want higher-end hardware. You don’t need a $40k Mac Pro but I’m unsure if a Mac Mini with all media on a single mechanical drive is adequate. At a minimum you want the cache and a lean library on an external SSD, preferably something like this Helix 2TB which can do 1,000 MB/sec and doesn’t have thermal slowdowns under sustained writing: https://www.amazon.com/dp/B07YCR1S3K/

After the media is ingested and organized, and after initial editing is well underway, then you may start applying effects. Since those are GPU-based, the lack of a discrete GPU might be a problem. In theory you can add an eGPU but those don’t work as well as an internal GPU.

[Joe Marler]

Since you have Media 100, you’ve probably used Avid. See these tutorials about transitioning from Avid to FCPX. Possibly some of it applies to Media 100: https://www.youtube.com/channel/UCZEWB-9BQ2DW-gwBlJJaWNg

[Joe Marler]

The current version is 10.4.10. It has significant performance improvements over 10.4.6. In general 10.4.10 is not buggy but if you have old plugins which have not been updated, those can cause problems.

While it’s not usually a good idea to update in mid project, this can often be safely done with the proper procedures. You simply need to have backup copies of your libraries and in Finder duplicate and rename the 10.4.6 version of Final Cut Pro.app in /Applications. That allows an easy safe roll back if any problems.

All plugins should be first updated, *especially* those from CoreMelt. Here are their installers: https://coremelt.com/pages/downloads

Catalina is not required to FCPX 10.4.10, Mojave is OK.

If your libraries are very large due to containing media or cache, then duplicating them is difficult. The solution is only use “lean libraries” which have external media and external cache. Cache can be placed in a user-designated folder by using the FCPX library inspector, Storage Locations>Modify Settings>Cache.

Having cache external accomplishes several things:

(1) Keeps your library smaller, thus allowing easier duplication for backup.

(2) The small library can be more easily located on an SSD which is much faster for the random I/O required for the library database.

(3) Puts all cache items external for possible placement on an SSD or other fast drive. Since waveforms and thumbnails are stored in cache, this can really help performance.

(4) External cache allows easy deleting of the cache bundle from Finder. This sometimes fixes problems with black thumbnails or red waveforms. The waveforms and thumbnails are not deleted by the command File>Delete Generated Library Files>Delete Render Files>All. However if cache is external you can safely shut down FCPX and delete the cache which is in a folder you specify. You delete the bundle named LibraryName.fcpcache. It will be automatically rebuilt.

From a performance standpoint you don’t want the library on the same drive as media. Library and cache can be on the same drive if it’s a fast SSD.

Disable background rendering in FCPX preferences. If needed you can render the timeline by selecting all clips with CMD+A, then render with CTRL+R. This avoids continuous rendering and build-up of discarded render files.

[Joe Marler]

There are several variants of XAVC. I’ve edited a lot of 4k XAVC-S, which internally is 8-bit 4:2:0 H.264. Both that and XAVC-L are sluggish to edit on most NLEs on almost any Mac.

The statement about the processors on the new Mac Pro is not really correct. They are simply Xeon CPUs, the same as in other high-end workstations. It’s true Xeon does not have Quick Sync video acceleration, but on the Mac Pro this is handled by Apple’s T2 chip. My iMac Pro has a previous version of that chip and it handles some H.264 versions OK, but it could be better.

The Afterburner card on the new Mac Pro does nothing for H.264 or any Long GOP codec. It only handles *decode* (not encode) of ProRes and ProRes RAW — that’s it. However the T2 chip makes the new Mac Pro much faster on some H.264 variants than any previous Mac Pro.

H.264 is not a single codec, but rather a family which includes many different internal formats. There is a general industry problem not unique to Apple whereby camera developers introduce new codec variants, hardware video accelerators don’t always work as desired, and there is a several-year lag time while both hardware accelerators and applications catch up.

Current video accelerators are not like a GPU, whereby if the app uses CUDA or OpenCL it works for a broad variety of cases. E.g, there’s no such thing as generic “H.264 video accelerator”. The accelerator typically can only handle a narrow set of encoding cases — certain GOP lengths, certain bit depths, certain chroma sampling, certain frame rates, certain frame sizes. Any deviation from those will cause the app to revert to software decode/encode.

Sometimes the hardware capability exists but there is lag at the applications level. E.g, Quick Sync was released in 2011 but Premiere Pro didn’t use it for years. Recently Blackmagic updated DaVinci Resolve to better handle some 10-bit 4:2:2 All-Intra codecs on Mac, but FCPX is still sluggish on the same machine.

Theoretically the upcoming new Apple Silicon Macs could have improved video hardware acceleration. More agile refinement of these accelerators to address changing camera codecs could also be possible. By contrast Intel has refused to put Quick Sync on Xeon.

The new 2020 iMac 27 is pretty fast. If you want a fast machine to use in the interim, consider that.

[Joe Marler]

You should be able to use footage already processed by ClipWrap on Catalina, but if ClipWrap is 32-bit it won’t run on Catalina or any following MacOS version. ClipWrap was replaced by EditReady2 long ago, and is frequently updated.

There were significant performance enhancements to FCPX starting with 10.4.7. The current version is 10.4.10 and has substantial proxy workflow improvements. You can run that on Mojave — Catalina is not needed.

As always any upgrade should be done carefully. It’s a good idea to backup all FCPX libraries and use Finder to duplicate and rename the Final Cut Pro.app file in /Applications. That facilitates an easy rollback if encountering problems.

Most issues with newer FCPX versions seem related to out-of-date 3rd-party plugins. Under no conditions update in a cavalier fashion. Especially update any CoreMelt plugins.

[Joe Marler]

In general the best approach with AVCHD is externally re-wrap with EditReady2 (successor to ClipWrap), then import using “leave files in place”. If ClipWrap still works I guess you could use that, but if it’s 32-bit it will never run on Catalina or later. Under no conditions copy the .mts files out of the AVCHD bundle and import those “in place”. This causes a severe I/O problem in the library. This seems unique to AVCHD and doesn’t happen with other tree-oriented media.

By itself FCPX will only import from the AVCHD bundle using “copy to library”, and in that case it properly re-wraps the files. However this creates a large library.

Oftentimes the .mts files inside multiple AVCHD bundles have redundant filenames, e.g, 00001.mts, therefore to avoid duplicate filenames FCPX will append a (fcp1), (fcp2), etc. “uniqueifier” to the on-disk filename. In a few edge cases this causes problems, also it improves data management to avoid this. This isn’t specific to AVCHD but can happen with Sony Alpha and other cameras.

It facilitates data management if you have totally unique filenames across an entire project. I suggest externally re-wrapping that media, then renaming the files before import to incorporate a 5-digit incrementing serial number. This is easy to do with Finder. See this MacMost video: https://youtu.be/fDcvqyHduHc?t=188

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]

It might be APFS local snapshots consuming space. If you confirm via OmniDiskSweeper that FCPX libraries aren’t the problem, then it’s not an FCPX issue but a MacOS system support issue.

Here is some info about APFS local snapshots and space consumption: https://eclecticlight.co/2020/04/09/where-did-all-that-free-space-go-on-my-apfs-disk/

[Joe Marler]

It is possible the camera’s shutter speed was not manually set to 1/50th sec, which would normally be required for 23.98 fps (180 degree shutter rule). To match the exposure the camera may have slowed the shutter speed which caused blurring.

I don’t think there is anything which will truly fix that. Your options are re-shoot it, or accept the look and try to make it look like an artistic choice. E.g, put additional effects on it to make it appear dream-like, etc.

[Joe Marler]

Eric, normally doing that should free up disk space. I’d first verifying the trash is empty, then running Disk Utility First Aid on the external drives to ensure all the space usage numbers are updated.

One exception is deleting generated library files will not delete thumbnails, waveforms or optical flow analysis files. In some cases the total of that can be large. Probably the easiest and safest way to delete all that is use the 3rd-party utility Final Cut Library Manager. It also has the advantage of scanning all your libraries and will safely delete that stuff without requiring you to load each library within FCPX: https://www.arcticwhiteness.com/finalcutlibrarymanager/

A good free 3rd-party utility to examine space consumption is OmniDiskSweeper. It has no ads or malware. It scans your disk and builds a column-like sorted list where you can rapidly identify what is consuming space: https://www.omnigroup.com/more

Is that external disk ExFAT, HFS+ or APFS?