Ryzen 7 4800U here running PMS under Docker on Ubuntu 24.04. As recently as a few days ago I was seeing software transcoding but I just updated the pull tag from plexinc/pms-docker:plexpass to plexinc/pms-docker:latest and HW transcoding seems to be working again. I verified by checking CPU usage and running radeontop to confirm GPU activity.
Just tested here, AMD transcoding still doesn’t work with 1.43.1.10611.
I upgraded to the latest version again to test @akmoney’s observations and when digging through the logs, found something interesting.
When the Android (TV) Plex app requests a transcode, two transcoder processes are spawned. The first one correctly identifies the hardware device and initialises fine:
-init_hw_device vaapi=vaapi:/dev/dri/renderD128
final decoder: vaapi, final encoder: vaapi
But almost immediately a second process spawns for the same session, and this one has an empty device path:
-init_hw_device vaapi=vaapi:
final decoder: , final encoder:
This second process is the one that actually does the encoding, falling back to libx264 in software. CPU hits ~80% as a result.
This happens every single time with the Android client, completely reproducibly. The web client and others don’t trigger this behaviour — they only spawn one process and it works fine.
Worth noting this is specifically the HLS/segmented .ts stream path that the Android app uses, vs the DASH .m4s path used by other clients.
I have noticed that Plex now identifies the hardware device as AMD Hawkpoint1 rather than AMD Phoenix3 as it did in the previous 1.42.X build.
Rolled back to 1.42.2.10156 and the problem is gone — Android client gets hardware transcoding with a single process and correct device path, as before. For now, I will stay on the older version.
For anyone following along at home that wants to try this themselves, the steps I followed were to turn on “debug” and “verbose” logging options in the Plex Media Server admin page, under General and then run the following command on the host (I’m on Linux so your mileage may vary), whilst starting a transcode session:
tail -f "/<path-to-plex>/Library/Application Support/Plex Media Server/Logs/Plex Media Server.log" | grep -i "final decoder\|final encoder\|hw\|vaapi"
After taking a second look, I will back up what @Alex-Moras observed: My PMS falls back to software encoding when an Android client is in use. Same with a Roku client. If I use a browser (Firefox on Windows), it will use hardware transcoding. In fact, if both an Android client and a Firefox browser are streaming from the same media source at the same time, Android will get software transcoding and Firefox will get hardware.
And to follow up even more, the Roku client does NOT like video streams coming from an AMD hardware encoder. Nothing but a black screen and no audio, even though the encoder’s working and data’s going over the network.
I’m pretty disappointed by all of this. Jellyfin’s transcoding capability blows PMS out of the water.
Same issue(revert to 1.42.x Version Fix Issue), also plex docker log says
/home/runner/_work/plex-conan/plex-conan/.conan/data/libdrm/2.4.120-4/plex/main/build/ba4ee9fcf280d38ea7457f18301aac09908b7976/meson-install/share/libdrm/amdgpu.ids: No such file or directory
Using pms-docker:1.42.2.10156 version, AMD iGPU H/W Accelation working again…
