Server Version#:1.20.2.3402-0fec14d92
Player Version#:4.34.4
When using AMD GPU (tried AMD’s RX 5500 XT and RX 5700X XT) for hardware encoding, video is corrupted with green blocks as shown below, not problem with software transcoding with same sources.
Look in recent forum “building PC, no IT knowledge” apparently plex isn’t compatible with AMD
That’s my guess too. Though in this Support Article https://support.plex.tv/articles/115002178853-using-hardware-accelerated-streaming/?_ga=2.86555484.593033935.1602395589-856506241.1602395589 it doesn’t explicitly say Plex doesn’t support AMD GPU encoding.
Anyway whether supported or not, it could be implemented that if the hardware is not explicitly supported, it will fallback to last available option.
I have an AMD GPU and I do not have this problem. Is your driver up to date? Possibly your GPU itself is borked. Just random spitball ideas, all I know is that my AMD GPU has no issue.
What is your CPU?
Sorry, just saw your response. My GPU is an AMD R9 390, and my CPU is an Intel i5-9400F.
This issue seems to only occur with RX 5x00 series GPUs and Ryzen 4000 series APUs, which share the same or at least much of the same relatively recent VCN (Video Core Next) 2.0 codec hardware. Older devices appear to be already comprehended in Plex Media Server’s codebase which is why you don’t hear complaints from Ryzen 3000 and 2000 series APU users. I made a GitHub ticket for this issue. Since the RX 5x00 series has been around now for over a year now, it would be nice for support to be fixed for this. See also this related forum thread, where the complaint seems to be coming from only RX 5x00 series GPU and Ryzen 4000 series APU users.
For what it is worth, I just bought a lifetime Plex Pass this week, so I hope that raises awareness among Plex staff that paying customers like myself are looking for dependable support to patch this longstanding issue.
Downloaded the new release (1.21.0.3711), no fix yet in sight. Tried again today. Same multicolored pixel distortion. It’s still giving me what I reported to them on GitHub. It is server-side and has to do with their custom broken implementation of FFMPEG and VCN 2.0. Other software out there like Handbrake that use FFMPEG have no issues with AMD’s VCN hardware encoding. This example I provided them is with a non-live, pre-transcoded or optimized file. They have yet to fix their issue with hardware encoding:
See example case below.
> > Gofile - Your all-in-one storage solution < <
This example above is less severe since, as a CGI animated short, it has more static or stationary frames, but it is still plainly obvious where the improper encoding occurs. This does not occur with other hardware encoding implementations I use, such as Handbrake which features VCE/VCN support. I included a log and database dump as requested. Some very obvious problem points I quickly noted in the hardware encode are ~2:14, ~2:18, and ~3:11, but there are many more problem points before and after as you may have already noticed.
this bug is still happening for anyone wondering
Today marks one month since my initial posting with no sign of first contact or show of interest from the Plex Team for me, a new paying Plex Pass user. Shame on you, Plex development team!
Today marks two months since my initial posting with no sign of first contact or show of interest from the Plex Team for me, a new paying Plex Pass user. Shame on you, Plex development team!
A Plex employee finally replied—after a spectacle was stirred—explaining that they have forwarded the concern and upon further investigation, it should be fixed once they update their FFmpeg libraries in the near future. Let me underscore here that I won’t dial down the rhetoric until I actually see action, because talk is cheap. How about this: with a well-managed software company, a customer never needs to rouse a spectacle in order to coax them to finally address a valid, widely reported, year-plus-old bug. If I had not made a spectacle, this bug would still be getting old and stale and many of us would be wondering why in the world our widely reported, dated bugs had gone unaddressed, many for over a year now. Yes, Plex is at fault here and no, I was well within my rights after countless people’s complaints had been falling on deaf ears for far too long. And yes, Plex needs to learn a valuable lesson: they need to take customer concerns far more seriously and attentively and stop blaming customers for their own internal management issues.
As explained in our support articles on hardware transcoding, support is not yet available for the AMD GPU platform. Some limited functionality may work, but it’s on an as-is basis, without any guarantees from Plex. We do plan to add full support for the platform, but there’s a fairly large amount of work required to do so, as it uses entirely different APIs on Windows for video postprocessing than the ones we use on Intel (or on Nvidia for that matter), so without a lot of new code, the available performance is severely limited. There’s work in progress in the upstream ffmpeg codebase to add the necessary infrastructure for high-performance transcoding on AMD GPUs on Windows, but it’s not yet complete.
There’s work in progress in the upstream ffmpeg codebase to add the necessary infrastructure for high-performance transcoding on AMD GPUs on Windows, but it’s not yet complete.
First, let’s correct this part. ffmpeg already fixed this well over a year ago and, as a result, this bug does not occur in Handbrake which utilizes ffmpeg. So no, the issue isn’t with main branch ffmpeg. So no, the issue is not with the upstream ffmpeg codebase. The issue with Plex’s downstream fork of the ffmpeg codebase. I cannot state this any more plainly: fix your broken code!
Now then, three weeks ago, I finally got a slightly more thoughtful response where it was said there was a “plan.” However, it was just a rough idea with no specifics, with just you saying that they have “a lot of new code” to write and “it’s not yet complete” so don’t expect a fix any time soon. I was kind to you because you said more and actually put more time and effort in, but it was pretty lackluster for a company of Plex’s size and scale.
The funny part is I have regularly communicated with software companies and even freeware GitHub projects. Many of these are run by just one person. Yet they are readily willing to give out more solid information and provide a rough timeline and plan of what to expect.
Here, it seems most of the Plex employees are just paid to troll their forums and give lame excuses. It sounds a lot like the corrupt insurance company Insuricare in The Incredibles that just is looking for ways to appease customers without actually following through with solid commitments and tangible deliverables.
Today marks almost four months since my initial posting with no publicly released fix from the Plex Team for me, a new paying Plex Pass user. Shame on you, Plex development team…
Do you have this enabled?
Green coloring on videos is a common sign of playing 10-bit HDR video on a non-HDR screen. You need this setting enabled to convert the HDR to down to SDR. Your hardware may not support this, in which case it should fallback to software transcoding.
Please note that this is not a bug as AMD GPU’s are not supported as previously mentioned.
Wow. That is not the issue. No, not by a long shot. Your colleague already noted my issue above, so I am a bit perplexed why you responded with such an off-the-wall response. Besides, I already have HDR tone mapping enabled. The clouds of pixel distortion described occurs when transcoding with HDR tone mapping enabled. If you would have thoroughly read the issue description and noted the common thread that I had pointed out, the pixel coloration occurs ONLY on later generation AMD hardware in Windows. Affected hardware are GPUs and integrated graphics with Video Core Next (VCN) 2.0 and later meaning Ryzen 4000G series (“Renoir”) and RX 5000 series and RX 6000 series (1st and 2nd Generation “Navi”). I first encountered this issue with my Ryzen 7 PRO 4750G. I have determined it is an issue with later generation hardware because that if I enable transcoding on my thin client with a Ryzen R1505G, for example, the issue does not occur because its hardware encoder is an earlier release of VCN. Ultimately, it has to do with Plex’s fork of FFMPEG, because, interestingly enough, the transcoding issue DOES NOT occur on other FFMPEG-based programs like Handbrake when using hardware encoding with my Ryzen 7 PRO 4750G.
Ok, it was just a suggestion in case your issue was not due to an incompatibility with AMD hardware. You did not mention HDR in your comments so just wanted to bring up a potential cause.
Right. Well, please note this:
I just tried the latest release of Plex Media Server (1.22.1.4228) on my Windows machine, and I am still getting the same issues. Here are some screenshots demonstrating this ongoing issue for your viewing pleasure (or viewing annoyance?). All heck breaks loose as soon as I enable the option “Use hardware-accelerated video encoding.” CPU usage drops and my integrated GPU engages as expected on my Ryzen 7 PRO 4750G, but this confounded pixel distortion begins to wreak its havoc on all my media when transcoding occurs. Now, I’m sure we’ve all heard of both Gandalf the Grey and Gandalf the White, but have you ever been introduced to Gandalf the Blue or Gandalf the Yellow 
?
The RX 5000 series GPUs have been around for almost two whole years now and all the latest generation AMD GPUs and APUs released since 2019 still are plagued by this very same issue. I realize development can add maybe a year delay to implement things, but even then Handbrake had this issue within ffmpeg resolved well under a year’s time and that is FREE software. We are now nearing the TWO -year mark for the RX 5700’s release (July 2019), which uses the same updated derivative of Video Core Next that the Ryzen 4000G series APUs like my 4750G has. And yet, with almost two years down, there is still no fix in sight for Windows users. It’s downright disgraceful to be quite honest.
