[Joe Marler]

The general concept is drag/drop the project to the new library, then consolidate media. That will copy the project and all related media.

However — you shouldn’t literally do this. There’s a specific procedure which should be used when copying media between libraries. Unfortunately this is not documented in most tutorials or Apple’s FCPX documentation. Symlinks may not work properly and spurious duplicate clips can occur if dragging clips or projects between non-managed libraries vs dragging an event.

The best practice is don’t drag or copy bare clips or projects across libraries but do it inside a “transfer event”. Sam Mestman discusses this from 06:30 to 11:00 in the below video, but you may want to watch Sam’s whole talk from 02:00 to 11:00. He demonstrates this on a Lumaforge NAS but it’s not unique to a NAS.

https://hazu.io/pixelcorps/fcvug-7

[Joe Marler]

[Paul Shoe] “new project that’s more sophisticated – multicam footage, secondary audio…I’m at a loss about how to work with some of this stuff…confused about how to edit multicam footage… for synced audio files, should I be generating new compound clips so I can lock the audio in place and edit it?”

It’s often best to use multicam (MC) clips even for one camera plus external audio. Before sync, the parent clips must be prepped properly by labeling each camera or angle in the Inspector.

Sam Mestman mentioned the advantages of using multicam over sync clips here:

https://www.fcpworks.com/sync-or-multicam-clips/

His procedure for prepping the clips for sync is here:

https://blog.wemakemovies.org/2012/10/fcpx-batch-renaming-advanced-multicam-sync/

When rating or keywording multi-cam clips it’s best to do this only on the MC clip itself, not the parent clips. Ratings and keywords are not inherited by the MC clip. In our workflow we always reject the parent clips and use “the Hide Rejected” filter after making the MC, so nobody will accidentally keyword/rate those or edit them into a timeline.

Sync can be manual, via audio waveform or via timecode. My documentary team uses Tentacle devices on each camera and recorder which greatly expedites sync in post: https://tentaclesync.com

If FCPX audio sync doesn’t work there is Plural Eyes: https://www.redgiant.com/products/shooter-pluraleyes/?gclid=CjwKCAjwqLblBRBYEiwAV3pCJmJ_SOY8Jhoo9WezcfQMJpo7cqn56_whsCOT7ZINnMfGoRQvtdS5-hoCGuUQAvD_BwE

With FCPX it’s best to spends lots of time rating and keywording material before you touch a timeline. This also applies to MC material. MC clips can be rated/keyworded in the Event Browser using the Angle Editor (SHFT+CMD+7).

Despite the advantages, multicam in FCPX has several limitations and quirks. E.g, you can’t apply stabilization or some other effects to a MC clip. Instead you must open the MC clip, blade the parent clip and apply the effect there. FCPX audition doesn’t work on MC, you can’t export a MC clip from the Event Browser, audio waveform height is not properly sized in the Angle Viewer, etc.

For more info on rating, keywording and workflow, see Ripple Training: https://www.rippletraining.com/product-category/final-cut-pro-tutorials/
For short brief free tutorials see MacBreak Studio: https://www.provideocoalition.com/tag/macbreak-studio/

[Paul Shoe] …a lot of the footage was imported at different times, in different ways (with various external storage locations, etc…), and I’m confused about how to best gather it all in one place. So now I have a bunch of drives plugged in, and am getting lots of beachballs as I work, despite an older (iMac 27″, 3.5ghz, iz, 24gb ram) but still pretty decent machine. Should I somehow move it all to one new clean drive and just retain the others as the original backups? Should I be working with some sort of optimized footage, or… ? “

As media comes trickling in from various sources, you can end up with a bunch of little drives each having pieces of your library media. Backup is more difficult plus it’s easy to forget what media is on what drive. If you must temporarily shelve the project then later reconstitute it, remembering all those drives is hard. IMO it’s best to have all media in a single folder tree on a RAID. For NAS-based storage, LumaForge makes good products: https://lumaforge.com

If you’ve already imported media from those drives, within FCPX you can define a new unified storage location then consolidate to that. See Ripple Training’s media management tutorial: https://www.rippletraining.com/products/final-cut-pro/media-management-in-final-cut-pro-10-4/

External directly-attached drives should be HFS+ only, not exFAT or NTFS. APFS is OK on the Mac’s internal SSD. For external SSD in theory you can use APFS but I’m not sure how well tested that is for FCPX.

For 4k H264 media, proxies are generally needed to obtain good editing performance, and especially if multicam. However FCPX proxies cannot be relinked and the drive containing them must retain the original volume name when they were generated. Proxies are 1/2 the linear and 1/4 the pixel resolution of the originals (IOW 1080p for UHD 4k originals) and are ProRes 422, so editing performance is good. Typically they are about 60% the size of H264 originals, so I/O load is low.

An alternate to proxies is optimized media, which is about 4x or 6x the size of H264 originals. CPU load is low but I/O load can be quite high.

FCPX only has a global proxy/original mode, so you can’t have proxies for only certain files without seeing red clips for the others. With mixed 1080p/4k it’s not usually practical to have proxies just for 4k. You must create proxies for it all (in which case the 1080p proxy resolution is 960×540) or create optimized media which preserves original resolution but takes lots of space.

Many cameras do not generate guaranteed unique filenames, and in a large media tree you can have duplicate names in separate folders. FCPX internally appends a “uniquifier” suffix upon ingest but this is not always handled properly. Also with a collaborative workflow it can be confusing to have duplicate filenames. Ideally I recommend renaming all files before ingest to add a unique incrementing serial number. We use the 3rd party tool A Better Finder Rename for this: https://www.publicspace.net/ABetterFinderRename/index.html

[Joe Marler]

[Jeff Feaz] “cheap USB webcam…video codec reports as avc1, and the files are in an mp4 wrapper. They are heavily artifacted. The weird thing is, the artifacts are different every time I play them from the library browser. One major issue is the whole frame turning green for several seconds, with a vague outline of the subject in different shades of green.”

I’ve seen that from some heavily-compressed codecs, but usually during VLC playback. Does it only happen in FCPX? If so what version of macOS and FCPX, and what Mac hardware? What about Quicktime 10 player, or Finder’s Quick Look (press space bar to play).

If it happens outside of FCPX, the file may be malformed due to a poor quality encoder or buffer overrun. You could try transcoding it with HandBrake, EditReady or VLC to something else. There are also video file repair tools. I have not used the one mentioned here, just mentioning it: https://www.stellarinfo.com/blog/repair-corrupt-video-file-vlc-media-player/

[Joe Marler]

[Michael Hancock] “I am not seeing this behavior for files stored on our QNAP. When the storage was local I could rename a file at the finder level with FCPX open and it would keep it linked to the file. On our network storage any change in the file name/location throws the file offline and a forced relink is necessary.
“

FCPX inode lookup of media on a network volume works fine using Macs and SMB. If media and library is hosted by a networked Mac, it behaves just like a local drive. You can move the files, rename them, even delete the symlinks from within the library package — and upon restart FCPX automatically reconstructs the symlinks with the new filenames and locations on that shared network volume.

I don’t know why it’s not working on your QNAP. It would be interesting if this works on a Lumaforge Jellyfish or other NAS systems. Maybe it’s related to whether you are using NFS, SMB or what version.

On Lumaforge’s web site it says: “On most NAS based storage, FCPX Libraries and media management commands will not work because NAS storage is typically shared through AFP or SMB Protocols, which are not designed to work with the FCPX Library Architecture….Currently, the best way to run FCPX in a shared environment is through NFS Protocol. Unfortunately, for FCPX users most NAS based storage is not optimized for NFS.”

https://lumaforge.com/workflow/

[Joe Marler]

[Oliver Peters] “When relinking media, is there a way to not have FCPX immediately try to match names as it searches? This is often an incredible waste of time, when you could manually navigate to the desired file more quickly.”

During relink you can navigate to the folder where the file is, click on that and it will only search that one folder. I have seen varying behavior on this in past versions where sometimes it would apparently start searching before you clicked on the target folder. In some past versions this could be very slow. But it currently seems to behave as expected and it seems fast — at least on my machine.

Within a given drive volume, relink is not normally necessary. You can shut down FCPX, rename every media file, move each file to a different location, go inside the library package and delete all the symlinks to the media, start FCPX and it will find all the files and rebuild all symlinks with the new filenames and locations. It is apparently storing the inode or other locator within two SQL tables inside CurrentVersion.fcpevent.

The inode is only unique to a volume so if the name changes or the media is placed on a different drive, then relink is necessary. Relink for media usually works very well. The big problem is there’s no relink for proxies.

[Joe Marler]

[Jeff Kirkland] “there is no 10-bit version of h264. Certainly, as far as I’m aware, there are no hardware 10-bit decoders. As Gary mentioned, you need to move to H265 to export and play 10-bit.”

There are 10-bit Long GOP H264 codecs, but as you say, this is not that common and you may frequently encounter various issues.

The Sony FS5 can do 10-bit 4:2:2 H264 using XAVC-L, and the Panasonic GH5 can do Long GOP 10-bit 4:2:2.

You then get into issues on both editing and playback. Does the NLE and version of Quick Sync (or AMD’s UVD/VCE on the iMac Pro) support 4k 10-bit 4:2:2 H264? Even if you could export 10-bit H264, would the playback device handle that? TVs probably have an ASIC for H264 decoding but I tend to doubt it’s designed for the less common 10-bit format.

Exporting 10-bit HEVC is possible but I don’t think FCPX/Compressor on any current Mac supports hardware acceleration for 10-bit HEVC. It is incredibly slow. Macs using the “Kaby Lake” CPU or later (e.g, the 2017 iMac) have hardware support for 10-bit HEVC encoding. Unfortunately FCPX/Compressor do not use this.

In December 2018 I tested this on a 2017 i7 iMac 27 using FCPX 10.4.3 and Mojave 10.14.1.

A 4k XAVC-S 63-second test file had these export times:

4k H264 “Fast Encode”: 40 sec
4k HEVC 8-bit: 1 min 23 sec
4k HEVC 10-bit: 40 min 15 sec

I just re-tested this using FCPX 10.4.6 and Mojave 10.14.4, and it’s not greatly different. They may have optimized HEVC software encoding but it’s still extremely slow. On prior versions, 10-bit HEVC encoding was 29x slower than 8-bit. Now it’s only 15x slower.

FCPX still does not use the available hardware acceleration in the Kaby Lake CPU for 10-bit HEVC encoding.

Re image quality of H264 vs HEVC, in theory HEVC produces about the same image quality at 1/2 the bit rate, or better image quality at the same bit rate. However — this is *highly* variable and codec dependent. The DJI X5S camera on our Inspire 2 drone produces much *worse* image quality using 8-bit HEVC than 8-bit H264 at the same bit rate. For that reason we only shoot ProRes.

[Joe Marler]

[Terry Flaxton] “It may all be in my head but the proposal about using 264 is against everything I’ve ever done for this reason: H264 is a very compressed codec…422 Pro Res is better…So casually going in and out of 264 is a problem because you’re trashing your quality each time you go in and out of it.

So: If I want to stay at least in Pro Res – how do I make FCPX stay true to the input codec? Is this about NOT optimising media?”

During ingest of H264 material to FCPX you can create optimized ProRes media or you can do this after ingest by selecting the clips in the Event Browser, right-click, transcode and pick “Optimized Media”. It will create full-res ProRes 422 versions of the media and use that for all edit or color correction operations but from a quality standpoint it won’t be any different than just editing the H264 material.

FCPX never re-compresses or re-encodes when editing an H264 timeline. You can make 1,000 edits or color correction steps to the same clip and it will be no different quality than if that clip was transcoded from H264 to ProRes and those same 1,000 edit steps done to the ProRes version.

If your camera media was H264 at a certain resolution, bit depth and chroma sampling, the quality was fixed for all time during acquisition. Transcoding that to ProRes will not help quality — but it can help editing performance.

*Acquiring* in ProRes is generally better from a quality standpoint (vs H264), but only because it often captures more sensor data. E.g, our Panasonic DVX200 can only internally record 4k 8-bit 4:2:0, but externally to an Atomos Ninja V it can record 10-bit 4:2:2 ProRes. Commonly, H264 is 8-bit 4:2:0 but there are exceptions.

The Panasonic GH5 can record inter-frame H264 4k 10-bit 4:2:2 internally, and if compared to HDMI ProRes 422 capture of that same stream, there’s not much difference. The ProRes is easier to edit but the image quality, dynamic range, chroma sampling are similar. In FCPX the H264 version will not degrade with subsequent editing because FCPX is not like Photoshop — it’s not re-editing and re-writing the same compressed data. In FCPX the edits are stored as metadata in a SQL database.

Re export and playback for large screen formats, it’s important to consider the playback chain. You hypothetically might want to export 4k ProRes 422 or higher, but some playback devices can’t handle the data rate. The output signal chain might not handle the resolution or fail during the EDID/HDMI handshake. If time permits, export a 720p, 1080p and 4k H264 version, plus a 1080p and 4k ProRes version, then test them all at the venue ahead of time. If it can’t be tested, then having a 720p or 1080p H264 version might enable playback if the venue’s equipment is antiquated. During playback testing, especially scrutinize gamma since there is often lack of standardization on how this is handled. E.g, VLC playback of an FCPX Quicktime file shows different gamma than playback with Quicktime 10 player. Obviously the venue audio should also be tested for sync and quality.

If the venue requires a Digital Cinema Package, here is a discussion on that: https://forums.creativecow.net/docs/forums/post.php?forumid=335&postid=101018&univpostid=101018&pview=t

Many projectors are not 4k and even if 4k, the THX-recommended viewing distance is less than one screen width. Further away and the viewer cannot perceive 4k: https://www.engineeringcalculator.net/home-theater-calculator.html

[Joe Marler]

[Terry Flaxton] “so I input pro res 422 – so the thought of these being transcoded to H264 is a horror story straight off the bat. Fine if they’re reference fils to take instructions back to the original media – but having only in the last could pf years embraced FCPX I haven’t understood wht the under the bonnet stuff is and how it works.”

If your camera records in 4k H264, then if you import that to FCPX and do not create proxies or optimized media, you are editing 4k H264. That is your editing codec. However — internally FCPX edits in ProRes, even for H264 media — IOW the render scratch files are ProRes. But these render files are somewhat short lived and often invalidated by editing steps, which can result in frequent re-rendering. The dotted line above the timeline means it’s not rendered.

Normally FCPX is fast enough to edit a non-rendered timeline, so you don’t need background rendering enabled in FCPX preferences. You usually don’t need to manually render the timeline with CTRL+R — at least on a contemporary machine. However 4k H264 is a difficult case (esp. for multiple layers or multi-cam), and in that case it’s often better to use proxies or optimized media.

Either during import or after import you can optionally create optimized media or proxies. Optimized media is full-res 4k ProRes 422, proxies (for 4k originals) are 1080p ProRes 422. Optimized media is typically about 4x to 5x the size of H264. Proxies are about 60% the size of the originals. To use proxies you must set the viewer to View>Proxies. For optimized media it will automatically use that. Optimized media and proxies are all intraframe and much faster to decode/encode, so editing is smoother. However due to the larger size, I/O bandwidth is more often an issue.

[Terry Flaxton] “…Take a for instance: if I output a 4k pro res 4444 file and re-input it for use as a layer – does this really mean it’s been then taken to H264 for manipulation by FCPX – if that’s the case that’s killer because I have to screen at minimum 20 foot and up…

If your editing codec is H264 you can output that as 4k ProRes 422, 4444, etc. then re-import that. However it’s normally easier to just create optimized media within FCPX. One benefit to output then re-import is to “bake in” a computationally-intensive effect like Neat Video noise reduction, but normally you’d just wait and apply that as the last editing step.

If your original content is 4k H264 8-bit 4:2:0, then transcoding that to ProRes 4444 will not create any more useful resolution, luma or chroma data. The final quality won’t be any better.

It does not improve image quality to transcode ingested content from H264 to optimized media. This is only a performance enhancement. FCPX does not internally re-write H264 edits. The list of edit steps are stored in a SQL database, then during render the H264 media is read, those edit steps are applied and the result is an internal render file or (for export) a rendered timeline encoded in the desired codec.

You don’t want to export H264 then re-import that, which would entail “generation loss” due to re-compressing an interframe codec. Any round-trip should ideally be in ProRes or similar codec.

[Terry Flaxton] “…I realise I probably don;t understand this and am looking for simple structural understanding of FCPX – is there anything out there?”

There are numerous tutorials available. See MacBreak Studio: https://www.youtube.com/playlist?list=PLj5Nh9NxSxdlDLI_z-GBII8_vTXD7J5AL

For a detailed FCPX media management tutorial, Ripple Training has a good one:
https://www.rippletraining.com/products/final-cut-pro/media-management-in-final-cut-pro-10-4/

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]

[Terry Flaxton] “I now use FCP X for 4k files – often running 4 layers and my machine is stuttering on playback

My question is what of the following should I change to eliminate stutter on playback – is it just where the library is situated in this case?

I have a mac tower 5.1
Running High Sierra 10.13.6
Processor: 2 x 2.66 Ghz 6-Core Intel Xeon…library is on a La cie 4tb currently writes 160 mb reads 125 mb (average)…
I have a raid I can lodge the library on that can read at 260 mb and write at 560 – would this be better and how many layers of 4k could I run and how many layers of HD?

Would a pro imac do better – should I want for the next mac pro – or will this do for a while if I kit it out better”

It depends on what codec you are editing. If it is 4k H264 (inc’l variants such as XAVC-S, XAVC-L, etc), it is almost impossible to get perfectly smooth scrubbing or skimmer performance. Mac Pros — whether the trash can or older towers — are especially poor at this since Xeon does not have Quick Sync. Smooth 1x playback is more achievable but few editors restrict themselves to 1x speed. For HD I don’t know as my doc team has shot only 4k for several years.

The I/O load for 4k H264 is not that high — typically about 12.5 megabytes/sec per stream. It is predominately a CPU-intensive task and cannot be meaningfully accelerated by normal GPU methods. If your timeline contains effects that can be GPU-accelerated, this helps — but only so much. Many so-called GPU-accelerated effects also entail significant CPU load.

If your editing codec is all-intraframe, that can be a more I/O-bound task. In those case improving I/O bandwidth can help.

Especially for 4k H264, the quickest step is use proxies. These are ProRes 422 at 1/2 the linear and 1/4 the pixel resolution of 4k. Proxies have certain complications such as no alpha channel, hard-coded dependence on the original volume name and inability to relink, but in general they work very well.

If you are doing acquisition in 4k H264, it might be possible to move toward doing acquisition in ProRes, ProRes RAW or other all-intraframe codec. There are various recorders like the Atomos Ninja V which work well on several cameras. That can eliminate need for proxies, at the cost of about 4x or 6x the storage and I/O bandwidth.

That said, 125 MB/sec is not very fast — even for 4k H264, esp for four 4k layers. 4k 8-bit 4:2:0 H264 will be over 50 MB/sec, plus FCPX does additional small random I/Os for the SQLite database which can disrupt the sequential I/O stream. If your library and cache are on a separate drive (vs the media files) this might help.

The new 8-core i9 iMac 27 is about as fast as an 8-core iMac Pro and uses a 9th-generation Intel CPU with the latest version of Quick Sync. The Intel code name for that chip is “Coffee Lake Refresh”. It has some hardware mitigations for the Spectre and Meltdown vulnerabilities. On older CPUs, firmware and OS patches are used. The older the CPU the greater the performance cost of those firmware/OS patches, although this varies based on workload.

A 2019 8-core i9 iMac 27 would be vastly faster on 4k H264 than your current machine. Whether you could edit four layers of 4k H264 without proxies, I don’t know. You definitely cannot on a 10-core Vega 64 iMac Pro. The iMac Pro will be quieter under high load but early tests indicate the 2019 i9 iMac is quieter than the 2017 model. The iMac Pro also does not have Quick Sync but FCPX uses the similar UVD/VCE hardware acceleration on the AMD Vega GPU. It is not as fast as Quick Sync but it’s much better than previous Xeon-powered Macs. The iMac Pro has multiple Thunderbolt channels and 10-gig ethernet, whereas the 2019 i9 iMac has a single Thunderbolt controller and 1-gig ethernet, but this is adequate for many tasks.

Nobody has any details on the upcoming modular Mac Pro. It will likely be Xeon powered and might use some kind of upgradable stackable modules with a proprietary high-bandwidth connector, vaguely like a RED camera.

[Joe Marler]

[Craig Seeman] “…wanted shots that may not have been used in the original. Sometimes they’re looking for things left “on the cutting room floor” as it were. It only happens occasionally but it was far easier for me to import from the camera masters into FCPX than to try to resurrect and FCP legacy project. “

In my case it’s not the legacy project but the legacy library that’s important. The last doc I worked on had 125 multi-cam interviews, 151 camera hours of material, 62 hrs external multi-channel audio, 3,133 clips totaling about 10 terabytes. Weeks of effort by multiple assistants went into rating and keywording the material. This enables later rapid retrieval during post — and afterward.

After delivery, if a subsequent request comes in to find a certain camera angle from a certain interview or to find additional b-roll to cover dialog, for me it’s usually easier to leverage the library which is already highly organized. This is especially for cases where sync’d multicams or sync’d external foreign language audio is required — that’s already done inside the library. If I kept only the camera files I couldn’t relink to those so the massive investment in the library would be lost.

In Tangier’s case, another complication is he probably cannot import the MXF with “leave files in place”. That can be a major issue if dealing with lots of material. It makes the library huge, which makes file-level library backups difficult. You can alter library properties to store that externally but that media will be in the reorganized FCPX folder structure and bear little resemblance to the original.

I like doing most of the data organizing inside FCPX, but I do a small amount outside before import — rename files, use a basic folder structure based on shooting day, operator+camera type, etc. Tree-oriented camera media is a dilemma. If you try to rename those in Finder, it may run afoul of embedded metadata storing the original filename. Some manufacturers have proprietary ingest tools to handle this. Or if you copy the bare video files out of the tree to obtain “leave files in place”, it might cause other problems.

Whether the files are re-wrapped by FCPX during import or by EditReady before import, if those are not saved you cannot later relink, thus you can never reload the project OR library. This creates the “double save” dilemma Tangier is trying to avoid. You either trust the rewrapped files and write off the camera files or buy more disk drives or LTO tape and save two copies of camera media *and* two copies of the rewrapped media.