VAAPI fails with Intel Arrow Lake-S

[krasty633]

Hi,
I'm running NextPVR in the official Docker container nextpvr/nextpvr_amd64 on Unraid.
I noticed playback issues while testing my recordings.

The host also has an Intel Arc A310, but that GPU is bound to vfio-pci and is not used by NextPVR.
The Arrow Lake iGPU is exposed to the NextPVR container as: /dev/dri/renderD128

The mapping on the host is:
pci-0000:00:02.0-card  -> ../card1
pci-0000:00:02.0-render -> ../renderD128

Inside the NextPVR container:
crwxrwxrwx 1 root 18 226, 128 /dev/dri/renderD128

NextPVR runs as root, so this does not appear to be a permissions issue.
1. VAAPI / web playback
With VAAPI enabled in NextPVR, playing a recording in the web interface fails with: Failed to start requested stream

Testing VAAPI directly inside the NextPVR container reproduces the problem:
ffmpeg \
  -hide_banner \
  -vaapi_device /dev/dri/renderD128 \
  -f lavfi -i color=size=1280x720:rate=25 \
  -vf 'format=nv12,hwupload' \
  -c:v h264_vaapi \
  -frames:v 25 \
  -f null -

[AVHWDeviceContext @ ...] libva: /usr/lib/x86_64-linux-gnu/dri/iHD_drv_video.so init failed
[AVHWDeviceContext @ ...] libva: /usr/lib/x86_64-linux-gnu/dri/i965_drv_video.so init failed
[AVHWDeviceContext @ ...] Failed to initialise VAAPI connection: -1 (unknown libva error).
Device creation failed: -5.
Failed to set value '/dev/dri/renderD128' for option 'vaapi_device': Input/output error
Error parsing global options: Input/output error

The versions installed in the NextPVR container are:
ffmpeg 5.1.9-0+deb12u1
intel-media-va-driver-non-free 23.1.1+ds1-1
libva2 2.17.0-1
libva-drm2 2.17.0-1

I also tested what upgrading the VAAPI stack from Debian Trixie would require. It would provide:
intel-media-va-driver-non-free 25.2.3
libva 2.22.0
libdrm 2.4.124

but it would also upgrade libc and several other core packages from Debian 12 to Debian 13, so I did not perform that upgrade.
As soon as I disable VAAPI in NextPVR, web playback works correctly.
Therefore this seems to be specifically related to the Intel VAAPI/media-driver version in the current NextPVR container and Arrow Lake-S.
Interestingly, Plex is running on the same Unraid server with the same /dev/dri device exposed and ships its own iHD_drv_video.so and works fine.

My questions is:
Is the Intel media-driver included in the current NextPVR Docker image known to be too old for Arrow Lake-S, and is there a plan to update it?

[mvallevand]

NextPVR uses the Docker from Microsoft. This fall I expect that NextPVR will be upgraded to .netcore 10 which defaults to Ubuntu 24.0.4 dropping Debian https://github.com/dotnet/dotnet-docker/...sions/6539 so you'd get whatever is in the repo at build time.

Martin

[mrdally204]

I'm also hitting a similar issue with my new server (Intel 270K PLUS) running nextpvr docker. Hoping to see your expectations on a fall update come to fruition.

[mvallevand]

You'd probably need to install a minimal 24.04 on your Docker and provide step by step instruction on what drivers and kernel are required.

NextPVR testing on .Net 10 is ongoing as is the new multi-rec capability.

Martin

[mrdally204]

You'd probably need to install a minimal 24.04 on your Docker and provide step by step instruction on what drivers and kernel are required.

NextPVR testing on .Net 10 is ongoing as is the new multi-rec capability.

Martin

It is not a show stopper for me, will patiently wait for the team to cook up something nice. Happy to set up another container to test either changes if you need some more eyes on it.

[mvallevand]

I would not expect more the default Ubuntu 24.04 Docker to be optimized without user input. There is a good chance that drivers suggested before will be different.

Martin

[mrdally204]

Hey Martin,

I used a little AI assistance to help me through, hope you don't mind.

I investigated the Quick Sync initialization failure and have some results that may help.

Hardware/host

- Intel Core Ultra 7 270K Plus, integrated GPU device ID "8086:7d67"
- Unraid kernel "6.18.58-Unraid"
- "/dev/dri/card0" and "/dev/dri/renderD128" are available in the NextPVR container
- Host logs show i915 initializing the GPU and HuC authentication succeeding

Current NextPVR image

- Debian 12
- FFmpeg "7:5.1.9-0+deb12u1"
- "intel-media-va-driver-non-free" "23.1.1+ds1-1"
- "libva2" "2.17.0-1"
- "libigdgmm12" "22.3.3+ds1-1"
- Neither "libmfx-gen1.2" nor "libvpl2" is installed

The current image fails during VA-API initialization:

libva: .../iHD_drv_video.so init failed
Failed to initialise VAAPI connection: 1 (operation failed)
Device creation failed: -5
Failed to set value 'qsv=qs,child_device=/dev/dri/renderD128'
Input/output error

Comparison test

I created a disposable Ubuntu 24.04 container with the same "/dev/dri" device access. Its stock Intel oneVPL runtime initially failed to discover an implementation. After upgrading to the Intel graphics PPA packages, including "libmfx-gen1.2" "26.3.5" and "libva" "2.24.1", "vpl-inspect" detected the integrated GPU:

Implementation #0: mfx-gen
AccelerationMode: MFX_ACCEL_MODE_VIA_VAAPI
ApiVersion: 2.17
Impl: MFX_IMPL_TYPE_HARDWARE
VendorID: 0x8086
DeviceID: 7d67/0

With that updated stack, FFmpeg successfully encoded 30 test frames using both "h264_qsv" and "hevc_qsv".

The working test used:
libmfx-gen1.2 26.3.5
libva 2.24.1
FFmpeg 6.1.1-3ubuntu5
Ubuntu 24.04's Intel media driver 24.1.0

This suggests the GPU and host kernel can support Quick Sync, while the failure is likely related to compatibility with the older media stack in the current image.

Let me know if this is helpful or if I can provide more info

[mvallevand]

That helps and sub will need to decide if he want to add an external PPA to the build. You might ask AI if mediasdk and onevpl can be installed in the same distro.

I like AI when it provides a potential solution. I don't like it forming a complicated problem without the user prompting AI to find the solution to that problem.

Martin

[mrdally204]

Can do.

According to Intel's documentation, yes, they have separate dispatchers and implementations, and coexistence is supported.

Relevant documentation:

- "Intel oneVPL documentation — coexistence with Media SDK" (https://intel.github.io/libvpl/latest/pr...ssion.html)
- "Intel oneVPL GPU runtime — supported hardware and dispatcher compatibility" (https://github.com/intel/vpl-gpu-rt)
- "Intel's guide to transitioning from Media SDK to oneVPL" (https://www.intel.com/content/www/us/en/...tel-r.html)

The key distinction is that oneVPL is the newer API and runtime path for newer Intel GPUs, while Media SDK provides legacy compatibility. Intel documents that the oneVPL dispatcher can work with either the legacy Media SDK GPU runtime or the newer oneVPL GPU implementation, depending on the hardware and application API.

So they aren't inherently mutually exclusive. The appropriate dispatcher and runtime combination still matters, particularly for applications using the older Media SDK API.