HW Tone Mapping Transcoding no longer works after updating to 4.9.1.80 (Synology 220+)

[bjjones 23]

Did this get addressed/fixed in the 4.9.3.0 release? Like above I'm holding off moving from 4.8.11 - thanks

[tlkounev 14]

No, same problem in 4.9.3.0.

[Luke 42828]

Hi, yes we are still looking at this. Thanks.

[tlkounev 14]

Has anyone tried the beta version 4.10.0.1?

[heffeque 92]

Using stable version here.

Maybe some brave knight will try it out to let us know!

[sa2000 806]

Emby Server Beta 4.10.0.2 is working for me with Hardware Acceleration and Tone Mapping on Synology with QuickSync GeminiLake UHD Graphics 600 GPU

 

[heffeque 92]

Awesome! 

Hopefully it comes to the stable branch soon! 

[NeverReadyEddie 2]

Still waiting for 4.10.0.2 to his stable release. Any news on when that might be?

[Luke 42828]

On 3/18/2026 at 9:46 AM, NeverReadyEddie said:

Still waiting for 4.10.0.2 to his stable release. Any news on when that might be?

Hi, we are working on getting a new stable release together. Thanks.

[Hot_Miguelus 0]

Hi,

I'm seeing exactly the same behaviour described in this thread on my Synology DS918+ (Intel J3455), but I spent some time trying to isolate the problem and I may have some additional information that could help.

Environment

• Emby Server 4.9.5.0
• Synology DS918+
• Intel J3455 (Apollo Lake)
• DSM 7.2.x
• Hardware acceleration enabled (Quick Sync + VAAPI)
• Tested with:

  Emby Web (Chrome on Windows)

  Emby Windows app

The problem

Whenever an HDR video is transcoded using hardware acceleration, the image becomes washed out, as if HDR is being displayed as SDR without proper tone mapping.

If I disable hardware acceleration and let FFmpeg perform software transcoding, the colours are correct.

Tests performed

I tried several different files and configurations to narrow it down.

HDR10 4K

• Hardware transcoding → washed out colours.
• Software transcoding → colours are correct.

Dolby Vision Profile 8.1 (HDR10 compatible)

• Hardware transcoding → washed out colours.
• Software transcoding → colours are correct.

HDR10 1080p

• Hardware transcoding → washed out colours.

I also tested:

• Quick Sync only (VAAPI disabled)
• Quick Sync + VAAPI
• Different remote streaming bitrates
• Different transcoding resolutions
• Emby Web and Emby Windows

The behaviour is always the same.

What I found in the logs

The interesting part is that Emby reports:

Tone Mapping would be desired, but hardware tone mapping is disabled

but immediately afterwards the processing plan says:

ToneMapping (when possible)
CanDoInHW = True
WillDoInHW = True

When I inspect the generated FFmpeg command, I only see:

HEVC_QSV
→ vpp_qsv (resize)
→ vpp_qsv (P010 → NV12)
→ H264_QSV

 

I cannot find any actual tone mapping filter being inserted (tonemap, tonemap_opencl, zscale, or any explicit BT.2020 → BT.709 colour conversion).

So it looks as if the processing plan expects hardware tone mapping to happen, but the generated FFmpeg command never actually performs it.

Question

Is this expected behaviour on Apollo Lake hardware, or could this be a bug or regression in the current hardware transcoding pipeline?

I've attached three different ffmpeg-transcode logs showing the same behaviour:

• HDR10 4K
• HDR10 1080p
• Dolby Vision Profile 8.1   (I also attach a software transconding log for this one)

If needed, I can also provide the corresponding embyserver logs.

Thanks!

4KHDR-ffmpeg-transcode-ce9e3357-e5fe-4e89-8083-135e1897db1b_1.txt 1080pHDR-ffmpeg-transcode-265e6ece-46b8-4317-bfd4-953bd2d6a758_1.txt 4KDV-Software_deco-ffmpeg-transcode-c8af9373-a1a5-40c3-a4ee-3037e5dd825d_1.txt 4KDV-Hardware_deco-ffmpeg-transcode-d506bd22-4ef2-4fc2-b0d1-0fc352bc8d04_1.txt

[heffeque 92]

Let's see if 4.10 solves it soon.

4.10.0.20-beta came out recently. Release notes don't mention changes on transcoding, but 99% of times the release notes don't contain all changes, so who knows (shrug) 

[Luke 42828]

Hi, there will be a new ffmpeg build on the server beta channel soon, so stay tuned for that. Thanks.

[softworkz 5331]

On 7/23/2026 at 1:56 PM, Hot_Miguelus said:

I cannot find any actual tone mapping filter being inserted (tonemap, tonemap_opencl, zscale, or any explicit BT.2020 → BT.709 colour conversion).

So it looks as if the processing plan expects hardware tone mapping to happen, but the generated FFmpeg command never actually performs it.

Question

Is this expected behaviour on Apollo Lake hardware, or could this be a bug or regression in the current hardware transcoding pipeline?

I've attached three different ffmpeg-transcode logs showing the same behaviour:

Well, did you enable tone mapping actually?

[sa2000 806]

The Emby Server Synology issues with hardware transcoding and tone mapping being enabled should be resolved in 4.10.x.x which is currently available as beta. The 4.9.5 release does not have the fix

[tlkounev 14]

But we are waiting for a solution for qnap nas. @Luke wrote that maybe someone is solving it but we doubt it. Can someone from the devs confirm that anyone knows about it at all? Communication from the emby team is zero on this. 

[sa2000 806]

3 minutes ago, tlkounev said:

But we are waiting for a solution for qnap

I know

my reply was specifically addressing the new synology related post 

[sa2000 806]

50 minutes ago, tlkounev said:

ut we are waiting for a solution for qnap nas. @Luke wrote that maybe someone is solving it but we doubt it. Can someone from the devs confirm that anyone knows about it at all? Communication from the emby team is zero on this. 

An observation - this topic was for synology and is in the synology forum category. We have fixed it for synology.

The QNAP issue should have been raised as a separate topic in the QNAP forum category. I will go through the posts in this topic and try to identify the QNAP related ones and move them to a new topic

Edited 14 minutes ago by sa2000