To clarify some pieces once again, I put up some basic statements or
questions:
For an end-user to utilize video acceleration support, he/she need a
computer with supported graphical hardware with libs/API and drivers
for it(?)
The libs and drivers can be dynamical linked (enabled) to the system
or static built (embedded) in CinGG?
So what happened when adding oneVPL (qsv) support to the build
system; dynamic linked to system or static added embedded into the
build?
If oneVPL was dynamic linked, the qsv support may be be distribution
specific, or if static built it will be generic available on
compliant hardware?
Is it correct to say the build machine does not need the specific
graphical hardware, but needs the actual graphic libs installed to
build Cingg with it?
Could in principle similar methods be extended to include broader
video acceleration support for AMD/amf and NVIDIA/nvenc?
--------------
So a confusing piece if "oneVPL" instead should have been replaced
with "libvpl?, because I just read
Note for Users of Intel® oneAPI Video Processing
Library (oneVPL) and for Intel® Media SDK
https://www.intel.com/content/www/us/en/developer/tools/vpl/overview.html
oneVPL is now called the Intel® Video Processing Library
(Intel® VPL). The library will no longer be part of the oneAPI
specification so that Intel can focus on providing video
processing features on Intel GPUs.
In comparision on openSUSE/Slowroll on Intel, there are libvpl(2)
(and no oneVPL).
The oneAPI Video Processing Library (oneVPL) provides
a single video processing API for encode, decode, and video
processing that works across a wide range of accelerators.
ffmpeg similar has --enable-libvpl --enable-vaapi --enable-vdpau
--enable-vulkan