vipvip242 wrote:thanks guys for your help, i hope the BM team has perhaps something to do to optimize theses kind of footages in future releases. Until that, i'll continue to optimize them.
Your footage is 4992x3744, 23.98 fps, 10 bit 4:2:0, 194 megabit/sec. It is encoded HEVC using the Main10 L6 High profile. GOP length is 12 frames.
There are multiple types of hardware video acceleration, and for each type there are multiple versions. E.g, there are multiple versions of Intel's Quick Sync, multiple versions of nVidia's NVDEC/NVENC, multiple versions of AMD's UVD/VCE, probably multiple versions of Apple's accelerator which first appeared in the T2 chip but is now integrated within the Apple Silicon SoC.
Each of those have different capabilities and different software frameworks to access them. For each combination of accelerator type, accelerator version and software framework, the NLE may (or may not) leverage those in various ways. For a specific resolution, bit depth and chroma sampling on H264 or HEVC, there are many internal variations such as encoding profile, GOP length, # of reference frames, whether GOPs are independent or dependent, etc. Each of those may or may not be handled by accelerator hardware.
FCPX used Intel's Quick Sync for decoding from about 2011 but Premiere Pro did not use that until much later. Resolve made a big jump around ver. 15 and apparently started using decode acceleration much more effectively.
Video acceleration hardware is not like a general-purpose GPU where texture & shading units can work on a wide range of parallel tasks. Rather it must be specifically designed for certain frame rates, resolutions, bit depths, chroma samplings, and encoding formats. Anything outside the list of handled formats, and video acceleration will fall back to software decoding. The core algorithm for decoding "Long GOP" like H264 and HEVC is inherently sequential. It cannot be parallelized by the hundreds of lightweight threads a traditional GPU uses for graphics. Rather, dedicated "fixed function" hardware must simply run that core sequential algorithm quicker. In some cases that special hardware is bundled on the GPU but is logically separate from it.
Measuring playback smoothness and responsiveness is difficult. What seems smooth to one person is sluggish to another. To some people smoothness is if 1x speed forward playback has no dropped frames. To another it is how rapidly the monitor updates when moving the playhead. For many editors it is how lag-free the program monitor and playhead are when doing rapid JKL edits, esp. when switching from fast forward to reverse, or when using a hardware jog wheel.
On my 2017 iMac Pro with 16GB Vega 64 and a 10-core Xeon CPU, your 5k Panasonic HEVC clip is quite sluggish in FCPX 10.5.2, Premiere Pro 15.1.0 and Resolve Studio 17.1.1. By contrast on my 2019 MacBook Pro 16 which has an 8-core i9 "Coffee Lake" CPU and 8GB Radeon Pro 5500M, both FCPX and Resolve are much smoother. Both are running Catalina 10.15.7. That shows the difference in the underlying decode acceleration. On the iMac Pro the NLEs are probably using an early version of Apple's T2 chip which likely cannot handle that format. Xeon does not have any build-in video acceleration. On the newer MacBook Pro (which has newer accelerators, inc'l Quick Sync) the NLEs may be using those.
All Blackmagic can do is call the relevant OS-specific software frameworks to leverage whatever acceleration hardware exists on your platform. If that hardware cannot handle a certain format (which is common for new cameras and new codecs), it will be sluggish.
Wed Apr 14, 2021 4:14 pm
