No `vkGetInstanceProcAddr` function provided, and libplacebo built without linking against this function!

[starryloki]

When using Vulkan for HDR tonemapping, there will be prompts. The issue can be reproduced on Win64 and Linux64 platforms. I found related problems and solutions in another issue.

Related parameters:

ffmpeg -i video.mkv -vf "hwupload=derive_device=vulkan,libplacebo=tonemapping=auto:colorspace=bt709:color_primaries=bt709:color_trc=bt709:format=yuv420p:upscaler=none:downscaler=none:peak_detect=1,hwupload=derive_device=cuda" OUTPUT COMMAND

Complete error output:

[libplacebo @ 0x5628c1091e80] No `vkGetInstanceProcAddr` function provided, and libplacebo built without linking against this function!
[libplacebo @ 0x5628c1091e80] Failed initializing vulkan device
[libplacebo @ 0x5628c1091e80] Failed creating Vulkan device!
[Parsed_libplacebo_1 @ 0x5628c109b9c0] Query format failed for 'Parsed_libplacebo_1': Generic error in an external library
[vf#0:0 @ 0x5628c0e456c0] Error reinitializing filters!
Failed to inject frame into filter network: Generic error in an external library
Error while filtering: Generic error in an external library
[out#0/matroska @ 0x5628c100fdc0] Nothing was written into output file, because at least one of its streams received no packets.

Related issue: https://github.com/haasn/libplacebo/issues/186

[BtbN]

That sounds like an issue in ffmpeg itself to me? Or is this related to static linking?

[starryloki]

That sounds like an issue in ffmpeg itself to me? Or is this related to static linking?

From the cited issue, it seems to be related to the installation order of dependencies. Perhaps it is necessary to adjust the order in which dependencies are imported in the script. When using jellyfin-ffmpeg, this command can work properly.

[BtbN]

The order is irrelevant. I build libplacebo with -Dvk-proc-addr=disabled, so FFmpeg can then provide it with the loader. Which it does since the addition of the libplacebo filter.

[cyanreg]

Could you try with:

ffmpeg -init_hw_device vulkan -i video.mkv -vf "hwupload,libplacebo=tonemapping=auto:colorspace=bt709:color_primaries=bt709:color_trc=bt709:format=yuv420p:upscaler=none:downscaler=none:peak_detect=1,hwupload=derive_device=cuda" OUTPUT COMMAND

[starryloki]

The order is irrelevant. I build libplacebo with -Dvk-proc-addr=disabled, so FFmpeg can then provide it with the loader. Which it does since the addition of the libplacebo filter.

The problem may not be related to ffmpeg. I downloaded a copy of the release from 2023-07-31 and found that the issue exists in both the shared and no-shared versions, while jellyfin-ffmpeg (the latest release built on 2023-08-29) does not have this problem. Here are the configuration for jellyfin-ffmpeg:

  configuration: --prefix=/ffbuild/prefix --pkg-config=pkg-config --pkg-config-flags=--static --cross-prefix=x86_64-ffbuild-linux-gnu- --arch=x86_64 --target-os=linux --extra-version=Jellyfin --extra-cflags= --extra-cxxflags= --extra-ldflags= --extra-ldexeflags=-pie --extra-libs=-ldl --enable-gpl --enable-version3 --enable-lto --disable-ffplay --disable-debug --disable-doc --disable-ptx-compression --disable-sdl2 --disable-libxcb --disable-xlib --enable-iconv --enable-libxml2 --enable-zlib --enable-libfreetype --enable-libfribidi --enable-gmp --enable-lzma --enable-fontconfig --enable-libvorbis --enable-opencl --enable-amf --enable-chromaprint --enable-libdav1d --enable-libfdk-aac --enable-ffnvcodec --enable-cuda --enable-cuda-llvm --enable-cuvid --enable-nvdec --enable-nvenc --enable-libass --enable-libbluray --enable-libmp3lame --enable-libopus --enable-libtheora --enable-libvpx --enable-libwebp --enable-libvpl --enable-libopenmpt --enable-libsrt --enable-libsvtav1 --enable-libdrm --enable-vaapi --enable-vulkan --enable-libshaderc --enable-libplacebo --enable-libx264 --enable-libx265 --enable-libzimg --enable-libzvbi

Could you try with:

ffmpeg -init_hw_device vulkan -i video.mkv -vf "hwupload,libplacebo=tonemapping=auto:colorspace=bt709:color_primaries=bt709:color_trc=bt709:format=yuv420p:upscaler=none:downscaler=none:peak_detect=1,hwupload=derive_device=cuda" OUTPUT COMMAND

I tried the method provided by @cyanreg, it ran smoothly without any error messages. However, the jellyfin version can run normally without adding "-init_hw_device vulkan". I didn't realize the correlation before. I added -init_hw_device cuda=cu:0 -filter_hw_device cu -hwaccel cuda -hwaccel_output_format cuda to my test commands to invoke hardware decoding. I started to suspect that the reason might be due to the lack of the "--enable-cuda" option. Under my testing, it seems that -init_hw_device vulkan cannot coexist with hardware decoding.

[BtbN]

The commandline might work by pure chance, but it's certainly not "healthy" if it ends up with a vulkan context without a valid loader. I intentionally disable the fallback loading libplacebo might do, since for one it heavily bites itself with static linking. And it can also cause weird issues if its loader loads different stuff than the ffmpeg once.

This is not something I can reasonably fix. Though I wouldn't even say it's broken? Maybe FFmpeg should bail out earlier, with a more useful error. Cause I can't imagine a Vulkan-hw-context without loader is valid.

[starryloki]

The commandline might work by pure chance, but it's certainly not "healthy" if it ends up with a vulkan context without a valid loader. I intentionally disable the fallback loading libplacebo might do, since for one it heavily bites itself with static linking. And it can also cause weird issues if its loader loads different stuff than the ffmpeg once.

This is not something I can reasonably fix. Though I wouldn't even say it's broken? Maybe FFmpeg should bail out earlier, with a more useful error. Cause I can't imagine a Vulkan-hw-context without loader is valid.

I originally thought it was a problem with compilation and building. From a long-term perspective, disabling fallback loading is the correct choice. Thank you for your professional answers. As a beginner in ffmpeg, I have learned a lot of new things from communicating with you.