Joe Marler
Forum Replies Created
-
You apparently have both audio and video with true SMPTE file timecode. If so the easiest method is use FCP ability to create a multicam clip with Use Custom Settings and for Angle Synchronization select Timecode. You can then skim the multicam clip in the browser and pull selects for the timeline. The reason for multicam vs sync clip is the timeline will inherit subsequent changes to the multicam so if you later adjust sync, add an angle, etc. that will appear in the timeline.
Creating a “massive” multicam clip of one audio and one video angle entails no overhead or additional storage, as that is just metadata.
If your video file type is MP4, in some cases FCP cannot read clip timecode from that. You can recognize this by skimming the clip and they will all start with 00:00, not the correct timecode value. This is due to both lack of standardization in the MP4 container spec, plus AV Foundation not supporting that. In that case you will need to re-wrap those clips using EditReady before import: https://hedge.video/editready
-
Joe Marler
April 8, 2022 at 12:45 am in reply to: Does anyone have experience with MASSIVE FCPX libraries?Libraries can be large in terms of data size, number of clips, number of edits, or some combination. Apparently your main concern is number of clips.
There is no documented limit, but practical experience indicates as you exceed 10,000 clips per event it may have problems. The FCP library is internally composed of several SQLite databases, one for each event and one for each project. Each database contains several SQL tables with indexes on certain columns.
Each clip can require multiple rows in some SQL tables to store the attributes, effects and edits. However even if this was 20 or 50 rows per clip, I don’t know why there would be even a soft limit around 10,000 clips, as SQLite can supposedly handle millions of rows.
However the underlying database model is apparently an object-oriented “graph database” using Core Data, which in turn uses SQLite as the persistent data store. It appears FCP does not directly emit SQL statements to the lower database layer but Core Data translates graph database directives to produce SQL statements. Maybe there are limitations there.
I’ve edited a large documentary composed of 8,500 4k clips, proxies for all of them, spread across about eight events, totaling about 20 terabytes of external data. It worked fairly well on a 10-core iMac Pro.
I recently had several crashes on FCP 10.6.1 on an event that contained 17,000 fairly small HEVC clips. In the Event Browser if I paged down, periodically setting markers, then tried to jump forward and backward between markers with the shortcut keys CTRL+; and CTRL+, (IOW CTRL+semicolon and CTRL+comma), it would crash in a hashing function, and the stack trace implies a thread was trying to obtain a shared read lock, probably on a database page.
In general the FCP library data integrity and performance seems very good. However in general I’d be a bit cautious about exceeding 10,000 clips per event.
To search across all events it may do a relational join or else store interim results in temp tables. I’m not sure if staying below 10,000 clips per event would allow you to have 100,000 clips spread across 10 events — you’d have to test that. The tests should include performance on library-wide queries, library-wide smart collections, setting markers on clips in the event browser and jumping forward and backward between those.
There is a more common performance issue if you have lots of projects. Each project is comprised of a separate SQLite database, and there is system overhead in keeping a database open (I don’t know how much). FCP apparently uses a “deferred open” algorithm for the projects, maybe to reduce overhead. It also seems to enumerate all or many projects in certain phases, and that seems to make opening a library or event slow. I don’t know why it does that but having lots of projects, project duplicates and snapshots will cause performance issues fairly quickly.
-
Each NLE and plugin implements morph cuts differently. They also vary in the available controls to adjust the cut. It’s similar to using a built-in stabilizer and finding it creates artifacts for a certain clip. You could file a bug or open a support case but it’s unlikely to be addressed in a time frame meaningful to your task at hand. The most expedient approach is try a different one.
For stabilization I may try the built-in FCP effect, if that doesn’t work I’ll try Core Melt Lock-n-Load or CrumplePop’s BetterStabilizer plugins. If that doesn’t work I’ll will try round-tripping to Premiere Warp Stabilizer or Resolve Studio, or maybe the the Mercalli stand-alone stabilizer.
For morph cuts the main strategy is avoid them by having other camera angles, b-roll or insert shots. You just cannot guarantee a morph cut will work perfectly. With 4k material you can often fake a jump cut to a tighter shot, cutting out the problem frames in the process.
I’ve used MotionVFX’s mMorphCut plugin, sometimes it works better than FCP: https://www.motionvfx.com/store,mmorphcut,p1906.html
Here are some suggestions about how to fix artifacts with Premiere’s MorphCut, maybe some of those will work with FCP: https://youtu.be/boP5SN6vO7Q
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.
-
There is no possibility it’s caused by FCP transcoding. We know that because you tried recording the A7SIII HDMI output on a Shogun as ProRes and it still happened. In that case FCP did no transcoding.
Every implementation of the flow transition is unique — just like each NLE implements stabilization differently. Simply because one NLE stabilizes a certain clip poorly, it doesn’t mean they are “late to the party”. Rather it means the specific characteristics of the effect are less well matched to that clip, or the effect is intentionally designed with limited scope.
That said, it does appear the “Smooth Cut” transition in Resolve Studio works very well. While in some cases it creates ghost frames like FCP and the FCP plugin mMorphCut, in other cases it appears Resolves looks beyond the cut point and uses non-shown head and tail frames to attempt a better match. In a simple test I did, it appears both FCP and Resolve do better than the Premiere Pro 22.1.1 “Morph Cut” transition.
But that is no different than comparing any other built-in effect. The Resolve temporal/spatial noise reduction is much better than the FCP denoise effect. The Resolve stabilizer (and sometimes Premiere’s Warp stabilizer) is better than the FCP stabilizer. The Resolve chroma keyer works better than the FCP keyer, so on FCP I use the Hawaiki keyer plugin.
By contrast the “move” option on Resolve media management was so unreliable and caused so much data corruption it was removed from the product in version 16.2.3. All NLEs have bugs and limitations.
You can’t always rely on a specific feature of one NLE working perfectly. For situations that seem to require a morph cut or flow transition, there are usually other options. This video “Three Ways to Hide Jump Cuts in Final Cut Pro” discusses some of them:
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.
-
Re ‘ghost’ images, the flow transition uses optical flow methods to calculate “in between” frames which should normally be morphed together. However if the subject has a large position change, you can sometimes see a ghost image.
This is not unique to FCP or material from the Sony camera. I tested this using the 3rd party plugin mMorphCut from MotionVFX, it also does the same thing.
Then I tested the same material using Resolve Studio 17.4.3, and it also did the same thing. Maybe they are all “late to the party”?
-
If MacOS crashes, that is either an OS-level bug, a 3rd-party kernel-mode driver or a latent hardware problem which surfaced upon an OS upgrade. In general, an app cannot cause an OS crash and there is no fix possible for an app to avoid that. This case would be likely better handled by MacOS support, and if directed to Pro App support they would just hand it off to them.
It also makes sense to examine the system config, such as % of free disk space remaining, what external hard drives are in use, also any 3rd-party kernel mode drivers. Starting with Catalina the terminal command to examine those kexts changed, and is now:
kmutil inspect | grep -v com.apple
-
If the ProRes export is OK, it’s probably the H264 compression plus 8-bit luma. Even though FCP 10-bit HEVC export is slow on all x86 Macs, you could export a short range to test that. The above workaround about transcoding with Handbrake is another option which is much faster for a longer timeline.
To use only luma in an HSL color mask, see this Ripple Training video:
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.
-
It is likely reduced bit depth of the MP4 file vs ProRes, not the encoding compression. If the original file was even more compressed HEVC, but 10 bit 4:2:2, it likely would not happen. The root cause is 8-bit material, a dark scene, a tonal gradient and a color mask. With only 8 bits per color channel it’s easy to run out of tonal values, which then causes banding. This is worsened if the original material was shot in a flat or log profile.
The default color mask in FCP is 3D, which blends HSL selection criteria by an automatic algorithm. Cases like this can be worse if using HSL masks. However since there is more luma data than chroma data you could try and HSL mask with only Luma enabled. It probably won’t work but it’s easy to try.
Unfortunately using Neat Video can make it worse because it makes the bands crisp and more apparent. Ironically adding noise to the background can help. There’s an “Add Noise” effect in FCP.
If you have a ProRes original and after editing you want to export an MP4 for upload or distribution, you could try exporting as 10-bit HEVC. Unfortunately FCP on all hardware except Apple Silicon is very slow at that. Here is a workaround:
– Export to ProRes 422 from FCP.
– If ProRes 422 file looks OK, proceed. If not, there is a bigger problem.
– Import ProRes 422 file to Handbrake.
– Use the Handbrake video encoder labeled “H.265 10-bit (x265)”.
– In Handbrake Video tab, modify encoder preset slider: VeryFast, constant quality slider RF10. Do your own QC tests and adjust to taste. Start with small files and evaluate best combination of workflow performance and quality.
– Verify quality of local playback. If not OK, adjust Handbrake parameters and try again.
– Upload HEVC file to streaming service and evaluate playback quality. The HEVC file will be 10-bit 4:2:0, as I don’t think any NLE or tool can currently export 10-bit 4:2:2 HEVC. However it should look better than an 8-bit H264 file.
-
Compressor can do optical flow rate conforming but I haven’t tried that. The issue is each scene must be checked. For some scene types it works perfectly. For others (say with complicated backgrounds and a dancer moving in front) it can cause morphing artifacts.
If that happens you then try the other rate conforming options such as nearest neighbor or frame blending, render the clip in place with CTRL+R, then evaluate. That must be repeated for each clip or scene type. That is the cost when someone shoots the wrong frame rate.
Due to the varying behavior it might be best to not bulk convert the footage, esp. if only a small portion will be used in the final edit. If you convert all the material, then that gets edited into the timeline, then you find there’s an artifact (because you didn’t scrutinize every second of material) you’ll have to frame match those clips, find the corresponding original material, replace the timeline clips and reconform it using a different algorithm.
Certain rate conforming pathways are harder than others. Going from 60 to 30 is easy. 24 to 30 is harder but is common. 30 to 24 is really difficult.
Gerald Undone discusses mixing frame rates in this video. At 09:18, see especially his discussion of using 30 (ie 29.97) material in a 24 (ie 23.98) timeline.
https://youtu.be/qAVfIQ2G7Io?t=558
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.
-
The problem with 29.97 in a 23.98 timeline is motion cadence, or jerky movement on some types of movement. You can try FCP optical flow rate conforming. It can often smooth out the required rate conform, but it requires additional computation when rendering. Optical flow conforming can sometimes introduce morphing artifacts, but it generally works fairly well.
To use optical flow rate conforming, select a clip in the timeline with a non-matching frame rate (29.97 in your case), then in the FCP video inspector, scroll to bottom and under Frame Sampling, select Optical Flow. Then select that clip in the timeline, render with CTRL+R, and examine the playback smoothness. If that works, do all the clips with frame rates that differ from the timeline rate.