[Joe Marler]

[Michael Gissing] “ProResRAW isn’t free either and they have limited acquisition to Atomos. So same problem”

Re FCPX supporting BRAW, why this is any different than RED RAW and Canon cRAW. In both cases RED and Canon have written plugins which add this support to FCPX. Why can’t BMD write a similar plugin to enable BRAW support in FCPX like RED and Canon did for their raw formats? You download that code from the manufacturer’s web site (who developed and supports it), not from Apple.

Re Resolve supporting ProRes RAW, I’m sure BMD could license it, write the code and include this in Resolve if they wanted to. Adobe supports ProRes RAW in Premiere right now.

Re how widespread BRAW is vs ProRes RAW and the future outlook, currently BRAW is supported on BMD cameras plus the C300II and EVA-1 if you get the BMD Video Assist 12G.

ProRes RAW is not tied to any camera manufacturer and is currently supported on about 12-15 cameras via Atomos, and Atomos claims it will be supported on 30 cameras by end of this year. Currently (or imminently)-supported cameras: Nikon Z6/7, Sony FS5, FS5II, FS7, FS7II, FX9, Canon C300II, C500, C700, Panasonic EVA-1, S1H, Varicam 35, Varicam LT, Z CAM E2, DJI X7.

The Kinefinity MAVO Edge will support internal ProRes RAW, not using Atomos. I don’t know how they deal with the RED patent. The DJI X7 seems to side-step the issue since technically it is not internal to the camera but integrated into the Inspire2 airframe SSD package.

[Joe Marler]

[Ricardo Marty] “There is no prores over 4k even prores raw. So i think bmd has the leverage for this one.”

Here is 8k ProRes from a RED camera: https://youtu.be/LinWyRFeE5E

Here is 8k ProRes (internally recorded) from a Kinefinity MAVO: https://youtu.be/KKPfOrn3yeE

The ARRI Alexa can technically record internal ProRes above DCI 4k, since it can go to 4448 x 3096 (open gate).

You likely won’t see any of these other cameras record BRAW since that is a camera-specific codec. ProRes (including RAW) is camera-independent, which is why many cameras and recorders from various companies use it.

BMD has published an SDK to allow *decoding* BRAW. That SDK includes compiled binaries that are essentially a “black box”. I don’t think they have published any info about how to *encode* BRAW which means nobody but BMD can do that. This differs from ProRes, where anybody with a license can encode it. It would seem until this changes that BRAW will be limited to BMD hardware, whereas ProRes (inc’l RAW) is hardware and manufacturer independent.

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]

[Bill Rabkin] “I recorded a recent Zoom meeting, as I’ve done many times in the past. I imported the zoom_0.mp4 file into a new FCPX Library. When FCPX finished transcoding, the imported clip had no video — only audio!

MediaInfo reports that the Video stream is 2560*1440 (16:9) at 25.000 fps, AVC (Baseline@L5) (1 Ref Frames) H.264/AVC video….

I’ve recorded several prior Zoom meetings that were similar to this meeting, and imported their zoom_0.mp4 files into FCPX with no difficulties. “

Like you I have imported many Zoom recordings to FCPX 10.4.8 w/o problem. However the metadata on mine shows 1280×720, 1,400 kbs, Codec: AVC, Format: CABC/11 frames, frame rate: 25 fps, chroma sampling: 4:2:0, audio: AAC low complexity, audio codec ID: mp4a-40-2, bit rate mode: variable, bit rate: 53.4 kbs, sample rate: 32 Khz.

Upon closing a Zoom recording, then for the initial double-click in Finder, it automatically launches does some kind of transcode or conversion. Is it possible that didn’t happen for this particular file?

Try a manual conversion as described here: https://support.zoom.us/hc/en-us/articles/201362753-Troubleshooting-failed-conversion-of-local-recordings

[Joe Marler]

[Tony West] “I could see prepping my footage on an iPad on the plane on the way back but I would want to prep in the the app that matched the NLE I was going to finish in.”

What if the Apple Silicon MacBook was the same size and weight as an 12.9″ iPad Pro + keyboard, had 2TB SSD, faster GPU, all-day battery life, plus had actual Thunderbolt ports and ran FCPX (plus all iOS apps)? It’s not out of the question something like that could be released this year.

[Joe Marler]

[Craig Seeman] ” With Big Sur on Apple Silicon, LumaFusion will run on Macs. It would seem that LumaFusion may become an alternative to FCPX over time…”

Besides this, it is likely some smaller Apple Silicon MacBooks will be roughly the size and weight of a 12.9″ iPad Pro with Magic Keyboard. They will probably have greatly improved battery life vs any previous x86 MacBook. In essence you will have an iPad-size package except it will run MacOS and real FCPX, not some watered-down future version crammed into iOS.

And as you said that Apple Silicon MacBook will *also* run LumaFusion and all other iOS apps without alteration.

Plus it will be straightforward for developers of high-end iPad apps like LumaFusion to use XCode tools to rapidly tailor those iPad apps for the MacOS environment. This was shown during the last WWDC.

Oliver’s question might also include: “Is iMovie on MacOS pointless?” A tailored MacOS version of LumaFusion for Apple Silicon could easily be produced, largely maintain source code commonality with the iOS version, and would have far greater capability than iMovie. LumaFusion is certainly on a much more rapid development track than iMovie.

[Joe Marler]

[Brad Hurley] “Final Cut “seems” faster and maybe it is because it’s optimized for the Mac, but a lot of the apparent speed difference is an illusion because by default FCPX render-caches everything for smooth playback. You can set up Resolve to do this as well, and you can render-cache every clip individually or just some clips, or even nodes on the color page.”

I also used to say that, but the current situation is more complex. FCPX is “fast” (IOW extremely responsive with low lag) due to meticulous attention to the software code path which implements certain functions. This is especially notable in the fluid, hyper-responsive skimmer and associated viewer. This is regardless of whether FCPX background rendering is on or off.

This was initially attributed to Apple’s single-platform focus. It seemed superficially plausible because Premiere and Resolve were clunky and slow (not long ago).

Today the latest versions of Resolve are really fast in most metrics. The interactive performance is very good as measured by lag to executing JKL input, viewer update rate, etc. Encode/decode performance is faster than FCPX in some cases — yet Resolve is cross platform. Premiere export performance has improved dramatically in some cases but the interactive performance on Mac for certain codecs is still very sluggish. This is especially seen on Sony 4k XAVC-S and -L, and Panasonic 4k 10-bit 4:2:2 All-Intra.

With cross-platform Resolve now encroaching on FCPX interactive and export performance, this apparently diminishes the argument that FCPX achieved this via single-platform focus.

Re the OP issue of “Resolve is slow, maybe my 2019 6-core iMac 27 can’t handle it”, I tend to doubt that. He only has the 575X GPU which IMO is not optimal (esp. for Resolve) but even the top Vega 48 GPU is 43% faster on GeekBench. That’s a very useful improvement but it won’t necessarily transform the entire workload.

In general I’d get the top GPU for any new Mac, but it’s possible his situation is a bottleneck somewhere else, or Resolve can be configured to better cache render files.

He could also experiment with eGPUs but that is another trial-and-error science project.

[Joe Marler]

[Stephen Underwood] “Updated an old library, opened a project. When playing the clips in the timeline some clips have the “red!” warning in the viewer .”

As Francois said, possibly some Fx missing. To narrow those down, there is a free 3rd-party utility called X-Library Check. I’ve only used it once to ensure it runs on Catalina and have no other experience with it. Developer Andreas Kiel has done several FCPX utilities over the years and is a good guy. Scroll down on this page to that item: http://www.spherico.com/filmtools/

[Joe Marler]

[Robert Withers] “Resolve is running very slow for me. Folks have advised selling my new 2019 iMac 3.6 Hz computer, replacing the Fusion drive, replacing the 575X Radeon Pro GPU (4 G), replacing my Firewire ext drives . . . Is Resolve just too demanding for ordinary computer resources? Does Premiere function with less demand on the computer and its parts? How about other NLEs? No one seems to talk about this. “

From a performance standpoint there is a complex relationship between the codec, operating system, NLE and hardware. Within each of those there are many variations.

E.g, there is no single H.264 codec — there are many variations which are internally different and place different demands on the NLE & hardware. On Macs alone there are four main hardware accelerators: Intel Quick Sync, Apple’s T2, nVidia’s NVDEC/NVENC, and AMD’s UVD/VCE. *Each* of those exists in various versions. Each NLE harnesses those (or fails to) in various ways.

That is just the decode & encode phase. The render phase is typically GPU oriented, and each effect or plugin has various capability to leverage that. Sometimes a single plugin (e.g, Neat Video) can be re-configured to use a specific mix of CPU cores and GPU.

Within a single NLE on the same OS and hardware, performance of that NLE can vary based on NLE version. In general Resolve has greatly improved performance in *recent* versions. Within a *single* NLE version on a single codec on the same hardware, the NLE can be reconfigured which affects performance (viewer resolution, proxies, media & cache placement, etc). Resolve has various ways to improve performance: https://blog.frame.io/2020/02/24/davinci-resolve-performance/

What does “performance” even mean? Render time? Export time (which is easy to measure)? Or is it viewer update rate or lag time to JKL keyboard input (harder to measure)?

People often focus on I/O but if you’re using a compressed codec it it unlikely IO-limited. After all the puny CPU in the camera managed to write that. OTOH a FireWire HDD is typically quite slow by today’s standards. For HDDs over 5 yrs old, studies have shown a 20% annual failure rate. Just from a reliability standpoint I would replace all those. If using a less compressed codec such as ProRes it is easy to encounter an I/O limit. If the NLE is internally using low-compression render files (e.g, FCPX uses ProRes 422 by default) you can hit a IO limit even on a compressed camera codec.

While video editing IO profiles are often viewed as dominated by large sequential operations, some NLE’s (e.g, FCPX) also emit a high-intensity stream of small random IOs. With FCPX this is due to the underlying SQLite database and operations for thumbnails, waveforms and plist files. Ideally you want to segreate those IO streams on separate devices to avoid conflict.

To answer your last question, in general FCPX and current versions of Resolve are quite fast, and Premiere is less so – especially on Mac. But this varies with all of the above-listed items.

[Joe Marler]

[Dean Hill] “I activated multi cam editing for synching, but edited by dragging clips around the old fashioned way.”

Next time you do this in FCPX, below are details of a suggested procedure. I also suggest you upgrade to more recent versions of MacOS and FCPX.

To make the FCPX sync work properly, the clips must be labeled with an angle name or camera name in the Inspector before doing the sync. This isn’t that difficult and the entire batch of clips shot by one camera can be named in a single step. In general create multicam clips, not sync clips — even if you only have a single camera and external audio source. Overall procedure:

1. Before importing anything, put all clips from each camera in a separate uniquely-named named disk folder. E.g, Wide_DVX200, CloseUp_S1H, etc.

2. When importing make sure the FCPX preference>Import>Keywords from folders and Finder tags are set. This will automatically tag the imported clips with the camera name. This is especially important when using similar cameras where you can’t tell the shots apart from the filenames.

3. Set Event Browser to List View to better see the clip data. Pick menu View>Browser>Toggle Filmstrip/List View or press OPT+CMD+2.

4. If you determine that time of day is incorrect for certain clips since the operator did not set the camera or recorder clock, the clips will not sort adjacent to each other chronologically. This can complicate picking all clips from a given take to sync in a multicam. This can be fixed and adjusted for all clips from that camera. Select the batch of problem clips and Modify>Adjust Content Created Date and Time.

5. After clip time of day is correct, in the Event Browser, select all clips from a given audio recorder or camera. If the Inspector is not on, use CMD+4 to show it.

6. In the Inspector, click the “i” button to show information about the clip. This will reveal a “Camera Name” edit box at the bottom.

7. Enter a Camera Name for that group of clips and press return. This batch labels all selected clips with that camera name.

8. Repeat for each camera or audio recorder. Note all clips from a given device can be labeled in one step, so this is quick.

9. Select all clips in the Event Browser you wish to sync

10. Right-click and select either “New Multicam Clip” or “Synchronize Clips”. Some experienced editors suggest using multicam clips even for single-camera situations: http://www.fcpworks.com/sync-or-multicam-clips/

11. For either multicam or sync clips make sure the checkbox “use audio for synchronization” is checked.

This will create a new multicam or sync clip which is synchronized using audio. You can double-click the multicam clip and open it in the Angle Editor to verify or adjust the sync. If the sync is not correct you can drag the problem clip left/right or use the comma/period keys for single frame adjustment or left and right angle bracket for 10-frame adjustments.

If you later want to add another camera to an existing multicam, click on down arrow next to the angle name at left of the timeline when in the Angle Editor, and select “Add Angle”, then drag the new clip from the Event Browser to the new lane on the timeline.

If a clip is synced incorrectly you can selectively re-sync that one clip within the multicam. In the Angle Editor, click down arrow next to the angle name for the master audio you wish to sync to, and select “Set Monitoring Angle”. Then select the clip which is synced wrong, and on that lane’s name select the down arrow and pick “Sync Selection to Monitoring Angle”. Only that one clip will be re-synced.

Likewise if you forget to add a clip to the multicam during the initial sync, it’s not necessary to rebuild the multicam. Just drag/drop the additional clip to the proper angle in the Angle Editor, then use the above procedure to sync that one clip within the multicam.

After the multicam is created, do not simply dump that on a timeline. Use FCPX favorites, rejects and keywords on the MC clip to tag it curate the content. Have the Angle Viewer enabled when doing this — SHIFT+CMD+7. Ideally mark all the individual “parent” clips comprising the multicam as “rejected” and run the browser filter with “hide rejected”. This will help prevent accidentally adding a single-cam clip to the timeline which would later require manual frame matching with the multicam clip.

“Sync and adjust camera angles”: https://support.apple.com/guide/final-cut-pro/sync-and-adjust-camera-angles-ver23c76b1a/mac

[Joe Marler]

You can try other stabilizers but there is no guarantee any will work. It is simply a trial-and-error process.

I use CrumplePop Better Stabilizer: https://www.crumplepop.com/product/fcpx-premiere-stabilize-plugin-betterstabilizer/

Also CoreMelt Lock-n-Load: https://coremelt.com/products/lock-and-load-x

I also use Mercalli and Resolve as stand-alone tools which require exporting the ProRes clip to them, stabilizing, then exporting ProRes back to FCPX.

Mercalli: https://www.prodad.com/Video-Stabilization-for-Professionals/Mercalli-SAL-Mac-48950,l-us.html

The stabilizer in DaVinci Resolve is one of the best and Resolve has a free version. Resolve’s stabilization is within the tracker menu of the color panel.
https://www.blackmagicdesign.com/products/davinciresolve/