I have done some recent tests, comparing multicam video playback performance in Adobe Premiere Pro to Apple Final Cut Pro X. I thought this could be of interest for more people, and I really wonder what Adobe has to say about this. This is not a scientific test by any means, but I have tried my best to visualize the differences to maybe help explain why there is such a big performance difference. Take it for what it's worth.
As I say in my final notes, the inefficiencies in resource usage/management in Premiere Pro appears to be a problem in general for video playback performance, which becomes very noticeable when adding additional streams of video. The extremely aggressive/excessive pre-fetching is certainly not working in favour of Premiere Pro, especially when playing video via TCP/IP from a NAS. To make sure storage wasn't a bottleneck, i tested using internal 4TB flash storage for the media files, as you can see below.
It seems like Adobe is asking for data faster than actually needed, which results in the video playback engine choking (dropping a lot of frames) unless you have insanely fast storage in addition to a lot of fast CPU cores and a lot of memory. It is also interesting (and strange) to see how the playback is a lot less resource intensive when playing from the beginning of the timeline, compared to hitting play right after moving the timeline indicator forward.
Comparing Premiere Pro to Final Cut Pro X, the test results kind of indicate two very different approaches in terms of video playback:
Apple's approach with Final Cut Pro X appears to be quite beneficial. The fact that even an old 2015 iMac 5K with a 4-core 4GHz Intel i7 CPU and 16 GB memory is able to play the same 10 streams of media in “High Quality” both from local storage and a NAS via 10 Gbit Ethernet and SMB3, while at the same time on the same machine doing a screen recording at full 5K resolution with Telestream ScreenFlow using 1 full CPU core of the 4 (8) available. Final Cut Pro X is using less 50% of the total CPU capacity on this old iMac, which is very impressive.
See the full test with graphs and metrics in the PDF above. You can also see TCP stream analysis of single-stream video playback in the PDF.
I have included the text from the test below.
Multicam video playback performance test
iMac Pro (2017)
2.3 GHz 18-core Intel Xeon W CPU, with Turbo Boost up to 4.3 GHz
128 GB 266 MHz DDR4 ECC memory
Radeon Pro Vega 64 with 16 GB of HBM2 memory
4 TB SSD
macOS 10.14.2 (18C54)
Adobe Premiere Pro 2019, Version 13.0.2 (Build 38)
Apple Final Cut Pro X 10.4.4
Media stored internally on the iMac Pro 4 TB SSD
10 two hour long Apple ProRes 422 Standard 1920x1080 25i QuickTime MOV files, at 120 GB each.
Files recorded/created by an EVS XS Production Server.
Playing around with 10 two hour long HD streams of Apple ProRes 422 in multicam mode in Adobe Premiere Pro on the fastest Mac currently available on the market (as of January 2019), with media stored on its blazing fast internal SSD storage, works pretty well in general. At certain points however, even the 18 Intel Xeon cores (36 with HyperThreading) is pushed beyond its limits by Premiere Pro. At one point it dropped over 600 frames in a row after moving the playhead and hitting play, because the CPU hit the limit.
Enabling “High Playback Quality” makes matters even worse.
There is no noticeable performance difference between Metal and OpenCL.
Observing the incredibly bursty and wildly unpredictable/inefficient resource usage in terms of CPU, storage bandwidth and memory in these local iMac Pro tests is quite revealing. It becomes pretty clear why a NAS that can deliver up to 700 MByte/s via SMB3 to a macOS 10 Gbit client can easily become an issue. It also explains why a 10-core iMac Pro (2017) or a 12-core Mac Pro (2013) hits a CPU limit during playback and suddenly starts dropping frames, regardless of how fast the storage is.
The initial burst in CPU usage and storage bandwidth usage when hitting play after moving the playhead appears to be causing a lot of issues for Premiere Pro.
I have been doing some tests in Premiere Pro 13.0.2 on Windows 10 as well. The only Windows PC I have access to that is able to play the same 10 media files in multicam mode in Premiere Pro is a Lenovo P900 with a Dual 14-core Intel Xeon (58 cores including HyperThreading), with 128 GB memory. The CPU is still hitting the limit, but just barely manages to make it without dropping too many frames. Interestingly, the network bandwidth usage when playing media via 10 Gbit Ethernet via SMB3 from a fast NAS never goes beyond 3 Gbit/s. It looks like Premiere Pro on macOS for some reason requires faster storage than Premiere Pro on a beefy Windows 10 PC, but it looks like bursty CPU usage is a problem for Premiere Pro regardless of platform.
Playing around with the same 10 two hour long HD streams of Apple ProRes 422 in multicam mode in Apple Final Cut Pro X works incredibly well.
Actually, even an old 2015 iMac 5K with a 4-core 4GHz Intel i7 CPU and 16 GB memory is able to play the same 10 streams of media in “High Quality” both from local storage and a NAS via 10 Gbit Ethernet and SMB3, while at the same time on the same machine doing a screen recording at full 5K resolution with Telestream ScreenFlow using 1 full CPU core of the 4 (8) available. Final Cut Pro X is using less 50% of the total CPU capacity on this old iMac.
On the iMac Pro with macOS 10.14.2 and Final Cut Pro X 10.4.4 Apple do things even more efficiently than Final Cut Pro X 10.4.3 did in previous tests on macOS 10.14.0 on an iMac Pro 10-core.
Apple is clearly doing things very differently and a lot more efficiently in terms of system resource usage/management, compared to Adobe.
The inefficiencies in resource usage/management in Adobe Premiere Pro appears to be a problem in general for video playback performance, which becomes very noticeable when adding additional streams of video. The extremely aggressive/excessive pre-fetching is certainly not working in favour of Premiere Pro, especially when playing video via TCP/IP from a NAS.
Extremely well done testing!
Copy link to clipboard