arc wrote: ... In my properties panel the video file comes up as H.264 but once again the Intel Quick Sync is not being used at all. Perhaps FCPX cannot make use of Intel's Quick Sync with these video clips as well...
Normally H.264 is synonymous with "Long GOP" inter-frame compression, which means all frames of a group are not stored, only metadata. This places great CPU burden on decoding this for playback, or encoding for output. Quick Sync or similar hardware-based acceleration can really help.
The core algorithm is inherently sequential, so normal GPU methods cannot accelerate this, no matter how fast the GPU. While Quick Sync is associated with the Intel CPU's integrated GPU, in reality is has little to do with that. It is totally separate hardware that only uses the GPU frame buffer and bus to get access to the data. The iMac Pro and 2018 and later MacBook Pros apparently use the T2 chip for this, so that shows how functionally separate the decode/encode acceleration is.
However *Intra-frame* compression can less commonly be classified as H.264. In this method each frame is stored separately and the only compression is within the frame, like .jpg. It's possible Quick Sync or similar hardware accelerated decode/encode is not as useful for this compression type. Some "All Intra" 4k material is very fast on FCPX such as the 4k 300 mbps stuff from a Canon XC15. Other "All Intra" material is much slower, like the GH5 codec the OP mentioned. I don't know why the difference for such superficially similar codecs.
Quick Sync and similar methods are called "fixed function" hardware. They are fast for the narrow range of cases they fit. Outside that range they do nothing. It is common that small codec variations may not work, e.g, on FCPX 4k 10-bit HEVC export is not accelerated but Premiere apparently is (on Mac).
arc wrote: ...The second video clip is much harder to playback using Premiere Pro. Does FCPX behave the same way?
The second clip is encoded just like the first one, however the short length of the first one enables Premiere to do some kind of optimization. They may be invisibly pre-rendering a small buffer, but this apparently isn't scalable for a real-world clip or timeline. In general FCPX 10.4.7 and Resolve 16.1 are much faster and smoother on this type of material (on Mac) than Premiere 13.1.5. However that varies between versions and hardware. FCPX 10.4.6 was not as fast, and the 10.4.7 improvement is more pronounced on the iMac Pro than on a 2017 i7 iMac.
However - these differences can matter less than first appears. With 4k H.264 there is "performance threshold" problem. It's not good enough that one NLE or hardware platform be faster than the other. If it is not *sufficiently* fast to meet the editor's needs without proxies, then you must create those. With proxies all NLEs are fast on almost any hardware.
The needs of each editor varies. E.g, for scripted work where an assistant editor has already done much of the content curation, a lead editor might be OK with a bit of timeline lag. By contrast for documentary work on FCPX, the Event Browser and skimmer must remain super fast, else they can't be used as designed.
My system can playback both video clips at full resolution with high quality enabled super easy. Trying to playback multiple layers work fine with the one video clip but not the other as you can see in the video below. Having said that thanks for the video clips.