Hello!
I’m using Shotcut 20.04.12 from Snap store on Ubuntu 20.04 LTS. GPU I have is Intel UHD Graphics 630. I would really like to use GPU encoding acceleration for H264 using VAAPI, but it seems not to be working in Shotcut. My system-wide libva libraries definitely support GPU encoding (OBS Studio uses that and I can even do HEVC), but the ones bundled with Shotcut throw out an error. I couldn’t force Shotcut to use system-wide libraries by using adding LIBVA_DRIVERS_PATH env variable to shortcut. Is there a way to make Shotcut use libva from system scope for encoding?
This is a drawback of our portable binary builds need to run on older, but VA-API is very version sensitive between the library, user space driver, and kernel module. The combination means it only works on older systems such as 16.04 through 18.04.
You might have better luck with the flatpak since it is based on newer libs. Or you can look for Debian packages that we are not involved with.
I’d like to avoid anything unofficial while still keeping updates, so I tried Flatpak and I managed to at least hack it through. Thanks for the suggestion!
It appears that there was a bug in libva, making it search for incorrect driver in case of Intel GPUs. It’s looking for iris_drv_video.so, which is not present anymore. This has been merged month ago, so the fix is relatively fresh: https://github.com/intel/libva/issues/396
With flatpack, I was able to (at least temporarily) force it to work by adding a symlink in Flatpak VAAPI files (something I believe is not possible in Snap):
# ls -altr /var/lib/flatpak/runtime/org.freedesktop.Platform.VAAPI.Intel/x86_64/19.08/active/files
total 35572
drwxr-xr-x 3 root root 4096 sty 1 1970 lib
-rwxr-xr-x 2 root root 8168496 maj 12 10:29 i965_drv_video.so
-rwxr-xr-x 2 root root 28235312 maj 12 10:29 iHD_drv_video.so
lrwxrwxrwx 1 root root 16 maj 12 11:43 iris_drv_video.so -> iHD_drv_video.so
Et voila:
[AVHWDeviceContext @ 0x7fc75c217900] Opened VA display via X11 display :99.0.
[AVHWDeviceContext @ 0x7fc75c217900] libva: VA-API version 1.5.0
[AVHWDeviceContext @ 0x7fc75c217900] libva: va_getDriverName() returns 0
[AVHWDeviceContext @ 0x7fc75c217900] libva: Trying to open /usr/lib/x86_64-linux-gnu/dri/iris_drv_video.so
[AVHWDeviceContext @ 0x7fc75c217900] libva: Trying to open /usr/lib/x86_64-linux-gnu/dri/intel-vaapi-driver/iris_drv_video.so
[AVHWDeviceContext @ 0x7fc75c217900] libva: Found init function __vaDriverInit_1_5
[AVHWDeviceContext @ 0x7fc75c217900] libva: va_openDriver() returns 0
[AVHWDeviceContext @ 0x7fc75c217900] Initialised VAAPI connection: version 1.5
[AVHWDeviceContext @ 0x7fc75c217900] VAAPI driver: Intel iHD driver - 1.0.0.
[AVHWDeviceContext @ 0x7fc75c217900] Driver not found in known nonstandard list, using standard behaviour.
[mlt_buffer @ 0x7fc75c269b80] w:1920 h:1080 pixfmt:nv12 tb:1/30 fr:30/1 sar:0/1 sws_param:
[h264_vaapi @ 0x7fc75c201e80] Input surface format is nv12.
[h264_vaapi @ 0x7fc75c201e80] Using VAAPI profile VAProfileH264Main (6).
[h264_vaapi @ 0x7fc75c201e80] Using VAAPI entrypoint VAEntrypointEncSlice (6).
[h264_vaapi @ 0x7fc75c201e80] Using VAAPI render target format YUV420 (0x1).
I guess final solution will be to wait for a possible upgrade of libva in flatpak/snap build.
A possible hack for snap is to edit the /snap/shotcut/current/Shotcut.app/shotcut (or similar, going off memory) launch script to change the VAAPI LIBVA_DRIVERS_PATH environment variable and do your symlink to package-managed files. I worry, however, that the included/linked libva will not accept the version of these userspace drivers. I am curious to hear if it works.
Currently, the snap is unconfined and simply the same binary bundle as the portable tar and AppImage. Please consider to volunteer to make a proper snap for us.
Tried that already, but it seems encoder doesn’t even see LIBVA_DRIVERS_PATH provided that way. It still tried to look inside snap image for libs, and like you said, libva included in snap probably is too old for the new libraries to work.
I wonder if the proper solution would be not to include libva and drivers at all, if they are so kernel-version-sensitive and instead rely on user to install them separately (especially when on Ubuntu one has to install -non-free version of driver for encoding to work properly). I could then possibly try to build a snap, but I have virtually no knowledge of snap’s ecosystem and have never build a package before.