Hardware Acceleration on Jellyfin lxc for Intel I9 10th Gen

[js-monroe]

I'm running a Jellyfin container in Proxmox and cannot get hardware acceleration to work. I realise this isn't exactly to do with ProxMox, but perhaps someone can lend some insights on what may be wrong in this case.

I'm following the guide here (for linux with Intel CPU, so I want VAAPI acceleration, I believe):
https://jellyfin.org/docs/general/administration/hardware-acceleration/intel/
*See the relevant section I am following at the very end of this post*

-With hardware acceleration enabled, my client app is getting this:
*Video plays back normally with hardware acceleration off.



-Checking the logs I am seeing this:

[AVHWDeviceContext @ 0x56451b810b00] No VA display found for device /dev/dri/renderD128.
Device creation failed: -22.
Failed to set value 'vaapi=va:/dev/dri/renderD128' for option 'init_hw_device': Invalid argument
Error parsing global options: Invalid argument

-From the Jellyfin console in ProxMox, I navigate to /dev/dri, but /dri does not exist.
As detailed in the steps below, I have changed permissions but it seems the /dri directory isn't present at all and I don't know why. I have changed permissions as the guide mentions, but it seems the /dri directory truly doesn't exist in the first place. Initially I had an AMD GPU in this system, but since removed it and set the BIOS to use the integrated GPU (from the CPU) if that even matters?

*In the final step of the instructions below: Check the OpenCL runtime status (by issuing the command):

/usr/lib/jellyfin-ffmpeg/ffmpeg -v verbose -init_hw_device vaapi=va:/dev/dri/renderD128 -init_hw_device opencl@va

This is the output:

ffmpeg version 5.1.3-Jellyfin Copyright (c) 2000-2022 the FFmpeg developers
built with gcc 12 (Debian 12.2.0-14)
configuration: --prefix=/usr/lib/jellyfin-ffmpeg --target-os=linux --extra-libs=-lfftw3f --extra-version=Jellyfin --disable-doc --disable-ffplay --disable-ptx-compression --disable-static --disable-libxcb --disable-sdl2 --disable-xlib --enable-lto --enable-gpl --enable-version3 --enable-shared --enable-gmp --enable-gnutls --enable-chromaprint --enable-libdrm --enable-libass --enable-libfreetype --enable-libfribidi --enable-libfontconfig --enable-libbluray --enable-libmp3lame --enable-libopus --enable-libtheora --enable-libvorbis --enable-libopenmpt --enable-libdav1d --enable-libwebp --enable-libvpx --enable-libx264 --enable-libx265 --enable-libzvbi --enable-libzimg --enable-libfdk-aac --arch=amd64 --enable-libsvtav1 --enable-libshaderc --enable-libplacebo --enable-vulkan --enable-opencl --enable-vaapi --enable-amf --enable-libmfx --enable-ffnvcodec --enable-cuda --enable-cuda-llvm --enable-cuvid --enable-nvdec --enable-nvenc
libavutil 57. 28.100 / 57. 28.100
libavcodec 59. 37.100 / 59. 37.100
libavformat 59. 27.100 / 59. 27.100
libavdevice 59. 7.100 / 59. 7.100
libavfilter 8. 44.100 / 8. 44.100
libswscale 6. 7.100 / 6. 7.100
libswresample 4. 7.100 / 4. 7.100
libpostproc 56. 6.100 / 56. 6.100
[AVHWDeviceContext @ 0x55f8f269e2c0] Failed to open /dev/dri/renderD128 as DRM device node.
[AVHWDeviceContext @ 0x55f8f269e2c0] No VA display found for device /dev/dri/renderD128.
Device creation failed: -22.
Failed to set value 'vaapi=va:/dev/dri/renderD128' for option 'init_hw_device': Invalid argument
Error parsing global options: Invalid argument

Here is the section of the guide I am following:

Configure On Linux Host​

Debian And Ubuntu Linux​

The jellyfin-ffmpeg5 deb package required by Jellyfin 10.8 comes with all necessary user mode Intel media drivers.

Besides that you only need to install the OpenCL runtime and configure the the permission of jellyfin user.


note
Root permission is required.

1. Assuming you have added the jellyfin repository to your apt source list and installed the jellyfin-server and jellyfin-web.
2. Install the jellyfin-ffmpeg5 package. Remove the deprecated jellyfin meta package if it breaks the dependencies:
   sudo apt update && sudo apt install -y jellyfin-ffmpeg5

Make sure at least one renderD* device exists in /dev/dri. Otherwise upgrade your kernel or enable the iGPU in the BIOS.


note
Note the permissions and group available to write to it, in this case it is render:
$ ls -l /dev/dri

total 0
drwxr-xr-x 2 root root 120 Mar 5 05:15 by-path
crw-rw----+ 1 root video 226, 0 Mar 5 05:15 card0
crw-rw----+ 1 root video 226, 1 Mar 5 05:15 card1
crw-rw----+ 1 root render 226, 128 Mar 5 05:15 renderD128
crw-rw----+ 1 root render 226, 129 Mar 5 05:15 renderD129


Add the jellyfin user to the render group, then restart jellyfin service:


note
On some releases, the group may be video or input instead of render.
sudo usermod -aG render jellyfin
sudo systemctl restart jellyfin

• Check the version of intel-opencl-icd thats the Linux distro provides:
  $ apt policy intel-opencl-icd
  
  intel-opencl-icd:
  Installed: (none)
  Candidate: 22.14.22890-1
  ...
  
  
  
• If the version is newer than 22.xx.xxxxx just install it. Otherwise install from Intel compute-runtime repository.
  sudo apt install -y intel-opencl-icd

Check the supported QSV / VA-API codecs:


note

• iHD driver indicates support for the QSV and VA-API interfaces.
• i965 driver indicates only support for the VA-API interface, which should only be used on pre-Broadwell platforms.

sudo /usr/lib/jellyfin-ffmpeg/vainfo --display drm --device /dev/dri/renderD128

libva info: VA-API version 1.17.0
libva info: Trying to open /usr/lib/jellyfin-ffmpeg/lib/dri/iHD_drv_video.so
libva info: Found init function __vaDriverInit_1_17
libva info: va_openDriver() returns 0
Trying display: drm
vainfo: VA-API version: 1.17 (libva 2.17.0)
vainfo: Driver version: Intel iHD driver for Intel(R) Gen Graphics - 23.1.2 (xxxxxxx)
vainfo: Supported profile and entrypoints
...


Check the OpenCL runtime status:

sudo /usr/lib/jellyfin-ffmpeg/ffmpeg -v verbose -init_hw_device vaapi=va:/dev/dri/renderD128 -init_hw_device opencl@va

[AVHWDeviceContext @ 0x55cc8ac21a80] 0.0: Intel(R) OpenCL HD Graphics / Intel(R) Iris(R) Xe Graphics [0x9a49]
[AVHWDeviceContext @ 0x55cc8ac21a80] Intel QSV to OpenCL mapping function found (clCreateFromVA_APIMediaSurfaceINTEL).
[AVHWDeviceContext @ 0x55cc8ac21a80] Intel QSV in OpenCL acquire function found (clEnqueueAcquireVA_APIMediaSurfacesINTEL).
[AVHWDeviceContext @ 0x55cc8ac21a80] Intel QSV in OpenCL release function found (clEnqueueReleaseVA_APIMediaSurfacesINTEL).
...

• If you wish to use the second GPU, change renderD128 to renderD129 in the Jellyfin dashboard.
• Enable QSV or VA-API in Jellyfin and uncheck the unsupported codecs.

Hopefully this explains it clearly and the right person(s) see this and can easily help. Thank You!

 

[Lukas Wagner]

There is a 'LXC on Proxmox' section in the guide you have linked, are you following that?

The key parts:

• The LXC container needs to be privileged
• The device must be passed through to the container, you do so by editing the config file for the container in /etc/pve/lxc/<id>.conf :
  

  lxc.cgroup2.devices.allow: c 226:0 rwmlxc.cgroup2.devices.allow: c 226:128 rwm
  lxc.mount.entry: /dev/dri/renderD128 dev/dri/renderD128 none bind,optional,create=file

• The jellyfin user inside the container must be in the correct group. On the host, the device should have the 'render' group, but I can happen that there is a GID mismatch between the jellyfin container and the host. As a result, the group 'render' on the host might actually map to a different group in the CT. Just do a ls -la /dev/dri/ in the container and then you will see, what group is used for the device. You can either add the jellyfin user to this group, or try to remap GIDs in the container configuration. The former might be much easier.

 

[js-monroe]

There is a 'LXC on Proxmox' section in the guide you have linked, are you following that?

The key parts:

• The LXC container needs to be privileged
• The device must be passed through to the container, you do so by editing the config file for the container in /etc/pve/lxc/<id>.conf :
  

  lxc.cgroup2.devices.allow: c 226:0 rwmlxc.cgroup2.devices.allow: c 226:128 rwm
  lxc.mount.entry: /dev/dri/renderD128 dev/dri/renderD128 none bind,optional,create=file

• The jellyfin user inside the container must be in the correct group. On the host, the device should have the 'render' group, but I can happen that there is a GID mismatch between the jellyfin container and the host. As a result, the group 'render' on the host might actually map to a different group in the CT. Just do a ls -la /dev/dri/ in the container and then you will see, what group is used for the device. You can either add the jellyfin user to this group, or try to remap GIDs in the container configuration. The former might be much easier.

Thanks for the details. However, I realize using an LXC for my purposes is not going to work as I need a VM with proper web services running on it, as Jellyfin only does http.

 

[Lukas Wagner]

Thanks for the details. However, I realize using an LXC for my purposes is not going to work as I need a VM with proper web services running on it, as Jellyfin only does http.

Well, you can just install a web server (apache, nginx, caddy) in the same container and request a HTTPS certificate for that, no need to switch to a VM for that. Or you can have a second VM/CT that plays the role of the reverse proxy. The world is your oyster.

The setup that I have at home is to have jellyfin in a container and a reverse proxy with TLS termination in a separate VM. The reverse proxy proxies no only jellyfin, but also a few other services, that is the main reason why I put it in a separate container. If you only have jellyfin running, you might as well put the reverse proxy in the same VM/CT.

Please also note that you needed to pass through your whole iGPU to the VM if you want to have hardware transcoding in Jellyfin. This means that the host (Proxmox VE) cannot access it any more.

 

[js-monroe]

Well, you can just install a web server (apache, nginx, caddy) in the same container and request a HTTPS certificate for that, no need to switch to a VM for that. Or you can have a second VM/CT that plays the role of the reverse proxy. The world is your oyster.

The setup that I have at home is to have jellyfin in a container and a reverse proxy with TLS termination in a separate VM. The reverse proxy proxies no only jellyfin, but also a few other services, that is the main reason why I put it in a separate container. If you only have jellyfin running, you might as well put the reverse proxy in the same VM/CT.

Please also note that you needed to pass through your whole iGPU to the VM if you want to have hardware transcoding in Jellyfin. This means that the host (Proxmox VE) cannot access it any more.

I appreciate the info. Initially I had a container but kept encountering situations where hardware acceleration wasn't working. Then I couldn't get a web server to work. That's why I thought a VM would be better.

I didn't realise I would lose transcoding everywhere else if I used a VM. It's all of these details that I lack that have caused me to setup Proxmox completely wrong in the first place, and then have to discover later why something won't work.

I have web services running on another VM, but for some reason I couldn't get anything to work on a Jellyfin container previously. So now I'm wondering where to go from here. Clearly I lack an overall understanding of how I should proceed.

I will try a container again and go from there, but so far, by the time I set something up and have a major problem, I find out it's because something was setup in Proxmox further up the chain that simply won't work. To which I'm finding out only after I have something already setup. I guess the VM space has a lot more pre-requisite knowledge than I had first realised. Thank You.