Transcoder segfaults on the VAAPI path when serving Plex for Android, but not Plex Web — AMD 780M

Plex Media Server
,
1

Server Version#: 1.43.3.10828
Player Version#: Plex for Android 2026.14.1
### Summary

(I’m using an LLM to report on this problem, sorry in advance)

On the same server, same file and same session, hardware transcoding works when the

client is Plex Web and fails when the client is Plex for Android. The failure is not a

decision the server makes: **the hardware transcoder process is launched and segfaults

after ~118 ms**, and the server then restarts the job in software.

Playback still works, so this is not user-visible except as unexpected CPU load. But the

crash is real, reproducible on demand, and appears to match an existing report from a

different user on different AMD hardware (linked at the bottom).

### Environment

- Proxmox VE 9.2, kernel 7.0.14-8-pve

- Plex Media Server 1.43.3.10828, Debian package from repo.plex.tv

- Unprivileged Debian 13 (trixie) LXC container

- Device passed through with Proxmox’s native device passthrough:

`pct set 101 --dev0 path=/dev/dri/renderD128,gid=992`

- AMD Ryzen 7 PRO 8845HS with Radeon 780M

(gfx1103; Mesa reports it as `phoenix`, PMS reports it as `AMD Hawkpoint1`)

- Mesa 25.0.7-2+deb13u1, libva 2.22.0, VA-API 1.22

- **Single GPU. There is no second graphics device in this machine.**

- Test file: Big Buck Bunny, 1080p H.264 in a .mov container, 5.1 AAC audio

### Steps to reproduce

1. Play the file from Plex Web, force a transcode by selecting a lower quality

2. Play the same file from Plex for Android, force a transcode the same way

3. Compare the live transcoder process in each case

### Evidence 1 — which encoder actually runs

Rather than trusting the Dashboard label, I checked the running process directly and

looked for `-hwaccel` in its command line:

ps -eo pcpu,etime,args --sort=-pcpu | grep "Plex Transcoder" | grep -v grep

| Client | Output | `-hwaccel vaapi` present | CPU |

|-------------|------------|--------------------------|-------|

| Web | 1280x720 | yes | 17.6% |

| Web | 1920x1080 | yes | 30.2% |

| Android app | 720x404 | no | 103% |

| Android app | 1920x1080 | no | 218% |

The CPU figures are indicative only — the transcoder throttles once it is ahead of

playback, so they are comparable only at similar elapsed times. The presence or absence

of `-hwaccel` is the unambiguous part.

The 1080p rows are the clean comparison: identical output geometry, identical source

file, identical requested bitrate. Web gets `h264_vaapi`, the app gets `libx264`.

### Evidence 2 — the hardware transcoder segfaults

Matching the PIDs makes the causal chain unambiguous. This is a single Android session:

20:11:38.111  TPU: hardware transcoding: final decoder: vaapi, final encoder: vaapi

20:11:38.114  JobRunner\] Jobs: Starting child process with pid 636

20:11:38.232  Jobs: 'Plex Transcoder' exit code for process 636 is -11 (signal: Segmentation fault)

20:11:38.242  TPU: hardware transcoding: final decoder: , final encoder:

20:11:38.242  JobRunner\] Jobs: Starting child process with pid 666

20:15:44.702  Jobs: 'Plex Transcoder' exit code for process 666 is 0 (success)

PID 636 is the process started immediately after the hardware decision, and it is the

one that dies. PID 666, the software replacement, runs to completion normally.

Before the crash, everything looks correct — the server finds the device, probes it and

selects it:

TPU: hardware transcoding: using hardware decode accelerator vaapi

TPU: hardware transcoding: zero-copy support present

TPU: hardware transcoding: using zero-copy transcoding

Codecs: hardware transcoding: testing API vaapi for device '/dev/dri/renderD128' (AMD HawkPoint1)

TPU: hardware transcoding: final decoder: vaapi, final encoder: vaapi

and launches ffmpeg with `-init_hw_device vaapi=vaapi:/dev/dri/renderD128` and

`-codec:0 h264_vaapi`. So the device path is known and correct at that point.

**The lifetime is the notable part.** PID 636 lived 118 ms — started at .114, dead at

.232. At that timing the process dies during initialisation, before emitting a frame.

### Evidence 3 — the software fallback is built with a malformed argument

The retry is not simply “the same job without hardware”. Its command line still carries:

-init_hw_device vaapi=vaapi:

with nothing after the colon, and the log correspondingly reports:

TPU: hardware transcoding: enabled, but no hardware decode accelerator found

Codecs: hardware transcoding: testing API vaapi for device '' ()

On my system ffmpeg tolerates this and the software transcode succeeds. On the system in

the linked thread the same argument produces `Failed to set value ‘vaapi=vaapi:’ for

option ‘init_hw_device’` and the fallback dies too, surfacing to the user as "Conversion

failed. The transcoder exited due to an error."

I mention it because it looks like a separate defect from the segfault, and it seems to

be what decides whether a user sees degraded performance or a broken playback.

### Ruled out

- **Permissions.** `runuser -u plex – vainfo --display drm` succeeds as the `plex` user,

not just as root. `id plex` shows membership in `render`.

(Side note for anyone reading with a similar setup: on Proxmox the host and the

container assign system GIDs independently — `render` is 992 inside my container and

993 on the host, where 993 is `kvm`. Copying the host value silently disables hardware

transcoding with no error anywhere.)

- **Device selection.** `AMD Hawkpoint1` appears in the Transcoder dropdown and is

explicitly selected rather than left on Auto.

- **Encoder capability.** `vainfo` lists H264 High with `VAEntrypointEncSlice`, HEVC

Main/Main10, AV1 Profile0, and `VAProfileNone: VAEntrypointVideoProc`.

- **Output geometry.** The server uses `h264_vaapi` successfully at 1920x1080 and at

480x270, so it is not a constraint on the scaler output size.

- **A second GPU.** There is none — `/dev/dri/by-path/` lists a single PCI address.

- **Requested codec.** The server picks `h264_vaapi` for the Android session too. It

isn’t the client asking for something the GPU can’t do.

### Not ruled out

Being explicit about this, since it is the obvious shared variable: **both this report

and the linked one run Plex inside an unprivileged LXC container on Proxmox.** I have no

bare-metal AMD system to test against, so I cannot say whether the crash reproduces

outside a container. If someone running PMS on bare-metal AMD can try the same web vs

Android comparison, that would narrow it down considerably.

Both reports are also AMD/VAAPI, so nothing here says anything about Intel or NVIDIA.

### Related thread

This looks like the same crash reported here:

Same PMS version, AMD APU, LXC on Proxmox, `-11` segfault on the hardware transcoder,

same web-works / Android-fails split. In that thread the hardware process was launched at

03:05:50.950 and segfaulted at 03:05:51.066 — **116 ms**, against my 118 ms. Two

different machines, two different AMD generations, two different source files, and the

crash lands within 2 ms of the same point.

That thread’s author initially attributed it to having a second GPU (an NVIDIA card

alongside the AMD APU) in the machine. My system has a single GPU and reproduces the

segfault and the client split, so the second GPU does not appear to be the cause of

either — though it does seem to be what turns the survivable fallback into a hard

failure, via the malformed `-init_hw_device` argument above.

I can reproduce this on demand and I’m happy to run any test that would help narrow it

down — including capturing a core dump if there’s a supported way to do that with the

bundled transcoder.

2

From the Plex Support page.

*Note: Our hardware-transcoding system has technical support for many dedicated AMD graphics cards, but we haven’t done official, full testing on those. Support for AMD GPUs is provided “as is” and your mileage may vary. It is recommended that you use Intel Quick Sync Video or a dedicated NVIDIA GPU.

3

Ah, so there isn’t a solution. It’s a shame because from the web UI everything works perfectly; the only problem is that the hardware acceleration doesn’t work when watching something from the mobile app.
Thanks for the info.

4

That’s too bad. The AMD iGPU actually works fine as long as it’s the only GPU in the machine.

The moment an nVidia GPU is added, the AMD iGPU stops working in Plex.

I want to use the nVidia for other purposes - running LLM, not for Plex transcoding.

The only workaround I found was to disable hardware transcoding altogether.

5

It actually works fine as long as there is only an AMD GPU present. It breaks if there are botth AMD & nVidia.

6

Same crash signature here on a different trigger (Plex Relay / Apple TV client rather than Android), same GPU family — Radeon 780M / HawkPoint1. Adding what I found in case it’s useful, since I went further into the driver mismatch than most other reports here.

**Setup:** Plex Media Server 1.43.3.10896-cb3ebc72d, Arch Linux (Omarchy), kernel 7.1.8, Ryzen 7 8745HS / Radeon 780M (`amdgpu`, `/dev/dri/renderD128`).

**Confirmed the crash is not a stale-process issue.** It segfaults on `h264_vaapi` every single time, including 22 seconds after a completely fresh `systemctl restart plexmediaserver` against freshly-matched on-disk binaries. Every attempt: `exit code for process is -11 (signal: Segmentation fault)`, then falls back to software with `-codec:0 png`, which pegs a core at 900-1100% and can’t keep up with real time — that’s the “server isn’t powerful enough” error people are getting.

**Root cause, as far as I can tell:** Plex vendors its own private VAAPI driver, completely separate from the system’s mesa. Mine resolved to:

```

LIBVA_DRIVERS_PATH=“…/Plex Media Server/Cache/va-dri-linux-x86_64”

→ radeonsi_drv_video.so → “Mesa Gallium driver 23.0.2”, file dated 2026-06-05

```

while my system’s actual mesa is current (26.1.6) and my kernel/amdgpu firmware have moved on since that blob was fetched. That version gap against the DRM/KMS ABI looks like the segfault source. It’s not the *server* that’s stale (I proved that with the restart test above) — it’s this vendored driver blob, and a restart just reloads the same one every time.

**What I tried, for anyone tempted to go further:**

1. Pointed `LIBVA_DRIVERS_PATH` at the system’s current driver (`/usr/lib/dri`, mesa 26.1.6) via `/etc/conf.d/plexmediaserver`, restarted. **Segfault stopped**, but VAAPI now failed to even initialize: `Failed to initialise VAAPI connection: -1 (unknown libva error)`. Turned out Plex *also* bundles its own `libva.so.2` core (reports version **1.22.0**) via `LD_LIBRARY_PATH=…/Plex Media Server/lib`, and it can’t negotiate with a driver built against a newer interface (system libva here is 1.24.0). Pointing only the driver path at something current isn’t enough — the core has to match too.

2. So I replaced Plex’s bundled `libva.so.2` and `libva-drm.so.2` in place with the system’s current 1.24.0 versions, keeping the driver path override from step 1. **This crashed the main Plex Media Server process itself** — not just the transcoder child — dying in ~17ms on every start until it hit systemd’s start-limit and gave up entirely. Reverting both files back to Plex’s originals immediately fixed the whole-server crash. So on this Plex version, the main server process and the transcoder apparently share enough of the `libva` linkage that you can’t safely swap it out from under just the transcoder — unlike some older threads here describing success copying `libva`/`libdrm`/`libstdc++` on older Ryzen APUs (4700U-era), which may have been linking a much lighter/older Mesa build.

Given the “AMD is as-is” stance already stated in this thread, I’ve settled on disabling hardware acceleration entirely — reliable, if CPU-heavier.

**Ask, same as others in this thread:** any chance of a refreshed vendored VAAPI driver bundle for current AMD iGPUs (or a documented, *safe* way to point Transcoder at the host’s own libva+driver stack without also touching the main server process)? Happy to provide full logs/coredumps if useful.