[Joe Marler]

[Andrew Kimery] “Until off the shelf computers can achieve ‘good enough’ results w/o needing to buy special-purpose hardware that requires specific support in order to be utilized.

That was the gist of the desktop video revolution was it not?”

The problem is certain higher-end video tasks have outstripped the capability of general-purpose CPU hardware, at least to the extent Intel is willing to commit. E.g, Xeon does not have hardware-acceleration for Long GOP formats, so Apple had to put that in the T2 chip due to the iMac Pro and (maybe) Mac Pro — even though the MacBook Pro has Quick Sync and doesn’t need it.

A full-custom ASIC (like the T2) is very expensive to design and has long lead time. The cost of a custom ASIC must be amortized over very large production runs, yet many customers might not need that capability. E.g, T2 is a security chip but there was likely no other place to put the transcoding logic so it went there. That probably consumed valuable transistor budget that could have been spent on other things.

By contrast an FPGA implementation is much quicker and cheaper to design, and can be targeted to just the systems that need it. But FPGAs burn more power so are not suitable for a laptop. They can be reprogrammed in the field with new algorithms. If it becomes important to have hardware support for Google’s AV1 codec, that could be added to deployed machines.

It appears the main reason for the Afterburner FPGA board was hardware acceleration for demosaicing high-resolution ProRes RAW, but it’s plausible it could also be programmed for RED RAW, and it’s not limited to that. They can even be used to accelerate Long GOP formats like H264 and HEVC.

Apple is not the first to use FPGAs for specific video processing needs:

https://www.streamingmedia.com/Articles/ReadArticle.aspx?ArticleID=129580

https://www.xilinx.com/products/intellectual-property/1-4iso32.html

However it could give Apple a proprietary hardware performance advantage. Even if they expose the Afterburner capability via an API to other Mac app vendors, this won’t work on a PC. A PC vendor would have to fund, design, support and rally software vendors to a similar device. Economies of scale could give Apple an advantage, even for the “niche” 2019 Mac Pro. They might sell more Afterburner cards in 6 months than the total historical sale of RED ROCKET cards. Plus it’s a single-vendor hardware/software solution with a single support source. A high-end customer would not have to do three-way conference calls between RED, Microsoft and HP.

[Joe Marler]

Within the library package, each project exists as a folder with the project name. Inside that folder is a CurrentVersion.fcpevent file which contains several SQLite database tables that hold all the edits for that project.

My first recommendation is make a file-level backup of your current library in case subsequent steps adversely impact that. You can right-click and pick “duplicate”. Obviously this is easier with a “lean library” where media and cache are stored outside the library.

Then in Finder you could do “show package contents”, open the event, and see if your project exists as a folder inside the event (or any other event in that library). If it’s not there that’s why it’s not shown in FCPX.

If you have file-level backups such as Time Machine you could try restoring a previous version of the library, examine it and see at what point the project vanished.

If you don’t have file-level backups, FCPX keeps auto backups of each library, by default located in /Movies/Final Cut Backups. I suggest first making a file-level backup of this entire folder to at least safeguard the current state.

Then within FCPX you could do File>Open Library>From Backups, browse/load each library on the list and see if any contain the missing project. Alternatively at the Finder level you could sort the list of FCPX backups in date order, then do “show package contents” on each one and inspect which has the missing project. Once found you can load that library backup and drag/drop the project to your current library, or just use that library if it is sufficiently recent. Or you could save a project XML file and try to load that in your current library.

The key is go slow and always have (at least one) file-level backup of the library you’re working with. In case something goes wrong you can revert to the previous state. You can rename the file-level library backup or use multiple alphanumeric Finder tags to remind yourself what state the library was in. E.g, “MyLibrary_BeforeLoadingProjXML”.

[Joe Marler]

[Jeff Kirkland] “EditReady will convert them to ProRes if you tell it to. I tend to convert to ProRes but that’s mostly because I’m using a 2013 Mac Pro which doesn’t handle h264/h265 all that well.”

Good point; I only meant the default EditReady conversion for this case is rewrap, not transcode. If rewrapping is acceptable from a performance standpoint, it is much faster than transcoding, plus this enables import with “leave files in place”.

The big question is how will the 2010 Mac Pro handle re-wrapped AVCHD for multicam? I formerly had a 12-core D700 Mac Pro, so I know it nor older Mac Pros handle 4k H264 very well. But maybe AVCHD’s 1080 resolution (which is 1/4 the pixels) would be acceptable. The OP will have to test this.

[Joe Marler]

Under no conditions import bare AVCHD MTS files using “leave files in place”. They should be either (1) Imported from the AVCHD bundle and allow FCPX to copy to the library or (2) Re-wrapped externally with EditReady then imported using “leave files in place”.

When the files are re-wrapped by either FCPX or EditReady they are not transcoded to ProRes. They are still H264 but for some reason the container format allows FCPX to work more efficiently.

Using Finder to copy bare AVCHD files out of the package and importing with “leave files in place” can create an anomalous I/O-intensive condition which greatly degrades library performance, even if only a small % of those files are in a library containing mostly other media types. Examination with Dtrace shows the I/O profile seems to consist many small random I/Os. It may be dynamically re-wrapping each MTS file upon each reference. This behavior is more apparent if the Event Browser is in filmstrip mode and manifests as very sluggish and continuous thumbnail generation. Using the above methods avoids this. In theory if the bare MTS files are already imported you can probably create optimized media as a workaround.

AVCHD is HD resolution not 4k, so if it is imported properly as described above, performance should be OK.

Normally optimized media isn’t required for HD resolution H264. However your 2010 Mac Pro uses Xeon CPUs which does not support Quick Sync, so there is no hardware acceleration for H264 encode/decode.

Due to the lack of Quick Sync, for heavy multicam work it’s conceivable you might need optimized media even for HD resolution. You can evaluate this by importing as described above, making a test multicam and checking edit performance. If it performs OK you don’t need it.

[Joe Marler]

[Kasey Gay] “My thoughts were that I could simply change the linked audio file to a licensed copy of the song when I was done. The files are identical in length and content, the watermarked version just has someone saying “Music Bed” all over it.
“

You can relink to a different audio file within certain constraints. It can have a different name, be located on a different disk path, have a different sample rate, and be encoded with a different codec (e.g. wav vs mp3).

However it must have the same audio channel config and must not be shorter than the original file. There may be other limitations but I’ve relinked audio files containing different material which were encoded with wav vs mp3 and it worked — provided the new file was long enough.

If you try to relink several files and it fails, it won’t tell you why it failed. If you pick a single file and try to relink that, if it fails the error message will indicate why.

Obviously if the new relinked file is longer, your prior audio edits may not be in the right place. If the only difference is varying lead-ins between the files, just cutting off or extending the start may be all that’s required. But if they are at different tempos then it may require re-editing.

You can also copy and paste audio effects between original and new clips using CMD+C and SHIFT+CMD+V. This is one clip at a time.

However if your original timeline audio consists of many audio clips with many edits, you can create an audio-only compound clip of that, add the new audio in a new lane to the timeline, create a compound clip of that, open the original audio CC, and copy/paste all audio effects on all audio clips using CMD+C and SHIFT+CMD+V.

[Joe Marler]

[Brent Griffin] “I have 4 camera angles with slates with no audio… FCPX doesn’t do ‘tracks’ so to speak. So in parts where camera 3 has no footage, camera 4s footage drops down to 3s track, which is quite frustrating.

What would be best practice in FCP X to sync slate marks of footage and then sync all those takes to audio to then set up a multicam take?”

In general you sync multicam clips in the Event Browser, not the timeline. For a no-audio case, you can put a marker on the slate of each camera plus the recorder, then select all the clips, right-click and pick “New multicam clip”. Press the “use custom settings” button and for Angle Synchronization pick First Marker on the Angle. It will sync them based on the markers.

Once the MC clip is created and synced in the Event Browser, THEN you add selections of that to the timeline.

If adjustment of the sync is required, double-click on the MC clip to open it in the Angle Editor. That looks like a timeline but it’s not. It presents each camera/recorder in a separate lane or “track”. You can move clips or adjust the sync there.

In the Angle Editor, you can set a monitoring angle, select “sync to monitoring angle” by clicking on the drop-down menu at the left of the track. This enters a sync mode with a two-up display where you then click the skimmer on each slate event of each track you want to sync. For details see this video about multicam syncing tips, esp. starting about 04:40:

https://www.youtube.com/watch?v=RzTmjfEcYJc

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]

There are two possible problem areas:

(1) Ideally media in FCPX should have globally unique filenames. It’s true it will automatically append a “uniqueifier” suffix of (fcp1), etc. However problems can still arise if the filenames are not unique on disk, across all folders and disk volumes. Normally the problems aren’t too serious, the main one is spurious duplicate clips under some conditions if loading XMLs. The only way to avoid this is rename the files before import. Afterwards it is too late. My team’s practice is append a unique, incrementing serial number to each filename before import.

(2) Dragging/dropping projects or clips between libraries can cause various problems with duplicate clips and mis-linked files. The best practice is place the projects or clips in a “transfer” event, and drag/drop that *event* (not the bare clips or bare project) to the new library.

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]

Was the media imported with “leave files in place” or was it copied to the library? If “in place”, was it imported directly from the hard drive they sent you? If so was that formatted HFS+, exFAT or NTFS?

If it was copied to the library, you shouldn’t have missing media, assuming the library itself is on an HFS+ or APFS partition.

If it was imported “in place” from exFAT or NTFS, then FCPX cannot store the inode of the media files since those filesystems don’t support that. It will still usually work but won’t be as resilient as HFS+.

When FCPX references “in place” media there are two levels of indirection. The first step is retrieving the pathname to the symlink from the SQL tables within CurrentVersion.fcpevent. The next step is resolving the symlink to the actual file. If this fails it will try to resolve the inode which is also stored for each media file within the SQL table. If that works it will rebuild the symlink to point to the right place. The auto-rebuild doesn’t work for external proxies only regular media files.

Re “Suddenly I have those pesky red missing clips on my timeline and in the browser”, at that moment did you try to access those media files from Finder? Is is possible the drive was momentarily off line?

There are cases where a “stale cache” problem can cause transient red clips. Sometimes this happens from a drive going off line or multiple external drives mounting in a different order after restart. You can sometimes fix this by deleting the FCPX cache and restarting FCPX.

For existing files, Finder CMD+I on the symlink will show the expected location. Unfortunately if an “in place” file is missing, Finder CMD+I confusingly shows the symlink’s own location, not where it’s pointing to. You can inspect the symlink pointer using the terminal ls -l command, but you must navigate in terminal to the Orig. Media folder within the library to do that.

As Brett said, another possibility is the files were imported from a card folder tree and it somehow didn’t finish the import. I’ve seen that reported a few times but have never experienced it.

If you haven’t run Disk Utility First Aid, that might be a good idea. Maybe it’s a permissions or file system issue.

[Joe Marler]

Julie, sorry about all the problems. Thanks for taking the time to post this in case it helps someone in the future.

Could you also post the model year and type of your Mac and version of macOS?

There have been several reports of *external* audio issues (say to USB output) for certain Macs. These are thought related to newer Macs having the T2 chip. But I don’t recollect any issues when processing or transcoding internal audio data.

It’s theoretically possible a 3rd-party kernel extension could induce latency when processing audio data. Here’s an article which describes how to list those: https://osxdaily.com/2010/08/03/list-all-third-party-kernel-extensions/

[Joe Marler]

If you are only editing a single stream of 1080p Long GOP H264, most computers and NLEs are fast enough to handle this without proxies or optimized media. This includes FCPX on a 2011 iMac.

For most 4k H264, a 2011 iMac is not fast enough except for the special case of the XC-15 using the 305 mbps “all intraframe” codec. That is technically H.264 but it’s not Long GOP, hence it’s much faster to edit. So ironically your 2011 iMac might be able to edit that specific 4k codec more smoothly than the 1080p Long GOP codec. However it takes up a lot more space — but then so do proxies or optimized media.

So youf computer is probably fast enough for 1080p Long GOP without using proxies or optimized media. It is not fast enough for regular 4k H264 (which is usually Long GOP), except if using proxies or optimized media.

For the XC15 305 mbps 4k H264 codec, that is not Long GOP so it’s possible your 2011 iMac might be fast enough to edit that without proxies or optimized media.