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(?)
yes
The libs and drivers can be dynamical linked (enabled) to the system
or static built (embedded) in CinGG?
well, here it gets complicated. vaapi and such actually TWO libs at least - one with generic code ffmpeg use, and hw-specific driver lib. Both are shared (*.so) and moreover runtime path where given generic lib looks for drivers depend on Linux distro/how it was compiled.
So what happened when adding oneVPL (qsv) support to the build
system; dynamic linked to system or static added embedded into the
build?
dynamic
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?
as above, at least due to different driver path it will not work out of the box everywhere even if static (*.a) libs were used. You probably should ask for details on ffmpeg or intel mailing lists ...
Distributions nowadays tend to avoid *.a files if possible, due to consistency in upgradeability (if you embed say libpng at some point any update to it will require not just updating *.so but also any application with embedded libpng, and there is no simple way to even tell from stripped binary that symbols it use)
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?
yes
Could in principle similar methods be extended to include broader
video acceleration support for AMD/amf and NVIDIA/nvenc?
nvenc already supported, I think? At some point I tried it with GF710 on livedvd and it was working for me. try to test it if you have proprietary nvidia drivers.
amf ... I have no idea how well it work or that it demand lib-wise. As long as it just ffmpeg switch - I can try to add this too but honestly, isn't it more like "checkbox" feature? Does it provide anything over vaapi?
--------------
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
naming a bit confusing, but this is what intel invented!
Probably OneVPL is technology/marketing name and libvpl is library component ffmpeg actually looks for.