Intel N97 - Struggling getting HW-Tonemapping working

[sh0rty 715]

Migrated my Emby Server to a small N97 box with attached DAS enclosure. Everything including HW-transcoding is working flawlessly except for content that requires (hardware) tonemapping. 
In this case the GPU is uitilized 0% and the full load is on the GPU. In theory the N97 (Specs) should be capable of tonemapping. Any suggestions what I could do to get it working @Luke@softworkz? I'm running latest Emby Stable Server 4.8.10.0 on an uptodate Windows 11 Pro. Windows Driver for UHD Graphics is 32.0.101.6129 (18.10.2024).

Tried latest Beta server with same results. Out of ideas, I tried Jellyfin and the whole transcoding chain is working (GPU around 90% and lower CPU consumption with ca. 140fps  compared to Emby with 100% CPU and 0% GPU with 35-45 fps).

Attached are the logs and the settings. Thanks for any suggestions!

embyserver.txt hardware_detection-63871253410.txt ffmpeg-transcode-b92b6a89-02fc-40cb-abc1-f9b4f54e865f_1.txt

Edited December 31, 2024 by shorty1483

[sh0rty 715]

The interesting part in transcode log seems to be this one:

14:50:17.251   Stream #0:0 (hevc_qsv) -> vpp_qsv:default (graph 0)
14:50:17.251   vpp_qsv:default (graph 0) -> Stream #0:0 (h264_qsv)
14:50:17.251   Stream #0:1 -> #0:1 (dts (dca) -> ac3 (native))
14:50:17.251 Press [q] to stop, [?] for help
14:50:18.126 [supertonemap_opencl@f4 @ 00000282eff9e540] Failed to build program: -11.
14:50:18.126 [supertonemap_opencl@f4 @ 00000282eff9e540] Build log:
1:2:26: error: unknown OpenCL extension 'cl_intel_required_subgroup_size' - ignoring
#pragma OPENCL EXTENSION cl_intel_required_subgroup_size : enable
                         ^
1:4:26: error: unknown OpenCL extension 'cl_khr_d3d11_sharing' - ignoring
#pragma OPENCL EXTENSION cl_khr_d3d11_sharing : enable
                         ^
1:5:26: error: unknown OpenCL extension 'cl_intel_d3d11_nv12_media_sharing' - ignoring
#pragma OPENCL EXTENSION cl_intel_d3d11_nv12_media_sharing : enable
                         ^

14:50:18.126 Error while filtering: I/O error
14:50:18.126 Failed to inject frame into filter network: I/O error
14:50:18.126 Error while processing the decoded data for stream #0:0
14:50:18.170 Conversion failed!
14:50:18.170 EXIT

Is this somehow fixable on my end? The device is running headless. I already disabled HW-accelerated RDP as suggested in Emby Wiki. When i set up the server, I did it with a local monitor connected over HDMI. 

Sorry for the dumb questions, but I am pretty new the onboard Intel Quicksync stuff (formerly NVENC user for 10 years now).

Possibly related to the following thread (same error message)? But my N97 has onboard graphics driver, no ARC like in the other thread. But it seems I could downgrade to the mentioned 31.0.101.5122 last working driver or upgrade to 32.0.101.6332 safely, since Intels site says the driver is also for my N97 (Intel® UHD Graphics for 12th Gen Intel® Processors)? @yocker

 

PS: Have a happy new year!

Edited December 31, 2024 by shorty1483

[yocker 1247]

1 hour ago, shorty1483 said:

The interesting part in transcode log seems to be this one:

14:50:17.251   Stream #0:0 (hevc_qsv) -> vpp_qsv:default (graph 0)
14:50:17.251   vpp_qsv:default (graph 0) -> Stream #0:0 (h264_qsv)
14:50:17.251   Stream #0:1 -> #0:1 (dts (dca) -> ac3 (native))
14:50:17.251 Press [q] to stop, [?] for help
14:50:18.126 [supertonemap_opencl@f4 @ 00000282eff9e540] Failed to build program: -11.
14:50:18.126 [supertonemap_opencl@f4 @ 00000282eff9e540] Build log:
1:2:26: error: unknown OpenCL extension 'cl_intel_required_subgroup_size' - ignoring
#pragma OPENCL EXTENSION cl_intel_required_subgroup_size : enable
                         ^
1:4:26: error: unknown OpenCL extension 'cl_khr_d3d11_sharing' - ignoring
#pragma OPENCL EXTENSION cl_khr_d3d11_sharing : enable
                         ^
1:5:26: error: unknown OpenCL extension 'cl_intel_d3d11_nv12_media_sharing' - ignoring
#pragma OPENCL EXTENSION cl_intel_d3d11_nv12_media_sharing : enable
                         ^

14:50:18.126 Error while filtering: I/O error
14:50:18.126 Failed to inject frame into filter network: I/O error
14:50:18.126 Error while processing the decoded data for stream #0:0
14:50:18.170 Conversion failed!
14:50:18.170 EXIT

Is this somehow fixable on my end? The device is running headless. I already disabled HW-accelerated RDP as suggested in Emby Wiki. When i set up the server, I did it with a local monitor connected over HDMI. 

Sorry for the dumb questions, but I am pretty new the onboard Intel Quicksync stuff (formerly NVENC user for 10 years now).

Possibly related to the following thread (same error message)? But my N97 has onboard graphics driver, no ARC like in the other thread. But it seems I could downgrade to the mentioned 31.0.101.5122 last working driver or upgrade to 32.0.101.6332 safely, since Intels site says the driver is also for my N97 (Intel® UHD Graphics for 12th Gen Intel® Processors)? @yocker

 

PS: Have a happy new year!

There are some commands that can be run that might help. Can't find them now being new years eve and having had some to drink but you should be able to find them on this forum.

You can also try to disable all Quick sync and use VAAPI instead, some people report that working.

[sh0rty 715]

1 hour ago, yocker said:

There are some commands that can be run that might help. Can't find them now being new years eve and having had some to drink but you should be able to find them on this forum.

You can also try to disable all Quick sync and use VAAPI instead, some people report that working.

Wish I could also drink, but I'm sitting in my home office with my dog next to me and brown noise as "music" since 2 hours, because he's panicking from fireworks.  

But thanks to your suggestion from the other thread I took the risk to upgrade to the latest 32.0.101.6332 with no success. After that I downgraded to 31.0.101.5122/5085 et voila, HW-Tonemapping works as it should with around 100fps. Since the server is just for Emby, I do not care for less 3D performance. Conclusion: Latest Intel driver 6332 -> still crap.

23:57:20.066   Stream #0:0 (hevc_qsv) -> vpp_qsv:default (graph 0)
23:57:20.066   vpp_qsv:default (graph 0) -> Stream #0:0 (h264_qsv)
23:57:20.066   Stream #0:1 -> #0:1 (truehd (native) -> mp3 (libmp3lame))
23:57:20.066 Press [q] to stop, [?] for help
23:57:21.061 Output #0, segment, to 'C:\Users\blingbling\AppData\Roaming\Emby-Server\transcoding-temp\E04847\E04847_%d.ts':
23:57:21.062   Metadata:
23:57:21.062     encoder         : Lavf59.27.100
23:57:21.062   Stream #0:0: Video: h264, qsv(progressive), 1920x1080 [SAR 1:1 DAR 16:9], q=2-31, 4616 kb/s, 23.98 fps, 90k tbn
23:57:21.062     Metadata:
23:57:21.062       encoder         : Lavc59.37.100 h264_qsv
23:57:21.062     Side data:
23:57:21.062       cpb: bitrate max/min/avg: 4616001/0/4616001 buffer size: 9232002 vbv_delay: N/A
23:57:21.062       DOVI configuration record: version: 1.0, profile: 7, level: 6, rpu flag: 1, el flag: 1, bl flag: 1, compatibility id: 6
23:57:21.062   Stream #0:1(ger): Audio: mp3, 48000 Hz, stereo, s32p, 192 kb/s (default)
23:57:21.062     Metadata:
23:57:21.062       encoder         : Lavc59.37.100 libmp3lame
23:57:21.062 elapsed=00:00:00.36 frame=    1 fps=0.0 q=0.0 size=N/A time=00:00:00.00 bitrate=N/A throttle=off speed=   0x    
23:57:21.062 elapsed=00:00:00.99 frame=    1 fps=0.0 q=0.0 size=N/A time=00:00:00.00 bitrate=N/A throttle=off speed=   0x    
23:57:21.568 elapsed=00:00:01.50 frame=   64 fps= 43 q=18.0 size=N/A time=00:00:02.64 bitrate=N/A throttle=off speed=1.76x    
23:57:21.703 [segment @ 00000185b6cd3c80] Opening 'C:\Users\blingbling\AppData\Roaming\Emby-Server\transcoding-temp\E04847\E04847.m3u8.tmp' for writing
.
.
.
23:57:32.122 elapsed=00:00:12.05 frame= 1277 fps=106 q=24.0 size=N/A time=00:00:53.23 bitrate=N/A throttle=off speed=4.42x    

Thanks again @yockerfor your suggestions (also in the other thread) and a Happy New Year to all!

 

@Luke@ebrWouldn't it be useful to put the info about the buggy Intel driver and the last working 5122/5085 version into the knowledge base in case more people have the problem until the problem is fixed by Intel or a workaround is present by you guys (honestly I would bet more on you than on Intel )?

Edited January 1, 2025 by shorty1483

[Clackdor 109]

2 hours ago, shorty1483 said:

Wouldn't it be useful to put the info about the buggy Intel driver and the last working 5122/5085 version into the knowledge base in case more people have the problem until the problem is fixed by Intel or a workaround is present by you guys (honestly I would bet more on you than on Intel )?

Agreed, this is something that needs to be better documented and monitored. Currently all of the information is scattered across multiple forum threads. I ran into the issue a while back on my windows server with a 12600k with the uhd 770 IGPU after updating drivers.

In my case I was able to roll back to 31.0.101.5382 (driver date 3-27-24) and hardware tone mapping was working again. I'm not sure if there is a more recent driver that works as I was just trying to fix the problem ASAP.

It would be nice to have a list of known working drivers for igpu's as well as Arc GPU's until the issue is resolved with the latest ones (whether the fix comes from Intel or emby.)

[yocker 1247]

3 hours ago, shorty1483 said:

Wish I could also drink, but I'm sitting in my home office with my dog next to me and brown noise as "music" since 2 hours, because he's panicking from fireworks.  

But thanks to your suggestion from the other thread I took the risk to upgrade to the latest 32.0.101.6332 with no success. After that I downgraded to 31.0.101.5122/5085 et voila, HW-Tonemapping works as it should with around 100fps. Since the server is just for Emby, I do not care for less 3D performance. Conclusion: Latest Intel driver 6332 -> still crap.

23:57:20.066   Stream #0:0 (hevc_qsv) -> vpp_qsv:default (graph 0)
23:57:20.066   vpp_qsv:default (graph 0) -> Stream #0:0 (h264_qsv)
23:57:20.066   Stream #0:1 -> #0:1 (truehd (native) -> mp3 (libmp3lame))
23:57:20.066 Press [q] to stop, [?] for help
23:57:21.061 Output #0, segment, to 'C:\Users\blingbling\AppData\Roaming\Emby-Server\transcoding-temp\E04847\E04847_%d.ts':
23:57:21.062   Metadata:
23:57:21.062     encoder         : Lavf59.27.100
23:57:21.062   Stream #0:0: Video: h264, qsv(progressive), 1920x1080 [SAR 1:1 DAR 16:9], q=2-31, 4616 kb/s, 23.98 fps, 90k tbn
23:57:21.062     Metadata:
23:57:21.062       encoder         : Lavc59.37.100 h264_qsv
23:57:21.062     Side data:
23:57:21.062       cpb: bitrate max/min/avg: 4616001/0/4616001 buffer size: 9232002 vbv_delay: N/A
23:57:21.062       DOVI configuration record: version: 1.0, profile: 7, level: 6, rpu flag: 1, el flag: 1, bl flag: 1, compatibility id: 6
23:57:21.062   Stream #0:1(ger): Audio: mp3, 48000 Hz, stereo, s32p, 192 kb/s (default)
23:57:21.062     Metadata:
23:57:21.062       encoder         : Lavc59.37.100 libmp3lame
23:57:21.062 elapsed=00:00:00.36 frame=    1 fps=0.0 q=0.0 size=N/A time=00:00:00.00 bitrate=N/A throttle=off speed=   0x    
23:57:21.062 elapsed=00:00:00.99 frame=    1 fps=0.0 q=0.0 size=N/A time=00:00:00.00 bitrate=N/A throttle=off speed=   0x    
23:57:21.568 elapsed=00:00:01.50 frame=   64 fps= 43 q=18.0 size=N/A time=00:00:02.64 bitrate=N/A throttle=off speed=1.76x    
23:57:21.703 [segment @ 00000185b6cd3c80] Opening 'C:\Users\blingbling\AppData\Roaming\Emby-Server\transcoding-temp\E04847\E04847.m3u8.tmp' for writing
.
.
.
23:57:32.122 elapsed=00:00:12.05 frame= 1277 fps=106 q=24.0 size=N/A time=00:00:53.23 bitrate=N/A throttle=off speed=4.42x    

Thanks again @yockerfor your suggestions (also in the other thread) and a Happy New Year to all!

 

@Luke@ebrWouldn't it be useful to put the info about the buggy Intel driver and the last working 5122/5085 version into the knowledge base in case more people have the problem until the problem is fixed by Intel or a workaround is present by you guys (honestly I would bet more on you than on Intel )?

I'm alone this new years also, what i had to drink is from just visiting the old neighbors and saying happy new years.
Give the dog some treats and pets from me.

Happy to hear what i have written helped.
I don't think Intel is even aware of the problem since it has been a problem for so long. Linux has fixed the problem in newer kernels and the other Media Servers like Plex and Jellyfin seems to have fixed it bandaid style by just disabling quick sync when intel arc is detected (not 100% sure on that but what info i can find says).

So i suggest people with the problem write to Intel about it and keep at it (in a friendly manner!!) until Intel fixes it.

[Thidsa 44]

Anyone tried some of the latest drivers?

[Clackdor 109]

@ThidsaThe issue is likely fixed in beta builds. I'm not sure what the ETA is for those fixes to make it to the stable release. 

[Thidsa 44]

If its just likely ill wait a little longer. Works ok as is...

[sh0rty 715]

Weird enough, Jellyfin needs the latest drivers as it seems while Emby stable needs an old one. 

  

On 5/24/2025 at 2:28 AM, Clackdor said:

@ThidsaThe issue is likely fixed in beta builds. I'm not sure what the ETA is for those fixes to make it to the stable release. 

@Luke@softworkzIf there is a fix in Emby Beta, is this already merged in latest stable so I am able to update my Graphics driver to a version newer than early 2024?

Edited June 16, 2025 by sh0rty

[Luke 42077]

On 6/16/2025 at 10:44 AM, sh0rty said:

Weird enough, Jellyfin needs the latest drivers as it seems while Emby stable needs an old one. 

  

@Luke@softworkzIf there is a fix in Emby Beta, is this already merged in latest stable so I am able to update my Graphics driver to a version newer than early 2024?

Hi, you'd have to just give it a try and let us know. If not, we will also have an updated ffmpeg build on the server beta channel in the neat future. Thanks.

[sh0rty 715]

On 6/17/2025 at 7:10 PM, Luke said:

Hi, you'd have to just give it a try and let us know. If not, we will also have an updated ffmpeg build on the server beta channel in the neat future. Thanks.

Just recognized that the old working Intel driver 31.0.101.5122/5085 fails to work with Tonemapping when updating to 24H2 (at least on my system). When I reverted back to 23H2 everything back to working state regarding HW-Transocding with Tonemapping activated. Before torturing the thread with new logs I want to politely ask if there is an approx. ETA when the updated ffmpeg will make it into Stable so I can also update my Intel driver to latest and therefor Windows to 24H2?

Edited August 22, 2025 by sh0rty

[Luke 42077]

It will be on the beta channel first in the near future, and then make it's way to stable. Thanks.

[sh0rty 715]

Can anyone confirm that the Intel driver issue is fixed with Emby 4.9.1.80?

 

@Luke did 4.9.1.80 stable include the updated ffmpeg?

Edited October 27, 2025 by sh0rty

[Luke 42077]

1 hour ago, sh0rty said:

Can anyone confirm that the Intel driver issue is fixed with Emby 4.9.1.80?

 

@Luke did 4.9.1.80 stable include the updated ffmpeg?

It does not. The beta channel has an updated intel driver. We are still working on updating the ffmpeg build.

[Thidsa 44]

Works for me now with 4.9.1.80 ,24h2 and driver 32.0.101.7029 (sept 6,25)

Before on 4.8, 23h2 i had to use the driver @Clackdormentioned from early 24

This on a i5-13600k, not n97

Edited October 27, 2025 by Thidsa
add