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.
