Color corruption on resize when HW transcoding HEVC content - Synology DS920+

This is a continuation of this thread: Color corruption on resize when HW transcoding HEVC content - Synology DS920+ - #16 by ChuckPa

I use a Synology DS220+ and I’ve just upgraded to plex pass premium to benefit of the hardware transcoding and I am facing the same artifacts and issues while transcoding.

The plex media server is installed directly in DSM without any docker container or other virtualisation.

Any thoughts on it? It seems that the previous post was closed without a solution.

1 Like

Same setup, same issue…

Here’s a workaround, by @jaB00M :
https://forums.plex.tv/t/color-corruption-on-resize-when-hw-transcoding-hevc-content-to-h264-4k-subs-synology-ds918-nas/223645/16

but…I dont know how to do this. I’m stucked after the “cd /volume1/@appstore/Plex Media Server” SSH command…

…and too afraid to make mistakes and crash my lovely Plex

An update on this would be great. I’m running a DS423+ and encountering the same HVEC color corruption as others in plex server releases beyond 1.32.7.7621.

May I ask for the short-form summary?

Are you all saying:

  1. Given GeminiLake CPU (DS920+ → DS923+)
  2. You are getting color corruption when transcoding?
  3. The unofficial workaround is to remove the nv12 from the FFMPEG command line?

As you all know, GeminiLake has been a very problematic QSV ASIC.
All our work points to a regression in the Intel Media Driver.

That having been said,

Can anyone provide me with:

  1. A sample of the video
  2. whatever FFMPEG changes are needed for this “workaround” so I can replicate.

– Sorry, I didn’t know this was still an issue. I thought it had been finally resolved when we updated the Intel Media Driver for Ubuntu 24.04 (which was then used for everyone).

One alternative workaround for GeminiLake is to change the VaapiDriver from IMD → i965 (which the GeminiLake does very well with being an older CPU)

Either way, I now have DS920+ here so can test and replicate.

First of all, thank you @ChuckPa for your quick answer. Really.

  1. For me, yes, it’s a Intel Celeron J4125 GeminiLake
  2. Yes
  3. Yes

My setup :

  • DS920+
  • Plex Version 1.41.1.9057 on DSM (latest)
  • Playing on Shield Pro 2019

For the samples :
The media test is a 1080p HEVC file.

Original :

1080p 20Mb/s :


(no problem)

and now, 720p 4Mb/s :


After reading some of your previous answers on different threads, I tried to add the following lines on the Preferences.xml :

  • VaapiDriver=“i965” => nothing happens (artifacts still here). Hardware transcoding
  • VaapiDriver=“iHD” => no artifacts. Software transcoding (CPU at 100%)
  • VaapiDriver=“imd” => same.

As I said, for the moment, I think my best chance is to try the @jaB00M workaround, but…I don’t know how to do this.

I use Plex since 2021. During this, I uploaded my 920+ from DSM6 to DSM7. I don’t remember there was any problem with this. And I don’t remember this issue was here 1 year ago. Maybe yes…

Thanks again

Hi all,

Just to chime in here - I don’t currently have the issue on my NAS - so I retired the workaround script @Les_Jouets is referring to a few years ago.

I’m still running on the same Synology DS918+, currently with:

  • DSM v7.2.1-69057 (Update 5)
  • Plex Server Synology Package v1.41.1.9057.

The DS918+ is an ApolloLake Celeron J3455 though - so as suggested - perhaps the regression has only occurred on GeminiLake. Certainly the screenshots look exactly the same as the problem I’d previously had.

I’ve no idea if the workaround I made back then still works - I would expect the command line args may have evolved a little as there have been a few major releases of FFmpeg in the intervening time.

Not sure if it’s connected in anyway - but I noticed Intel recently abandoned the Intel-Vaapi-Driver repo on github.

[IMPORTANT] Discontinuation of intel-vaapi-driver Project by xhaihao · Pull Request #569 · intel/intel-vaapi-driver

1 Like
  1. yes, I’m using a DS423+ which is an Intel Celeron J4125 GeminiLake processor
  2. yes
  3. I have not tried removing nv12 from the ffmpeg command line. I downgraded plex server to 1.32.7.7621 which does not suffer from this issue. All server releases beyond this version leads to HVEC trancoding color corruption, as far as I’m aware. Likely a naive question, but what changed in transcoding after 1.32.7.7621?

I don’t have a screenshot available to show this but happy to upgrade plex server and send one over. Most obvious when watching cartoons.

My concern is that synology released DSM 7.2.2 and, from what I understand, this update necessitates upgrading plex server to 1.41.0.8994-72008994 which has the color corruption issue, with no way of downgrading the server back to 1.32.7.7621…

May I have a sample of the video which causes this artifacting when transcoded?

Screenshots showing the problem are not helpful except for me to verify I’m seeing what you see WHEN I recreate it.

In an attempt to recreate what you see. I’ve already tried:

  1. BluRay Rip
  2. Transcoded to 3 Mbps
  3. Yes, you can see the macroblocking at the lower quality
  4. No, there is no artifacting

@ChuckPa

Do you have an HEVC Main 10 video to test? I think it mostly affects these types of videos.

I just updated plex server to 1.40.4.8840 on DSM 7.2.1 (DS423+).

I then compared direct streaming a 1080p HEVC Main 10 file or hw trancoding to 720p.

direct stream 1080p:

720p hw trancode:

Notice the color distortions around edges (i.e. ears) when hw transcoding on this version of plex.

Happy to send this file over to you - just let me know the best way to do this.

Thanks again for looking into this.

Is this what you’re referencing?

Am I correctly seeing where you are taking a 1.2 Mbps video and transcoding it?

Yes, I would very much appreciate a copy of the video

Here is HDR-10 as requested.

Yes those artifacts are what I’m referencing.

Yes I was transcoding a 1.2 Mbps 1080p video to 720p in the original screenshots.

Here is another example using a better quality reference video:

original 3.1 Mbps, 1080P, direct stream:

and now hw transcoded to 480p @ 1.5 Mbps:

You can clearly see artefactual color striping here:

Here is the transcoding info:

Please tell me how I can send you a copy of the video(s) - should I upload via google drive or can I send directly to you?

Can you try a 1080p file? I haven’t extensively tested 4K/4K HDR files.

These are the types of files the hw transcoding struggles with (1080p HEVC Main 10):

I don’t have any 1080p HEVC HDR (main 10).

Can you get me a sample / enough of that file to replicate with?

yes - how do you want me to send to you? The first file is under 20 MB

PM sent

Cheers - link sent

Working on it now. I will summarize when done.

Using Nvidia GPU

Using GLK GPU

Using FFMPEG 6.

1 Like

@ChuckPa

how did the tests go?

Seems like the color corruption is present in only the GLK GPU image above, which is the behavior many of us are having. Any workarounds? Again this only seems to be happening in PMS versions later than 1.32.7.7621.

@snipernumber2

Correct. The issue only occurs with GLK on Transcoder (FFMPEG v4.x)

When I used different FFMPEG versions, the issue did not occur.

I am hoping, which we’ll be able to test soon (transcoder upgrade preview), that it is resolved for PMS as well.

1 Like