[Joe Marler]

[Ben Lithman] ” ..fastest way of going from having an un-rendered project in an FCPX timeline to getting an exported and compressed video to something like YouTube. ….’sharing’ straight from FCPX to YouTube can take an absolute age, in comparison to manually rendering the timeline, exporting it as a master file, compressing it, then uploading it manually…What is generally regarded as the best workflow to do this? For example share to “Apple Device”, to skip the loading into compression software phase, also seems to take horrendously long…On a Mac Pro (trash can) 6x core 3.5GHz”

One problem is your Mac Pro (while generally a nice machine) does not have Quick Sync so this penalizes it on H264 export. Ironically a late-generation MBP could be faster at exporting. This isn’t Apple’s fault; for a variety of reasons Intel did not put Quick Sync logic on any Xeon above 4 cores.

However the nMP is widely used so this should not be a show stopper. In general I find the fastest method is exporting to Master File>Settings, then using Format: Computer, Video Codec: H264 Faster Encode, and Resolution 1280×720. For most Youtube stuff, 720p is probably OK, and this reduces the upload time by about 1/2. Everything ABC, Fox and ESPN shoot and broadcast is exclusively 720p.

The bit rate FCPX uses is about 2x the minimum Youtube recommends so in theory you could compress it more but I prefer the faster export from FCPX and simpler procedure. Supposedly the performance of Compressor has been improved but I always find exporting straight from FCPX is faster.

Although FCPX does not usually require using background rendering, if this was enabled and if your timeline is render-heavy (say a lot of effects) this could reduce the export time.

In general FCPX is very fast at exporting (even on a nMP), and there’s nothing FCPX can do about your upload performance — that’s determined by your ISP. I always prefer to export then upload in two separate steps because it allows inspection of the video file, plus it differentiates between export time and upload time.

[Joe Marler]

[Scott Witthaus] “He is looking at an iMac and a Pegasus Raid array to hang off of it. Should I just have him buy the iMac that is tricked out on everything or are there certain items I need to make him aware of? Dissuade him from the iMac and go with a MBP?”

That is a good combination, which I formerly used. I have a top-spec 2015 MBP and don’t use that for editing unless I’m in the field and cannot avoid it. For extended editing sessions, a top-spec 2015 iMac 27 is much better — quieter, faster, bigger screen, etc.

The Pegasus arrays are good but (like most hardware RAID boxes) you are locked into their proprietary format. If the chassis itself goes down, the drives can only be used in another Pegasus. By contrast something like an OWC Thunderbay 4 using SoftRAID is just as fast and in a chassis failure scenario the drives can be used in any other drive enclosure.

Spinning RAID arrays have good sequential I/O performance but FCPX does a lot of random 8k I/O when building and maintaining thumbnails and plist files for the Event Browser. RAID arrays are not good at small random I/Os. If he can afford it, an 8TB OWC Thunderbay 4 Mini with 4 x 2TB Samsung EVO 850 drives in RAID-0 is about $3k and delivers over 1,100 MB/sec plus vastly higher random I/O performance. Unlike spinning RAID arrays (indeed all spinning drives) SSD performance does not drastically degrade as the drive fills up.

Obviously any disk storage should also be backed up, so he’ll need (at a minimum) 2x his total storage to include backups.

A top-spec 2015 iMac 27 is certainly adequate for editing 1080p and 4k H264, but if the updated iMac should be out pretty soon. If I were in his shoes I’d consider waiting for that, or if that’s not possible getting a less expensive refurbished iMac until the update is ready. The update probably won’t be much faster from a CPU standpoint but the GPU will probably be considerably faster.

[Joe Marler]

[Steve Shamp] “I edited together the basic scenes on Windows Movie Maker, and then added the audio clips and synced them to the video where the dialogue is spoken. I then saved the rough edited scenes in high res, using the basic ‘save video in high res’ button. Ok, so my plan is then to pay an experienced video editor to simply take all the finished scenes, and piece them together into his editing program timeline, and do a final polish and edit…is it ok that the scenes are pre-saved/rendered rather than giving editor a project type of file?…will an editor be able to fix audio, etc, from the already rough edited scenes?…if its not the best way of doing things, its although still doable correct? “

It is doable but will not produce the best results. No editor likes to work off edited, rendered, compressed H264 material. Every cut you already made must be re-bladed to frame accuracy. If you had any transitions such as cross-fade, those must be cut out since you can’t easily do separate color/exposure/stabilization, etc on either side of the blended region. Cutting any video out then throws off audio sync, so you then must compensate for that somehow. If your original audio is multiple channels, e.g, natural sound, dialog, voiceover, music, etc and already mixed down in the rendered output, the final editor cannot pull those apart.

As Craig already mentioned, the editor will likely need/want additional head/tail content from each clip to refine the edit, but it’s not available since you already cut it and rendered the file.

Your situation is a common one and this is often done before a better workflow is devised. So it’s not like nobody has ever done this before, it’s just not the best way.

In your current situation, if you want the best quality results the editor will need to backtrack and get the original source clips for each clip used in the rendered file. That can be very tedious, depending on how many cuts are involved. It will also take a lot more time and if you’re paying him, more money. If you are willing to accept lower quality results he can edit the rendered file, blade each clip, correct color/exposure/stabilization/audio, etc.

In the future it would be best to edit in the same software the finishing editor will use and hand off the project or library to him, or else edit in software that can export XML of sufficient quality so he can import the project into his preferred software. Using Resolve (which is free) would give much better options than Windows Movie Maker. If using FCPX there is a tool called XtoCC that helps export content for editing in Premiere CC: https://itunes.apple.com/us/app/xtocc/id487899517?mt=12

If you haven’t priced any finish editing work, be advised it can be very expensive. This is an FCPX forum so I assume you at least have a Mac. For basic jobs it might be better to just use iMovie and learn to edit it yourself. At least iMovie can export ProRes which is much better to edit than H264. Also an iMovie project can be exported to FCPX: https://support.apple.com/kb/PH12746?locale=en_US It would be interesting to try and take an iMovie project to FCPX and then to Premiere using XtoCC and see how well that works.

[Joe Marler]

[Noam Osband] “…render these films with a lot of effects on them. It takes a while….does it make a difference what kind of drive they are on for render times. I imagine the big thing is the RPM of the drive and speed of the computer processor. For rendering, does it make a difference if I’m using Thunderbolt 2.0 or USB 3.0?…

Technically, “rendering” means resolving all effects and edit directives in the timeline, not exporting to an output file. Exporting means writing a rendered, encoded timeline to an output file. If the timeline is not rendered before export, then the export phase will do that. Also it may require encoding based on the selected output codec. However we often loosely use the term “rendering” to mean exporting to a file, but two different logical phases are involved.

Normally rendering is either CPU or GPU bound, not I/O bound. You can examine that using various monitoring tools such as Activity Monitor or iStat Menus — the I/O load is generally not very high. Likewise exporting or encoding is usually CPU bound (if to H264 or similar long GOP formats).

A chain is only as strong as the weakest link, which for rendering or encoding is usually the CPU or GPU. So it usually does little good to further improve I/O for this phase. On a Mac, I/O queue depth can be examined using the command line Dtrace tool iopending. Always exercise caution when using any terminal commands.

Note the Dtrace utilities cannot be used starting with El Capitan unless System Integrity Protection is first disabled: https://apple.stackexchange.com/questions/208762/now-that-el-capitan-is-rootless-is-there-any-way-to-get-dtrace-working

If you are editing or exporting to ProRes or other low-compression codec, and especially if multicam, then I/O performance can be more limiting. However in your case I doubt whether the interface is Thunderbolt or USB 3.0 will make much difference for a single 7200 rpm drive during the rendering phase.

In a large library, FCPX does a lot of 8k random I/O for thumbnail and plist generation and maintenance, so in this case random I/O performance can be important. Unfortunately spinning RAID arrays are not very good at small random I/Os.

[Joe Marler]

[Herb Sevush] “according to one of it’s better known proponents it’s taken 5 years for X to be suitable for long form work. Well, I guess that is progress.
“

This was apparently a new problem. Previous versions have been tested with a timeline up to 588 *days* long, and with up to 1,000 layers:

https://www.fcp.co/final-cut-pro/news/1372-pushing-apple-s-new-mac-pro-and-final-cut-pro-x-to-their-limits

Although described as a “long timeline” performance problem, this new issue doesn’t really require a long timeline. It can be seen in a 15 min. timeline provided there are many connected clips. It is supposedly fixed in 10.3.2. It was some kind of performance regression inadvertently introduced when adding the “Timeline 2” functionality.

[Joe Marler]

[Ivan Knežević] “FCPX is extremely laggy, choppy, and it freezes too often. Problem is, I tried to import about 60GB of MTS files into FCPX, recorded at Panasonic GH4 at 1080p, 50fps, 28Mbits…it took almost a 6 hours to import”

In general FCPX is somewhat faster than Premiere CC (on the same hardware) in terms of playhead response on the timeline and especially in export performance to H264. Like Premiere CC, FCPX can usually do pretty well when editing camera native files. Creating proxy or optimized media is not usually required for 1080p H264. However there are some variations, and in some cases Premiere CC can be faster.

In your specific case — bare MTS files extracted from the AVCHD container — FCPX may not handle certain aspects well.

It took you 6 hr to import 60GB of MTS files — NOT because FCPX is slow per se but (a) Because you voluntarily created both proxy and optimized media files, and (b) Imported bare MTS files stripped from the AVCHD package. IOW you told FCPX to transcode the media twice upon import. It takes a while to transcode all that content.

I suggest you either import from the AVCHD package or re-wrap the .MTS files before importing using EditReady:https://www.divergentmedia.com/editready or the free tool ReWrapAVCHD: https://www.macupdate.com/app/mac/39800/rewrapavchd. Also you don’t generally need proxy or optimized media for H264 1080p editing on a recent Mac. Your GH4 has several different H264 file formats and bit rates. You were apparently using AVCHD at 28 mbps. In general I recommend using .MP4 or .MOV at a higher bit rate. Those also eliminate the unwieldy AVCHD package.

I just did an import of 60GB of 1080p bare MTS files using “leave files in place” and without creating proxy or optimized media. On my 2015 iMac it took about 10 min to import these, after which you can immediately edit. The background task of generating audio waveforms will continue for about 13 more minutes and that might slow things down a bit. After that, skimming, editing and timeline operations are very fast. So my total time was 23 min vs your 6 hours.

I then re-wrapped the 60GB of MTS files to MOV using EditReady, which took about 3 min. Importing from these files took about 2.5 seconds, and creating audio waveforms took 57 seconds. Timeline performance might have been a little quicker but it was already so fast on the MTS files it’s hard to be certain.

Importing the same MTS files in Premiere CC 2017 took about 15 sec, and generating the audio peak files took about 2 more minutes. Timeline responsiveness in Premiere was OK but the viewer update rate was slower than FCPX and there was much more lag on JKL keyboard inputs.

I then imported the re-wrapped files to Premiere CC 2017 — this took about 10 sec, and generating peak files took about 20 sec — not that different from the bare files.

So while FCPX can edit bare MTS camera native files which have been extracted from the AVCHD package, it doesn’t handle this optimally. I have seen cases where a few of these files in a large library can cause significant performance degradation due to excessive I/O. It may be that FCPX is dynamically re-wrapping these files upon each reference.

I then did further import and export performance tests using a 6.8GB AVCHD package containing 79 1080p/29.97 files from a Canon HF-10. We haven’t used AVCHD for years, so that’s all the content I could find. All tests on top-spec 2015 iMac 27 running macOS 10.12.2, with content on 8TB Thunderbolt 2 SSD RAID-0 array. You can see FCPX is not good at handling bare .MTS files removed from the AVCHD package, and this even affects export performance.

Import 79 files from from 6.8GB AVCHD package (requires importing files within library for FCPX):
Premiere CC 2017: 40 sec, + 20 sec audio peak file generation (60 sec. total)
FCPX 10.3.1: 35 sec + 8 sec waveform generation (45 sec. total)

Import from 79 bare .MTS files:
Premiere CC 2017: 37 sec + 24 sec audio peak file generation (1:01 total)
FCPX 10.3.1: 3:00 + 2:00 audio peak file generation (5:00 total)

Import 79 .MTS files rewrapped to .MOV via EditReady:
Premiere CC 2017: 5 sec
FCPX 10.3.1: 2 sec + 8 sec waveform generation (10 sec total)

Export H264 60 sec 1080p content from one clip in an AVCHD package:
Premiere CC 2017: 0:55
FCPX 10.3.1: 1:07

Export H264 60 sec 1080p content from a bare .MTS file:
Premiere CC 2017: 0:53
FCPX 10.3.1: 2:22

Export H264 60 sec 1080p content from a bare .MTS file re-wrapped as .MOV:
Premiere CC 2017: 0:51
FCPX 10.3.1: 0:18

Since XAVC has some similarities to AVCHD, I then tested this with a 45GB 4k set of XAVC-S content:

Import from 45GB XAVC folder tree (requires importing files within library for FCPX):
Premiere CC 2017: 1:22 + 1:12 peak file generation (2:34 total)
FCPX 10.3.1: 2:57 + 10 sec waveform generation (3:07 total)

Import from 45GB XAVC bare .MP4 files:
Premiere CC 2017: 1:10
FCPX 10.3.1: 0:03

Import from 45GB XAVC bare .MP4 files re-wrapped to .MOV:
Premiere CC 2017: 1:10
FCPX 10.3.1: 0:08

Export 60 sec single H264 4k bare XAVC-S file:
Premiere CC 2017: 2:09
FCPX 10.3.1: 46.7

Export 60 sec single H264 4k bare XAVC-S file re-wrapped to .MOV
Premiere CC 2017: 2:09
FCPX 10.3.1: 46.6

[Joe Marler]

[Noam Osband] “a keystroke which let me go from a clip in the primary storyline to a connected clip. Does such a thing exist?”

Yes, on 10.3 it is CMD + up arrow or down arrow. Here is a MacBreak Studio showing how to use it:

https://www.youtube.com/watch?v=8S6HNSZ7-q4

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]

[Martin Szucs] “macbook pro is terribly slow. I know my macbook pro is quite old and it lacks ssd and ram….2010 macbook pro 13″…2.4GHz Intel-Core2Duo…4GB ram….250GB hhd…Nvidia Geforce 320M…..i don’t want to edit 4k videos, only 1080p. Is there any way to improve it so that it won’t be that choppy?….More Ram or an SSD? My main problem is that sometimes the playback is choppy and what is really confusing that when i want to edit by frame to frame “

Besides being a minimally-spec’d computer, the CPU does not have Quick Sync which makes it even slower when encoding or decoding H264 content. Furthermore it does not have USB 3.0, which greatly limits your ability to use external hard drives.

Even a used or refurbished 13″ MacBook Air with 8GB RAM would be a lot better. There are plenty of those available in the used market.

The easiest solution without spending anything is use FCPX’s built-in proxy feature and transcode your files to proxy (not optimized). Then you set the viewer to proxy. Just remember to set it back to optimized/original before final export.

That will take more space but decrease the CPU load and make editing smoother. However you are already space-constrained with only 250GB, and using USB 2.0 hard drives is generally not a good idea.

[Joe Marler]

[Cherin Bower] “.. I am new to editing…I shot 4 TB of footage on a Sony PXW-z150 4K XDCAM camcorder mostly in 4k, and I am combining multiple clips in FCPx 10.3.1. The native mxf files are too large for import to FCP and I don’t necessarily want to create proxy media for every clip. I prefer to “copy files to library” on import into FCP so I will end up creating large FCP libraries.”

You are walking down a path of ever-increasing time and workflow complexity. With older, slower editing software lacking asset management tools, the standard procedure was evaluate the material before import and only import what you really want.

FCPX is so fast and has such good organization tools, it is often better to just import everything using “leave files in place”. That does not require any additional space for transcoded media and import is lightning fast. Make sure all analysis options are turned off on import. Then inside the editor, use skimmer, rating, keywords, etc to evaluate and classify the content in a single pass. The library will remain quite small except for cache files, which can be located elsewhere if you want.

If you have 4k multicam content, that may require transcoding to proxy for smoothest editing performance. However in general camera-native H264 4k content can be skimmed and initial selects done within FCPX after importing with “leave files in place”. Normally copying the content to a library, or creating proxy or optimized media is not needed.

I normally don’t work with MXF but I imported some DCI 4k MXF content to FCPX 10.3.1 with “leave files in place”, added it to a timeline and it worked fine. It was 10-bit 4:2:2, encoded at 240 mbps. Skimming and playhead movement in the timeline was pretty quick and responsive.

This is the procedure I use for other large documentary projects in the 5 terabyte range. My 2015 top-spec iMac 27 handles it well, although the media is on several Thunderbolt 2 drive arrays, one of them SSD RAID-0.

[Joe Marler]

[Oliver Peters] “My regimen is to transcode any of these consumer formats to ProRes…. “

Transcoding them to a non-consumer format which FCPX will not re-wrap is also a good idea for collaborative work when emailing FCPX “lean libraries” back and forth. That only works with “leave files in place”.

FCPX will sometimes unpredictably re-wrap and copy certain consumer media to the library. The conditions for this are not documented. In the case of XAVC-S it may do this even though the import UI says “leave files in place”. This in turn creates a situation where a huge library consisting mostly of “in place” files has been “poisoned” by inadvertent import of a few re-wrapped files. This grows the library too large for easy file transfer, yet there is no easy way to get those files out of the library. The consolidate function is all or nothing. With a 5TB “files in-place” library contaminated by a few of those re-wrapped files, you’d have to consolidate the entire 5TB to another location — despite 98% of that already being externally managed. This is the only way to shrink the library to an emailable size. The solution is don’t get in that situation in the first place, but this requires lots of testing since the situations causing it are undocumented.