[Joe Marler]

[Ray Sherman] “…I also plan on exporting native 4K when not in a mixed format envirement…”

If you need 4k export you have two options, both of which will preserve the full 4k resolution for a crop/zoom:

(1) Edit the 4k material in a 1080p timeline (aka project) as described above, then when you are finished, copy/paste the entire timeline into a 4k project and export from that. Otherwise you can only export at the 1080p max project resolution.

(2) Edit 4k material in a 4k project and export from that at 4k. Editing performance won’t be quite as fast but if you are using proxy it likely won’t matter — it will be fast enough.

[Ray Sherman] “My 4K media is MXF H.264. With that being said, do you feel that I should rewrap my 4K as well or just use it native in FCPX?”

Provided you have installed Apple Pro Video Formats 2.0.5, FCPX should be able to handle MXF OK: https://support.apple.com/kb/DL1898?locale=en_US

However MXF media cannot be imported “in place” from a copy of the original card structure. You can theoretically copy the .MXF files outside the structure and import it in place from that location, but that is considered a poor practice and risks losing valuable metadata.

The other option is rewrap the MXF using EditReady which should combine the metadata from the folder tree into the resultant .mov file. You could then import from those .mov files using “leave files in place”. Any workflow decision should be thoroughly tested and verified before adopting it for production.

[Ray Sherman] “If I convert the m2t media to ProRes 422 LT and/or ProRes 422 Proxy, will I be able to to optimize the media in FCPX to ProRes 422? Please correct me if I’m wrong but, wouldn’t I be degrading the media upon the conversion therefore, making it impossible to bring it back to it’s native quality in FCPX? “

You don’t need to externally transcode .m2t media to ProRes before import. You only need to rewrap it with EditReady, then you can import it with “leave files in place” and — optionally — create proxy or optimized media. If the material is 1080p you probably don’t need either proxy or optimized — you edit the rewrapped .m2t files (in .mov format) directly, with adequate performance and quality.

Because your .m2t media is 1080p, proxy would be fairly low resolution, so in that case IF you needed better editing performance (which I doubt) it might be better to create optimized media either during or after import. In theory you could do that directly from the .m2t files without rewrapping them first. However I don’t trust anything FCPX does with bare AVCHD files. Even though it is an extra (albeit quick) step, I would always rewrap any AVCHD content (whether bare files or not) using EditReady.

[Joe Marler]

[Ray Sherman] “….playing around with EditReady…all the files I mentioned in .m2t clips only. I now see that a lot of storage is needed when I convert them to ProRes 422….At least FCPX will handle the 4K natively without conversion…”

You are apparently using EditReady to transcode, not rewrap. This is NOT necessary and will take a lot of time and space. In EditReady, simply set the preset to “Rewrap”. This will rapidly produce .MOV files which can be almost instantly imported to FCPX using “leave files in place”.

Do NOT import AVCHD bare files to FCPX — whether .m2t or .mts. The import phase takes a long time and it does NOT handle them well after import. It may cause significant performance problems down the line.

IF you need higher editing performance you can have FCPX create proxy (not optimized media) when importing the rewrapped files or afterward.

To review:

(1) Use EditReady to rewrap (not transcode) the .m2t or .mts files.
(2) Import the rewrapped .mov files using “leave files in place”. This will be very quick.
(3) IF you need better editing performance, create proxy files — but not optimized media. You can do this during import or afterward.

Optimized media is a lot bigger and not generally necessary when dealing with 4k. Proxy 4k is still HD resolution so the viewer resolution will be good even in proxy mode.

To change to proxy mode, at the upper-right corner of the viewer set it to proxy. After you are finished editing, remember to set this back to “Optimized/Original”, otherwise your export will be at proxy resolution.

If you want to edit in 4k but have no need for 4k export, you can put the 4k material on a 1080p timeline. This will retain the ability to crop/zoom into the frame, using all 4k resolution, but the temporary render files will be 1080p so it will help performance.

You create a 1080p timeline (aka project) by doing File>New>Project, select “Use Custom Settings”, and select (typically) 1080p and 29.97p. If you don’t do this, by default the project properties will be whatever the 1st clip is — 4k in your case.

[Joe Marler]

[Ricardo Tabosa] “… I will have 45 shooting days to import/optimize and FCP X is putting everything on the same drive, witch will soon kill my media management estimation and leave me with a unwanted giant Media Library….when you mention re wrap are referring to the transcode workflow?
“

You have a lot of data so it makes sense to streamline the transcoding and space consumption. You should NEVER remove bare .MTS files from the AVCHD package and import those with “leave files in place”. The import itself will be very slow and it can cause later editing performance problems. The fastest approach is simply drop the entire AVCHD package into EditReady and re-wrap (not transcode) the files.

EditReady can either transcode or re-wrap — you must specifically select re-wrap to ensure this happens, else it will transcode them which is much slower. After re-wrapping, FCPX can import those very quickly (often just seconds) using “leave files in place”. The re-wrapped .mov files essentially become your original media from that point forward, although keeping an archival copy of the AVCHD camera files is a good idea.

Your A7SII is recording AVCHD which means you limited the bit rate and recorded only 1080 HD content. If you only want HD (not 4k) I’d suggest using XAVC-S HD which is a higher bit rate and avoids the complexity of dealing with AVCHD. However I suggest an overall evaluation of image quality, noise, dynamic range and low light performance on the various recording modes. In general the camera will produce best results on XAVC-S 4k. Even if you only need an HD delivery it might be better to capture and edit in 4k. However 4k would definitely require using proxy files (but not optimized media).

But since you have only recorded 1080 HD, after re-wrapping and importing, you may not even need proxy files, much less optimized media. 1080 AVC/H264 media can normally be handled by either FCPX or Premiere very smoothly without any proxy files.

So considering all of the above (and assuming you will be staying with AVCHD 1080 HD material), the fastest workflow for FCPX would be re-wrap (not transcode) using EditReady, then import those .mov files using “leave files in place”, and don’t generate either proxy or optimized media.

[Joe Marler]

[Mark Morache] “I’m curious about the performance of my MBP and my XAVC footage…I now own a Sony PXW-FS5, and I’m shooting 1080 XAVC-L footage, and simply playing clips in the browser starts heating my MBP and getting the fans to kick in….when I play one of my clips in Quicktime, activity monitor indicates QT is using about 6-10% CPU. That makes me think that playing these clips isn’t a big problem for my mac. However when I play a clip in my browser, my CPU jumps up to about 200% CPU….Can anyone explain why it requires so much more CPU in FCP?…My render bar is clear since I have raw clips in my timeline right now – not even any color correction – and just hitting play starts making my fan kick in….Maybe there’s something else going on. I’ve had more freezes and crashes of FCPX, and maybe I should do a clean install?”

I played some 50 mbps XAVC-L 1080p test material on my 2015 MBP using both Quicktime and FCPX 10.3.2, and it plays OK with low CPU utilization on both. This was a native camera file and imported to the library without proxy or optimized media, and playback monitor set to full screen and “Better Quality”.

I also tried removing the MXF file from the folder tree and importing with “leave files in place” — same result: plays good on FCPX without high CPU.

If you wanted to ensure we’re using the same files, you could download one of these and try it. I used the HD Log version: https://zsyst.com/sony-4k-camera-page/sony-fs5-sample-footage/

The only time I’ve seen high CPU consumption just playing back an AVC/H264 file is on Premiere.

[Joe Marler]

[Mathew Farrell] “Removing from the wrapper is one thing, but I’m talking about leaving media on its source drive and not duplicating it all into the library file. Surely that’s a global option, and nothing to do with the file format/codec. Are you talking about something different?”

You need to :

(1) Remove any .MTS files from your library
(2) Rewrap the .MTS files using EditReady
(3) Import the re-wrapped files using “leave files in place”. They will not be copied to the library.

This is super-fast and very reliable. Even though EditReady cannot remove the wrapper of MTS files “in place” and must make a new re-wrapped file, this is very fast. The re-wrapped files can then be imported “in place” — typically within seconds. Your total processing time for all stages of import (inc’l manual re-wrap and file copy) will be vastly quicker.

Just make sure that you configure EditReady for re-wrap, not transcode. It can do either one.

There are two separate situations here, both involving AVCHD files:

(1) AVCHD media (even if within the AVCHD package) cannot be imported using “leave files in place” but FCPX itself will re-wrap those on import and copy them to the library. FCPX performance and stability should be OK. If you don’t want them in the library, you’ll need to re-wrap them yourself using EditReady prior to import.

(2) Bare .MTS files removed from the AVCHD package can be imported “in place” but this is very slow and can cause I/O performance problems for FCPX thereafter. It may be repetitively re-wrapping each file upon each reference. It does not handle it well, and that is the scenario you are facing. Unfortunately this is not documented in any KB article or Tech Note.

Normally FCPX handles various camera native files very well and you can get good editing performance using “leave files in place”. However bare .MTS files removed from the AVCHD package are an exception. You have a very easy and straightforward solution for this, which will continue to be useful for any subsequent .MTS files you are given.

[Joe Marler]

[Mathew Farrell] “…20 hours later I haven’t gotten very far. FCPX hung several times trying to import all that media at once (leaving in location, not copying to the stupid library secret archive)….the MTS clips don’t look promising (loooong progress bars of Processing Files for Import that don’t seem to progress)….It seems to me that FCP just can’t handle any volume of MTS files. Can anyone think of any alternative workflows, or anything I’m missing before I toss it in trash and go back to Resolve?”

These are bare .MTS files extracted from the AVCHD wrapper, else you wouldn’t have the “leave files in place” option. The performance issues you describe are a known issue. MTS files should never be removed from the AVCHD wrapper, and if you do, FCPX does not handle it well.

The easiest and best solution is re-wrap the MTS files before import using EditReady: https://www.divergentmedia.com/editready

The rewrap is very fast and afterward enables lightning-quick import (ie a few seconds) with “leave files in place”.

If you have any MTS files already imported, those should be deleted from the library and then re-import the rewrapped versions. If any bare MTS files are left in the library it can cause runtime performance problems, even if they are only a small % of the overall material.

[Joe Marler]

[Noam Osband] ” both my computer and the external drives have at least 10% free.”

That is extremely tight. Both FCPX and macOS are constantly using storage for paging, temp files, render files, etc. The in-use storage you see statically does not necessarily reflect the flickering “high water mark” of dynamic storage consumption. Ideally software should exhibit graceful degradation when hitting limits or errors, but this doesn’t always happen. Sometimes it just crashes. I would personally never operate with a boot drive at 10% free space or a media drive holding a library at 10% free space.

However that was just a thought — your crashes may have some other cause. If you’ve made many project snapshots of a 3-hr project, that could slow it down at startup, but it shouldn’t cause a crash. It might be worth breaking it into smaller projects just for an experiment.

Are you on 10.3.2? That version contains significant performance enhancements for large projects.

[Joe Marler]

[Gabe Strong] “not sure why you are taking ‘an average of the entries in the CPU database.’ That is a little like averaging the speeds of any GPU anyone puts into the 2009 Mac Pro. “

I did NOT take an average of ‘any GPU’ (or CPU) in the GeekBench 4 database. Rather — as I described — I took an average of the fastest entries. Of the approx. 30,000 entries, I sorted those in descending order by multi-core CPU or GPU performance and took the average of roughly the fastest 10 out of those 30,000.

It is the average of the best 10 CPU or GPU entries in a database of 30,000 entries. It is not an average of those 30,000 or even an average of the first page of entries. The fastest entries in the GeekBench 4 database include the fastest upgraded or modified machines, and it automatically filters out medium and lower-end machines.

Of course it’s possible that someone with a special 2009 Mac Pro might get better performance and just not upload it to the GeekBench database. It’s also possible they ran GeekBench 3 which is less accurate and may produce misleadingly higher numbers than GeekBench 4.

Taking an average of the fastest entries — and noting the version of GeekBench — is just a standard practice to properly reflect the best achievable performance. Just listing a single number without stating the GeekBench version would risk being non-representative.

[Joe Marler]

[andy patterson] “Upgrading the 2009 Mac Pro…a 3.2 GHZ dual quad core Xeon system from 2012…with a GTX 1080 would work great with FCPX….”

To my knowledge there are no macOS drivers for a GTX-1080 so it can’t be used with FCPX, Premiere or any other app on a Mac.

For a 2009 Mac Pro, the average of the fastest entries in the GeekBench 4 CPU database is around 2,500 single-core and 13,800 multi-core. GPU performance is around 110,000, except for one entry using a GTX-980Ti which was 141,000.

For a 2012 Mac Pro, the fastest GeekBench 4 GPU numbers are around 145,000-150,000, again using the GTX-980Ti. By contrast a 2013 New Mac Pro with dual D700s produces about 94,000 per card or 188,000 total. So from a GPU standpoint, a D700 2013 Mac Pro is still faster than anything you can easily build using a single GPU that will run on macOS. I have seen claims that people got a Hackintosh running using dual nVidia GPUs, but it’s apparently not straightforward, and I don’t know well FCPX would use that.

The only exception is the Radeon 280X which is almost identical to the D700 and can use the same drivers. It is an older card but dual-280X performance on FCPX is excellent and from a driver/macOS standpoint it is plug-and-play. Max Yuryev demonstrated a reliable, easy-to-build Hackintosh using these dual GPUs in this video. Max also said due to how Apple optimized FCPX for those AMD cards it’s faster than nVidia alternatives. So there’s a difference between benchmark numbers vs real-world application performance, which in this case is FCPX.

https://www.youtube.com/watch?v=I6ZJWPi_CBc

Your thread title asked about a 2009 Mac Pro, but even for a 12-core 2012 Mac Pro, the GeekBench 4 CPU database shows about 2,700 single-core and 20,000 multi-core. Those are the fastest CPU numbers in the GeekBench 4 database for any 2012 Mac Pro, regardless of CPU configuration or aftermarket modification. By contrast a 12-core 2013 New Mac Pro does about 3,450 single core and 25,500 multi-core.

So even though the 2013 Mac Pro is three years old, it still looks faster than most of the upgraded 2009 or 2012 Mac Pros — from both CPU and GPU standpoints. There could still be a good reason to upgrade an older Mac Pro, assuming there is macOS driver and software support and it has demonstrated performance benefit on FCPX.

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]

[Tom Sefton] “Around the 12min mark it gets interesting. Fcpx gets huge performance from a laptop with less ram and a huge GPU disadvantage,”

Note he was testing the top-spec Razer Blade Pro against a mid-spec MBP. The top-spec MBP using 2.9Ghz CPU and Radeon Pro 460 would have been considerably faster than the MBP he tested, and it would have still cost $830 *less* than the Razer Blade Pro (at current US prices). This is very different from the Mac stereotype of “it’s lighter, thinner, and looks great but it’s more expensive”. In this case a top-spec Apple solution would have cost 22% less and weighed 90% less.

Since he didn’t test the top-spec MBP it’s unclear what the performance difference would have been, but the GeekBench 4 GPU test shows the Radeon Pro 460 is about 26% faster than the Radeon Pro 455 he used. The hulking GTX-1080 in the Windows machine would have still been faster on some tests but the difference would have been less.

He also didn’t test battery life, but on tests by laptopmag.com, the 2016 15″ MBP lasted 10 hr 32 min vs the Razer Blade Pro lasting 2 hr 45 min. So the GTX-1080 looks really good until you have to provide power and use it in a real world environment.

That said, several of his tests were skewed by FCPX’s better performance which wasn’t really fair if it’s intended as a laptop hardware test.