[Joe Marler]

David Mathis: “how many of you are considering or have migrated to Resolve from another editor? What has stopped you from making a complete migration? Would love to hear your thoughts and see what opportunities are there in addition to any challenges that have come your way. As much as I would love to completely use Resolve the fact remains that there is no ProRes RAW support at the moment.”

My team uses both FCP and Resolve, with most editing done in FCP. If you are a solo editor or work on a very small team with limited need for re-editing past projects, it is easier to contemplate a total switch.

OTOH if you need to re-train many editors with varying experience levels, that is a significant impact. Resolve is both capable and complex. The manual is over 3,000 pages. All editors don’t need to know all that, but it would be a major transition.

If you have major work in past FCP libraries you will be re-using in the future, then you’d need to maintain some FCP expertise. If there is a transition period, you can easily end up with projects done partially in each NLE. Without very crisp workflow planning (which means yet more editor training), you can end up trying to patch together two projects because someone got sick and had to hand off their work in a different NLE from collaborators.

On this positive side, Resolve product development has been incredibly rapid. It is cross-platform, which implies better access to faster, cheaper Windows machines. However the new Apple Silicon Macs may change that equation.

Other positives:

– Built-in option for collaboration using a true client/server database.

– “Qualifier” (aka color mask), tracking, node-based grading, etc. is vastly better than FCP.

– Cool features like visual “diff” of two timelines.

– Playback performance has now improved to near-FCP levels with a skimmer-like feature.

– Resolve is actually faster than FCP on the same x86 Mac hardware for certain tasks, such as 10-bit HEVC export and decode performance of certain codecs such as Panasonic’s 400 mbps 4k 10-bit 4:2:2 All-Intra. FCP will likely regain this advantage with Apple Silicon Macs.

– Resolve can export a timeline with trimmed clips plus additional handles. Currently FCP cannot do that and Worx4 X does not handle multicam or compound clips which means it’s not practical in many cases.

Price: the basic version of Resolve is superficially free, but there is a growing feature divergence between free and Studio versions. I think any of these features required the paid version:

– De-interlace

– HDR support

– HEVC decoding

– H264 accelerated encoding using nVidia

– High 10 Profile (10 bit) H.264 decoding (probably also encoding)

– Multiple GPU support

– Dehaze

– Face Refinement

– Sharpen

– Skin soften

– Deflicker

– Spatial/temporal video noise reduction

– Timeline resolution higher than UHD (3840 x 2160)

– Timeline frame rates higher than 60 fps

I don’t think Resolve can re-link to proxies *as proxies* (inc’l camera-generated proxies), which FCP can do as of 10.4.9.

The licensing for the paid version can be frustrating. It appears to require authentication based on a paper card sent via postal mail.

Re ProRes RAW, despite all the talk I don’t see that as a major issue. ProRes RAW has some significant considerations (typical of true RAW formats; don’t know how BRAW handles these). E.g, no in-camera lens profile corrections, on Sony Alpha cameras (or likely any camera with sensor-based digital stabilization) no “Active Steadyshot” stabilization, generally noisy on darker scenes which prevents effective use of HSL mask without initial noise reduction. One incentive for ProRes RAW is the 12-bit 4444 data to enable better color masks and grading but in actual practice this may require a prelim Neat Video pass, then a round-trip to ProRes 4444XQ to bake that in, otherwise timeline is too slow. If using Resolve and you really want that ProRes RAW data you can always do “first light” WB correction (if available) export from FCP, Premiere or Avid to ProRes 4444XQ, then import to Resolve.

[Joe Marler]

But now that we have proxy relink, I don’t see much practical difference for the OP case. He initially planned on using (or had access to) just the proxies. What difference does it make whether he edits proxies as originals or proxies as proxies? He can’t select “proxy preferred” if he didn’t (or couldn’t) import the originals. He can later relink to full res media, then relink to the proxies he was already using.

The hypothetical feature for proxy-only import as proxies would save you a grand total of one relink, which typically takes seconds. A study of the internal SQL tables used by FCP indicates the current data design might not permit proxy-only import as proxies. It appears the SQL rows describing the proxy files depend on rows already existing for original media files, and there is inadequate descriptive info in those tables to support stand-alone true proxies without ever having imported the originals. Of course you can do anything with software but the schema implies it might be a major effort in the current design.

When implementing that planned feature, you might *also* theoretically provide more adjustability like other NLEs have. E.g, options to disregard filename extensions during relink, ignore x characters of filename, disregard audio check, etc. But those are separate improvements independent of a “proxy-only import as proxies” feature.

[Joe Marler]

“I look forward to the day that I can add proxies first, then relink to originals when ready (probably a long wait)”

As I said in the above post, this is possible right now, given the relink constraints are met.

[Joe Marler]

It is possible to initially import only proxies as original media, edit, then later relink to full-res media, then also relink the proxies as FCP proxies. I have tested this with the camera-generated proxies from my A7SIII.

As always there are certain relink criteria for FCP. Any planned workflow involving relinking should thoroughly test this at a small scale before committing to a larger project. Known FCP relink criteria:

– Files must have the same audio config (same number of channels), but sample rate can differ.

– Pixel aspect ratio should be the same, but it may relink even if different. This could result in a squeezed or stretched frame.

– Relinked file duration must be the same or longer as the timeline *clip*. Note this is timeline clip not file clip. Absent a timeline you can relink to shorter files. But if used in a timeline the file must be long enough to cover the timeline clip.

– File name including suffix must be the same.

– Codec need not be the same, e.g. you can transcode ProRes originals to 720p H264 and relink those.

– If the clip timecode does not match the original file, it will not relink. The error is “The original file and new file have no shared media range”. This is due to metadata in the video header labeled “time code of first frame”.

– After relinking to a different resolution file, the viewer may show a window-boxed screen. This is typically a cache issue and can sometimes be resolved by deleting the FCPX cache, which is either stored in the library or outside as defined by the library inspector. The cache is a file bundle named LibraryName.fcpcache.

If relink fails it is often beneficial to try and relink a single file. In that case (but not the multi-file case), FCPX may state why the relink failed.

It is often informative to use the 3rd-party tool Invisor to compare side-by-side the video header metadata from the two files when relink fails: https://apps.apple.com/us/app/invisor-media-file-inspector/id442947586?mt=12

[Joe Marler]

Here is a similar 64-layer project. They apparently used all connected clips (not multicam or compound clips), cut them at the transition points, scaled them, and then enabled/disabled the clips using the V key.

https://www.fcp.co/final-cut-pro/articles/1472-building-a-64-layer-chessboard-project-in-final-cut-pro-x

[Joe Marler]

If the original clips are not ProRes or a similar codec, it is expected that a re-encoded version may have slightly different characteristics, called “generational loss”. Normally this isn’t a big deal for a one-time decode from H264. With FCPX all subsequent edits are done to a database and use ProRes scratch files. Those edits don’t cause re-writing of the source files.

You apparently passed the FCP XML to Resolve, which should have accessed the original media files. It would then do a one-time decode of those files and export in your chosen codec. If that codec is Long GOP (H264, HEVC, etc) it will be re-compressed and there’s a greater chance of small differences. If the export codec is ProRes or similar, this would reduce that possibility, but there is still a one-time decode required. The differences shown in your frame grab are very minor.

You can try exporting the original media from FCP to a full-res ProRes file, then compare that to a version exported by Resolve from those same files to ProRes (without stabilization). That would help determine if the decode/encode paths of the two NLEs are producing differences.

Anytime an effect is added (esp. stabilization) that may cause slight differences in the image.

Transcoding from an H264 capture to ProRes or optimized media before the edit does not help this. The media was already captured from 16mm film and encoded in some format, maybe H264 or similar. If there is concern over absolute maximum fidelity, the original capture should have been done to a ProRes file, with scanning producing 10-bit 4:2:2 or greater data.

If possible the best solution is send the film to a professional service capable of doing “wet gate” scanning and restoration: https://www.posthouse.com

The FCP stabilizer is OK for basic tasks but (as you experienced), the stabilizer in Resolve is vastly better. I think the paid version also has various other stabilization options. The tracker and stabilizer can be used together in either point tracking or cloud tracking modes.

[Joe Marler]

Re AU plugins on Apple Silicon, supposedly most will work: https://support.apple.com/en-gb/HT211907

MotionVFX already has a bunch of native Apple Silicon plugins ready. Several other big plugin developers say theirs will be ready late this year or early next year. It appears they are working on these aggressively. However no word so far about Neat Video: https://support.apple.com/en-gb/HT211941

[Joe Marler]

AudioUnit plugins may run either out-of-process or in-process. It is conceivable the out-of-process plugins might work under Apple Silicon using Rosetta2 emulation, but I don’t know. You’d have to contact the developer or vendor to get details of how each plugin is classified.

https://developer.apple.com/documentation/audiotoolbox/audio_unit_v3_plug-ins/incorporating_audio_effects_and_instruments

[Joe Marler]

I don’t have an Apple Silicon Mac but there’s a key FCPX issue that no reviewer has discussed.

To my knowledge there is currently no Apple Silicon support for 3rd-party FCPX plugins developed with Apple’s FxPlug 3 framework. That generally means all higher-end plugins like Neat Video, Digital Anarchy Flicker Free, Imagenomic Portraiture, Color Finale, and probably most of the plugins from CoreMelt and MotionVFX. It’s possible a template-style plugin based on Motion might work.

This is because Rosetta2 cannot emulate x86 code which is loaded within the address space of an Apple Silicon app, and the above plugins are in that category. It should be relatively straightforward for plugin developers to port their code to Apple Silicon, but until that is done those will be unavailable.

The Apple Silicon plug-in compatibility issue not limited to FCPX. In-process plugins or extensions for *any* MacOS app will not work on Apple Silicon until the 3rd-party developers port those extensions to Apple Silicon. The core x86 app will run under Rosetta2 and if they port the app itself to Apple Silicon, that will work, but the possibly diverse collection of plugins and extensions (if in process) will not be available until ported. In my case I use Neat Video almost every day so I can’t even entertain moving to Apple Silicon Macs until that plugin is ported (and fully functional) on Apple Silicon. I also have various other expensive plugins which I would have to write off, not use or wait for the port. I don’t recollect any guidance or strategy from Apple on this issue.

The technical details were discussed in the 2020 WWDC talk “Port your Mac app to Apple silicon”, which explained why in-process x86 plugins would not work in Rosetta2: https://developer.apple.com/videos/play/wwdc2020/10214/

Some preliminary reviews indicate Apple Silicon Macs are much faster at decoding “difficult” compressed codecs, esp. 4k 10-bit 4:2:2 H264 and HEVC. For anybody forced to transcode to proxy or optimized media, avoiding that would be a major improvement. However until the plugin issue is resolved, the question is whether your workflow can function with no FCPX plugins, or at least none of the sophisticated ones developed with FxPlug 3.

[Joe Marler]

I used to have an R4 and back then they used a MacOS kernel extension. I don’t know about today but an x86 kernel extension will not run on an Apple Silicon Mac, and it might not even run on x86 on Big Sur due to kernel extensions being deprecated.

You can check whether your old system has a Promise kernel extension by typing the below from a terminal window. If that exists, check with Promise support or Promise user forums about whether newer firmware or Promise software exists.

To examine kernel extensions, type this from terminal window. The “|” is the vertical bar, typically above the back slash key on most keyboards.

kextstat | grep -v com.apple