Intel UHD 770 QuickSync - Hardware Tone Mapping Produces Washed Out Colors on Unraid

[Brendin 0]

Setup:

• CPU: Intel Raptor Lake with UHD 770 iGPU
• OS: Unraid (Docker)
• Emby: Official Emby Docker container (version 4.9.x)
• GPU passthrough: /dev/dri/renderD128 and /dev/dri/card0 mapped correctly
• OpenCL installed: intel-opencl-icd, ocl-icd-libopencl1, intel-media-va-driver-non-free

 

Question: Is this a known limitation with Emby's hardware tone mapping on Intel iGPUs? Plex produces vibrant, accurate colors with the same UHD 770 hardware. Is there a fix or workaround, or is my only option to use software tone mapping (with high CPU usage) for proper color accuracy?

 

 

Emby: Set as 10 Mbps (No Direct Play)

Plex: Set as 10 Mbps (No Direct Play)

ffmpeg-transcode-df0df95e-e4ee-4e9d-b895-2408672e5b81_1.txt embyserver.txt

Edited November 8, 2025 by Brendin

[Abobader 3477]

Hello Brendin,

** This is an auto reply **

Please wait for someone from staff support or our members to reply to you.

It's recommended to provide more info, as it explain in this thread:

Thank you.

Emby Team

[GrimReaper 4813]

Have you tried using difefrent algorithm, i.e. Mobius and see how does it compare? 

Edit: Also, if you disable experimental HEVC encoding and transcode to AVC, are you getting same results? 

Edited November 8, 2025 by GrimReaper

[Brendin 0]

Hi, thanks for the reply!

Update:

I've disabled experimental HEVC encoding and tried changing the tone mapping algorithm from Hable to Mobius - still washed out colors. Then I tried Reinhard and still no improvement.

Also, what do you mean by "transcode to AVC"? Is there a specific setting to force AVC/H.264 output instead of HEVC? I can't find that option in the transcoding settings.

[GrimReaper 4813]

4 minutes ago, Brendin said:

Is there a specific setting to force AVC/H.264 output instead of HEVC?

Disabling HEVC does it (you should be able to see it in your ffmpeg log also). 

5 minutes ago, Brendin said:

I've disabled experimental HEVC encoding

 

[GrimReaper 4813]

11 minutes ago, Brendin said:

I've disabled experimental HEVC encoding and tried changing the tone mapping algorithm from Hable to Mobius - still washed out colors. Then I tried Reinhard and still no improvement.

Not sure of any other recommendation at this point, maybe try enabling VAAPI and move it on top, see what kind of results you'd get. Otherwise, maybe @softworkzmight have a hint or two. 

[Brendin 0]

5 minutes ago, GrimReaper said:

Not sure of any other recommendation at this point, maybe try enabling VAAPI and move it on top, see what kind of results you'd get. Otherwise, maybe @softworkzmight have a hint or two. 

Update 2:

I tried moving VAAPI to the top of the hardware acceleration list and enabled "VAAPI HW Tone Mapping." This fixed the color issues, but the video looked blocky/pixelated and my CPU would spike to 100%.

Then I changed it to "Extra-T - OpenCL" which didn't use any CPU power, but the colors are still washed out.

 

VAAPI HW Tone Mapping: ON

VAAPI HW Tone Mapping: ON

VAAPI HW Tone Mapping: Extra-T - OpenCL

VAAPI HW Tone Mapping: Extra-T - OpenCL

[Brendin 0]

Update 3:

I tried playing the same video in the Emby app from the Windows Store, and the colors are working correctly! Plex still looks slightly better due to darker/richer colors, but the Emby Windows app is manageable and much better than Chrome.

I'm not sure why Chrome is washing out the colors when the Windows app displays them properly?

For my settings, I'm only using QuickSync (not VAAPI) with the Hable tone mapping algorithm. I tried the other algorithms ( mobius, reinhard) but they're all too bright.

 

Thanks @GrimReaper trying to help!

So, i should say is this normal on Chrome/Edge Browser or a new bug?

 

[softworkz 5103]

@Brendin- please post ffmpeg logs to be sure about what's happening.

[Luke 42135]

@Brendin?

[redoXiD 3]

On 11/9/2025 at 12:28 PM, softworkz said:

@Brendin- please post ffmpeg logs to be sure about what's happening.

I have the exact same issue and I think was able to identify the root cause.

Environment:

• Emby Server: 4.10.0.5 beta (same behavior on 4.9.3.0 but switched to beta as there were changes to transcoding/tonemapping)
• OS: Unraid (Docker, LSIO image)
• Hardware: i5-14600K (Intel UHD 770 iGPU)
• Affected clients: web browsers (I tested Firefox and Chrome)

I compared the ffmpeg commands generated by Emby web app and Windows app playback. The filter chains looked identical, so I downloaded one of the transcoded .ts segments and inspected it with MediaInfo. This revealed incorrect color space metadata in the output:

Color primaries                          : BT.2020 (should be BT.709)
Transfer characteristics                 : BT.709
Matrix coefficients                      : BT.2020 non-constant (should be BT.709)

The transfer characteristics are correctly rewritten to BT.709 after tone mapping, but color_primaries and matrix_coefficients are still BT.2020. Browsers like Firefox and Chrome seem to still interpret the stream as HDR and apply their own additional HDR to SDR conversion on top of the already tone-mapped video, which I think causes the desaturated appearance. I was able to confirm this in Chrome by briefly switching browser tabs between a broken and a fixed test clip - the broken version looks correct for a split second before the browser applies its own color conversion.

ffmpeg-transcode-ed4165ea-88ed-473b-861a-e770172e3833_1.txt

Comparing Emby's generated command to Plex (which produces correct output on the same hardware), there is a notable difference:

Emby generates:

tonemap_opencl=tonemap=mobius:format=nv12:desat=0

Plex generates:

tonemap_opencl=tonemap=mobius:format=nv12:m=bt709:p=bt709:r=tv

Without the parameters m=bt709:p=bt709:r=tv the tone mapper probably does not know what target color space it is converting to or something like that, resulting in both suboptimal pixel values and incorrect output metadata.

I manually ran both versions of the ffmpeg command (the original Emby command and the modified one with m=bt709:p=bt709:r=tv added) and encoded 10-second test clips from the same source file.

These were the used commands:

Spoiler

Emby parameters:

"LD_LIBRARY_PATH=/app/emby/lib:/app/emby/extra/lib OCL_ICD_VENDORS=/app/emby/extra/etc/OpenCL/vendors LIBVA_DRIVERS_PATH=/usr/lib/x86_64-linux-gnu/dri:/app/emby/extra/lib/dri ./bin/ffmpeg -y -init_hw_device qsv=dev1:hw_any,child_device=/dev/dri/renderD128 -filter_hw_device dev1 -f matroska,webm -ss 00:00:10.000 -c:v:0 hevc_qsv -threads:v:0 1 -hwaccel:v:0 qsv -hwaccel_output_format:v:0 qsv -noautorotate -i '/data/media/tv/Foundation/S01/Foundation.S01E01.Der.Frieden.des.Kaisers.GERMAN.DL.2160p.DV.HDR.WEB.H265-TSCC/Foundation.S01E01.Der.Frieden.des.Kaisers.GERMAN.DL.2160p.DV.HDR.WEB.H265-TSCC.mkv' -filter_complex '[0:0]vpp_qsv@f1=width=1920:height=960:async_depth=8,setparams@f2=color_primaries=bt2020:color_trc=smpte2084:colorspace=bt2020nc,hwmap@f3=mode=+read:derive_device=opencl,tonemap_opencl@f4=tonemap=mobius:format=nv12:desat=0,hwmap@f5=mode=+write:derive_device=qsv:reverse=1:extra_hw_frames=16[f5_out0]' -map '[f5_out0]' -map 0:1 -c:v:0 h264_qsv -b:v:0 29616000 -maxrate:v:0 29616000 -bufsize:v:0 59232000 -r:v:0 23.976024627685547 -profile:v:0 high -c:a:0 libmp3lame -ab:a:0 192000 -ac:a:0 2 -t 10 /config/foundation_broken.mp4

Modified (Plex) parameters:

"LD_LIBRARY_PATH=/app/emby/lib:/app/emby/extra/lib OCL_ICD_VENDORS=/app/emby/extra/etc/OpenCL/vendors LIBVA_DRIVERS_PATH=/usr/lib/x86_64-linux-gnu/dri:/app/emby/extra/lib/dri ./bin/ffmpeg -y -init_hw_device qsv=dev1:hw_any,child_device=/dev/dri/renderD128 -filter_hw_device dev1 -f matroska,webm -ss 00:00:10.000 -c:v:0 hevc_qsv -threads:v:0 1 -hwaccel:v:0 qsv -hwaccel_output_format:v:0 qsv -noautorotate -i '/data/media/tv/Foundation/S01/Foundation.S01E01.Der.Frieden.des.Kaisers.GERMAN.DL.2160p.DV.HDR.WEB.H265-TSCC/Foundation.S01E01.Der.Frieden.des.Kaisers.GERMAN.DL.2160p.DV.HDR.WEB.H265-TSCC.mkv' -filter_complex '[0:0]vpp_qsv@f1=width=1920:height=960:async_depth=8,setparams@f2=color_primaries=bt2020:color_trc=smpte2084:colorspace=bt2020nc,hwmap@f3=mode=+read:derive_device=opencl,tonemap_opencl@f4=tonemap=mobius:format=nv12:desat=0:m=bt709:p=bt709:r=tv,hwmap@f5=mode=+write:derive_device=qsv:reverse=1:extra_hw_frames=16[f5_out0]' -map '[f5_out0]' -map 0:1 -c:v:0 h264_qsv -b:v:0 29616000 -maxrate:v:0 29616000 -bufsize:v:0 59232000 -r:v:0 23.976024627685547 -profile:v:0 high -c:a:0 libmp3lame -ab:a:0 192000 -ac:a:0 2 -t 10 /config/foundation_fixed.mp4

Output files (you have to download them, as the proxy generated by GDrive looks fine, at least on my PC):
https://drive.google.com/drive/folders/1h0HG0zYUO3mOxed6IliBuRCh8ZDvbt6a?usp=drive_link

- original parameters: Color primaries and matrix coefficients BT.2020, looks washed out in browser
- With "Plex parameters": All color metadata field show BT.709, colors look accurate and matches Plex output

The fix would probably be to add m=bt709:p=bt709:r=tv to the tonemap_opencl filter in the transcoding/tonemapping command, at least in my test scenario it solves the problems with both the metadata and the visual output.

Happy to provide further information if needed.

[softworkz 5103]

@redoXiD

Thanks for the analysis. Our tonemap_opencl filter is totally different from the regular one in ffmpeg (and faster), but your observation are probably still valid.

@sa2000

Let's track this as post-ffmpeg migration task

[redoXiD 3]

I already figured that, which is why I used Emby's ffmpeg version inside the Docker container for my testing instead of a regular ffmpeg binary.

Thanks for looking into this!

As a temporary fix I used the "Parameter adjustment" option in the Diagnostics plugin, works great so far:

Text to replace:

tonemap_opencl@f4=tonemap=mobius:format=nv12:desat=0,

Replacement text:

tonemap_opencl@f4=tonemap=mobius:format=nv12:desat=0:m=bt709:p=bt709:r=tv,

(this example also includes the tone so filter type, so one would have to adjust it or maybe it's also possible to use a shorter match without the filter type)

[softworkz 5103]

The problem is that the number (f4) will change depending on how many filters are present before the tonemap filter (e.g. scale or no scale), so you should start later, like

=tonemap=mobius:format=nv12:desat=0,

even though, this might possible conflict with other tone mapping filters (sw tone mapping).

 

9 minutes ago, redoXiD said:

I already figured that, which is why I used Emby's ffmpeg version inside the Docker container for my testing instead of a regular ffmpeg binary.

In the new ffmpeg, this will be a separate filter named extratonemap_opencl, and tonemap_opencl will be the original one from ffmpeg, because extratonemap_opencl uses Intel-specific OpenCL extensions (which make it faster) and we need the default one for AMD GPUs.

[softworkz 5103]

Just now, softworkz said:

even though, this might possible conflict with other tone mapping filters (sw tone mapping).

No, it's fine, these don't have a format parameter.

[redoXiD 3]

11 minutes ago, softworkz said:

The problem is that the number (f4) will change depending on how many filters are present before the tonemap filter (e.g. scale or no scale), so you should start later

Thanks, I wasn't aware of this. But makes totally sense, I'll try to change it.

11 minutes ago, softworkz said:

In the new ffmpeg, this will be a separate filter named extratonemap_opencl, and tonemap_opencl will be the original one from ffmpeg, because extratonemap_opencl uses Intel-specific OpenCL extensions (which make it faster) and we need the default one for AMD GPUs.

Sounds interesting, I guess a fix will come with the new ffmpeg version? Or already sooner?