[Joe Marler]

[Paul Gracia] “I use my own compressor settings which had Multipass disabled, but if FCPX now forces it… it makes sense that times are slower… In a same computer it might be 2x, but since this computer is faster it’s just a 1.4x times slower?..”.

FCPX doesn’t force multi-pass H264 encoding, it defaults to single-pass. What changed was multi-pass now uses Quick Sync or VCE, whereas previously (I don’t know how far back) only single-pass used Quick Sync.

[Paul Gracia] “… I used a 120Mbps 1080p file with a custom 1080p compressor export setting. I don’t know your source file, but you probably used FCPX’s h264 default export option, right? We could upload a test file and try both using the same export method, would be interesting…”

Yes it’s not a good comparison. If you’re interested in evaluating *encoding* performance, that should be done with all parties using the same ProRes clip, no effects or edits, and encoding to the same H264 parameters. That prevents any decode-side distortions of the results and prevents intermixing render performance with encode performance.

Ultimately you want the whole thing to go fast — render *and* export. But without breaking down the problem and testing individual pieces it’s impossible to tell the relative contribution of each. E.g, if I used Digital Anarchy’s Flicker Free, Neat Video, and Imagenomic Portraiture on some clips, then tried to measure encode time, this wouldn’t tell me anything about Quick Sync or encoding performance. Those are extremely compute-intensive plugins.

[Paul Gracia] “…..And both my old iMac and this Hack are using quicksync, of that I’m sure. If you manually get rid of quicksync, export times of good quality 1080p is incredible slow, it’s almost hard to believe…

OK that’s good but your encoding results can’t really be compared to anything else because your timeline has features which make that impossible. If you want to compare we should both use the same clip with no effects or edits. Then we should carefully add specific effects or edits we both have. This could be interchanged with XML. Unfortunately I’m leaving on a field assignment until mid-September so can’t do any work on this until then.

[Paul Gracia] “….My workflow is a little weird though…
* I capture 2K + 1080p in one same file in a 3640*1440 resolution canvas.
* I also capture a native 4K file in a regular 2160p canvas.
* 2-3 audio tracks, sometimes more.
In FCPX I create a 4K project and put my base 4K video track and over it the 2K+1080p video track.
In some projects it stays disabled the whole time, in others I crop it so it uses the 2K one, in others the 1080p, and in some I duplicate it to use both. These are the tracks I put more effects (and maybe chroma key) on.
I know FCPX sometimes struggles with timelines which have tracks not its actual size, so this might be it?..

It might somehow be related to this. Your workflow is so different from mine, we can’t draw any conclusions about platform performance. You would need to take the time to try alternate workflows, starting with a more simple approach and see at what point the performance problems happen.

[Paul Gracia] “…The graphics power is very low, my Vega 64 isn’t easy beatable. I tried to export 5 mins of the 4K projects in the app store in their computers and times were much slower. They even had top tier iMacs and MBPs but none got close to my Hack…”

OK that was a good idea, and more people should test like that. This is difficult because most stores only have base-configured machines, not CTO (Configure To Order). You could probably try this on a base iMac Pro at the store, that might be interesting.

[Paul Gracia] “…4K projects on the other hand, with all the effects… the Vega 64 help is amazing, at this point I think only the iMac Pro can beat it because of its extra 8GB of GPU RAM (mine is the 8GB version), but the iMac Pro doesn’t have quicksync so… it might even be slower in my projects…”

I agree despite the high performance of my 2017 iMac handling H264, my 10-core Vega 64 iMac Pro is preferable. It’s just more robust and stable when under extreme loads, quieter, and the more powerful GPU and additional cores help with compute-intensive plugins. I only suggested the 2017 iMac because it’s super-fast on H264 in FCPX but when you add lots of effects it slows down.

[Joe Marler]

[Sam Lee] “problems with FCP 10.4.3 with its ability to “Leave File In Place” for MXF OP-1b files created with the Varicam 35, LT, HS series. It’s treating the edit ready file as a camera structure. 12-bit AVC Intra 444, & Pro Res 4444 would not leave me leave file in place….Are there any known workaround, tricks to get the OP-1b files in FCP 10.4.3 to import it and “leave it in place”?”

I suggest you re-wrap them with EditReady before importing in place. The latest version of EditReady supports MXF OP-1b: https://www.divergentmedia.com/editready

In general it’s not a good idea to copy files out of a tree-oriented format. In some specific cases we know this works with no apparent problems such as XAVC-S. In other cases it definitely causes problems such as AVCHD. In yet other cases we just don’t know. The risk is it might initially look and behave OK, but only later you discover something in the discarded metadata files is needed, e.g, for clip spanning, color space management, etc.

Supposedly EditReady reads the metadata and folds all that into the resultant re-wrapped files, which can be imported with “leave files in place”. The re-wrap is essentially pass through from a codec standpoint, so it’s very fast.

[Joe Marler]

[Paul Gracia] “…quicksync depends on the processor and all Intel chips have it, so it should be the same. On the other hand…when “hackintoshing”, you have to manually enable some memory addresses and pipelines, and some might be workarounds that work at a 80% performance…”

I thought most Hacks must disable the on-board GPU which in turn disables Quick Sync. Max Yuryev has built lots of Hacks and he mentioned that in one of his videos, I can’t remember which one. See his Youtube page for details.

[Paul Gracia] “….I guess that there is no way of checking whether or not FCPX is using quicksync instead of vce, right?…”

No way I know of. iStat Menus has a GPU activity monitor but it doesn’t correlate with Quick Sync activity. But the performance difference with and without Quick Sync or VCE is so great, you can usually infer this. The problem is how to force that change. On a Hack you can usually turn off the integrated GPU in the BIOS. On a Mac you can’t do that. I’d suggest turning it off on your Hack, running a timed encode test, then turning it back on and comparing the times. If there’s a big difference, Quick Sync is probably being used. If little difference it’s not being used.

VCE use by FCPX is more complex, and much newer. It was only with the iMac Pro that Apple started using this. I don’t know how the macOS and FCPX layers determine which to use in a machine with both Quick Sync and VCE hardware. However maybe you could temporarily remove your discrete GPU, disable the integrated GPU, run timed encoding tests and see if there’s any performance difference vs using the discrete GPU with integrated GPU disabled. For all those tests use only ProRes material, no effects or edits and export to H264 “fast encode”. This reduces the possibility of regular GPU graphical operations distorting the results.

You formerly could infer if FCPX was using Quick Sync by using “Fast” vs “Better Quality” encoding — the multi-pass encoding was software only. However I believe the latest versions of FCPX use hardware acceleration for multi-pass, so it’s slower but not the huge difference in previous versions.

Premiere Pro before the 2018 version did not use hardware acceleration for H264 encoding on Mac. It was about 4x or 5x slower than FCPX on the same iMac hardware. Starting with 2018 it uses hardware acceleration on both iMac and iMac Pro, so it’s roughly as fast (encoding) as FCPX.

However Premiere does not use hardware acceleration for *decoding*. It is still plodding and sluggish on a 4k H264 timeline. By contrast FCPX is much faster and more responsive.

I think in former macOS versions, access to hardware acceleration required using Apple’s Video Toolbox framework, a low-level interface below AV Foundation. The complexity of this might explain why apps like Premiere did not use hardware accelerated encoding on Mac until recently. Now it can be accessed via the higher-level AV Foundation framework.

If anyone is more interested in the low-level details of macOS and encode/decode acceleration, that is here:

Video Toolbox and Hardware Acceleration: https://www.objc.io/issues/23-video/videotoolbox/

WWDC 2014 “Direct Access to Video Encoding and Decoding”: https://developer.apple.com/videos/play/wwdc2014/513/

[Paul Gracia] “… I’m not particularly worried because the one thing that was taking forever (4K transcode, edit and export) is much more fast now…”

If you inspect your encode times vs mine on the 2017 iMac, mine is 3.4x faster than your Hack (8:45 vs 2:34), and 4.6x faster than your 2014 iMac (11:47 vs 2:34). This indicates neither your iMac nor your Hack are using Quick Sync or something in the test is distorting the results, such as effects, non-rendered timeline, etc.

For doing encode tests it’s best to use only a ProRes timeline or at a minimum optimized media, have no other edits or effects in the timeline. Those perturb the results. If possible it’s best to use the exact same H264 codec between platforms, because some H264 codecs differ in the computational demands and compatibility with hardware acceleration.

[Paul Gracia] “….I wanted a hack… there is no iMac that can beat this CPU power (besides the pro that is), even though it’s not its main task, I also use Handbrake quite often and oh boy… that’s fast!!”

There are available Mac Handbrake builds which use Quick Sync but they aren’t normal production releases. Those might be considerably faster, but I haven’t tested them for stability or image quality.

[Paul Gracia] “….proxy editing on multicam 4K… I have an “issue” I’ve chatted about with other editors and they all suffer it to some degree, (with actual macs as well)….Even when editing with proxy files, if my timeline has multiple 4K video tracks (for instance a base + 2 chroma keys), every time I do a cut the timeline freezes for like… half a second. In my old iMac this was like 3-4 seconds…Since everyone I talk to suffers from this, I’m guessing this is FCPX related, but maybe you guys know what causes it?”

I don’t recollect ever seeing this, and I edit 4k H264 multicam every day, but I usually don’t do chroma keying. I just finished a documentary that was full of multicam, probably had 2,000 color correction effects, sometimes 10 keyframed corrections on a single clip, and it ran fine using proxies. The media was on a 4-drive Thunderbolt 2 SSD RAID-0 array. This was on both 2017 i7 iMac and 10-core iMac Pro.

You could possibly greatly improve your FCPX H264 encode performance by just getting a used or refurbished 2017 iMac.

[Joe Marler]

[Paul Gracia] “I mostly do 4K now, so this is not a huge deal, but still… does anyone have any idea of what is going on?
Gotta say that I had some issues activating hardware h264 acceleration, but I finally did. It now fully works, tested and verified. “

Getting Quick Sync to work reliably on a Hack is usually difficult. There is code in FCPX which can use the similar AMD logic called UVD/VCE, which is used on the iMac Pro. They have different performance characteristics. Maybe on your Hack it’s using Quick Sync on 4k and VCE on 1080p.

FCPX on the 2017 iMac is about 2x faster than the 2015 at H264 encoding. This is possibly due to the improved Kaby Lake version of Quick Sync, or some refinement in how FCPX uses it. You would probably have been better off getting a used or refurbished 2017 iMac. It exports to 4k H264 faster than my 10-core Vega 64 iMac Pro. It’s also faster on the decode side, and it can edit single-stream 4k H264 without proxies. It’s almost fast enough to edit multicam 4k H264 without proxies.

However the iMP can export proof copies to 1080p H264 faster than the iMac, is faster on most other tasks and is very quiet and stable. The slower export to 4k H264 is probably an anomaly or limitation in AMD’s VCE; hopefully future versions of FCPX will improve this.

Here are some quick tests I ran using 5 min. of UHD 4k H264 XAVC-S 100 mbps 8-bit 4:2:0 on my 2017 top-spec iMac 27, using FCPX 10.4.3 and macOS 10.13.6. This is just a straight clip with no effects.

Create proxy 5 min: 1:40
Create opt 5 min: 3:40
Export 5 min 4k to 1080p H264 faster encode: 2:08
Export 5 min 4k to 4k H264 faster encode: 2:34

Same test on 2017 iMac Pro, 10-core Vega 64 version:

Create proxy 5 min: 1:25
Create opt 5 min: 1:53
Export 5 min 4k to 1080p H264 faster encode: 1:44
Export 5 min 4k to 4k H264 faster encode: 3:35

[Joe Marler]

[Jeremy Garchow] “This needs to be done in the inspector (command-4). I would change the clips inside the Multicam (that means open the angle editor and do it there, as well as the mutliclip itself, if that it possible).”

Yes, you do it in the Inspector as you showed. You can do all the clips in the entire event in a single step. Just select them all then change the color space override in Inspector. They all get changed.

I’m not sure you need to open the Multicam and do those. When I re-flagged to Rec 709 the parent clips in the Event Browser for an existing Multicam clip, then looked inside the MC clip, those had inherited the change.

You can’t change the color space override of the MC clip itself.

As I said before, I’d suggest making a backup of the library before doing global changes like this. It should cause no problems but it’s easy to make a mistake or maybe later find you had Rec 601 or 2020 clips you didn’t want changed.

[Joe Marler]

[Ray Bright] “The current max enlargement is useless in extremely precise editing, like removing a single pop or rustle….”

This Ripple Training tutorial shows how to navigate by 1/80th of a frame, and do sample-accurate audio editing in FCPX. However it must be a connected audio clip or compound clip that contains only audio.

Also the menu option View > Zoom to Samples must be enabled.

https://support.apple.com/kb/PH12569?locale=en_US&viewlocale=en_US

MacBreak Studio #225: https://www.youtube.com/watch?v=POlbuVkoTkI

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]

[Sara Blom] “The problem is however that I can’t seem to make any change in that tab. I can change things like format but the standard-rec709 tab remains non-active. Could this be because it is a multicam clip? “

I think you can just select all clips in the Event Browser (not just the parent clips for your multicams) and re-flag them Rec 709. In my experience the problem is elusive and unpredictable so it’s better to re-flag everything, else it could happen again, maybe in a subtle way that eludes QC checks until your product is delivered.

I’d suggest first trying that on a small scale, such as only the parent clips of one multicam that reliably exhibits the problem. If that works, do them all, but make a backup of your library beforehand. If you are intentionally using some non-709 material, I’m not sure how to selectively re-flag only the 709 clips, or if the problem even happens on non-709 clips.

If that doesn’t solve it, you may need to delete and regenerate all render files and maybe proxies, if you’re using proxies. It’s not just a playback issue. Once the problem happens it becomes encoded in generated or rendered files.

[Joe Marler]

[Mike Lemons] “client who has shot a LOT of shaky footage. Now I try not to use the inbuilt stabiliser (or any) as I get that jelly effect some of you will be aware of, however I feel that I have no choice now as the footage is really really shaky.”

Besides the FCPX stabilizer, I use Premiere CC 2018 warp stabilizer, Lock & Load, CrumplePop’s BetterStabilizer: https://www.crumplepop.com/product/fcpx-premiere-stabilize-plugin-betterstabilizer/, and Mercalli, which is stand alone for FCPX but a plugin for Premiere: https://www.prodad.com/Video-Stabilization-for-Professionals/Mercalli-V4-SAL–29795,l-us.html

There is also the stabilizer in DaVinci Resolve but I haven’t used it. It’s in the free version of Resolve. It supposedly is very good.

Of all the stabilizers I’ve used, they each have pros and cons. Sometimes one will work better than another on a certain scene, and it’s hard to predict when or why. In general the Premiere Warp stabilizer is quite slow to run but produces good results. Mercalli is a lot faster yet very good, but for FCPX users requires exporting a ProRes file, stabilizing that externally then importing the result file. The CrumplePop stabilizer is fast and has few controls to adjust. Sometimes it works. I haven’t had great results with Lock & Load but I always try it in difficult cases. The FCPX stabilizer is pretty fast and works fairly well but there are cases where the others work better.

No stabilizer can fix frame blurring or perspective shift caused by parallax changes between the subject and background. They all will often produce artifacts, so the typical procedure is endless trial and error while you adjust the controls.

FCPX is especially difficult if you are using multicam, since the stabilization effect must be applied to the parent clip, which must typically be bladed on the multicam clip boundary to avoid time-consuming CPU cycles outside the region of interest.

In general you don’t want to stabilize anything until the final edit. There’s no need to waste huge amounts of time stabilizing material that won’t be used. But you can’t always predict stabilization success, so shaky clips must be optimistically picked which intuition and experience indicate might respond well to stabilization. Then you stabilize it in the final edit and if not successful use a different clip or discard it.

Post production stabilizers often cannot fix highly shaky footage without leaving significant artifacts. IMO it’s better to use them with a “light hand” and accept whatever improvement is possible without artifacts. The real answer is stabilize the camera either optically or mechanically during shooting.

[Joe Marler]

We have a DVX200, but we never use AVCHD but the UHD 4k/29.97 .mp4 format. To me AVCHD is a hassle because (1) FCPX cannot import using “leave files in place” (without causing problems), and (2) The re-wrapped files are copied into the library which prevents “lean library” media management (3) AVCHD appears as a bundle at the Finder level, and (4) It’s 1080p only, not 4k.

If you are copying the .MTS video files out of the bundle and importing those using “leave files in place”, that should never be done on FCPX and may cause I/O performance problems. This is apparently due to FCPX trying to repeatedly re-wrap the .MTS files upon each reference, which causes a huge number of small random I/Os. FCPX needs to statically re-wrap the AVCHD content once during ingest, or else you need to re-wrap it using EditReady. If the AVCHD media is externally re-wrapped using EditReady, then (and only then) can they be safely imported using “leave files in place”.

AVCHD is a variant of H.264 and the 2013 Mac Pro does not have Quick Sync to accelerate decode/encode of this. Normally it’s no problem for 1080p but maybe the specific 60 fps AVCHD flavor is causing a performance problem.

The DVX200 won’t do UHD 4k at 60 fps, only DCI 4k (2160p). All our other cameras are shooting UHD 4k at 29.97, and even though DCI 4k is only a small compositional change in post it’s easier to keep them the same. Also 4:2:0 8-bit 4k (whether DCI or UHD) can theoretically be transcoded to 10-bit 4:4:4 1080, so shooting 4k gives better quality for 1080 distribution. More info: https://pro-av.panasonic.net/en/dvx4k/pdf/ag-dvx200_tech_brief_vol1_en.pdf

[Joe Marler]

My documentary team frequently has this problem, and it’s one reason we don’t use camera archives. I’ve never tried it, but I think the archive is just a file bundle and you could probably open it and delete the file. However it’s a bigger problem than whether to use camera archives.

If you have a lot of camera offloading from various operators, the dilemma is how to handle duplicates from non-cleared cards. The cards might have several days of material, when the expectation is they should be new cards each day. This often happens with “special” cameras like drones or time lapse.

If you only offload the current day, you risk losing material. If you offload all material from each card and they aren’t cleared each day, that causes duplicates. That’s an immediate problem for backup, storage size, and offloading time. Later it becomes a post production problem of de-duplicating the files.

For us this was only solved when we began using an on-set data wrangler who was empowered to enforce the policy of clean cards every day. She uses a checklist or spreadsheet to verify each operator offloads their cards each day. If they don’t hand in their cards, she tracks them down. If she receives non-cleared cards, she follows up to prevent that.

Yet there is a risk to immediately reformatting the cards, since they serve as a last-ditch backup. This risk is magnified by cameras with two card slots, some of which will silently auto-switch to the other card if the camera is just powered up with one card inserted. This can create confusion about which card was used, making it possible the operator could hand in a blank card, then reformat the other in-camera card which had good material on it, and only then be told “the card you handed in is blank”.

Our solution is each operator has enough cards to shoot for 2-3 days, so we have an approx. two-day buffer in case of a processing error. We currently only use a single card in two-card cameras to prevent confusion. Yes each operator should know their own camera perfectly but that doesn’t always happen.