MacInTouch Amazon link...

Final Cut Pro/FCPX and video editing

Channels
Apple, Troubleshooting, Products

JDW

For the "corrupt media" theory to be sound, one would expect to see my "corrupt media" result in freezes regardless of the Mac on which it is used, but such is not the case.

My late 2015 iMac 5K never freezes in FCPX 10.4.x, even when I use 10-bit 4K HLG footage straight out of my GH5 without transcoding, but the same media will very quickly freeze my mid-2015 MacBook Pro 15" when using FCPX 10.4.x.

The data throughput on the internal Apple-branded 1TB SSD inside my mid-2015 MacBook Pro is 1510MB/s write and 1850MB/s read.

And as I said, I get no freezes in apps other than FCPX, not even in Compressor while compressing for several hours at a time, and while seeing both CPU and GPU utilized extensively via iStat Menus. But as I said, when I transcode to ProRES 422, it is very, very difficult to get the freeze in FCPX on the MacBook Pro. My iMac, however, doesn't care whether I transcode or not.
 


....
My late 2015 iMac 5K never freezes in FCPX 10.4.x, even when I use 10-bit 4K HLG footage straight out of my GH5 without transcoding, but the same media will very quickly freeze my mid-2015 MacBook Pro 15" when using FCPX 10.4.x.
If you are copying the "master" media from the camera to each Mac in question, I think the previous post was getting at the possibility that you are not necessarily processing the same file. One copy could be different from another if the media isn't recording properly.

One way would be to copy the MacBook Pro 'copy' to the iMac and repeat with that. Another 'in place' method would be to do a simple checksum on each copy. In a open Terminal app window, you can invoke md5. For example,
Bash:
md5   copy_of_video.mov
That will produce a long hex number. Each copy on the two systems should produce the same md5 hash.
 


JDW

I pretty much knew before I even tried the "use md5 in the Terminal" advice that my media is fine. How? If media is corrupt, I would expect errors when I transcode it, but such is not the case. Furthermore, the ProRES 422 media that is produced by transcoding won't freeze my MacBook Pro while being played back in FCPX 10.4.x, further giving evidence that the original media is sound. Nevertheless, I ran the md5 hash in the terminal on one original straight-out-of-GH5-camera clip that was stored on my MacBook Pro at home, and then I ran the md5 hash on a copy of the same media on my 5K iMac at the office, and the resulting number is exactly the same. So I think this definitively proves we are not dealing with corrupt media here.

In my opinion, the 2015 MacBook Pro 15" with M370X dGPU and FCPX 10.4.x simply doesn't like 10-bit HLG media straight out of the camera, and the bug in FCPX 10.4.x is that it freezes the computer during playback. If FCPX simply cannot handle that media for some reason, it should produce a dialog box saying so, rather than just freeze.

Once again, I have filed a bug report in the Developer Bug Reporter, but Apple stopped replying back to me quite some time ago, and in my experience, they probably won't offer me the courtesy of another reply. I also know that if I took my MacBook Pro to an Apple store, even if I told them of my bug report and this thread, they'd probably just try a hardware swap rather than investigate it possibly being a bug. And my guess is that even with a hardware swap, the problem would remain.

Surely there must be one among us who has a 15-inch MacBook Pro 2015-edition with M370X GPU and FCPX 10.4.x? I am happy to provide the aforementioned 10-bit HLG clip to that person so they could give it a test on their machine. And if their machine freeze,s too, that pretty much settles the matter -- it be clear evidence of a FCPX bug.
 


If you are copying the "master" media from the camera to each Mac in question, I think the previous post was getting at the possibility that you are not necessarily processing the same file. One copy could be different from another if the media isn't recording properly.

One way would be to copy the MacBook Pro 'copy' to the iMac and repeat with that. Another 'in place' method would be to do a simple checksum on each copy. In a open Terminal app window, you can invoke md5. For example,
Bash:
md5   copy_of_video.mov
That will produce a long hex number. Each copy on the two systems should produce the same md5 hash.
Another test would be to copy the "master" media file to an external drive, and then hook that drive to each computer so they are both getting access to the same "master." I'd use the laptop to do the copying from the camera, and then if that file has frozen FCPX, try the external drive on the iMac.
 


I pretty much knew before I even tried the "use md5 in the Terminal" advice that my media is fine....
I have 22 years of experience of computer / film editing. Technically, you might be on to something, but you are not ruling out the obvious first. Separate copies of media are not the same - even if they MD5 checkout. That's because you are dealing with drive (SSD) mechanisms, cables, chip sets, and "time" - meaning, with video, the frames are expected to play in real time, and MD5 comparisons do not test this. The best way to test the two machines is to have them play off that same set of drives (and even that doesn't rule out everything. (Bad Thunderbolt chip in the MacBook Pro? Bad Ethernet port / cable?)

One test I would run:
1) Can you get the MacBook Pro crash consistently on one piece of media or one place in the time line?​
2) Make sure this same piece plays properly on your iMac.​
3) From the iMac, copy just the files required to an external drive - media and project.​
4) On the iMac, hide video files. (Change the folder name? Not sure how FCPX works.)​
4a) On the iMac, make sure the new files play correctly.​
5) On the MacBook Pro, hide the video files. (Change the folder name? Not sure how FCPX works.)​
6) Plug the drive into the MacBook Pro. Now try it out the same file / sequence there.​
7) Does it beachball there?​

** You could copy the new files to the Internal MacBook Pro drive as well. Sounds like you have a fast drive in there. Test that as well.
 


Ric Ford

MacInTouch
... The best way to test the two machines is to have them play off that same set of drives...
One way to do that: Boot the MacBook Pro in Target Disk mode (with a Thunderbolt connection), then use that to boot the iMac. Then the only difference is the two computers themselves (and the Thunderbolt connection between them), not the files or drive.
 
  • appreciate
Reactions: JDW


One way to do that: Boot the MacBook Pro in Target Disk mode (with a Thunderbolt connection), then use that to boot the iMac. Then the only difference is the two computers themselves (and the Thunderbolt connection between them), not the files or drive.
That’s a great test as well.
 


JDW

Ric, I'll need to bring my MacBook Pro into the office to give your excellent advice a test. If I remember, I'll try to do that tomorrow.

Doug, I can get my MacBook Pro to crash consistently on any piece of 10-bit HLG footage from my GH5 that is not transcoded to ProRES 422. Editing the same media on my iMac normally does not crash, but when FCPX does crash on my iMac (and it does, albeit less rarely than my MacBook Pro), the crashes are comparatively nicer than the MacBook Pro freeze, and in one of two forms: (1) a beachball lockup that affects only FCPX and I can use force-quit and then relaunch, or (2) FCPX just up and quits! And that is with the same 10-bit HLG footage straight out of camera that is not transcoded. So to repeat, when my MacBook Pro freezes, it's a total freeze requiring shutdown, but my iMac's crashes affect only FCPX and no other apps.

So again, I'll give Ric's advice a try, booting my 5K iMac from the MacBook Pro's internal 1TB SSD in Target Disk Mode. I will then report back on that test. Thanks.
 


JDW

I just realized I don't have a Thunderbolt-to-Thunderbolt cable, so I just ordered one from Apple Japan. This will be a $35 test. I will do the Target Disk Mode test on Monday and then report back.
 


Sorry to be late to the discussion... I hope I've read the discussion well enough to understand the situation and offer some help....

Ric, David, Doug, Warren, Paul, and Lyman have provided some really useful general hardware and macOS troubleshooting info, with Doug and Warren providing some important info specifically related to using NLE applications like FCPX.

JDW, you first said that all forms of your footage crash your MacBook Pro but later stated that ProRes 422 transcoded footage works fine in FCPX (no crashes).

I suspect that your MacBook Pro probably hasn't got adequate resources to properly support HEVC in FCPX (a completely different thing to playing HEVC media in QuickTime Player or something similar). Your iMac is more capable, but still has problems with the native footage. Only 2017 and 2018 MacBook Pros and the new iMac Pro have official support for hardware encoding/decoding of HEVC/H.265 media. And, HEVC support is new in macOS 10.13, so there may be issues for other Macs that only support software playback.

One of my colleagues uses the lower-spec'ed 2015 MacBook Pro (2.5 GHz) with macOS 10.13 and FCPX 10.4.3 with the same kind of footage, without any issues. However, he follows a "best practices" workflow when using FCPX, which doesn't include using native H.264 or H.265/HEVC media. It's well known that H.264 or H.265/HEVC media at, or above, HD resolution, whether 8-bit or 10-bit, is to be avoided. My colleague also spreads the various FCPX file locations between an external, Thunderbolt 2 RAID and the internal SSD.

Apple provides somewhat misleading information when they list various camera/media formats as having "native editing support". It all depends on frame size, bit rate, bit depth, and codec used for encoding/recording footage, as well as the system configuration used to run FCPX. Lots of ambiguity there...

JDW, your current workflow is almost certainly going to result in performance issues with FCPX, with FCPX and macOS crashes likely to occur depending on a combination of factors: system configuration (RAM, CPU, GPU, disk/SSD) and the type of media you're using. It's not at all surprising that you are getting crashes with 4k/UHD footage and especially with a 10-bit variant. With your footage and the LUT you're applying, you are likely overloading your MacBook Pro's hardware resources. Yes, it would be nice if warning dialogs popped up, rather than FCPX or macOS freezing/crashing. Also, playback is part of editing, So, if that aspect is not smooth, then your entire editing experience is poor (and unacceptable).

From what you describe, you are not following best practices for dealing with H.264 or H.265 (HEVC) footage with FCPX. Yes, some combinations of bit rate, bit depth, frame size, and codec work on some systems but not others. Apple actually recommends that H.264 and HEVC/H.265 footage be transcoded or "optimized" before use in FCPX (see the footnotes for the list of supported cameras on Apple's website). Additionally, the use of "proxy" media in FCPX may be helpful, or required, to get a decent editing experience.

What you've described has happened to lots of people since 4K footage started to become more common a few years ago. Now, we're beginning to see HDR footage and more 10-bit variants and larger than 4K sizes, too. People would just "throw" their footage at FCPX and expect it to work without any consideration, often with poor results.

Another complication is created when you add your LUT to your footage in FCPX. It has to process that LUT information, adding to the stress on your system. The iMac you mentioned has at least twice the GPU bandwidth of your MacBook Pro (and more RAM). FYI, DaVinci Resolve has much higher system requirements, and, even so, doesn't play well with many camera-native codecs like H.264 or H.265. Your testing was with transcoded ProRes footage, with which Resolve works well.

It is also possible that some of your media is corrupt. Your FCPX library, an event, or project (timeline) could be corrupt, too.

You should consider changing your workflow to one that more closely follows commonly-used best practices. This would include using transcoded or optimized media, as well as the use of proxy media. Also, reworking storage locations to help reduce disk I/O bottlenecks is a good idea.

Here are some ways you can do this:
  • Transcode your footage to ProRes 422 prior to import into FCPX. EditReady ($50) is a wonderful application that can also apply your LUT during transcode; it's several times faster than Compressor. Or, use Compressor.
  • During import in FCPX, optimize the media. Or, you could choose to just create proxy media. Or, do both. This should drastically improve the editing experience and stop the "crashing" you reported (which is confirmed by your later testing with transcoded footage).
  • Optimize only clips you are using in projects (timelines). Or, create proxies.
  • You could apply your LUT in FCPX, then export optimized media with the LUT burned in, and reimport the media and use that.
  • ProRes is your friend. Use it always. It was specifically designed to provide the best editing experience possible. Don't ignore that. FCPX is not iMovie.
  • Consider separating your various media types in different storage locations (devices). There are good tutorials about this and other performance optimizations you can do in FCPX (see Ripple Training's offerings or get a copy of the Apple Pro Training Series book for FCPX --- they are two of the better options). FCPX-specific forums are also good places to get info (e.g., http://www.fcp.co/forum/index or http://www.lafcpug.org/phorum/list.php?19).
  • Take some time and learn about best practices when using FCPX. As you continue to edit more projects, you will come to the realization that working on a project with all media, and associated files, sitting on the system SSD/drive is not going to work well, if at all.
  • Double check your FCPX preferences. Check your project (timeline) settings where you use your footage.
You should continue to test working with transcoded footage, as well as considering the use of proxies in FCPX. Getting a fast external SSD or RAID, connected via Thunderbolt, and separating your media storage should also help. Only if these workflow changes don't work would I suggest you look further for system HW issues.

Sorry to repeat this... you should get into the habit of transcoding your media before use in FCPX, or utilize FCPX's built-in support for optimizing media, as well as using proxy media when beneficial.

If you work with ample knowledge of FCPX's strengths and weakness, you should find the process much more enjoyable...
;-)
 



Another vote for EditReady or ClipWrap from

Solved my FCPX slowness problems caused by using out-of-the-camera AVCHD in place on an iMac. Very fast, and the rewrapped media edits problem-free, including creation of four-angle multicam clips.

I remember Panasonic also had a free software transcoding tool (not sure if it is applicable to your camera or footage, and may be old), but I don't have a URL for that at the moment.
 


Another vote for EditReady or ClipWrap from
Solved my FCPX slowness problems caused by using out-of-the-camera AVCHD in place on an iMac. Very fast, and the rewrapped media edits problem-free, including creation of four-angle multicam clips.

I remember Panasonic also had a free software transcoding tool (not sure if it is applicable to your camera or footage, and may be old), but I don't have a URL for that at the moment.
Thanks, Ben. FYI, EditReady has "absorbed" all the functionality of ClipWrap, which is no longer being maintained.

I believe that you're right about the transcoding tool being "old" and no longer available (or needed)... that may have happened a few years ago. It used to be that older versions of FCP (≤ v.7) couldn't deal with certain media storage formats or some codecs.....
 


Mea culpa...
;-)

Even though I have the current version of EditReady, I don't use it quite as much nowadays. I have been able to get Compressor to run faster, so the speed difference between the two is negligible. Compressor has additional features not present in EditReady, such as advanced retiming, resizing, deinterlacing, etc.

However, only EditReady has the "LUT addition" feature (as far as I can tell)...
 


JDW

I finally was able to do my $35 test today, appropriately named in light of the cost of this extremely short (0.5m) and pricey Thunderbolt 2 cable I purchased from Apple Japan.

I put my 2015 MacBook Pro 15" in Target Disk mode, then launched FCPX 10.4.x on my late 2015 iMac 5K and created a new Event. I then imported, found the .mov file (straight out of the GH5 camera, not transcoded) on my MacBook Pro (mounted as a drive on my 5K iMac) and assigned that .mov file to be "left in place", so FCPX would have to read that file from my MacBook Pro's SSD -- the entire purpose of this test. I then applied my Rec.2020 to Rec.709 Leeming HLG conversion LUT v502 (as a Camera LUT), put the clip on the timeline and began editing and playback.

Playback was choppy, of course, and sometimes I would get temporary beachballs in FCPX, but I was always able to switch to other apps during those beachballs, and eventually the beachballs went away. Never once did my 5K iMac freeze akin to the complete freeze I get when using FCPX on my MacBook Pro using the same footage. And, yes I applied sharpening, adjusted color balance, duplicated clips and used masking, made multiple compound clips -- the works. I was maxing out my GPU and CPU the entire time on my 5K iMac, but again, my iMac never froze. (My MacBook Pro was running on battery power, just to let you know.)

So I hope my $35 test puts to rest the incorrect speculation that my media is bad or something is wrong with the SSD in my MacBook Pro. If my media was bad, all my media would be bad, since I get the complete freeze on my MacBook Pro with any clip pulled straight from my GH5.

DaveM, I appreciate all you wrote. For the record, I have never edited HVEC H.265 footage. The 10-bit HLG .mov files out of my GH5 are H.264. I can easily verify that by selecting the file in the Finder and doing Get Info. It says they are H.264.

The summary of what you wrote, as my brain interprets it is this, and I quote:

"ProRES is your friend. Use it always."

And of course, SSD-space willing, I shall try. But the fact remains that all my testing to date has proven there is a bug in FCPX that seems to affect the 2015 MacBook Pro 15" (and perhaps other Mac models), such that the MacBook Pro freezes completely during playback of 10-bit H.264 4K footage during editing. And like I said, I've filed a bug report with Apple via their Developer Bug Reporter. Whether Apple is giving it a serious look or not is something none of us know. But I do hope that regardless of whether I use ProRES or not, Apple will fix FCPX so that if it ever gets over-taxed on a particular Mac, it will just stutter or throw up a dialog rather than freeze. The fact that it freezes in an unrecoverable way is the bug.

My thanks to everyone who contributed to this discussion. I found all your input very helpful, even if it doesn't fix the core bug in FCPX 10.4.x. Best wishes to one and all.
 


Note the H.265 caveat there - in other words, highly compressed video. That's the opposite of what Apple touted in its 2019 Mac Pro launch, power to handle native raw (uncompressed) video
The H.265 note sent me on a search for what that means "in real life." And that search turned up a site discussing in some detail the inter-relationships of hardware choices for video editing. Even though it's an article focused on Windows, PC hardware, and Adobe Premiere Pro, I found it instructive on the general topic of video editing hardware, and it does strongly recommend NVMe over SATA.
CGDirector said:
Best Computer for Video Editing (Updated) [June 29, 2019]
Let’s start with putting a Samsung 970 PRO 1TB into our Best Computer for Video Editing. That way we should already be able to rule out the storage medium as a bottleneck.
Referring back to the Mac Pro:
Apple touted in its 2019 Mac Pro launch, power to handle native raw (uncompressed) video
From several third party reports, that's not inherent to the Mac Pro itself, but reliant on the "Afterburner" add-on card, which, like the stand, costs extra (and likely a lot extra).
Y.M. Cinema Magazine said:
Apple’s Mac Pro Afterburner: The Mysterious Card to Enhance 8K RAW Editing
With Afterburner, video editors using high‐quality cameras that require the conversion of native file formats into proxies for easy editing can now use native formats right from the camera and decode up to three streams of 8K ProRes RAW video and 12 streams of 4K ProRes RAW video in real time..
This is unfortunately taking me deep into terra incognita, but my searches also found this:
Cinema5D said:
Faster 8K Editing with NVIDIA Quadro RTX and Turing Architecture (Aug. 15, 2018)
NVIDIA presented some big news: their newly developed GPU architecture called Turing and new NVIDIA Quadro RTX graphic cards, which are the first GPUs based on the Turing architecture. These new cards aim to ease 8K workflows and NVIDIA worked closely with RED to optimize and test the results with the REDCODE RAW file format. The new Quadro RTX GPUs should allow editing 8K footage in full resolution, in real time.
And this from April 25, 2019
Cinema5D said:
RED’s Easier 8K Workflow with Realtime GPU Decode and New REDCINE-X Pro
RED digital cinema announced the release of SDK for NVIDIA CUDA R3D decoding as well as new version of the REDCINE-X for Windows. These new updates should significantly improve 8K real-time playback and editing by utilising the power of GPU. The new version of REDCINE-X PRO (for Windows) will decode and debayer 8K RED RAW footage much faster.
The RED/Nvidia announcements precede "Afterburner." Perhaps "Afterburner" will be a lot more powerful, but from what's in the linked articles, there seems a lot of similarity in purpose.
 


I started many years back with FCP X 10.04 on Mac OS X 10.6.8 (2011 MacBook Pro 17-inch) and did a ton of editing for my websites and YouTube but haven't had any pressing editing needs the last four years or so. When I went to macOS Sierra, I also upgraded FCP X to 10.4.

The last couple of weeks I started editing some live music video footage shot in 1080p 29.97 and .mts format. It was really, really, really slow. I figured since the OS and QuickTime Player understood the .mts format now, FCP X must understand the format by default, too. I was wrong.

I muddled through an edit or two and tried using a proxy file, which certainly did help, but something still seemed wrong. My immediate reaction was that Apple must be trying to force me to buy new hardware (which won't be happening anytime soon - I still have two of the 2011 MacBook Pros). After more thought, I figured I'd try my old ClipWrap app for a quick re-wrap test, which was a must-do back when I was editing a lot in Snow Leopard. It worked great!

I also found out that my old ClipWrap app became EditReady2. I don't see any pressing reasons to upgrade ClipWrap (for $30), so I guess I'm good to go.

My question at this point is that, if any one is using FCP X 10.4.x on High Sierra or Mojave or Catalina Beta, do the default .MTS files work any better without using proxy files, optimizing, or re-wrapping them in a .MOV container? I don't have any immediate reasons to go above Sierra right now, but I was just curious. Thanks.
 


I started many years back with FCP X 10.04 on Mac OS X 10.6.8 (2011 MacBook Pro 17-inch) and did a ton of editing for my websites and YouTube but haven't had any pressing editing needs the last four years or so. When I went to macOS Sierra, I also upgraded FCP X to 10.4. The last couple of weeks I started editing some live music video footage shot in 1080p 29.97 and .mts format. It was really, really, really slow. I figured since the OS and QuickTime Player understood the .mts format now, FCP X must understand the format by default, too. I was wrong.
When you previously used FCPX, what kind of footage were you editing? Does your MacBook Pro have a functional discrete GPU? Have you replaced the hard drive with an SSD?

FCPX still supports .MTS files (which are AVCHD files with H.264 video and AC3 or PCM audio).
I muddled through an edit or two and tried using a proxy file, which certainly did help, but something still seemed wrong. My immediate reaction was that Apple must be trying to force me to buy new hardware (which won't be happening anytime soon - I still have two of the 2011 MacBook Pros). After more thought, I figured I'd try my old ClipWrap app for a quick re-wrap test, which was a must-do back when I was editing a lot in Snow Leopard. It worked great! My question at this point is that, if any one is using FCP X 10.4.x on High Sierra or Mojave or Catalina Beta, do the default .MTS files work any better without using proxy files, optimizing, or re-wrapping them in a .MOV container? I don't have any immediate reasons to go above Sierra right now, but I was just curious. Thanks.
In FCPX, "optimizing" media on import, or afterwards, transcodes media using ProRes 422. The "proxy" setting (on import or afterwards) creates ProRes 422 Proxy files at half-resolution (frame size).

However, you do need to make sure that either proxy or optimized media is selected for use in FCPX, or it isn't used. Note that these operations are done in the background by default and can take some time (during which, performance is further reduced because of the background rendering/transcoding).

Using something like EditReady (nee ClipWrap) to convert media into ProRes or DNx formats (similar to the built-in methods in FCPX described above, albeit with options for customization), provides a way to do the transcoding outside of FCPX.

I suspect that to get any sort of decent performance on that old 2011 MacBook Pro, you will need an SSD for media storage and a working discrete GPU (not the integrated Intel GPU). Additionally, you should only use some flavor of ProRes 422, ProRes 422 LT, or ProRes 422 Proxy, preferably at a fractional frame size. When you're finished editing, you can let a project render at a higher quality, if you really need it.

Though the marketing types like to say that H.264 or HEVC (H.265)-based codecs work in iMovie or FCPX, in reality those codecs are really resource intensive and best to avoid.
 


Saw a movie review of a new film that was "shot" in digital iMax 6K. Tried to find out what that means in terms of the discussion of transferring raw video to be processed. The camera was an ARRI Alexa 65 with proprietary changes for iMax. It records to a PCIe drive, either 1 or 2 TB.
ARRI said:
Codex SXR Capture Drive® 1TB
High-performance solid-state drive with 1 TB (960 GB usable) capacity in a rugged aluminum casing. Transfer speed up to 20 Gbps. Recording capacity at 24fps: ARRIRAW approx. 58min 3.4K OG, 32min 4.5K OG Apple ProRes 444 approx. 52 min 16:9 4K UHD
ARRI said:
Codex SXR Capture Drive® Dock (TB3)
Single-slot desktop dock to access Codex SXR Capture Drives® or Compact Drives™ via macOS. Dual Thunderbolt 3 interface for maximum transfer speed (backwards compatible) and daisy chaining option.
 


Great questions and thoughts, Dave M, and I will answer them one by one...
When you previously used FCPX, what kind of footage were you editing? Does your MacBook Pro have a functional discrete GPU? Have you replaced the hard drive with an SSD?
These are the same .MTS files from the exact same old S100 Vixia HD Canon camera. Yes, all my laptops have SSDs now. On my main 2011 MacBook Pro, I also took out the optical disk drive and replaced it with a Samsung 1TB SSD a few years back which is dedicated for FCP X editing (i.e. media files and FCP X Libraries).
FCPX still supports .MTS files (which are AVCHD files with H.264 video and AC3 or PCM audio).
Actually, FCP X did not support .MTS back when it first came out (v 10.0.x), or at least my Canon .MTS files were not supported. I was forced to use ClipWrap. I have actually never had a problem, though, in FCP X with standard H.264 files, like ScreenFlow screen captures. I could/can edit them without optimizing or using proxy files.
However, you do need to make sure that either proxy or optimized media is selected for use in FCPX, or it isn't used. Note that these operations are done in the background by default and can take some time (during which, performance is further reduced because of the background rendering/transcoding).
Yes, absolutely. For new editors out there, the option to switch from Optimized/Original media to Proxy media is found in the upper right corner of the Viewer window in the drop down "View" menu. (Important note: if you are using Proxy media to speed up editing, remember to switch back to "Optimized/Original" media before doing a final export, otherwise the export won't be at its highest quality.)
I suspect that to get any sort of decent performance on that old 2011 MacBook Pro, you will need an SSD for media storage and a working discrete GPU (not the integrated Intel GPU).
I do have both discrete and integrated graphics on these 17" 2011 MacBook Pros. I use a great little app called "gfxCardStatus", which displays exactly which card is being used at the moment. When FCP X opens, you can see it switch to the discrete card vs. being on the default Intel integrated card. It's very handy to have, especially since both these 17" 2011 MacBook Pros have had multiple logic board replacements, due to the failure of the "discrete" AMD Radeon HD 6750M graphics.
When you're finished editing, you can let a project render at a higher quality, if you really need it.
Agreed. Unless I really need to see something as it should be while editing, I rarely bother to render. I know what the final version will look like. Since rendering is part of the final export process, it's not worth my time. My tests have shown that rendering before exporting doesn't even significantly speed up the export process. On the other hand, I don't ever do long movie-length projects or anything above 780p or 1080p timelines and don't have clients who want to view the progress of the edit. If I did, I would likely render throughout the editing.
Though the marketing types like to say that H.264 or HEVC (H.265)-based codecs work in iMovie or FCPX, in reality those codecs are really resource intensive and best to avoid.
I'm still on Sierra, so I don't have any experience yet with HEVC files, but as I mentioned above, I don't have any significant slowdowns when editing raw H.264 files, like screen captures.
 


Ric Ford

MacInTouch
Codex SXR Capture Drive® Dock (TB3)
Single-slot desktop dock to access Codex SXR Capture Drives® or Compact Drives™ via macOS. Dual Thunderbolt 3 interface for maximum transfer speed (backwards compatible) and daisy chaining option.
I was curious about whether this device could transfer over two Thunderbolt 3 ports simultaneously for faster performance, but I couldn't find any details about it.

I'm guessing it probably can't, but it seems like it might theoretically be possible. I suppose a good test would be hooking up two Samsung X5's to two Thunderbolt 3 ports, using SoftRAID to create a RAID-0 configuration, and testing performance, which probably depends on exactly which Thunderbolt 3 ports are used on the computer, as well as what else is plugged into the computer.
 


I was curious about whether this device could transfer over two Thunderbolt 3 ports simultaneously for faster performance, but I couldn't find any details about it. I'm guessing it probably can't, but it seems like it might theoretically be possible. I suppose a good test would be hooking up two Samsung X5's to two Thunderbolt 3 ports, using SoftRAID to create a RAID-0 configuration, and testing performance, which probably depends on exactly which Thunderbolt 3 ports are used on the computer, as well as what else is plugged into the computer.
From what I've (recently) learned about how (Hollywood type) movies are made, relatively short segments (scenes?) are shot and, from cameras like the ARRI, viewed as they're shot, then possibly reviewed on set after shooting, then the "film = SSD" is exchanged, set aside, and, based on my experience with stuff going bad, likely backed up ASAP. Shooting then picks up with a fresh SSD.

The ARRI itself can write only so fast to its SSDs, the speed limit implied by "transfer speed up to 20 Gbps." Don't know if that limit applies to downloading from the drive connected through the Thunderbolt 3 ARRI dock. Per this "File Transfer Time Calculator", unloading 960 GB at the 20Gbps Thunderbolt 2 speed would require 6m 24s and just 3m 12s over Thunderbolt 3. A job for an eager and possibly unpaid intern?
 


Great questions and thoughts, Dave M, and I will answer them one by one...
I, too, have a 17" 2011 MacBook Pro (with an SSD). I've never had any graphics problems, so it's as it was when I bought it (save the SSD). I also have gfxCardStatus.

I've only used .MTS files from Panasonic cameras, so I don't know if the Canon variants were more or less problematic. Since I used FCP 7 until 2016 (though I had started using Resolve a year earlier), I only began using FCPX at version 10.3.x. I also used EditReady/ClipWrap in many instances.

On occasion, I edit some screen capture video in ScreenFlow itself, without issue (on my 2011 MacBook Pro). I otherwise tend to transcode everything into ProRes when editing in FCPX (or Resolve).

I wonder if FCPX is more resource-intensive now, at version 10.4.x. Or, perhaps there may have been earlier 10.4.x versions that had issues with certain codecs. Because I wanted to be able to use FCPX 10.4.6 (for new/improved features, like subtitles, captions, and metadata), I upgraded my MacBook Pro and 2012 Mac Pro to High Sierra. In doing so, I lost the ability to use a second GPU with my Mac Pro. I am eagerly waiting to move to newer hardware this fall.

I haven't heard about any issues that might make High Sierra worse than Sierra, with respect to using FCPX or your MacBook Pro, especially if you want to go to FCPX 10.4.6.

I know I didn't definitively answer all your questions...
 


Ric Ford

MacInTouch
Per this "File Transfer Time Calculator", unloading 960 GB at the 20Gbps Thunderbolt 2 speed would require 6m 24s and just 3m 12s over Thunderbolt 3.
Those are grossly unrealistic times. If you can get speeds like that copying files from one Mac drive to another, let me know how you managed it!

Carbon Copy Cloner took 2 hours 28 minutes to copy 870 GB from a fast internal SSD to an external (USB 3.0) SSD for one of my backups. Even if Thunderbolt 2 were actually delivering data at 20Gbps, which it won't, it would still take 40 minutes with a 4x Thunderbolt 2 speed boost over USB 3.0 to back up 960GB. In reality, it would probably be more like 10x the time that calculator cited for Thunderbolt 2. (Obviously, different file types and data transfer software could have major effects on results.)

Just did a quick test*, using dd to copy a single 3.6GB file from internal SSD to a Samsung T5 on USB 3.0 (2015 MacBook Pro, macOS 10.12):

116 MB/sec.

Same test, but with Thunderbolt 3 (Samsung X5), a faster internal SSD, and a faster computer (2017 iMac 5K):

193 MB/sec.

Those tests had FileVault enabled on all volumes. Switching to an unencrypted Thunderbolt 3 (Samsung X5) target, speed improved a little:

207 MB/sec.

Copying the drive from one internal SSD volume to another gave the same speed, interestingly:

207 MB/sec.


*Here's the test:
Bash:
sudo time dd if=~/3.6GBsourcefile of=/Volumes/external/copyfile
 


Since I used FCP 7 until 2016 (though I had started using Resolve a year earlier), I only began using FCPX at version 10.3.x.
I went from FCP 7 to FCP X the month that X was released and hadn't spent enough time in FCP 7 that the move was all that painful for me. I stayed with FCP 10.0.4 for many years and then briefly moved to 10.3.x and then moved to 10.4.0. I can't go any higher than 10.4 since I'm still on Sierra. (Libraries were a big shock to me after all the time spent with Events and Projects, but now I'm happy with the change).

On a related topic, how did you like Divinci Resolve? Are you still using it? If not, why?

I still have the dream that someday I can completely dump Apple and move to PC hardware and Linux Mint, but I can't work without Logic X or FCP X at this point. I've downloaded Resolve, but haven't really had a chance to play around with it. And, there is no equivalent for me for Logic X on Linux, so I may be with Apple for the foreseeable future.
 


I went from FCP 7 to FCP X the month that X was released and hadn't spent enough time in FCP 7 that the move was all that painful for me. I stayed with FCP 10.0.4 for many years and then briefly moved to 10.3.x and then moved to 10.4.0. I can't go any higher than 10.4 since I'm still on Sierra. (Libraries were a big shock to me after all the time spent with Events and Projects, but now I'm happy with the change). On a related topic, how did you like Divinci Resolve? Are you still using it? If not, why? ...
I stayed with FCP 7, because the initial releases of FCPX were missing features I needed. I began to learn Avid Media Composer and then Resolve, buying a Studio license (when it was still $999). I learned to use these other NLEs in anticipation of a possible move away from FCP.

When FCPX 10.3 was released, I found I could do most everything I needed in FCPX, so I decided to give it a try. I really like the magnetic timeline in FCPX (my biggest frustration working on projects with many dozens of tracks was that I might mistakenly move clips or tracks out of synch with the rest of the timeline). I really started to like FCPX even more when 10.4 and subsequent updates came out.

However, I was also growing increasingly frustrated with Apple's lack of a new pro machine and lack of real support for professionals. Had Apple not make the huge change of direction in introducing the new Mac Pro this year, I would now be leaving Apple behind for a Linux or Windows PC (though, reluctantly, after having almost exclusively used Macs since 1986).

I really like the fine level of granularity in the functionality of Resolve. It's a very nice NLE, and its only downside really is that it requires a very robust hardware configuration to work well. I do use the Color Page a bit for things that can't be done in FCPX.

With Fairlight in Resolve maturing quickly, you may soon have the option of a full-featured audio workstation that can run on Linux.
 



I appreciate you taking the time to post a brief history of your involvement with FCP X and Macs. I also started with Macs in about 1986 with a Mac Plus.
I really like the fine level of granularity in the functionality of Resolve. It's a very nice NLE, and its only downside really is that it requires a very robust hardware configuration to work well. I do use the Color Page a bit for things that can't be done in FCPX.
I have Resolve but have not spent enough time in it to get a feel for whether I like it or not. I, too, am a big fan of the FCP X magnetic timeline.
With Fairlight in Resolve maturing quickly, you may soon have the option of a full-featured audio workstation that can run on Linux.
That's great to hear! I will definitely keep my eye open for that.
 


Amazon disclaimer:
As an Amazon Associate I earn from qualifying purchases.

Latest posts