[Joe Marler]

[Gabriel Spaulding] “… my 10-core iMac Pro had significant hardware issues Apple was unable to fix, then I upgraded to an 18-core iMac Pro that had the exact same problems. I returned that and now have a maxed out 5k iMac, and in nearly every case it is outperforming the 18-core iMac Pro. Multicam editing is smoother, playback is smoother, Motion render times are more or less identical…In fact, before I returned the 18-core machine I compared it to my late 2013 iMac: the 18-core with directly attached OWC Thunderbay 4 drives was MUCH slower at playback and export than the late 2013 iMac accessing media on the same drive… over a network…”

I’ve had two different 10-core Vega 64 iMac Pros and tested them extensively vs a 12-core D700 Mac Pro and a top-spec 2017 iMac. The results vary based on codec and workflow. Even the old nMP is pretty quick on ProRes. It is hobbled on H264 since it doesn’t have Quick Sync.

While the iMP doesn’t have Quick Sync, FCPX apparently uses AMD’s UVD/VCE hardware so it’s much faster than the nMP but no faster at encoding, editing or encoding H264 than a 2017 i7 iMac. In fact the iMac is smoother and faster on 4k H264 than a 10-core Vega 64 iMP.

The main problem with the iMac Pro is H264. It’s faster than the “trash can” but that’s a low bar — the nMP is very slow on that codec. If I used an all ProRes or raw workflow I’d be happy with the iMac Pro.

The iMP might do better than the iMac on an effects-heavy timeline but it’s difficult to know what effects use what % of GPU. Even effects which are frequently described as “GPU intensive” often don’t use that much. This can be determined with various monitoring tools like the latest version of iStat Menus.

The BruceX test is GPU-intensive but is tricky to run to avoid caching, pre-rendering or codec effects. If exporting to ProRes 422 from an unrendered timeline using a fresh library, I got the following numbers:

2017 i7 iMac 27: 15.8 sec
12-core D700 Mac Pro: 17.0 sec
10-core Vega 64 iMac Pro: 14.8 sec

For those using an all-ProRes or RED RAW workflow the iMP is pretty fast. I didn’t test those codecs vs the nMP but my impression is a 10 or more core iMP is faster.

Re I/O, I tested the iMP on many different Thunderbolt drive arrays and it did just fine, certainly no slower than the iMac.

[Joe Marler]

[Oliver Peters] “if the main concern is rendering/exporting within an NLE like FCPX or Premiere Pro, then the iMac Pros will still yield superior results. Although we are mainly talking about a 10-20% bump for the iMP over a decked out iMac.”

This will vary based on the codec and NLE. Some common workflows in FCPX are significantly slower on a 10-core Vega 64 iMac Pro than a top-spec 2017 iMac. I ran these tests yesterday:

Export from 4k Sony XAVC-S, clip length = 10:17

Output = 4k H264 Fast Encode, 2017 iMac 27 = 5:53, 10-core Vega 64 iMac Pro = 7:10
Output = 4k H264 Better Quality, 2017 iMac 27 = 11:25, 10-core Vega 64 iMac Pro = 14:49
Output = 1080p H264 Fast Encode, 2017 iMac 27 = 5:53, 10-core Vega 64 iMac Pro = 4:00

So at least the iMac Pro is faster at encoding to a 1080p H264 file, but it’s slower than a 2017 iMac at encoding to a 4k H264 file. FCPX on the iMac Pro is also slower than the 2017 iMac on the H264 decode side, not just encode. This can be seen by how scrubbing an H264 4k timeline is more sluggish on the iMP than the iMac. The iMac Pro is faster at encoding and decoding ProRes.

In Premiere 2018, the iMac Pro is faster than the 2017 iMac at all the H264 encoding tests I’ve done.

[Joe Marler]

[Mandy Leonardo] “I went from a macbook pro to the air…I’m editing on an external drive and turned off rendering during playback. Doing very simple edits…no titles, graphics, etc… figure out why it’s running so slow.”

Depending on the two computers, it’s possible the MBA is just slower. Some MacBook Pros are quad core and all MBAs are dual core.

Another possibility is your external drive is USB 2.0. Those only work at slow USB 2.0 rates, even when connected to a USB 3.0 port. But if it’s the same drive you used on the MBP, it doesn’t explain that.

You can check the external drive performance by running Black Magic disk test. Be sure to select the external drive in the menus before running it, else it will use the internal SSD Drive. Do that and post your results here: https://itunes.apple.com/us/app/blackmagic-disk-speed-test/id425264550?mt=12

Editing ProRes (even at only 1080p) implies a higher I/O rate since the file sizes are about 6x larger than equivalent H264.

You can take a small sample of that project or one clip and create a test library on the internal SSD drive, then check editing speed. If it becomes fast, then it’s an I/O problem and the solution is get a faster external drive.

How was your 1080p ProRes material generated? Is it possible it was 4k H264 and you’re using ProRes proxies at 1080p? Maybe the FCPX viewer is not switch to proxy and it’s trying to edit 4k H264? That would be slow on a MBA.

If the 1080p ProRes came from, say, an Atmos recorder on a DSLR, it should be pretty quick to edit on a MBA, unless it’s been hobbled by a slow USB 2.0 external drive.

If there is any uncertainty on the characteristics of the source material, you can examine this with a tool like MediaInfo or Invisor:

https://itunes.apple.com/us/app/invisor-media-file-inspector/id442947586?mt=12

[Joe Marler]

[Jagster rana] “so next time shld i import the files> pause background rendering > manually set all clips to REC 709 then restart the rendering ? is that work flow correct “

I’m glad the workaround was successful. I never use background rendering so I didn’t think about that. But in theory the flickering problem could be injected into any rendered file, so your procedure probably makes sense. Likewise for stopping auto generation of proxies on import until all the material has been manually re-flagged REC 709.

This problem is so serious I’m actually hoping Apple will fix it very soon so we don’t have to deal with workarounds. The workarounds aren’t that bad, but the problem is lots of material could be infected with these infrequent, spurious brightness fluctuations which are encoded to output files. The infrequent, fluctuating nature means it’s possible some material may have slipped by QC and been delivered or broadcast with these defects.

[Joe Marler]

[Jagster rana] “click on clip in browser window
inspector
change from BASIC > SETTINGS
Colour space override is default to off change to REC 709 in drop down menu
put clip on timeline “

If it is the same problem, this should work. If you have any render files or proxies, the corruption could be encoded to those, so it’s probably safer to delete those and regenerate them. I definitely saw cases where I moved a project and media from my iMac Pro to my iMac, and it happened there until render files and proxies were regenerated.

There are cases where a file in the timeline might not inherit the change made in the browser, but you added the file after you flagged it REC 709, so that should handle it.

In my case to be absolutely certain I re-flagged all the files in both browser and timeline to REC 709. I think for multicam I opened each one in the browser and re-flagged those also, not just the parent clips. I’m not sure if that’s needed but this problem was so serious and time-consuming to identify, I didn’t want to take any chances.

[Joe Marler]

This is likely a known issue with 10.4.x color space identification. The solution is manually use Inspector to flag all clips as REC 709, even if the library and clips are already REC 709. Note you must select “settings” at bottom of Inspector to get this option.

It’s a transient, elusive glitch whereby light colors will intermittently flicker or fluctuate in brightness. It is very difficult to reproduce but typically requires two layers such as connected clips, titles or generators over the primary storyline. I have only seen it on my iMac Pro, not the 2017 iMac, but others have seen it on regular iMacs.

I’ve only seen it on 4k H264 source material. When I used 4k optimized media or 4k ProRes sources it didn’t happen. However I have seen it on proxies, which are ProRes. Others have reported it on 1080p AVCHD (which uses H264). The behavior is very elusive and difficult to reproduce, and implies a possible underlying race condition or cache state issue.

This is unrelated to render files or 3rd party plugins. Reformatting the hard drive, reinstalling macOS and FCPX does not eliminate it.

It is not just a display problem but the results are encoded into an exported file (whether ProRes or H264). That is gravely serious, as it’s essentially corrupting the integrity of the material. If that machine was used to transcode material for downstream consumption, it’s possible a huge amount of work could be subtly “poisoned”. The behavior is very hardware-like and may appear to be thermally-related (it’s not), which in turn could lead to unnecessary hardware troubleshooting and machine replacement.

I’ve reported this to Pro Apps escalation support.

[Joe Marler]

[Noam Osband] “how can I see wave forms in the browser? “

View>Browser>Waveforms

[Joe Marler]

[Oliver Peters] “…most editors think visually. As such, an NLE interface should be designed to accommodate visual organization in a freeform manner… Every other NLE…structure the interface design along a spreadsheet-like grid. You can sort lists according to some alphanumeric criteria, but you can’t simply rearrange frame tiles at will or add some sort of markup to the bin…”

It’s ironic he said “open letter to….Apple” and “NLE software hasn’t changed in decades” when FCPX entailed vast changes and is by far the closest to implementing his ultimate goals.

Many of the things he was complaining about can be done right now in FCPX, he’s just not familiar with it. Maybe not done the *way* he’s thinking but that’s an implementation detail. Examples:

Bell: “….huge amounts of material, greater and greater every year, more and more cameras..I need to manage this footage…in an effective way…”

FCPX gives him that. I was 1st AE on a documentary that had 230 hrs, 8,500 4k clips, 20 TB of material. FCPX was not perfect; it had various issues but it was far better than when I did large docs in Premiere.

Bell: “need…visual tools….all these clips over here”

What he needs is improved media management. He he’s thinking of it visually — and that’s OK — but it’s not the only or necessarily the best way. This is an old issue that goes back to the origins of database management. This has been debated and researched ad infinitum for many decades. People tend to think of data navigationally or hierarchically, e.g, “Brown” is before “Smith”, or Smith is in nested folders Year/US/State/City. The problem is it’s not effective to design databases that way. Since the 1970s it’s been generally understood that a relational database query/response model is better, more flexible and more scalable.

In the relational model Brown does not exist before Smith, only queries and result sets exist. If you want Brown you request where lastname = “Brown”. Many other criteria can be added such as state of residence, age, etc. This is essentially how the Finder query works. You do CMD+F then start adding query criteria for files. It’s not an unfamiliar concept to Mac users.

FCPX media management generally uses a similar model, although it has Events as a single-level folder.

Walter Murch used a cobbled-together primitive version of this method when he edited Cold Mountain in legacy FCP. He used a Filemaker Pro database to keep track of scenes and clips. He kept Filemaker print outs on his table. He pasted up a physical “Event Browser” next to his desk. In this photo it looks like a crude mocked-up prototype of what FCPX provides today: https://newcdn.transom.org/wp-content/uploads/2005/04/M1246.jpg

Bell wants to make notes per clip. You can do that in FCPX per *range*. Admittedly this currently requires list view. The overall idea of clicking on a clip in thumbnail (or filmstrip) view, then adding pop-up queryable notes seems valid. FCPX could be improved but it supports range-based notes and querying now.

He wants “bin overlays”. What he meant is he wants to selectively filter on clips containing his assistant’s notes. FCPX has this right now in keyword collections and notes. He described it as a graphical spatial implementation but FCPX already achieves his ultimate goal, he’s just unaware of it.

Bell: “I don’t want to always load the clip into the source monitor to see the notes I’ve added”

This was a fundamental design issue on FCPX — to allow rapid browsing of video and metadata without loading each clip into a source monitor. So he can already do that on FCPX if he only knew about it.

He made various remarks about visually organizing clips in Avid’s “Frame View”, which is like FCPX’s filmstrip view shrunk to one frame per clip and without the skimmer. He mentioned drawing on the screen, annotating clips with icon images, scrolling in two dimensions around the frame view window with a mouse. Those are simply one way to browse and organize material — not necessarily the best, only, or most scalable way.

Imagine if a die-hard still film photographer’s only exposure to organizing media was putting prints on a table. He has little notes stuck to them. They are in piles. He’s running out of table space. When describing his ideal computerized version he will tend to think in terms of his limited experience. He might request a computerized version with a larger virtual table he can scroll around faster. He might request computerized post-it notes since he’s using those. It’s unlikely he would envision or request the database organizational system that Lightroom uses today, yet it works a lot better than a 2D scrolling virtual table with graphical post-it notes. Photographers think visually just like videographers. Yet they mange to use database systems like Lightroom to organize, manage and navigate large amounts of content.

The European feature film The Unknown Solder had 500 hours of 4k material (168:1 shooting ratio), and was edited by Ben Mercer on FCPX. He feels strongly that FCPX helped him manage this huge amount of material. Maybe video editors think visually but Mercer had no problems using the spreadsheet-like database features of FCPX. He’d like an enhancement to allow spatially repositioning clips in the Event Browser, but that’s very different from saying “NLE software hasn’t changed in decades”: https://www.provideocoalition.com/art-of-the-cut-with-ben-mercer-on-editing-unknown-soldier-in-fcp-x/

I think if Alan Bell was more familiar with FCPX he could make a more compelling and informed argument. FCPX is not perfect and I’ve had many problems with it. It needs improvement in various areas. But it already provides solutions to several of the things Bell mentioned. Other professional feature film, TV and documentary editors are using FCPX effectively to manage and edit very large projects.

[Joe Marler]

[Walter Soyka] “Is it just encodes? If this accelerates decode, too, does it make working with those devilish H.264 formats [link] any smoother?”

I tested 1080p AVCHD and Sony 4k XAVC-S, and for both it appears to be encode only. Decoding, as measured by viewer frame rate during timeline scrubbing and JKL responsiveness, is about the same between PP 2017 vs 2018. This is also the same on a 10-core Vega 64 iMac Pro — IOW PP 2018 doesn’t exhibit any significant speedup when scrubbing the timeline vs 2017 (at least on Mac). Selecting Metal vs OCL made no difference for either decode or encode.

There’s no question PP 2018 is a lot faster at encoding than 2017. On a 2 min UHD 4k XAVC-S clip, and encoding to 1-pass 20 mbps 1080p H264, it was.

2017 PP on 2017 i7 iMac: 04:15
2018 PP on 2017 i7 iMac: 01:19
2018 PP on 2017 10-core iMac Pro: 01:10

Encode time using the same parameters and same clip on FCPX 10.4.2 was:

2017 i7 iMac: 01:09
2017 10-core iMac Pro: 00:51

Interestingly, when comparing timeline responsiveness of PP 2018 on a 2017 i7 iMac vs 10-core Vega 64 iMac Pro, it was a little faster on the iMac Pro. CPU graphs shows Premiere timeline scrubbing (without effects) is highly CPU-intensive and the GPU isn’t used much. The iMP has more CPU horsepower so it was a bit quicker.

By contrast with FCPX, the iMac Pro was actually a little more sluggish than the 2017 i7 iMac on timeline responsiveness on 4k XAVC-S (ie H264). H264 decoding is hardware accelerated on FCPX — that’s obvious due to the lower CPU levels for equivalent actions vs Premiere. However it appears the AMD UVD hardware acceleration on the iMP is not as effective as Quick Sync on the i7. The iMP’s extra CPU horsepower isn’t helping FCPX decode/encode on H264 because the code path uses either Quick Sync or AMD’s UVD/VCE.

So Premiere 2018 H264 *encode* performance now rivals FCPX on the same Mac hardware, but decode performance is not dramatically improved. On 4k H264, FCPX timeline operations remain much quicker and more responsive than Premiere, esp for JKL.

However it is sad that FCPX is actually slower at 4k H264 encode *and* decode on a 10-core Vega 64 iMac Pro than a 2017 iMac.

Encode time for a 2:00 UHD 4k ProRes clip to 4k 1-pass H264:

2017 i7 iMac: 01:04
2017 10-core iMac Pro: 01:25

I don’t think this deficiency of FCPX on the iMac Pro is widely appreciated in the video editing community. It’s easy to say H264 is for beginners, just use ProRes or RAW. However my documentary team sometimes has several multicam teams, three drones, several motion control rigs, multiple action cams and several time lapse cameras — all in simultaneous use at a single site. All of that is 4k H264 and we can shoot nearly 1 terabyte per day, which must be offloaded and duplicated on site. ProRes would be six times that amount, so it’s just not feasible.

[Joe Marler]

[Cindy Hill] “was working on an earlier version of FCP X (10.3) as well as an earlier version of OS….I needed to update the Library as I am running new OS and new FCP. Unfortunately everything got buggy and the Library would not open nor would any of the backups…The project was working on an earlier version of OS and FCP. Should I try to load that on to a laptop that I have? Is there any kind of way to restore the Library without a backup? “

I’ve updated several huge libraries from 10.3.4 to 10.4 without major problems, but it’s possible something could go wrong. I always had a complete disk backup in case it failed.

In FCPX there are two types of libraries, managed (which contain the media) and unmanaged (which use external media). The unmanaged type are easy to manually back up and restore at a file level because they are small. The managed type can be difficult to back up using file methods since they are so large. However the FCPX “backups” are supposed to be the project-oriented elements of those, minus the data.

If your iMP has a Time Machine or any other type of backup you could restore the original library from that. What error are you getting? Will the library not open or does that open and an event (aka folder) or project (aka sequence) not open? Is there any possibility the machine or media drive is just out of space?

If the library has been updated it probably cannot be opened except in 10.4.x. If it has not been updated, then 10.3.4 could open it, but you’d need that version of FCPX. It may be too late now, but the easiest way to save that is duplicate the FCPX application file and save it before updating the app version. If you have the previous version on your laptop, at least duplicate and save that in case it’s needed and the laptop accidentally gets updated to 10.4 also.

If the library did not really update, in theory you could either (a) connect it to your laptop running 10.3.4 and try to open it or (b) Revert to 10.3.4 on the iMP by copying the .app file from laptop to your iMP, the try to open the library on the iMP using 10.3.4. If the library is stuck in some half-updated state I’m not sure what the results would be.

If I was in a situation like this, before trying anything else I’d make a complete file backup of the current library in case things get worse, that way you at least have the present version.