Plex Transcoder Cannot Initialize VAAPI on Intel Arc Pro A40 (DG2)

[Menel]

Pretty simple.
Ubuntu Desktop LTS, Docker, as below:

Home cameras via Homebridge Docker get routed through igpu.
Plex gets directed to the sparkle a310.

[Paolino625]

Hello everyone.

I wanted to point out that I’m experiencing the exact same problem as slhogg.

Environment

Hardware

• CPU: AMD 9700X
• GPU: Intel Arc A380
• Host OS: Proxmox 9.1.2 (kernel 6.17.2-2-pve)
• GPU passthrough: via PCIe to LXC (works correctly)

LXC

• OS: Ubuntu 25.10
• Kernel: 6.17.2-2-pve
• CPU: 6 cores
• Memory: 2 GB
• Drivers: xe drivers loaded
• Plex user: plex

Plex

• Plex Media Server version: 1.43.0.10389
• Installation method: Proxmox Helper Scripts ( Proxmox VE Helper-Scripts )
• GPU selected in Settings → Transcoder: Intel DG2 Arc A380

Analysis

I followed the same debugging steps and got the same results.

1) vainfo

sudo -u plex vainfo --display drm --device /dev/dri/renderD128

Works correctly.

2) ffmpeg with VAAPI

sudo -u plex ffmpeg -hwaccel vaapi -vaapi_device /dev/dri/renderD128 -i "/mnt/synology/videoPaolo/Video.mp4" -t 5 -f null -

Works correctly.

3) Plex Transcoder with VAAPI

sudo -u plex /usr/lib/plexmediaserver/Plex\ Transcoder\ -hwaccel vaapi\ -hwaccel_device /dev/dri/renderD128\ -vaapi_device /dev/dri/renderD128\ -i "/mnt/synology/videoPaolo/Video.mp4"\ -t 5\ -f null -

Does not work.

[AVHWDeviceContext @ 0x7d3afdce8dc0] Failed to initialise VAAPI connection: -1 (unknown libva error).
Device creation failed: -5.
Failed to set value '/dev/dri/renderD128' for option 'vaapi_device': I/O error
Error parsing global options: I/O error

---

Conclusion

Unlike slhogg I’m running a different GPU (Intel Arc A380).
It appears to be supported in Plex based on other users’ reports, but I’m running into the same issue, so it looks like we’re in the same boat.

Has the Plex team shared any updates on a fix?
In the meantime, does anyone know of a reliable workaround? It’s honestly pretty frustrating because I bought the A380 specifically to use it with Plex for hardware transcoding, and right now I can’t.

Thanks everyone in advance for any help or suggestions.

[ChuckPa]

We’re finishing the new build system and repository.
(what I’m working on today)

Chris will be able to build proper packages VERY soon.

With this:

sudo -u plex /usr/lib/plexmediaserver/Plex\ Transcoder\ -hwaccel vaapi\ -hwaccel_device /dev/dri/renderD128\ -vaapi_device /dev/dri/renderD128\ -i “/mnt/synology/videoPaolo/Video.mp4”\ -t 5\ -f null -

Why are you escaping the spaces which are required ?

1. Plex\ Transcoder requires the escaping or quotes
2. -hwaccel vaapi\ -hwaccel_device /dev/dri/renderD128 are discrete args.
   → -hwaccel vaapi -hwaccel_device /dev/dri/renderD128 (example)

[Paolino625]

Thank you for the update, looking forward to the fix!

Regarding the escaping/quoting: I copied slhogg’s command incorrectly: the backslashes were only for line breaks.
For convenience, I’m pasting the correct command below in case anyone wants to try it.

sudo -u plex "/usr/lib/plexmediaserver/Plex Transcoder" -hwaccel vaapi -hwaccel_device /dev/dri/renderD128 -vaapi_device /dev/dri/renderD128 -i "/mnt/synology/videoPaolo/Video.mp4" -t 5 -f null -

[ChuckPa]

If you look in the PMS logs DEBUG enabled,

The FFMPEG command can be copied out and used as-is

[Morphy]

Hi

Sorry for asking here, but im also trying to get the new xe to run with my Proxmox setup. I have an Intel Core Ultra i9 285T running on Proxmox Host with 6.17.4-2-pve .

LXC container is running Ubuntu 24.04

If I change my PVE host grub to:

GRUB_CMDLINE_LINUX_DEFAULT="quiet intel_iommu=on iommu=pt i915.force_probe=!7d67 xe.force_probe=7d67"

I can see that the xe driver is loaded:

root@pve:~# lspci -nnk | grep -A 3 VGA
00:02.0 VGA compatible controller [0300]: Intel Corporation Arrow Lake-S [Intel Graphics] [8086:7d67] (rev 06)
        DeviceName: To Be Filled by O.E.M.
        Subsystem: ASRock Incorporation Device [1849:7d67]
        Kernel driver in use: xe
--
80:14.5 Non-VGA unclassified device [0000]: Intel Corporation Device [8086:7f2f] (rev 10)
        Subsystem: ASRock Incorporation Device [1849:7f2f]
80:15.0 Serial bus controller [0c80]: Intel Corporation Device [8086:7f4c] (rev 10)
        Subsystem: ASRock Incorporation Device [1849:7d67]

But I can’t seem to get plex to work with xe ? Can you maybe assist me here?

@ChuckPa Maybe you could give me a hint ?

[Morphy]

Seeing new Intel drivers are on its way :

The following upgrades have been deferred due to phasing:
  i965-va-driver libdrm-amdgpu1 libdrm-common libdrm-intel1 libdrm-nouveau2 libdrm2 libva-drm2 libva-wayland2 libva-x11-2 libva2
  python3-distupgrade ubuntu-release-upgrader-core va-driver-all
The following packages have been kept back:
  mesa-libgallium mesa-va-drivers

sudo apt-cache policy mesa-va-drivers
mesa-va-drivers:
  Installed: 25.0.7-0ubuntu0.24.04.2
  Candidate: 25.2.8-0ubuntu0.24.04.1
  Version table:
     25.2.8-0ubuntu0.24.04.1 500 (phased 20%)
        500 http://archive.ubuntu.com/ubuntu noble-updates/universe amd64 Packages
 *** 25.0.7-0ubuntu0.24.04.2 100
        100 /var/lib/dpkg/status
     24.0.5-1ubuntu1 500
        500 http://archive.ubuntu.com/ubuntu noble/universe amd64 Packages

Hopefully fix for xe? Dont know - but will def. test it out

[syobwoc]

any update on this issue? I recently bought an Intel Arc Pro b50 and i’m running into the same issue. Is there a specific build I should try? Thank you!

[FordGuy61]

@syobwoc

Intel Arc Pro b50

See this thread for Battlemage GPUs: Battlemage Support - #245 by chris_decker08

[mordax7]

Adding another data point to this issue:
I have an Intel Arc A380 (DG2, PCI ID 56a5) on Arch Linux (kernel 6.19) and cannot get Plex to use VAAPI hardware transcoding on it, despite the host VA-API stack working perfectly.

Hardware:

• CPU: Intel Arrow Lake-S (has integrated GPU at 00:02.0)
• dGPU: Intel Arc A380 at PCI 04:00.0 → /dev/dri/renderD129
• OS: Arch Linux, kernel 6.19
• Plex: AUR plex-media-server package (latest)

What works on the host:

$ vainfo --display drm --device /dev/dri/renderD129
# Lists all VAEntrypoints successfully (iHD driver)

$ sudo -u plex ffmpeg -init_hw_device vaapi=va:/dev/dri/renderD129 -i input.mkv -vf 'format=nv12,hwupload' -c:v h264_vaapi output.mp4
# Transcodes successfully using Arc A380 VAAPI under the plex user

The plex user has correct group membership (video, render), and /dev/dri/renderD129 permissions are fine.

What fails: PlexTranscoder reports Cannot initialize VAAPI regardless of configuration. I’ve tried:

• Setting LIBVA_DRIVER_NAME=iHD and LIBVA_RENDER_DEVICE=/dev/dri/renderD129 in the Plex environment
• Switching the Arc A380 from the i915 driver to the xe driver (both work for host VA-API, neither work for Plex)
• plexinc/pms-docker official Docker image with /dev/dri passed through
• LinuxServer Docker image

None of these make any difference, Plex’s transcoder always fails to initialize VAAPI on the Arc.

Based on the earlier posts in this thread, the root cause appears to be that Plex bundles its own musl-based libva.so.2, libva-drm.so.2, and libdrm.so.2. These musl-built libraries cannot load the host’s glibc-based iHD_drv_video.so (Intel media-driver). The __isoc23_* symbol errors reported earlier in this thread confirm the ABI mismatch.

This affects all DG2 (Arc) GPUs because Plex’s bundled VA-API path simply cannot interface with the host’s media-driver for these newer GPUs.

Current workaround: I’m using the Arrow Lake-S iGPU (/dev/dri/renderD128) for Plex hardware transcoding instead. Plex’s bundled stack can drive the iGPU fine, it’s only the discrete Arc that fails. This works but obviously doesn’t give me the Arc’s encoding capacity.

Could the Plex team update the bundled VA-API/media-driver path to support DG2 (Arc) GPUs? Or at minimum, provide an option to use the host system’s VA-API libraries instead of the bundled ones?

This is the only blocker, the host drivers, permissions, and kernel support are all confirmed working. The problem is entirely inside Plex’s bundled transcoder runtime.

Update (2026-04-22): Tested ghcr.io/home-operations/plex-next:1.43.1.10611

I tested the community Docker image ghcr.io/home-operations/plex-next (tag 1.43.1.10611, digest sha256:e41b5945ca383acc22dc966ace9d1418cbfd01438556065ebfff2b5544fcd1d4). This image takes a different approach: it’s Alpine-based but replaces Plex’s bundled libva/libdrm/iHD with Alpine system packages (libva 2.23, libdrm 2.4.131, intel-media-driver from Alpine edge). It also removes Plex’s bundled copies so system libs take precedence, and symlinks /usr/lib/dri into Plex’s driver cache path.

What this image fixed:

• The driver loading problem is solved, Alpine’s glibc-compatible iHD_drv_video.so (39.9MB) is loaded instead of Plex’s bundled musl copy (38.3MB)
• Plex now detects the Arc A380: “Preemptively preparing driver imd for GPU Intel DG2 [Arc A380]”
• Plex attempts full VAAPI pipeline: transcodeHwDecoding=“vaapi”, transcodeHwEncoding=“vaapi”, transcodeHwFullPipeline=“1”

What still fails:
Plex’s bundled ffmpeg (libavfilter.so.9, ffmpeg 6.x era) crashes when building the VAAPI filter graph for DG2:

ERROR - Impossible to convert between the formats supported by the filter ‘Parsed_hwupload_2’ and the filter ‘auto_scale_0’
ERROR - Failed to inject frame into filter network: Function not implemented
ERROR - Error while filtering: Function not implemented

This happens at the hwupload → scale_vaapi stage when the video needs scaling (e.g., 4K HEVC → 1080p). The transcoder dies and falls back to CPU (libx264).

So the issue has two layers:

1. Driver loading (musl libva can’t load glibc iHD), FIXED by plex-next
2. Plex’s bundled ffmpeg can’t handle DG2 VAAPI surface format negotiation in the filter graph, STILL BROKEN

This confirms the problem isn’t just driver loading, even with the correct iHD driver loaded and VAAPI initialized, Plex’s bundled ffmpeg binary cannot handle the DG2 hardware scaler. This likely needs an ffmpeg update inside Plex’s transcoder to support DG2 VAAPI filter format negotiation.

[slhogg]

Hi all—I wanted to humbly report that I’ve resolved the VAAPI issue in my setup, and it turned out to be a PICNIC (problem in chair, not in computer).

I let the issue sit for a while. For a long time, Direct Play worked perfectly, Direct Stream mostly worked, but any video transcoding would fail over from hardware to software, and Plex reported VAAPI/transcoder initialization errors.

This weekend, I tried to play back a file that (for some reason) required audio transcoding, but not video transcoding.

The file hung, and the Plex console reported new errors that helped me crack the code:

[Req#1200f4/Transcode/b28b799ac8f25dd5-com-plexapp-android] Unzip: could not set executable bit on output file
[Req#1200f4/Transcode/b28b799ac8f25dd5-com-plexapp-android] CodecManager: failed to extract zip
[Req#1200f4/Transcode/b28b799ac8f25dd5-com-plexapp-android] Error configuring transcoder: Decoder install failed: truehd_eae

This pointed to a permissions error I missed in my previous troubleshooting that I still needed to track down.

For my first try, I changed the Plex Transcode Storage from the host path: /mnt/SSDs/Applications/plex/transcode/ to tmpfs (temporary directory created in RAM).

The errors persisted, and with a bit more digging/investigating it turns out the ACL permissions for the Dataset: /mnt/SSDs/Applications/plex/ (where my config, data, logs, and transcode folders were set up) were set to the NFSv4 ACL type.

I don’t know when or how I made this mistake, but the NFSv4 ACL type effectively breaks Plex’s ability to extract codec files, set executable bits, and properly read/write transcoder temp files, but it aparretnly allows the command I was using to test user permissions “sudo -u plex ffmpeg -hwaccel vaapi -vaapi_device /dev/dri/renderD128 -i “/Movies/SomeMovie.mkv” -t 5 -f null -” to function with the correct user’s/groups assigned in the ACL settings.

My solution was as simple as editing the dataset configurations as follows:

/mnt/SSDs/Applications/plex/
/mnt/SSDs/Applications/plex/config/
/mnt/SSDs/Applications/plex/data/
/mnt/SSDs/Applications/plex/logs/
/mnt/SSDs/Applications/plex/transcode/

Changing the ACL type from NFSv4 to POSIX (making sure to check the box to apply permissions recursively), then used the POSIX_OPEN preset in the ACL editor (see attached screenshots).

The issue was being passed through to both the TrueNAS Plex App and my VM-based Plex install, since both were targeting the same existing host paths so I wouldn’t have to recreate libraries and meta data from scratch.

Fixing the ACL settings resolved both the new audio transcoding errors and my initial VAAPI initialization errors.

So my issue was resolved with the following combination of actions:

1. updated to plex media server version v1.43 or newer with current FFMPEG version
2. adjust ACL type from NFSv4 to POSIX (with preset POSIX_OPEN applied recursively)

This might not solve the problem for everyone, but if you’re running into similar VAAPI errors, I would definitely recommend double-checking the ACL permissions on your /Applications/plex/ datasets as part of your troubleshooting process.