AMD GPU transcoding broke in 1.43.0.10492

Server Version#: 1.43.0.10492

AMD GPU transcoding is busted. It was working in 1.42.2.10156. Looks like it segfaults with the new Transcoder that was built.

kern: info: [2026-03-10T15:36:57.165173825Z]: mux0:stream_seg[134692]: segfault at 54 ip 00007f59209a8f5c sp 00007f590191b580 error 4 in libavformat.so.60[195f5c,7f59208e2000+208000] likely on CPU 6 (core 6, socket 0)
kern: info: [2026-03-10T15:36:57.165186825Z]: Code: 44 24 10 45 31 ed eb 22 48 83 c3 1c 48 8b 47 18 4c 8b af c8 00 00 00 4c 39 e8 44 0f 47 e8 44 2b 6f 08 49 89 ff 48 89 5c 24 10 <8b> 47 54 89 44 24 0c 85 c0 0f 88 1d 01 00 00 83 7c 24 60 00 74 3b

libavformat.so.60 is outdated, and I assume so is the amd gpu dri drivers.

Please do the following;

  1. Confirm server DEBUG logging is enabled, VERBOSE logging is disabled.
    SAVE if changes.
  2. Restart PMS
  3. Give it two minutes to start and stabilize
  4. Start a playback which shows the issue
  5. Let it play for 20 seconds
  6. Stop the playback
  7. Download the server logs
  8. Attach the logs so I may see them.

Plex Media Server Logs_2026-03-10_11-46-32.zip (132.5 KB)

War Machine (2026) is what I attempted to transcode.

Here is the segmentation fault you called out. This looks to be happening after attempting to analyze Madea's Destination Wedding.

Jobs: '/usr/lib/plexmediaserver/Plex Transcoder' exit code for process 505 is -11 (signal: Segmentation fault)

Once this segmentation fault occurs PMS loses access to the AMD card.

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

Can you check on Madea's Destination Wedding to see if there is issue with this file? Can you play on Plex and/or VLC or some other player?


I’m actually able to reproduce the lose of the ā€œdeviceā€ after some other playback sessions.

There is no issue with the file as I can play it via VLC and Plex (minus GPU transcoding). I compared this to using Jellyfin, and it transcodes the file using my amdgpu just fine.

ffmpeg version 7.1.3-Jellyfin Copyright (c) 2000-2025 the FFmpeg developers
built with gcc 14 (Debian 14.2.0-19)
configuration: --prefix=/usr/lib/jellyfin-ffmpeg --target-os=linux --extra-version=Jellyfin --disable-doc --disable-ffplay --disable-static --disable-libxcb --disable-sdl2 --disable-xlib --enable-lto=auto --enable-gpl --enable-version3 --enable-shared --enable-gmp --enable-gnutls --enable-chromaprint --enable-opencl --enable-libdrm --enable-libxml2 --enable-libass --enable-libfreetype --enable-libfribidi --enable-libfontconfig --enable-libharfbuzz --enable-libbluray --enable-libmp3lame --enable-libopus --enable-libtheora --enable-libvorbis --enable-libopenmpt --enable-libdav1d --enable-libsvtav1 --enable-libwebp --enable-libvpx --enable-libx264 --enable-libx265 --enable-libzvbi --enable-libzimg --enable-libfdk-aac --arch=amd64 --enable-libshaderc --enable-libplacebo --enable-vulkan --enable-vaapi --enable-amf --enable-libvpl --enable-ffnvcodec --enable-cuda --enable-cuda-llvm --enable-cuvid --enable-nvdec --enable-nvenc
libavutil 59. 39.100 / 59. 39.100
libavcodec 61. 19.101 / 61. 19.101
libavformat 61. 7.100 / 61. 7.100
libavdevice 61. 3.100 / 61. 3.100
libavfilter 10. 4.100 / 10. 4.100
libswscale 8. 3.100 / 8. 3.100
libswresample 5. 3.100 / 5. 3.100
libpostproc 58. 3.100 / 58. 3.100

Hey @Atomatth is there anything else you need from me?

No I don’t think so. Like I mentioned, I was able to reproduce on a machine I have access to. I created an internal issue for tracking.

I will state that we don’t officially support transcoding with AMD GPUs at this time. So while it may have worked before there was never any guarantee that would continue working. I’m not trying to use that statement to dismiss your issue but instead to set the expectation of support. As we continue to update the transcoder it should allow us to officially support transcoding with AMD GPUs. Once that day comes we’ll have an official announcement.

@skreii actually, yes, there is something. Could you share the XML info for Madea's Destination Wedding? I was able to reproduce your issue when attempting playback of a MPEG2Video file, I’m wonder if this codec is problematic for AMD specifically.

22347.txt (56.6 KB)

Server Version#: Any 1.43.x version

Hello.

Since the 1.43 server upgrade, the server will no longer use HW acceleration if I use any other client but the web one.

I tried with the Android, Windows and LG apps and they are all the same. They show the same error and go back to software transcoding. The web client still works correctly.

It works immediately if I switch back to any 1.42.x version.

I am using the official plex docker container on Unraid 7.2.4.

Here is a portion of the log:

Mar 23, 2026 16:42:19.702 [22689808501560] DEBUG - [Req#147/Transcode] Started session successfully: ######
Mar 23, 2026 16:42:19.702 [22689915816760] DEBUG - Completed: [REDACTED] 204 PUT /video/:/transcode/session/######/#####/progress?duration=1293.543000 (22 live) #15e 0ms 203 bytes (pipelined: 7) (range: bytes=0-)
Mar 23, 2026 16:42:19.710 [22689806392120] DEBUG - Request: [REDACTED] GET /status/sessions (22 live) #13a TLS GZIP Signed-in Token (REDACTED)
Mar 23, 2026 16:42:19.710 [22689806392120] DEBUG - [Req#13a] [Now] Adding 1 sessions.
Mar 23, 2026 16:42:19.711 [22689915816760] DEBUG - Completed: [REDACTED] 200 GET /status/sessions (22 live) #13a TLS GZIP 0ms 3025 bytes (pipelined: 10)
Mar 23, 2026 16:42:19.716 [22689839680312] DEBUG - [MediaProviderManager] Refreshing media providers
Mar 23, 2026 16:42:19.716 [22689839680312] DEBUG - [MediaProviderManager/Response::fetch/HCl#3f] HTTP requesting GET ``https://plex.tv/media/providers
Mar 23, 2026 16:42:19.725 [22689816083256] DEBUG - Request: [REDACTED] GET /status/sessions (22 live) #150 TLS GZIP Signed-in Token (REDACTED)
Mar 23, 2026 16:42:19.725 [22689816083256] DEBUG - [Req#150] [Now] Adding 1 sessions.
Mar 23, 2026 16:42:19.726 [22689917926200] DEBUG - Completed: [REDACTED] 200 GET /status/sessions (22 live) #150 TLS GZIP 1ms 3025 bytes (pipelined: 10)
Mar 23, 2026 16:42:19.732 [22689810611000] DEBUG - Request: [REDACTED] GET /status/sessions (22 live) #13c TLS GZIP Signed-in Token (REDACTED)
Mar 23, 2026 16:42:19.732 [22689810611000] DEBUG - [Req#13c] [Now] Adding 1 sessions.
Mar 23, 2026 16:42:19.733 [22689915816760] DEBUG - Completed: [REDACTED] 200 GET /status/sessions (22 live) #13c TLS GZIP 2ms 3157 bytes (pipelined: 5)
Mar 23, 2026 16:42:19.838 [22689880001336] DEBUG - [HttpClient/HCl#3f] HTTP/1.1 (0.1s) 200 response from GET ``https://plex.tv/media/providers`` (reused)
Mar 23, 2026 16:42:19.838 [22689839680312] DEBUG - [MediaProviderManager] discovered cloud provider (Metadata)
Mar 23, 2026 16:42:19.838 [22689839680312] DEBUG - [MediaProviderManager] loading cloud provider details (Metadata) (alive: 1)
Mar 23, 2026 16:42:19.838 [22689839680312] DEBUG - [MediaProviderManager] we had 1 cloud providers online, we now have 1
Mar 23, 2026 16:42:19.838 [22689839680312] DEBUG - [MediaProviderManager] cloud provider (Metadata) is online and available
Mar 23, 2026 16:42:19.838 [22689839680312] DEBUG - [MediaProviderManager] Media provider refresh complete
Mar 23, 2026 16:42:19.849 [22689924225848] DEBUG - Jobs: ā€˜/usr/lib/plexmediaserver/Plex Transcoder’ exit code for process 491 is -11 (signal: Segmentation fault)
Mar 23, 2026 16:42:19.849 [22689775876920] DEBUG - Streaming Resource: Changing client to use software decoding
Mar 23, 2026 16:42:19.849 [22689775876920] DEBUG - Found session GUID of ######in session start.
Mar 23, 2026 16:42:19.849 [22689775876920] DEBUG - TranscodeUniversalRequest: using profile Plex Desktop

Please let me know if I can provide more information about the issue.

Thanks in advance

This sounds similar to the issue in this thread. See my comment.

Thanks for the fast answer.

So what is the recommendation atm since AMD is not officially supported? Do I revert to 1.42 and wait until some day it works again or is there anything I can provide that can help troubleshooting this?

I read the thread you linked and I can tell you that there isn’t a specific problem with the file that user talked about since I can reproduce this with any file and quality. Also a clue that you might not have noticed is that if you try to play the same files through the web browser and trigger a transcode by let’s say, changing the quality, then it works with hw so the regression has to be subtle.

Let me know if I can provide any more useful info.

@skreii meet @m33ts4k0z. @m33ts4k0z I’ve moved your thread into this one, hope that’s ok.

I had a question for both of you. When the issue manifests, do you have Tone Mapping enabled?

I have tried with both enabled and disabled and it still shows segfaults :grinning_face:

PS: Latest version that it worked: 1.42.2.10156

Mine doesn’t work with it enabled or disabled. I built a custom plex container for 1.43.0.10492 and upgraded libva + libdrm as well as all of the dri drivers. It works now.

What AMD GPU do both of you have? I have a RX 7600 in the test server I have access to. I was only ever able to see an issue when attempting MPEG2Video playback. Everything else seems to be playing fine for me. This is both on bare metal and docker.

its a Raphael iGPU on a Ryzen 9 7950X3D for me.

Btw indeed, using the image posted by @skreii does solve the issue completely, with all clients so thanks for that. Most likely, the reason its not working with the official plex image is because the bleeding edge packages needed for the HW acceleration to work with the new ffmpeg aren’t available on noble.

From skreii’s logs I can see they have a AMD Ryzen 9 9955HX. So iGPU. Which could be why I’m not seeing this issue. Thanks!

Just to add a new finding here. Although @skreii image seems to work with about every client I tried, it seems to completely break the Hisense VIDAA plex app. It only shows playback error no matter if hw acceleration is on or not. Maybe I could create an issue directly in the repo about that :smiley:

Running Plex 1.42.2.10156 on Ubuntu 25.10 with a Ryzen 7 PRO 8845HS (Radeon 780M, Phoenix/gfx1100).

Like others, 1.43.0 and 1.43.1 both segfault in libavformat.so.60 when attempting AMD VAAPI hardware transcoding. Rolling back to 1.42.2 restores hardware transcoding immediately with no additional configuration — final decoder: vaapi, final encoder: vaapi working correctly out of the box.

The segfault appears to be a regression specific to the new FFmpeg 6.1 transcoder binary introduced in 1.43.0, as the underlying hardware and drivers are fully functional on the previous version.