Hardware acceleration
Hardware acceleration in a nutshell
OVRLEY splits the export into two phases. The overlay frames are first drawn on the
CPU and this is where widget layout, font rendering, and the overlay compositor run.
Each frame is then sent to the encoder and this is where hardware acceleration makes
a difference: instead of encoding each frame on CPU and blocking the first step,
OVRLEY can send raw frames directly to a chip on your GPU/iGPU that is dedicated and
optimized for encoding.
Hardware acceleration often cuts encode time by a factor of 3–5x for
H.264 and H.265. The catch is that not every combination of codec, hardware generation,
driver, and operating system exposes a working option. OVRLEY does not guess, but it tests
every potential encoder at launch with a "fake" synthetic frame. If that test frame fails,
the option is disabled in the UI entirely, so you never pick an encoder that would crash.
On NVIDIA GPU, NVENC/CUDA requires driver v610 or newer because FFmpeg
needs a recent version of the NVENCODE API. On Intel, Quick Sync is only
available on CPUs that include the media engine, typically Core processors from Haswell
onward. AMD AMF is supported on every modern RX GPU, but its support
depends on Ryzen CPU model or generation. On Linux, VAAPI can work if
NVENC/AMF is not supported. If you are on macOS, VideoToolbox is available
on pretty much every modern machine.
What about hardware-acceleration for Prores? FFmpeg recently added support
for Vulkan acceleration, but it is a very new feature. It is either still
not optimized very well or I was not able to configure it properly — it always performed
worse than CPU-only ProRes. In any case, Vulkan is enabled in OVRLEY so you can give it
a try, but don't expect it to be faster.