Yep, super consistently an issue on anime with burned ASS subs. I have yet to play any anime on the new hw subtitle burn test build so I don’t know if it is still happening there. I should be able to confirm that tomorrow.
This issue is super consistent, especially on streams with ASS subs. My files are all h265, 1080p. This quality issue is a bummer.
I can confirm that limiting the remote stream to 15 Mbps, and throwing my local subnet out of network settings somewhat mitigated my issue, but it’s a quick and dirty fix since that limits all Plex users. My family can kiss 4K content goodbye for now.
Also, since when you force the bitrate the issue is mitigated, you should trigger the transcode at its original quality.
I have tried updating the bios, but that fixed nothing. Also tried updating drivers on my proxmox host, but nothing stuck.
I did fail to mention that I also use a 32g ramdisk for transcodes.
Here is the media part of a few XML files I have gotten this problem with (basically anything that transcodes original quality). These I have personally seen.
I would provide logs, but nothing there indicates something is going wrong. It’s just transcoding badly.
@ChuckPa - before we start looking at subtitles - let’s start with a base control file for quality. It is not a SUPER high bitrate, but it’s also not terribly low. This should be a good representation of a standard 265 quality media file that goes through the transcoding process, and the 2-minute scene is split between light and dark settings for comparison.
On my 13th gen, it is clear there are problems - especially in the dark scenes in the second half. – It runs on my 10th gen with no noticeable issues.
TEST #1
Has anyone tried playing with the drivers Plex has shipped with? We do have some confirmation on the issue here I guess.
So last night I happened to play a show that needed ASS subs burned, and I didn’t notice this quality issue happening at all. I am on the latest Plex Pass build, using the LSIO Docker container on Ubuntu 22.04 kernel 6.8, which includes the new HW subtitle burning capability. Video was H.264, so maybe this is related to H.265? I still need to test with an H.265 example.
Over 90% of my library is h265, so this would be possible since I have these artifacts everywhere. I have transcoded some files with Tdarr to see if I get the same issue when transcoding files with the same iGPU. I didn’t find any problems like this. This only confirms it’s a Plex issue.
I’ve been continuing to watch the same show that needs burned subtitles, and have noticed the problems again. So doesn’t appear limited to just H.265 content.
@ChuckPa any update regarding this?
Also, this issue is not only related to Tizen clients but all clients overall.
Just an update. I bought a 10th gen Intel Nuc, installed proxmox, clustered it with my 12th gen Nuc, and migrated the Plex container over to the 10th gen system.
Quality has been perfect since - though the issue remains on current gen intel QS. (I can easily migrate between the two to reproduce the issues)
I seem to have mitigated the issue by disabling HW encoding with the following option:
It still needs more testing so I can see if the difference is real, or its just my hopes and dreams.
For now, I think this lowered the artefacting when transcoding.
Is there any update regarding this issue? As I’m seeing the same.
i5-12400, UHD730, Server 2022 (not VM), Version 1.41.1.9057
4K, HEVC, AAC7.1, HW transcode 1080p (subs ON or OFF - makes no difference) - intermittent pixelation, but seems more prevalent in high action/dark scenes.
Disabling “Use hardware acceleration” fixes the issue - but CPU goes from idle to 60% to manage, which I’d expect.
I tried just disabling “hardware accelerated video encoding” - as per zbe post – this does seem to fix the issue, but then causes major buffering (even though CPU is still only at 60%)?
CPU usage does increase by disabling HW encoding a bit for me, but not enough to cause any buffering, even on multiple streams. I do however, hear the fans spin up when a new stream is started.
I have spun up a Jellyfin instance to see how it looks there, and it’s also normal, so this is probably an issue with how Plex handles HW encoding with QSV.
I just hope there will be some kind of update for this, since having HW encoding disabled is like a bandaid for a stab wound, since not everyone has CPUs capable of handling this as it seems.
I was going to troubleshoot/test this further; but from all the comments so far and now your Jellyfin addition (I was thinking of spinning it up to test as well) I won’t bother, as it’s clearly 11th gen+ and Plex related. The strange thing is I’m sure this wasn’t always the case - so I’m trying to track down what actually changed (and when)…or maybe I just never noticed?
Agreed about the update coming soon, the main reason I purchased a Plex Pass was for the HW coding options (alongside supporting Plex as I’d used the free version for years) - not a massive issue in the short term (for me) as I can fail over to CPU - but to echo your comment, I’m assuming many users can’t.
Yes, no need to test further on different devices. I can move my Plex container seamlessly between my two NUCs (clustered) to reproduce the issue on 11th gen+, and to watch it go away on my 10th gen.
Since I have this running on a NUC, I’m purely reliant on QSV - alternative encoding is not an option with this hardware. The whole point was 10+ streams on QSV (no need for more) in a 20w package with memory / cpu to spare for other containers on the same system. It’s amazing when it works, but I’ll have to settle with a second 10th gen dedicated to Plex for quality’s sake.
I hope this will get some attention. My family has been watching more than usual this week, and my CPU usage on my i9 went up quite a bit. It’s fine with one to three streams, but more than 5 and my CPU is begging for help when a stream starts.
I’ve been moving some of my family over to Jellyfin (those, that don’t have Samsung TVs) cause of this. It’s nice since transcoded stuff is also in H265, so it even uses less bandwidth when transcoding. But I would love it If I could actually use the service I paid a license for.
Also, the Tizen client is more or less dependent on the transcoding function for me, since most of my stuff has PGS or ASS subs, and the Plex client for Tizen does not like any of these.
@ChuckPa, I know I already asked, but are there any eyes on this? This issue has been around for a few years now, and more and more users will have the same issues. People are running on NUCs, are moving their servers to newer gear (11th, 12th, 13th, 14th gen), etc.
I think we have provided more than enough context, media samples, and reports for this issue to be escalated further.
Bumping to keep acitve
2025 and still struggling.
Bumping
Honestly, I don’t expect much to change on this front until the upgrade to FFmpeg 6.x that’s in the works is completed. I wouldn’t be surprised at all if the entire problem was caused by using the ancient 4.x branch that Plex is currently on in combination with newer Intel drivers.
