чт, 12 дек. 2024 г., 00:43 Terje J. Hanssen via Cin < [email protected]>:
> 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 > <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. > > > > > > > > > > > > -- > Cin mailing list > [email protected] > https://lists.cinelerra-gg.org/mailman/listinfo/cin >
-- Cin mailing list [email protected] https://lists.cinelerra-gg.org/mailman/listinfo/cin
