✎ Latest Forum Posts
✎ Latest Free FCPX Effects

wizoomer95 wrote: Thanks for the response. I trimmed the video as you suggested. Importing the trimmed clip into FCPX still reports the incorrect frame rate of 25fps...

Thanks. I downloaded and inspected the clip. DaVinci Resolve 16.2.7 also reports the frame rate as 25 fps.

The command-line tool FFPROBE reports the following items in the video header of your test file:

r_frame_rate: "50/1"
time_base: "1/50"

This is probably throwing off Resolve and FCPX when identifying the clip characteristics. The clip appears to have originally been an interlaced file, maybe PAL which would be 50 fields per sec. It was somehow captured or translated incorrectly to a 23.976 fps progressive file. You can see the interlaced artifacts are now "baked in" and cannot be fixed.

You can possibly convert the file to 24 fps using VLC. To do this start VLC, do File>Convert/Stream, drag/drop the clip to VLC, then Choose Profile>Customize>Encapsulation: MP4/MOV, then under Video Codec pick H.264, Frame Rate = 24 fps, Resolution>Width: 1920, then Apply. Under Choose Destination pick a location, then click Save. It will re-encode the file at 24 fps. Then try to import to FCPX.

FFPPROBE: ffmpeg.org/ffprobe.html
VLC: www.videolan.org/vlc/download-macosx.html


wizoomer95 wrote: ...I have a video file I'd like to edit in Final Cut Pro X. It's a traditional 1080p MP4 file, H264-encoded with AAC audio. MediaInfo, QuickTime, and even VLC all report the frame rate as 23.976 (NTSC Film). I'm 99.999% sure that this is the proper frame rate for this particular video file....However, whenever I attempt to import this video into FCPX, it reports the frame rate as 25 frames per second.

Can you upload this file or a piece of it so we can examine it. If the content is proprietary, you can trim this using Quicktime Player which does not re-encode the file and should preserve all metadata. The trim command is CMD+T. After trimming the file, inspect the header with MediaInfo, then import to FCPX to verify it behaves the same. Then upload to DropBox or some other place we can examine it.


Joe M. replied to the topic 'Working with 1080p vs 4K' in the forum. yesterday

Xavier Novembre wrote: ...both give similar results, except that the first one (Fit/Fill) is much more convenient and time saving...now I have read on this very forum that it will give mushy exports ... ? (never tried)...

Using 4k in a 1080 timeline, you can use Spatial Conform=fit and scale to 200% or set Spatial Conform=none and don't scale. In both cases if exporting at 1080p the resolution is the same. You can easily test this yourself.

There are other more complex situations involving 1080p content in a 4k timeline vs 1080p timeline, both exported as 1080p which may in some cases significantly degrade the resolution depending on the source codec and export codec. Reported cases include screen capture 1080p video from OBS and exported 1080p H264 video from Microsoft PowerPoint. This apparently does not happen if exporting from FCPX as ProRes 422 or exporting from Premiere or Resolve as H264. I am investigating these.


Joe M. replied to the topic 'Working with 1080p vs 4K' in the forum. 2 days ago

I don't remember. I has been that way at least back to around 10.1.4; I don't know about earlier. When I formerly used Premiere Pro CS6 I had to use the procedure you described. I was surprised that FCPX did not require that.


Joe M. replied to the topic 'Working with 1080p vs 4K' in the forum. 2 days ago

dgwvideo wrote: To be able to zoom in on your 4K footage, create your 1080p project and then when you drop a 4K clip onto the timeline select the clip and set the spatial conform (in the video inspector) to NONE. Your image will immediately show scaled up and you can resize it and reposition it as needed to fill the 1080 frame.

In some other NLEs this may be required, but in FCPX you can leave spatial conform at FIT or FILL, and a 4k clip in a 1080p timeline will show the underlying 4k detail when transformed (zoomed) to 200% and repositioned. The extra detail is visible both in the FCPX viewer and if exported to 1080p.

There are some possible performance advantages to using 4k in a 1080p timeline, because render file size (hence generation time) is based on timeline resolution, not original media resolution.


Joe M. replied to the topic 'FCPX Crashes on Export' in the forum. 3 days ago

Google shows several people having Mac system hangs or kernel panics, maybe from com.wdc.kddfuse.filesystems.kddfuse.

If your iMac won't run Apple Diagnostics, that itself could indicate a problem.

The Genius Bar has access to overnight and multi-day "bench diagnostics" which are much better at finding hardware problems. I had an intermittent problem with my 2017 iMac 27 causing spontaneous reboots, and the Genius Bar diagnostics had to run over 24 hr straight before it flagged a problem. In that case the entire logic board was replaced.


Joe M. replied to the topic 'Vanishing files' in the forum. 3 days ago

JCoultas wrote: In the last few days when I start up FCPX some of my projects are showing that they files are missing. I check original media folder and sure enough they are gone...

Except for copying files inside the library during import, FCPX does not open media files for writing. They are opened with read only access, so normally FCPX cannot by accident delete or damage a file.

You can verify FCPX is looking for the expected file and location by clicking on the red missing media icon, and doing Files>Relink Files. Do not relink them, just look at the relink dialog. It will state at the bottom what pathname and file it's looking for. If the pathname is too long to fit, hover your mouse over the filename in the box and a "tool tip" popup will show the complete file and pathname.

If that shows the expected file and location but in Finder the file is missing, then something moved or deleted it. One possibility is some kind of iCloud Drive or DropBox media management which moves content to the cloud to save space. You can check the config of those.


Joe M. replied to the topic 'FCPX Crashes on Export' in the forum. 4 days ago

OMMBoy wrote: ... I've been experiencing the same issue as @aloyisiusoxbow since around May or June 2020...I'm not sure if Aloyisius' FCPX crashes only, or if his whole computer crashes, too, but when I try to export a project to YouTube, my iMac (late-2012) crashes within 30 seconds of starting the upload. Every. Dang. Time. I noticed this started after updating to Catalina, but I don't know if it's related...

His issue was a FCPX applications crash, not a MacOS hang or crash. He was using Digital Rebellion's Crash Analyzer (which only works on app crashes) to study it: www.digitalrebellion.com/promaintenance/

If your entire machine hangs or crashes that is a system-layer issue and cannot be fixed at the application layer. It is caused by hardware, system config, or something like that. You can try basic things like verify all drives have at least 20% free space, run Disk Utility First Aid on all drives, etc. You can run Apple Hardware Diagnostics but that is a very simple test and a clean pass does not mean no hardware issues. However if it finds something thats significant: support.apple.com/en-us/HT202731

Examine what kernel extensions are in use. A bug in any kernel extension can freeze or crash the machine. That is why Big Sur will begin elimination of those. You can examine what kernel extensions you are using by typing this command from a terminal window:

kextstat | grep -v com.apple


Joe M. replied to the topic 'OS 10.15.7 and Compressor update slows down Compressor?' in the forum. 4 days ago

What if the CPU and GPU graphs were lower, but the job finished faster because it made better use of Quick Sync which isn't reflected on those graphs? Did the person who posted that even time the job, or was he so mesmerized by the graphs that was overlooked?

Also the title said "no hyperthreading". How would they know that? If it was a 10 core machine, the CPU graph shows 11 cores which implies hyperthreading was enabled.


Joe M. replied to the topic 'Does having too many plugins slow down FCP?' in the forum. 4 days ago

pszilard wrote: That’s very interesting. Would you care to mention which, as it might help others (and me) in case we have the same loaded.

That one plugin was Imagenomic Portraiture for video: imagenomic.com/Products/VideoSuite

However I've examined other people's crash logs which show plugin code within FCPX address space, even though they had not applied it to a timeline. I don't remember which ones.

I'd say just not applying the plugin or 3rd-party effect is about 80-90% safe. But simply having it installed (though not applied) has some risk, especially if you have a ton of them.

This will hopefully be improved with the FxPlug 4 architecture that runs plugins in a separate, isolated address space. But plugin developers must re-write their code for that. Realistically that may not happen until after the ARM transition.


Joe M. replied to the topic 'Does having too many plugins slow down FCP?' in the forum. 5 days ago

pszilard wrote: Not sure if the OP was talking about just having plugins installed, but not applied to the timeline, OR having many plugins actually applied.

I have a ton of plugins installed, but rarely use more than a handful on any one timeline. I expect that should not matter. Can anyone confirm this?

Normally a slowdown happens from *using* the plugin. Less commonly, just having the plugin installed can cause performance or stability problems. I have had a few FCPX crashes caused by a plugin which was installed but not used in any project. This was confirmed by the plugin mfg, also the crash report showed their code inside FCPX address space.


Joe M. replied to the topic 'Exported files won't open in Premiere Pro' in the forum. 5 days ago

There is a 10.4.10 FCPX bug fix update out today. You could try that and see if it makes any difference.


Joe M. replied to the topic 'Does having too many plugins slow down FCP?' in the forum. 5 days ago

KScha wrote: ... My current practice to to load all clips into the library when I import them. I understand that keeping them out of the library and into a separate source folder my help with speed and performance. Any thoughts on that?...

That will only make a difference if you have an IO-bound problem. If it is CPU or GPU-bound, that won't help. The fact you mention periodic "beach balls" and lots of 3rd-party effects (inc'l Pixel Film Studios) implies it could be compute-bound. A chain is only as strong as the weakest link. If the weak link is computation from (a) Plugins or (b) A difficult codec, then improving I/O won't help.

That said, even if IO is *not* your current problem, it's generally a good idea to have the library and cache on a separate (preferably SSD) drive than the media. The IO stream to library and cache includes lots of small random IOs which conflicts with the large sequential IOs required of media.

If your system drive is HDD or Fusion, you definitely don't want the library, media or cache there. If it is SSD, in theory there's sufficient IO bandwidth, but typically the internal SSD isn't big enough so it's a moot point.

To place cache on a designated location, select the library in FCPX and in the Inspector at upper right, pick Storage Locations>Modify Settings>Cache>Choose, and pick an external SSD drive. Note if on Catalina and not running 10.4.9, there is a bug which can hang FCPX if you try to create a folder in that dialog. To workaround that create the folder in Finder, do CMD+I, scroll to bottom and grant Read/Write access to user "Everyone", then click the gear icon and pick "Apply to Enclosed Items". After that use FCPX to designate that folder for Cache.

It is more likely you have a compute-intensive issue due to the 3rd-party plugins. Do the previously-stated timed tests about rendering the timeline vs exporting, both with and without effects, to determine where the problem is.

If you create proxies it will probably improve performance a lot. Ripple Training has an excellent tutorial on FCPX media management: www.rippletraining.com/products/final-cu...ent-in-fcp-x-10-4-9/


Joe M. replied to the topic 'Cannot load library from external disk - always empty' in the forum. 6 days ago

As a contingency, copy all FCPX auto-backups to external media. By default those are in /Movies/Final Cut Backups.

Then run Disk Utility First Aid on your external drive. Observe to see it runs without errors. The disk format of all drives holding FCPX media and libraries should be HFS+ (Mac OS Extended Journaled), or APFS, not ExFAT, NTFS or anything else.

If your library is on your system drive, make sure you have at least 20% free space on that drive.

As Tom said, try opening a backup library. You can do that within FCPX or by navigating to the above-listed backup libraries in Finder and double-clicking on them.

If you are on Catalina, make sure FCPX has full disk access. Go to System Preferences>Security & Privacy>Privacy, unlock it, scroll down to "Full Disk Access" and make sure FCPX is enabled for that.

If you select an event, it should either show existing clips or red "missing media" clips. You showed a screen cap inside your library, however it was at the top level, not within the event. Inside the event within the Original Media folder should be symbolic links to each media file contained on your external drive. Are those symbolic links present?

Note those symlinks will only be present in the original library, not the backup libraries. Apparently the backups store only "inode" locators for the external media files, then after loading the backup library in FCPX the symlinks are regenerated. For that to work the external drive must be on line, and have the same volume name as before.


Joe M. replied to the topic 'Thumbnails in Multicam cripplingly slow' in the forum. 6 days ago

tijuanakez wrote: 2011 iMac 3.4Ghz AMD Radeon HD 6970M 2048 MB.
So definitely not the greatest by todays standards....

You said you have a dozen angles in your multicam? Is that 4k or 1080p? Is it H264? Are you using proxies?

You have a 2011 iMac 27 with a 4-core 3.4Ghz i7 ("Sandy Bridge"), and a 2GB Radeon HD 6970M. That machine has FireWire, USB 2.0 and Thunderbolt 1 ports. How is your SSD connected? Unless it's a Thunderbolt device it seems it would be slow? If you run Blackmagic speed test on that SSD, what is your performance, plus the performance of any other internal or external hard drives?

The Sandy Bridge CPU had the very first version of Quick Sync, so if you have any H264 content, the hardware acceleration may be limited. Just between 2015 and 2017 iMacs, Quick Sync had a 2x performance increase.

Also what version of MacOS and what version of FCPX are you running? There was a significant performance increase in FCPX starting with 10.4.8 due to Metal optimization, also more in 10.4.9. If your iMac can't run those versions, that is another possible source of performance issues.

If I was editing a 12-angle multicam on my 10-core iMac Pro I'd be using proxies, and I'd have the library and cache on a 1,000 MB/sec dedicated SSD via USB-C or Thunderbolt. I realize you must make do with what you have, and you can still do valuable work on the 2011 iMac. My co-worker had a 2010 iMac until recently, and he edited 1080p H264 content. However we have spent a large amount of time investigating a presumed FCPX performance issue which might have a significant hardware performance constraint.


Joe M. replied to the topic 'Does having too many plugins slow down FCP?' in the forum. 6 days ago

KScha wrote: ...struggling with slow rendering... I'd assume that I should fly through most of the projects I do (most 3 - 10 min in length) but it seems so slow sometime and I do get the beach ball on occasion...

When you say "slow rendering", do you mean exporting to a file or rendering the timeline to cache or both? Or do you mean scrubbing through the timeline is laggy and slow?

Can you give more info about what codecs from what cameras? Is it 4k? Is it H264? Is it single-camera or multi-camera? If uncertain, play a couple of clips in Quicktime Player and do CMD+I. That will show you the media and codec info.

Re beach ball, that is not really an indicator of slowness but that something is wrong or software or plugin is poorly written. A beach ball is not a "busy indicator" but means the app has quit responding to events for several seconds. Ideally you should never see a beach ball, because a well-written app either does asynchronous (ie non-blocking) API calls or offloads time-consuming tasks to other threads. However there are limitations in MacOS and related frameworks which require that certain APIs be called from the main thread which also runs the app's UI.

Further complicating this is the programming and threading model in the current FxPlug 3 framework which plugin developers use. In this scheme all plugin code and threads run within the FCPX address space, so a plugin bug or simply a CPU-intensive plugin code path which does not properly yield every few seconds can cause a temporary beach ball. As plugin developers migrate their code to FxPlug 4, this problem should be reduced: developer.apple.com/documentation/profes..._minor&language=objc

For the above reasons it's important to be *very* selective about what plugins you install and use, and also keeping those plugins updated.

It can help to isolate performance problems between several areas: user interaction (e.g navigating and editing the timeline), rendering and exporting. Also isolate whether effects are involved.

The first step is disable background rendering in FCPX preferences, then delete all cache files via File>Delete Generated Library Files>Delete Render Files>All. After that select all clips in the timeline with CMD+A, then do a one-time render of those via CTRL+R. Do not use the machine while that runs.

Once it finishes no render dots should show above the timeline. Scrub back and forth in the timeline and evaluate performance. If export was slow before, try exporting the pre-rendered timeline using this preset: File>Share>Mater File>Settings, Format: Computer, Video Codec: H.264 Faster Encode, Resolution: 1920x1080.

If any problems with those, state the results. If your source material is 4k H264, that can be sluggish to edit on almost any Mac. In some cases you may need to create proxies or optimized media.

If you have (or suspect) very compute-intensive plugins such as Neat Video, update to the newest version which is faster. If still unsure of plugin contribution to your performance problem, make a snapshot copy of the project. Right-click on the project icon and pick "Snapshot Project" (in 10.4.9), then open the snapshot. Select all timeline clips with CMD+A, then remove all effects using Edit>Remove Effects. Navigate the timeline, and do the above export. Time that export and compare to the one with effects. That helps determine what % of the problem is simply a difficult codec vs what % is from effects.

FCPX itself has had recent performance upgrades, starting with FCPX 10.4.8 and continuing in 10.4.9. For some workflows, codecs and effects, it is significantly faster than 10.4.6 or earlier. If you have not upgraded to these versions, consider doing that. As always it's wise to fully back up everything before upgrading (especially FCPX libraries). In /Applications, use Finder to right-click and duplicate the Final Cut Pro.app file. That allows easy roll back to the previous version if you encounter a problem.


Joe M. replied to the topic 'Thumbnails in Multicam cripplingly slow' in the forum. 7 days ago

tijuanakez wrote: So each time I want to open up my Multicam clip and make some changes, it opens blank and starts recreating all the thumbnails again. There's a dozen or so angles and most are composites so it means I have to wait 10 secs each time I want to see where things are to make an edit...Is there any way to pause the regeneration of thumbnails or even just use a poster frame for thumbnails?...

You can temporarily turn off thumbnails (inc'l generation) by setting "Clip Labels Only" which is CTRL+OPT+6, or CTRL+OPT+1 (waveform only). CTRL+OPT+1 through 6 sets various view options.

Unfortunately you cannot retain existing thumbnails and turn off only generation of new ones.

For clips in the Event Browser, thumbnails are initially generated upon import. They are regenerated under some conditions if the filmstrips are resized either vertically or horizontally. They are not all pre-generated en masse, but only sufficient for the current Browser display. As you scroll down in the Browser more are generated.

Timeline thumbnails are generated when the clip is added, and under some conditions when resizing the timeline.

Both thumbnails are stored by default in the library in EventName/Render Files/Thumbnail Media. Examination of the I/O profile during thumbnail generation indicates it's doing a lot of small random writes, roughly around 10K to 20K bytes. On a mechanical drive this will be slow, so if the cache was placed on an SSD that might help.

I previously sent an enhancement request to Apple for more control over thumbnail generation. In LightRoom you can control pre-generation of previews, trading off resolution vs time to create. However in keeping with the FCPX design philosophy, I think Apple wants a "no config" automatic algorithm for thumbnail generation.

Aside from the thumbnail issue, it's generally a good idea if possible to place the library and cache on an SSD. The library itself is internally a SQLite database and involves a lot of small random IOs. You can designate a location for cache by using the Library Inspector>Storage Locations>Modify Settings. Note on Catalina, FCPX versions before 10.4.9 might hang if creating a new folder for media or cache within the Modify Settings dialog. The workaround is first create folder with Finder, then do CMD+I and grant read/write permissions to group "Everyone", the click the gear icon to apply to "Apply to Enclosed Items". This bug is fixed in 10.4.9.

Certain codecs and import modes can worsen performance of thumbnail generation. In particular if bare MTS files are extracted from an AVCHD package and imported using "leave files in place", thumbnail generation can be extremely slow.The solution is transcode to optimized media or first re-wrap with EditReady2 before import.

If using "Clip Labels Only" view mode, it may seem difficult to navigate without thumbnails. However by using clip skimming you can generally find the location. In some cases with lots of connected clips or with a big multicam, it can be beneficial to assign a role color to tell the clips apart. For video-only clips a video role color can be assigned. A/V clips take the audio role color, so assigning an audio role color would be needed. That is the display mode Apple often uses in the FCPX ads: www.apple.com/final-cut-pro/


Joe M. replied to the topic 'Compounding multiple audio clip slowing down FCPX' in the forum. 1 week ago

FCPX.guru wrote: ...Snapshots should not cause any slowdowns at all...

In my experience creating a bunch of snapshots might slow things down. It seems variable, based on project complexity, machine performance and where the library is located. If the library is on a fast SSD it seems less pronounced.

Each snapshot is another CurrentVersion.fcpevent database (like any other project). In theory a large # of projects need not slow things down. But according to the SQLite documentation, each open database consumes resources.

It appears FCPX may internally pre-open a certain # of projects, possibly to improve response time when one is clicked on. This is apparent because under some conditions it shifts to a deferred opening algorithm, where you suddenly see an "opening project..." status line, followed by a delay. This is when you don't click on the project -- it just does it.

I'm guessing they are trying to balance three things: (1) Cumulative overhead if all projects were internally pre-opened (2) Response time if they only opened projects on user action, and (3) A "no config" UI so it's fully automatic as it shifts between modes.

In my experience if you make more than about 20-30 moderate-complexity snapshots, it is more likely to slow down -- mainly when opening a library or shortly afterward.

IMO it's a good idea to have a "lean library" (no media or cache) located on a fast SSD. The cache should ideally also be on that SSD. The reason for separate cache is not performance (it would also be on SSD) but to keep the library small for easy file-level backup and it also streamlines deleting cache items like thumbnails, waveforms, and optical flow files which cannot be deleted using the FCPX UI.


BillBridger wrote: C300 II footage shot in 4K, C-LOG3, Rec. 709

The footage looks flat, as you'd expect from LOG in the file browser, when imported into FCPX it looks flat while skimming and during playback but a second or two after I pause it gets a slightly darker look...