[Joe Marler]

[Gary Huff] “Actually, the MJPEG codec is quite efficient as far as CPU decoding power. “

By “inefficient” I meant the normal use of the term in codec technology. E.g, the “HE” in HEVC means “High Efficiency”. This means coding efficiency, not computational complexity. MJPEG is invariably described in the industry as “inefficient”.

However the term as I used it could be misleading. The difficulty the OP stated was more likely due to an I/O limitation than a CPU limitation. The low coding efficiency may have increased the I/O rate such that performance lagged.

In my tests of 500 megabit/sec 4k MJPEG material from a Canon 5D4, the playback CPU levels are lower than 300 megabit/sec 4k H264 intra material from a Canon XC15. However the 5D4 MJPEG content required an average of about 60 megabytes/sec just to play at 1x, whereas the 4k H264 intra content only required about 40 megabytes/sec.

Both of those 4k codecs can be smoothly edited in FCPX on a 2015 iMac 27 without using proxy — given a good disk subsystem. They are vastly smoother than typical 4k H264 long GOP interframe material.

So if he cannot smoothly edit the 5D4 500 megabit/sec MJPEG material, he either needs to upgrade his computer, his hard drive, or transcode to proxy.

Even though the 5D4 has been slammed for using the MJPEG codec, it is actually roughly equivalent in coding efficiency and quality at a given bit rate vs H264 intra, and even better in some cases. I think what people really wanted was an interframe option which would lower the bit rate yet preserve a lot of the image quality for many scene types. But in the OP’s case that would likely have not changed his situation, as it would have then lagged from inadequate CPU instead of inadequate I/O. In either case he’d probably have to transcode to proxy.

See below paper “Performance evaluation of Motion-JPEG2000 in comparison with H.264/AVC operated in pure intra coding mode” (Marpe, et al, 2004):

https://pdfs.semanticscholar.org/c536/1ffbae7992e26a934682ca4892d066005cc2.pdf

[Joe Marler]

[Claude Lyneis] “I have been thinking about upgrading to a 4k camera and a new high end iMac, but not sure 4k is worth it, since I am my own client. The idea of buying a 4 k camera would “future proof” it for a while, but I seem to buy cameras about every three years anyway. How fast is 4k or about catching on? Certainly slower that the transition from analog to SD to HD.”

My doc team transitioned to all 4k about two years ago. The decision was not about distribution resolution but primarily about reframing in post, improving shelf life of footage, and ability to take 8 megapixel frame grabs. We don’t distribute in 4k.

For productions of significant size, 4k can be an *immense* burden in post. If the acquisition codec is long GOP H264, this usually requires transcoding to proxy for smooth editing. If acquisition is in ProRes or DNxHD, this may avoid transcoding but increases storage size by typically 6x to 8x.

Of course years ago we transcoded everything to a “mezzanine” codec and that was the accepted practice. However since around 2009 or 2010 Premiere became fast enough to edit most camera-native formats including DV and 1080p H264 without transcoding. Even today on Adobe’s web site, the Premiere intro video says: “allows editors to work with 4k and beyond, without time-consuming transcoding”, and “never needing to render until your work is complete” : https://helpx.adobe.com/premiere-pro/how-to/what-is-premiere-pro-cc.html?set=premiere-pro–get-started–overview

FCPX users also got used to similar performance. However this mostly came to an end with 4k long GOP H264, which is why Adobe fairly recently added proxy capability. Whether you use Premiere or FCPX — if you’re accustomed to 1080p, 4k is just a huge burden in post if you shoot much of it.

If you accept the space and time requirement to transcode, then almost any computer can edit 4k in proxy mode. But if you want a computer that edits H264 4k with the comfortable, easy workflow of H264 1080p, that is a tall order indeed. The new top-spec 2017 iMac 27 is the only computer I’ve used that is remotely fast enough to edit 4k long GOP 4k single-camera material without transcoding on FCPX, and even it is a bit laggy. On the Windows side you could probably build a workstation that would do this in Premiere or Resolve but it might be expensive. Resolve has recently made great performance improvements so that might be an easier path forward.

Good quality 1080p is very good indeed. The problem is 4k is like color TV was in the 1960s — it’s an unstoppable tidal wave of inevitability. But this doesn’t mean you should jump to 4k without a good reason. Nowadays a fairly high % of audience views content on mobile devices or laptop computers. I doubt many of those can see the difference between 1080p and 4k from a resolution standpoint.

[Joe Marler]

[Oliver Peters] “Looking for opinions from those who have done the comparisons. Using a newish, loaded MBP as your main computer versus an older cheese grater MP. Figure the laptop would have an external display and some external drives. How would the MBP compare? FCPX?”

I have a top-spec 2016 MBP, 2015 and 2017 iMac 27, and just finished testing a 12-core Mac Pro D700 on FCPX 10.3.4 and some on Premiere CC 2017.1.2. Below are some numbers. In general I greatly prefer a desktop machine to a laptop except where portability is absolutely required. Even with an external monitor for the laptop, the desktop is generally faster and quieter. That said, in one test my 2016 MBP was faster on FCPX than my 2015 top-spec iMac 27, but the 2017 iMac 27 was yet faster. For those who must do significant editing in the field, there are some good laptops.

FCPX BruceX benchmark:

iMac 27: 26.9 sec
Mac Pro: 17.0 sec
2017 iMac 27: 15.8 sec
2016 MBP i7: 36.2 sec

FCPX timeline render, Neat Video 4.5.5 NR on 31 sec XAVC-S 4k (after using Neat Video optimization to select best CPU/GPU combination):

2013 Mac Pro (12 cores and 2x D700 GPUs used): 6 min 58 sec
2015 iMac 27 (5 cores and M395X GPU): 9 min 7 sec
2017 iMac 27 (7 cores and R9 580 GPU): 8 min 3 sec
2016 MBP i7 (5 cores and Radeon Pro 460 GPU): 12 min 12 sec

FCPX Import & create proxies for ten XAVC-S 100 mbps H264 4k files from Sony A7RII, total media duration 11 min 43 sec

2015 iMac 27: 5 min 37 sec
2017 iMac 27: 2 min 40 sec
2016 MBP: 3 min 46 sec
(I didn’t do this on the Mac Pro but other similar tests show it is 1.9x slower than the 2017 iMac i7 on this task)

FCPX and Premiere CC: Export 1 min 51 sec 4k H264 XAVC-S media from timeline to single-pass 20 mbps H264 4k output

FCPX, 2015 iMac 27 i7: 1 min 21 sec; CPU levels: moderate, noise & heat: low
FCPX, 2017 iMac 27 i7: 1 min 8 sec; CPU levels: moderate, noise & heat: low
FCPX, 2016 MBP i7: 1 min 24 sec; CPU levels: moderate, noise & heat: low

Premiere, 2015 iMac 27 i7: 4 min 43 sec; CPU levels: high, noise & heat: high
Premiere, 2017 iMac 27 i7: 4 min 11 sec; CPU levels: high, noise & heat: high

[Joe Marler]

[Hakan Tanak] “I have Canon 5D mark 4 and it can shoot 4K videos in MJPEG format. When i tried to edit this videos in FCPX video seems laggy and not smooth. I think it’s about for MJPEG format because it’s normal in the camera screen.”

As Jeff said, this is likely due to the inefficient 500 mbps MJPEG codec that Canon uses for 4k on the 5D Mark IV. Normally when you use a high bitrate intra-frame codec, you have the hope of editing that directly without transcoding. E.g, I can edit 300 mbps 4k H264 intra-frame material from the Canon XC15 on my iMac in FCPX without transcoding — it is very fast.

If you can’t edit the native 500 mbps codec, that unfortunately seems the worst of both worlds — you pay the price for a high bit rate yet still must transcode to proxy for editing.

However it’s conceivable that you’re facing an I/O problem due to the high bit rate, not a CPU problem. If you examine your CPU state when editing that 5D4 material and they are low, then a faster bandwidth disk might help, or SSD. But if they are high it’s a CPU limitation and the only solution is proxy.

The benefit of proxy is you can try it right now without buying anything, but it will take time and disk space to create. I’d definitely suggest trying proxy not optimized media. Optimized media would further aggravate the space consumption problem of that MJPEG codec.

[Joe Marler]

[Ken Bennett] “running FCPX’s Share as H.264 Better Quality, for rendering an MP4 file, will cause my iMac to crash and reboot. I’ve done it 6 times in the past 12 hours. If I set it to H.264 Faster Render it works fine.”

What Oliver said is a good guess. When you render in H.264 Better Quality, I don’t think that uses Quick Sync. Without that the CPU is under more stress which generates more heat. The GPU must also be used to render any GPU-implemented effects before encoding. You are rendering and encoding a long timeline. A heat-related intermittent component or circuit board problem would be consistent with these symptoms.

As already mentioned your best near term workaround might be exporting to ProRes and if that works transcoding it externally to H264. However that also might cause the OS crash, and if so you could transcode it on another machine.

Another possibility is you’re running out of disk space and during the render & export, it is destabilizing the operating system. The OS should handle that gracefully but no OS is perfect, not even macOS. It wouldn’t hurt to verify you have plenty of disk space on all volumes and maybe run Disk Utility First Aid on all volumes.

This very unlikely a bug in FCPX (or any other app) as each process exists in a separate address space and normally cannot crash each other or the OS.

You can run Apple Diagnostics, but if it’s an intermittent problem that only happens after prolonged stress, it won’t find it. The Genius Bar can run overnight bench diagnostics which stress the machine a lot more and can find intermittent problems.

[Joe Marler]

[Oliver Peters] “Here’s the full detail for folks who don’t know:

https://digitalfilms.wordpress.com/2017/06/24/baby-driver/“

https://www.panavision.com/bill-popes-cinematography-baby-driver-has-panavision-under-hood

It appears this movie was shot on film, not digital. The Panaflex Millennium XL2 camera has a video tap which was run through an In2Core QTake encoder, apparently producing 2k ProRes output for editing on Avid: https://qtakehd.com/

[Joe Marler]

[Oliver Peters] “Both FCPX and Resolve 14 are looking strong on the newest iMacs.”

I just tested FCPX 10.3.4 on a 2015 vs 2017 top-spec iMac 27. The 2017 is much faster in some FCPX workflows, far more than synthetic benchmarks would indicate. It is about 2x faster to transcode 4k H264 long GOP to ProRes proxy, and about 2x faster exporting to 4k H264.

When editing 4k H264 long GOP on a timeline without proxy or optimized media, the viewer frame rate is much faster — it’s hard to quantify and it likely varies with the exact codec variant, but it seems about 3x faster. For the first time on any hardware or editing software I’ve tested, it’s fast enough to edit single camera 4k H264 long GOP without proxy. Editing two-camera 4k H264 multicam on the 2017 is faster than single-cam on the 2015 model.

Compared to the 12-core D700 nMP I tested recently, the 2017 iMac feels much faster on H264 workflows. The nMP still has an advantage if doing ProRes acquisition (so you don’t have to transcode) and if maintaining an all-ProRes workflow.

Ironically (despite its faster GPU) the 2017 iMac isn’t that much faster than the 2015 on several FCPX effects I tested.

Under heavy CPU load the cooling fan on the 2017 iMac does spin up to 2700 rpm quicker, but the CPU temps never get about about 70C during FCPX transcoding. However for some workloads it is working twice as fast, so for me that’s an OK tradeoff. My desk is stacked with spinning Thunderbolt drive arrays and they all make noise. For someone doing sustained high-CPU work with only SSD storage in a quiet room, it might bother them.

Other tests:

Neat Video 4.5.5 on 31 sec clip of 4k XAVC-S from Sony A7RII (each optimized using Neat Video config utility for optimal CPU/GPU split):

2013 12-core Mac Pro D700: 6 min 58 sec
2015 iMac 27 i7: 9 min 7 sec
2017 iMac 27 i7: 8 min 3 sec

Digital Anarchy flicker reduction on 12-sec H264 4k from DJI Phantom 4 Pro:

2013 12-core Mac Pro D700: 9 min 6 sec
2015 iMac 27 i7: 9 min 15 sec
2017 iMac 27 i7: 7 min 38 sec

BruceX FCPX benchmark (each average of two runs)

2013 12-core Mac Pro D700: 17.0 sec
2015 iMac 27 i7: 25.8 sec
2017 iMac 27: 15.8 sec

FCPX sharpen effect on 31 sec H264 4k XAVC-S clip, timeline render:

2013 12-core Mac Pro D700: 27.7 sec
Using ProRes optimized media: 12.1 sec

2015 iMac 27: 21.2 sec
2015 iMac 27 ProRes: 24 sec
2017 iMac 27: 20.3 sec
2017 iMac 27 ProRes: 23.8 sec

FCPX aged film effect on 31 sec H264 4k XAVC-S clip, timeline render:

2013 12-core Mac Pro D700: 30.45 sec
Using ProRes optimized: 21.8 sec

2015 iMac 27: 35.3 sec
2015 iMac 27 ProRes: 47.3 sec
2017 iMac 27: 29.8 sec
2017 iMac 27 ProRes: 37.8 sec

[Joe Marler]

[Jeff Kirkland] “I thought it was the media format rather than anything of Apple’s doing. Can any NLE edit AVCHD or XAVC without rewrapping it?…”

FCPX itself can import these “in place” without rewrapping — just not if the video files are within the original folder tree. This works for XAVC-S and XAVC-L. I haven’t seen any problems on XAVC-S but I haven’t tested XAVC-L as much. In general moving video files out of the folder is considered poor practice but the current FCPX behavior encourages this because it won’t import them “in place” from a folder tree on the hard disk.

It technically also works for AVCHD but there is a hidden problem whereby those bare .MTS files may cause performance problems. Referencing those files in the Event Browser (which doesn’t require clicking on them — just scrolling a window where they exist) may cause excessive I/O, slowing the performance of the entire event. It may be repeatedly rewrapping those files upon each reference, but that’s just a guess. The solution is rewrap the AVCHD files with EditReady before importing with “leave files in place”.

To my knowledge Premiere doesn’t have any of these problems, although I haven’t tested it as much.

[Joe Marler]

[Jacqueline Nauman] “My usb hub is AC plug-in powered, so not sure why I’m having so many issues with it. Seems to only happen if I am using more than one of the external drives at the same time. “

This is likely because the USB chip used by the hub manufacturer does not support the same DC current as the Apple USB ports. They may also have an aggregate limit on DC current to all ports on the hub. They probably took a design shortcut and used a cheap USB chip, which despite the hub’s external AC power, has this limitation.

This same situation exists on some USB 3 hyperdocks for the new MacBook Pro. Despite drawing power from two 15-watt USB-C ports on the MBP, they are not properly designed to provide adequate power to the USB-A output ports on the dock. Hence if you try to use two bus-powered USB drives via a hyperdock or USB-C-to-USB-A hub, they may drop off line.

From a consumer standpoint this is a difficult area because few reviewers understand this or test for it.

[Joe Marler]

In the 4k era, using proxies is more important than ever. Likewise maintaining a “lean library” for collaborative remote editing is also more important than ever, as is using a proxy-only workflow.

The current product does not well support using these together. Relink is unreliable when using external proxies and can lock up the app. The only workaround is rename the portable drive volume name to match the original volume name where the proxies were generated. There is also no built-in UI support for non-video elements such as graphics or audio in a proxy-only workflow.

Since proxies are stored by default in the library they must be created or moved outside the library to keep the size small and portable. There is no direct UI support for this but requires a cumbersome, error-prone procedure which is discussed in Ripple Training’s 10.3 Media Management Class. There are hack workarounds such as manually moving proxies outside the library and recreating aliases but procedures like this should not be necessary: https://www.fcp.co/final-cut-pro/tutorials/1828-cheating-final-cut-pro-x-proxies-to-store-where-you-want-by-using-aliases

There should be well-thought-out direct UI support for external proxies and proxy-only workflow, also relink should be more reliable and not choke when using external proxies and a different volume name.