FFmpeg-Builds
FFmpeg-Builds copied to clipboard
BtbN
Enable oneVPL(libvpl) support
oneVPL(libvpl) has been added recently as the successor of mediaSDK(libmfx). But this requires a new dispatcher, which means mfx_dispatch may not work in this case. --enable-libmfx and --enable-libvpl are mutually exclusive.
Does it offer any advantages? Adding it would mean complicating the build process, since support for it is not uniform across ffmpeg versions.
I just noticed that support for that was merged literally 9 hours ago. That's a bit early to consider adding support, since stuff might still be in flux/broken.
Give it a few weeks/months, and once it has any actual advantage, it can be added. The build system for it looks fairly friendly for building a pure static dispatcher without much fuzz.
I added a build script for it, but it's not yet enabled. It's available for custom builds though, if you want to test it.
It works. Thanks for your instant response.
ffmpeg version N-107767-g7158f1e64d-20220812 Copyright (c) 2000-2022 the FFmpeg developers
built with gcc 12.1.0 (crosstool-NG 1.25.0.55_3defb7b)
configuration: --prefix=/ffbuild/prefix --pkg-config-flags=--static --pkg-config=pkg-config --cross-prefix=x86_64-w64-mingw32- --arch=x86_64 --target-os=mingw32 --enable-gpl --enable-version3 --disable-debug --enable-shared --disable-static --disable-w32threads --enable-pthreads --enable-iconv --enable-libxml2 --enable-zlib --enable-libfreetype --enable-libfribidi --enable-gmp --enable-lzma --enable-fontconfig --enable-libvorbis --enable-opencl --disable-libpulse --enable-libvmaf --disable-libxcb --disable-xlib --enable-amf --enable-libaom --enable-libaribb24 --enable-avisynth --enable-libdav1d --enable-libdavs2 --disable-libfdk-aac --enable-ffnvcodec --enable-cuda-llvm --enable-frei0r --enable-libgme --enable-libass --enable-libbluray --enable-libjxl --enable-libmp3lame --enable-libopus --enable-librist --enable-libtheora --enable-libvpx --enable-libwebp --enable-lv2 --enable-libvpl --enable-libopencore-amrnb --enable-libopencore-amrwb --enable-libopenh264 --enable-libopenjpeg --enable-libopenmpt --enable-librav1e --enable-librubberband --enable-schannel --enable-sdl2 --enable-libsoxr --enable-libsrt --enable-libsvtav1 --enable-libtwolame --enable-libuavs3d --disable-libdrm --disable-vaapi --enable-libvidstab --enable-vulkan --enable-libshaderc --enable-libplacebo --enable-libx264 --enable-libx265 --enable-libxavs2 --enable-libxvid --enable-libzimg --enable-libzvbi --extra-cflags=-DLIBTWOLAME_STATIC --extra-cxxflags= --extra-ldflags=-pthread --extra-ldexeflags= --extra-libs=-lgomp --extra-version=20220812
libavutil 57. 33.100 / 57. 33.100
libavcodec 59. 42.101 / 59. 42.101
libavformat 59. 30.100 / 59. 30.100
libavdevice 59. 8.101 / 59. 8.101
libavfilter 8. 46.101 / 8. 46.101
libswscale 6. 8.102 / 6. 8.102
libswresample 4. 8.100 / 4. 8.100
libpostproc 56. 7.100 / 56. 7.100
[AVHWDeviceContext @ 00000277991dc840] Defaulting child_device_type to AV_HWDEVICE_TYPE_D3D11VA for oneVPL.Please explicitly set child device type via "-init_hw_device" option if needed.
[AVHWDeviceContext @ 00000277991dc840] Use Intel(R) oneVPL to create MFX session, API version is 2.7, the required implementation version is 1.3
Breaks Win32 builds:
2022-08-17T13:23:26.0201873Z > [layer-50-onevpl 1/1] RUN --mount=src=scripts.d/50-onevpl.sh,dst=/stage.sh run_stage /stage.sh:
2022-08-17T13:23:26.0202399Z #65 62.24 -- Up-to-date: /opt/ffbuild/lib/x86/libvpl.a
2022-08-17T13:23:26.0202837Z #65 62.24 -- Up-to-date: /opt/ffbuild/lib/x86/libvpl.a
2022-08-17T13:23:26.0203328Z #65 62.24 -- Installing: /opt/ffbuild/lib/x86/cmake/vpl/VPLConfig.cmake
2022-08-17T13:23:26.0203873Z #65 62.24 -- Installing: /opt/ffbuild/lib/x86/cmake/vpl/VPLConfigVersion.cmake
2022-08-17T13:23:26.0205137Z #65 62.25 -- Installing: /opt/ffbuild/lib/x86/pkgconfig/vpl.pc
2022-08-17T13:23:26.0205598Z #65 62.25 -- Installing: /opt/ffbuild/etc/vpl/vars.bat
2022-08-17T13:23:26.0206353Z #65 62.25 -- Installing: /opt/ffbuild/etc/vpl/vars32.bat
2022-08-17T13:23:26.0207314Z #65 62.25 + rm -rf /opt/ffbuild/etc /opt/ffbuild/share
2022-08-17T13:23:26.0207650Z #65 62.28 + cat /opt/ffbuild/lib/pkgconfig/vpl.pc
2022-08-17T13:23:26.0208602Z #65 62.28 cat: /opt/ffbuild/lib/pkgconfig/vpl.pc: No such file or directory
Same story in another repo: https://github.com/sudo-nautilus/FFmpeg-Builds-Win32/actions/runs/2875284634.
I've no idea. Win64, Linux x64, Linux ARM64 are all fine. Only Win32 fails.
They for some reason decide to override the libdir to some extremely broken non-standard something on 32bit: https://github.com/oneapi-src/oneVPL/blob/e460e62f978f4dad304b08cc2914a02ffbc4a5f0/cmake/oneAPIInstallDirs.cmake#L11
The reason for the “weird library install overrides by onevpls build system” is that there is a requirement to be able to build VPL based 32bit and 64 bit applications. So I need to be able to build hello-decode targeting either 32 bits or 64 bits using standards that CMAKE developers expect (-A Win32 or -A x64). This build of hello-decode should find the correct VPL lib without the application knowing the location (just that it needs to depend on VPL lib via its .cmake file)
if(WIN32 AND CMAKE_SIZEOF_VOID_P EQUAL 4)
set(CMAKE_LIBRARY_ARCHITECTURE x86)
endif()
find_package(VPL REQUIRED)
target_link_libraries(${TARGET} VPL::dispatcher)
If there is a more standard way to do this I’d love to align to it.
See https://cmake.org/cmake/help/latest/variable/CMAKE_LANG_LIBRARY_ARCHITECTURE.html. What should we be doing on windows instead?
The standard way would be to rely on GNUInstallDirs and let the user override to their desired location during configure-time. Deviating from defaults like that is not very pretty, and while easily worked around, has every user or packager do a double take for sure.
On top of that, the path I'd at least somewhat expect would be lib32, instead of an x86 subdir in lib. That's at least pretty standard on every distro. But even there is some disagreement and deviation depending on multilib configuration. Some put the native arch into lib, others always in lib64 and have x86 in plain lib.
So really the only sane thing for any buildsystem to do is to use the GNU standard paths, and leave everything else to whoever is building.
@BtbN
GnuInstalldirs source already takes care of lib32 vs arch tuple on Linux and we respect that. The problem is that it offers no help/standard for Windows, so we need to pick a convention.
Microsoft uses x86 and x64 directories for Visual Studio runtimes.
The install location may be a bit of a red herring. It seems the real issue is the expected location of the pkg-config file. In the FFmpeg build for Windows how is PKG_CONFIG_PATH set?
So really the only sane thing for any buildsystem to do is to use the GNU standard paths, and leave everything else to whoever is building.
Our problem is that we also need to provide good out of the box/default experience to people building applications that may be 32 bit or 64 bit after they build VPL
FFmpeg itself does not set it at all, and just expected pkg-config to work correctly. This set of scripts just hardcodes it to the usual defaults: https://github.com/BtbN/FFmpeg-Builds/blob/master/images/base-win64/Dockerfile#L35
So far everything has complied to that by default, libvpl is the first outlier that comes to mind. I can see the situation on a Windows-Host to be odd. But on Linux, even when cross compiling, it's pretty well defined.
So looks like pkg-config files not installed in correct location in cross compilation scenarios, and we need to figure out if we are cross compiling and install files in the right place in cross environment.