[Joe Marler]

Your library is automatically backed up in /Movies/Final Cut Backups. This is only the edits, not the media or cache. In Finder you can manually copy those to another drive for off-site storage.

However you cannot override or control the backup frequency. It generally happens about every 10-15 min if you are doing active work.

If you want total control over manual library backups, you’ll need to use a “lean” library where media and cache are stored outside the library. This can easily be done with the library inspector storage settings “modify” command. You define folders for library and cache, then consolidate, which moves all the media and cache out of the library to those folders. Subsequently the library is very small and can easily be duplicated in Finder by selecting the library bundle, right-click and pick “duplicate”. I do this frequently when working, especially before loading an XML file.

If you want to work at home, you’ll need a separate copy of the external media folders, then take your lean library home. Ideally the drive and folder names should be the same but they can quickly be relinked if not. However you cannot relink proxies.

[Joe Marler]

Not sure what the problem is. Can you verify plenty of free space on both system and Lacie drives?

Run Disk Utility First Aid on system and Lacie drives. To properly run it on the system drive requires booting in recovery mode: https://support.apple.com/guide/disk-utility/repair-a-disk-dskutl1040/mac

After that rebuild Spotlight indexes. FCPX uses this for expedited search. If damaged or corrupt it can cause problems: https://support.apple.com/en-us/HT201716

Make sure you have the latest version of Apple Pro Video Formats installed. Starting with Mojave that is in System Preferences>Software Update.

Reset FCPX preferences (step 11): https://support.apple.com/en-us/HT203477

After doing that make sure background rendering is off in FCPX>Preferences and all other prefs are as you expect.

Even though you have deleted the render files, try setting a specific location for cache. Select the library, then in the library inspector do Storage Locations>Modify Settings and under cache give a folder location. If it asks about including render files, state “don’t include”. This ensures all render files are rebuilt, including thumbnails and waveforms.

Then load project in FCPX, select all timeline clips with CMD+A and render the timeline with CTRL+R. Observe all render dots are gone. If you have any clips using optical flow or stabilization, make sure the analysis phase of those are complete before rendering the timeline. This helps isolate the problem between render phase vs encode phase.

If that completes with no errors try to export it: File>Share>Master File
Settings>Format>Computer
Video Codec: H.264 Faster Encode
Resolution: 1920×1080

Make sure the destination file is on a valid drive with sufficient free space and permissions. If any doubt export to /Documents or insert a thumb drive and export to that.

If that gets stuck or doesn’t work, make a snapshot of the timeline: select the project icon, right-click and pick duplicate as snapshot. Then open the snapshot, select all clips in timeline with CMD+A, then strip all effects with Edit>Remove Effects. Select all clips in timeline with CMD+A, then try to render with CTRL+R. If that is OK, then try to export (without effects – just a test).

If that works but the other steps failed, duplicate the timeline again, select 1/2 the clips and remove effects from those, try render then export. Based on these results try the other 1/2, then 1/4, then 1/8 and find where the problem region is.

[Joe Marler]

It currently appears to not be an Avid issue, nor isolated to Mac Pros. On any Mac with disabled System Integrity Protection, it appears a Chrome “Keystone” update alters the /var symlink which prevents OS boot. It probably showed up on Avid systems because those users often disable SIP for 3rd party Video Cards.

There is a current solution that does not require re-installing macOS: https://mrmacintosh.com/google-chrome-keystone-is-modifying-var-symlink-on-non-sip-macs-causing-boot-issues/

[Joe Marler]

[Greg Ball] “The videos are multiclip videos with 3 streams. Do you think that’s why this is so slow”

Likely the main reason is (ironically) because it’s a Mac Pro and you’re doing H264 processing.

I don’t think a multicam clip by itself will slow down exporting. It only needs to decode and encode the visible layer. If using blending it needs to decode, render, composite multiple layers then encode the final composite.

Some possible choices:

– Plug drive containing project and media into a Quick Sync-equipped Mac, preferably a 2017 or later iMac 27. However even a 2015 iMac 27 or 2017 or later 15″ MacBook Pro would probably be faster.

– Render/Export on the Mac Pro to ProRes, then have a separate Quick Sync-equipped machine transcode to H264. That could take place in parallel. In theory the latest HandBrake uses Quick Sync on Mac but I haven’t tested that. Compressor would be better. The 2010 Mac Pro is pretty fast on ProRes, plus probably fast rendering effects, the thing slowing it down is H264. This lets each machine do what they are good at.

[Joe Marler]

[Greg Ball] “I have about 28 90-minute videos that I need to export so I can send them to my client for approval. Each video is taking a loooong time to export (around 1 hour each).

Is this typical?

Also the projects are all 1080P. But I’m exporting them as 720P MP4 files. Would the conversion process be causing the export to be that long?

Would I be better off keeping the exports at 1080P?”

What kind of hardware? For any Mac without Quick Sync (which means all current and past Mac Pros) H264 encoding may be slow. The iMac Pro doesn’t have Quick Sync but has similar hardware acceleration on the T2 chip. Starting with the 2017 iMac, Quick Sync (as used by FCPX) is about 2x faster than prior machines due to Kaby Lake optimizations.

If you have more than one Mac available, for a large series of long exports it can be faster to connect the hard drive to a Mac with Quick Sync. Even a laptop can be significantly faster than a Mac Pro for this.

Also picking the “faster encode” option is quicker than the “better quality” option, and I cannot see any visual difference in the output.

Re 1080 vs 720 output from 1080 project, usually 720 is a little faster but I have run tests on some machines where 1080 was faster.

On my 10-core Vega64 iMac Pro, export of a rendered 1080p H264 timeline to 1080p H264 output using the “fast encode” option is about 5x faster than real time, or 18 min for a 90 min timeline.

[Joe Marler]

[Howie Young] “What types of projects do you edit?

How much RAM does your iMac Pro have?

Which GPU would you recommend?”

Re iMac fan ramping up, that is *definitely* the case on 2017 and earlier. However supposedly the 2019 8-core iMac is much better in that regard, although not as quiet as the iMac Pro. Despite all the discussion of this I don’t recall any review doing a controlled test of this area – iMac Pro fan profile and db noise under sustained load vs 2019 8-core iMac under the same load. Maybe someone else does.

I think some people are over-sensitive to noise. They complain about the iMac fan noise at *idle*. I’ve measured my household HVAC and it’s much louder than that. I don’t see how such people could work in a typical office environment.

That said, I often spend *days* transcoding material and the 2014-2017 iMac is irritating. Even though it’s “white noise”, that gets old after a while. By contrast the iMac Pro almost never spins up.

My projects are mostly documentary, often 50+ 2-3 camera interviews, 4k H264 but more recently 4k ProRes 422. The final products range from 5 min to 30 min, although sometimes we’ll do a 2 hr stringout. The final product may contain thousands of edits and many effects.

We’ve done several blue screen shoots and those don’t seem that bad. However — as the edits and effects pile on the timeline slows down. Anyone who says their Mac is always super-speedy has never done this kind of work. Put Imagenomic Portraiture, Digital Anarchy Flicker Free and Neat Video on a bunch long clips and see how fast your Mac is.

My 10-core Vega 64 iMac Pro has 64GB, but it would probably do OK on 32GB. My 2017 i7 iMac is 32GB and I’ve never seen Activity Monitor showing memory pressure when under heavy load. Note: even the iMac Pro can be field upgraded with more RAM, although only by an Apple-certified service center.

Re GPU I usually recommend the top one, simply because GPU progress is rapid and software people are constantly finding new ways to harness those. That said I’m not sure in the real world you could tell a major difference on a FCPX workload between the Vega56 and Vega64 GPU.

Part of it is just “emotional protection”. Anyone doing serious work will inevitably encounter slowdowns, and often when facing a deadline. When that happens, if you spec’d a lower-end config you will think “maybe it wouldn’t be so slow if I had only…”. In reality it would probably have been slow no matter what the config. But if you got the top config you can comfort yourself thinking “I got the top machine and it’s STILL slow….I did the best I could!”

[Joe Marler]

I have a 10-core Vega64 iMac Pro and a top-spec 4-core 2017 iMac. The iMac Pro is much quieter but supposedly the 2019 8-core iMac is quieter than the 2017.

For collaborative work when we’re passing around lots of portable drives (some USB-C and some USB-A), I like all the iMac Pro ports and the built-in 10-gig ethernet to connect to a NAS.

From a performance standpoint I don’t think either 8-core or 10-core iMac Pro is vastly faster than the 8-core iMac. They are all fairly fast but all will struggle on certain codecs such as some 4k H264 variants. Panasonic’s 8-bit 4k 4:2:0 H264 isn’t that bad, Sony’s 4k XAVC-S is worse, likewise DJI and GoPro 4k H264 is difficult. Panasonic’s 10-bit 4k 4:2:2 H264 is more difficult. In general if you are doing multicam or need really fluid response on 4k H264, you may need proxies — with any of these machines.

The base model iMac Pro is a pretty good deal if you can get it on sale. Micro Center would previously sometimes sell them for $3999, and you can get them on the Apple Refurbished store for about $4250.

You can avoid all the transcoding by acquiring in ProRes to something like an Atomos Ninja V. The file sizes are bigger but much smoother to edit.

I think 32GB RAM is generally OK for something like FCPX and Motion. If you are running multiple large apps in parallel, you might need more. You can inspect “memory pressure” in Activity Monitor on your workload to see if it’s memory constrained.

Re 1TB or 2TB SSD, normally 1TB is enough but 2TB is pretty nice especially on a laptop. Another factor that eats space is the increasingly common tendency for cloud-based providers like DropBox, etc. to sync large folders down to your hard drive. You can intervene and turn that off but it’s better to have some “elbow room” so you aren’t on a hair trigger to react.

[Joe Marler]

[Jeff Kirkland] “Blackmagic’s new version of their Video Assist monitor/recorder adds BRAW support to the Panasonic EVA1 and the Canon C300 II with more cameras to come. If Blackmagic stick to their plans, BRAW is certainly going to become an option for a lot of shooters going forward. I’ll be interested to come back in a year and see how many cameras have a BRAW option vs a ProRes Raw option. “

Recently at IBC, Atomos CEO Jeromy Young said they have ProRes RAW working on 15-16 cameras, and they expect about 30 cameras by end of next year:

https://www.newsshooter.com/2019/09/14/atomos-announce-16bit-raw-support-for-the-sony-fx9-prores-raw-update/

I don’t know his list of cameras, but but I see on Adorama they have “ProRes RAW Atomos/camera kits” available with the Canon C300 II, Panasonic EVA1 and Sony FS5. Also supported are the Canon C500, Varicam LT, Sony FS7 and FS700. ProRes RAW is available on the DJI Inspire 2 with X7 camera, the Nikon Z6/Z6 (November), and will be available early next year on the Panasonic S1H.

Jeromy Young also revealed the 8K files used at WWDC to demonstrated the Mac Pro were recorded on an Atomos Neon at 8k/60 in ProRes RAW from this prototype Canon 8K cinema camera: https://images.app.goo.gl/6B5pDSsYkqUFyZZEA and in the future Atomos would support up to 4k/120 ProRes RAW from the Sony FX9.

[Joe Marler]

[Craig Seeman] “If BMD cameras weren’t so popular it might not be an issue”

It is a fluid situation. BMD cameras are popular but BRAW was only released for the BMPCC4k six months ago. Most BMD installations are probably using a ProRes ecosystem and a NLE that supports ProRes. This can change, but much beyond single-camera “hobbyist”-type use involves workflow issues, analysis, buy-in from post production managers, producers, etc.

For anything above single users, I don’t see an immediate near-term move from FCPX to Resolve or other NLEs based solely on presence or absence of BRAW support. Likewise I don’t think groups were abandoning Avid for Resolve due to lack of BRAW support, only to suddenly stop two days ago when Avid began supporting it. Things happen more slowly than that when production groups and workflow issues are involved. E.g, a lot of feature films shot on Arri still use 12-bit ProRes 4444, even though ARRIRAW is available.

However Apple can’t bank on institutional inertia. If it were not for Blackmagic and BRAW, maybe they could take their time. If only narrow high-end raw formats like Arri and RED existed, Apple could try to gradually convince the ecosystem to standardize on ProRes RAW, while negotiating hard on licensing. But I don’t think they can handle it like ProRes.

Blackmagic is developing Resolve very rapidly and BRAW is proliferating rapidly. The glacial development pace of FCPX has got to improve.

Maybe this is already happening, only we don’t know it. With few exceptions (like the new Mac Pro) Apple doesn’t keep the community informed of their plans. The best source of “inside” intelligence comes, not from leaks, but putting yourself in the mind of inside decision makers. Using that method I don’t see Apple harming their investment in the new Mac Pro (and associated halo effect) by letting FCPX development grind to a halt or not supporting BRAW.

Based on this I would expect a significant upgrade in FCPX in the relatively near future, also that it will support BRAW. This is nothing more than a guess.

On the low end the FCPX upgrade will have to include basic performance and scalability-related issues to fully harness high-end Mac Pro hardware. That may involve more than just drivers for the Afterburner card. It could include significant performance tuning for FCPX on high-core-count hardware or algorithmic changes for database I/O, thumbnail caching, etc. on 100 terabyte libraries.

For user-facing features, it might include some kind of collaborative workflow elements or script/text support. Collaboration is extremely difficult if done in a meaningful way. It is essentially a distributed transactional database, and SQLite is not designed for multi-user access. The development, test and support implications are major. It would make sense for a long period of limited new features while that internal development happens. We will know fairly soon when the Mac Pro is released.

[Joe Marler]

[Paul Golden] “Can a third party write an FCPX plug-in to support BRaw”

Starting with Catalina this is no longer possible. The QTKit method of user-installable codecs is going away.

It is apparently still possible to write and install new 64-bit codecs via plugin because Pro VIdeo Formats does this (XAVC, DV, etc). Also future 3rd-party codec support is possible because RED RAW and Canon Cinema RAW Light are listed in Apple’s HT209000 article as being supported within FCPX going forward – provided RED or Canon software is installed. Likewise Avid just announced Apple will support DNxHD and HR (under Catalina) with a Pro Formats update. This is different from Avid supporting DNxHD solely within Media Composer; it implies there will be system-wide support including FCPX editing DNxHD on Catalina.

Unlike QTKit which had a documented procedure for extensible 3rd-party codecs (which were 32-bit and will no longer work starting with Catalina), under AVFoundation the technical method and approval mechanism for doing this has not been revealed.

In Nov. 2018 Jon Chappell at Digital Rebellion wrote a good blog post explaining some of the underlying issues: https://www.digitalrebellion.com/blog/posts/thoughts_on_32_bit_codecs_being_phased_out_in_macos