

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.Įncode time for a 2:00 UHD 4k ProRes clip to 4k 1-pass H264: On 4k H264, FCPX timeline operations remain much quicker and more responsive than Premiere, esp for JKL.
Quicksync h.264 mac#
So Premiere 2018 H264 *encode* performance now rivals FCPX on the same Mac hardware, but decode performance is not dramatically improved.
Quicksync h.264 code#
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. However it appears the AMD UVD hardware acceleration on the iMP is not as effective as Quick Sync on the i7. H264 decoding is hardware accelerated on FCPX - that’s obvious due to the lower CPU levels for equivalent actions vs Premiere. The iMP has more CPU horsepower so it was a bit quicker.īy 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). CPU graphs shows Premiere timeline scrubbing (without effects) is highly CPU-intensive and the GPU isn’t used much. 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.
Quicksync h.264 1080p#
On a 2 min UHD 4k XAVC-S clip, and encoding to 1-pass 20 mbps 1080p H264, it was.Įncode time using the same parameters and same clip on FCPX 10.4.2 was: There’s no question PP 2018 is a lot faster at encoding than 2017. Selecting Metal vs OCL made no difference for either decode or encode. 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). Decoding, as measured by viewer frame rate during timeline scrubbing and JKL responsiveness, is about the same between PP 2017 vs 2018. I tested 1080p AVCHD and Sony 4k XAVC-S, and for both it appears to be encode only. “Is it just encodes? If this accelerates decode, too, does it make working with those devilish H.264 formats any smoother?”


Test: Encode from 4k timeline to 1-pass H264 at 30 mbps (4k) or 20 mbps (1080p) Test material: 1:20 UHD 4k 8-bit 4:2:0 100 mbps from Sony A7RII

In limited tests I’ve run on both a 2017 top-spec iMac 27 and a 10-core Vega 64 iMac Pro, Premiere CC was faster in some cases than FCPX at H264 encoding on the iMac, and faster in every case on the iMac Pro. It seems Adobe also did this on the iMac Pro, as Premiere CC exhibits hardware-accelerated transcoding speed on that platform. Intel’s Xeon CPU doesn’t have Quick Sync but with FCPX 10.4.x, Apple apparently began using AMDs UVD/VCE hardware as a substitute. To enable it on Windows several steps are needed (see below video) it’s automatically used on Mac if the hardware supports it. It makes a huge difference when dealing with H264 material on either decode or encode side. Starting with 2018 it’s supported on both Windows and Mac. A year or two ago Premiere started using this on Windows (to some degree) but not Mac. For years Premiere has been criticized as being much slower than FCPX at H264 encode and decode due to not using Quick Sync.
