HDR10 blanking screen intermittently on Nightlies (not on stable), plus wrong video output levels.

    Chewitt suggested I opened a discussion here before going to GitHub and so here I am.

    On a NUC11TNKI3 (i3-1115G4) I am experiencing the following.

    In Nightlies (tried today's) HDR10 content sees the screen "blank" intermittently. It's like the TV is temporarily losing the signal and soon after getting it back in a split second. On my LG TV (it's a C1 OLED) this has the HDR logo appearing and disappearing constantly in the top right corner, which is a clear indication of the signal getting lost and the getting connected soon after. I tested the stable release (12.2.1) and it doesn't happen.

    On both Nightlies and stable I am also seeing video levels being output incorrectly. My TV is calibrated to 16-235, I activate "Use limited color range (16-235) under Settings/System/Display/General but if I play back both HDR and SDR material, black level is raised, obviously wrong looking. I used test patterns in both SDR and HDR to check and level 16 (for SDR) and 64 (for HDR), instead of being black, are perfectly visible as a dark grey (and even levels below 16, for SDR, and 64, for HDR, are clearly visible). If I disable "Use limited color range" in settings, black levels seem normal but the GUI displays with clear black crush.

    As an extra element of information, using CroqueMr's Dolby Vision experimental builds (that can convert HDR10 to Dolby Vision), if I convert HDR10 to Dolby Vision levels appear correctly. I haven't tested with Dolby Vision patterns as I don't think I have them (I should look more thoroughly, though).


    I remain available to provide logs or test whatever might be required.

    EDIT:
    The NUC is connected to a Denon X3800H AVR and from there to the LG C1. On the same connection an Ugoos AM6B+ has no problem outputting HDR10, nor displays wrong video levels. HDMI cable is supposedly of good quality (certified for HDMI 2.1 use).

    Quote from ashlar

    My TV is calibrated to 16-235, I activate "Use limited color range (16-235) under Settings/System/Display/General but if I play back both HDR and SDR material, black level is raised, obviously wrong looking.

    That's because levels are compressed twice - in the shaders and by the driver. I have an open Kodi PR with a fix.

    Quote from ashlar

    I tested the stable release (12.2.1) and it doesn't happen.

    Your NUC has 2 HDMI ports - one native, the other one via DP PCON. Try another port.

    Quote from smp

    That's because levels are compressed twice - in the shaders and by the driver. I have an open Kodi PR with a fix.

    Could you link it here, please? And thank you.

    Quote from smp

    Your NUC has 2 HDMI ports - one native, the other one via DP PCON. Try another port.

    I am using port 2, which is the native one (known to solve audio problems too).

    I think I discovered something interesting.

    The NUC has a 2.0 HDMI port. It's not 2.1. As such, it can output a maximum of 2160p 60Hz 8 bit. Whereas it can output 2160p 24/25Hz at 10 bit.

    I had my GUI set at 2160p 60Hz. And the output was 8 bit. When I tried switching to 24Hz, in order to avoid the auto refresh rate switch, the problem came back almost instantly. At GUI level, no video playback.

    The TV, when refresh rate switches to lower than 50Hz values (so 30, 29.97, 25, 24, 23.976) for some reason receives a 10 bit signal. I have an LG C1 OLED, pressing repeatedly the green button on the remote brings up an info overlay with data on refresh rate, resolution and bit depth.

    When the NUC is outputting 2160p at 30, 29.97, 25, 24 and 23.976Hz, the TV shows that the input signal is "RGB 10b TM". When the NUC outputs 2160p at 60 or 50Hz the TV shows the input signal is "RGB 8b TM".

    I wanted to understand why the Dolby Vision conversions from CroqueMR builds seemed to solve the problem.

    And the answer I think lies in how the 12 bit DV signal is sent to the TV for a TV led solution. Inside an 8 bit transport stream. In fact, with the conversions active, the TV reports the signal as "RGB 8b TM" and everything works perfectly with no screen blanking at all.

    The "TM" thing has to do with how HDMI 2.0 sends data. It stands for Transition Minimized Differential Signaling, and it's the way HDMI 2.0 transmits to the TV. HDMI 2.1 uses FRL (Fixed Rate Link).

    So, to sum it up... the problem seems to derive from 10 bit color depth in the signal. It's not a bandwidth problem (after all 2160p 60Hz is the maximum HDMI 2.0 can output) and I really don't think it could be the cable, which is a brand new HDMI 2.1 cable (plus I tested it connecting the NUC directly with the cable coming from the TV too, another HDMI 2.1 cable that works perfectly for both an AM6B+ and an Nvidia RTX 4070 outputting 4K at 120Hz).

    I actually wonder if a solution exists or if I have to sell this NUC and call it quits.

    Try this image. It includes this PR which gives you full control over bit depth/color format options from Kodi GUI. See which 4K modes work ok on your setup. Intel does not support 4:2:2, so don't try it. 4:2:0 is only for 4K 50/60.

    Quote from smp

    Try this image. It includes this PR which gives you full control over bit depth/color format options from Kodi GUI. See which 4K modes work ok on your setup. Intel does not support 4:2:2, so don't try it. 4:2:0 is only for 4K 50/60.

    Can I install it on a key and try it from there?

    I am beginning to strongly suspect that my NUC is defective. Tested a live run of Kubuntu with mpv, same thing with 10 bit. Tested a live run of Windows 11 (the ages it took to become operative...), same thing with 10 bit.
    I could maybe simply live by converting HDR10 and HDR10+ to Dolby Vision with CroqueMr's builds, since SDR content seems to work ok. I've been doing it on AM6B+ anyway for a long time now.

    I am also considering buying a different NUC, maybe a 14 Pro if I can find a good price. But then, I mean, if that doesn't work correctly as well, I'm really wasting money...

    Quote from smp

    Yes.

    Yup, already prepared the key. It has just booted up. I'll report back shortly. Thanks for trying to help, it's really appreciated.

    Only way 4K HDR10 played with no glitching was forcing 8 bit output. Which is of course not ideal. At that point, converting to Dolby Vision with CroqueMr's builds at least should not discard color information.

    Considering everything I've tried (see above the different OSs), it's probably my NUC being defective? Or is there anything that might be wrong in how Intel distributed/implemented their drivers on both Linux and Windows?

    Edited once, last by ashlar: Merged a post created by ashlar into this post. (November 5, 2026 at 3:11 AM).

    Quote from HiassofT

    chewitt I guess this patch should better be dropped and intel devs need to fix the issue properly

    I don't think this would cause problems. The patch caps the DRM connector at 10-bit output to prevent it ending up in 12-bit which results in bandwidth issues when HBR audio is present. For DV output we are tunnelling in 8-bit RGB and avoid the problem. I don't see DV issues with a Generic build based on current development running on an N150 box.

    That patch is a hack though, so a candidate for improvement as userspace vs. kernel colour support evolves.

    Quote from chewitt

    I don't think this would cause problems. The patch caps the DRM connector at 10-bit output to prevent it ending up in 12-bit which results in bandwidth issues when HBR audio is present. For DV output we are tunnelling in 8-bit RGB and avoid the problem. I don't see DV issues with a Generic build based on current development running on an N150 box.

    That patch is a hack though, so a candidate for improvement as userspace vs. kernel colour support evolves.

    I am sorry to ask in a development discussion but since my predicament is so... peculiar? I take the liberty. Pardon me in advance, if you're so kind.

    Is there a surefire "everything works" NUC among the recent series? NUC 13? NUC 14? Something that's confirmed to work correctly through an AVR (even if in my case the problem is not the AVR). Or are these shenanigans happening across the whole Intel range of products?

    Quote from chewitt

    I don't think this would cause problems. The patch caps the DRM connector at 10-bit output to prevent it ending up in 12-bit which results in bandwidth issues when HBR audio is present. For DV output we are tunnelling in 8-bit RGB and avoid the problem. I don't see DV issues with a Generic build based on current development running on an N150 box.

    That patch is a hack though, so a candidate for improvement as userspace vs. kernel colour support evolves.

    I'm not convinced it's a bandwidth issue, even 720p has enough bandwidth for HBR audio. More likely they got their N / CTS values wrong or have some other clocking issue (that's just an educated guess though, I'm not familiar with the intel driver).

    ashlar could you give this build a try: https://www.horus.com/~hias/tmp/libr…-50716e4.img.gz - that's current LE master with the "10bit hack patch" dropped.

    No idea if this actually helps (guess video output might then be at 12bit instead of 10) but it would be an interesting data point to know if this patch has some (negative) impact.

    so long,

    Hias