LUT Calibration fails with UGREEN 25173 + Ezcoo SP12H21 — "The error is too high"

[pappaq]

Setup

• Source: Apple TV 4K (Dolby Vision, 50Hz)
• AVR: Denon AVR-X2800H (HDMI Out 1 → Ezcoo)
• Splitter: Ezcoo EZ-SP12H21 (HDMI 2.1)
  • Output 1 → LG C4 77" OLED (4K DV, works perfectly)
  • Output 2 → UGREEN 25173 (no scaler)
• Grabber: UGREEN 25173 (CM700), connected via USB 3.0 to Proxmox host
• HyperHDR: Running in a Proxmox LXC container (Debian 12 Bookworm), USB passthrough for /dev/video0
• P010: Working (DKMS patch installed, P010 shows up in v4l2-ctl and in the HyperHDR GUI)
• Kernel: Proxmox 6.17.13-2-pve (x86_64)
• HyperHDR version: Latest stable from the Debian repo

What works

• P010 capture at 1080p25 — confirmed in HyperHDR GUI and via v4l2-ctl
• Live preview in HyperHDR looks good — a little bit less bright than the TV picture, correct colors - Much too bright if HDR to SDR Tone Mapping is active
• Normal video playback capture works perfectly

Problem

LUT calibration always fails with "The calibration failed. The error is too high."

I've tried every combination:

• P010 1080p25, P010 1080p60
• HDR calibration file (calibration_HDR_yuv420_limited_range.mp4)
• Apple TV set to 4K DV 50Hz, and also tried 1080p SDR 50Hz
• Ezcoo scaler on Output 2: OFF
• Quarter of frame mode: disabled
• Blackbar detector: disabled
• LCH correction: disabled
• Video played via VLC on Apple TV, fullscreen, no overlays
• Contrast set to both -1 and default (0)

The captured color values are always identical regardless of settings:

White: [ 255 255 255 ] => [ 161 165 162 ] (YUV: [ 157 127 126 ])
RED:   [ 255   0   0 ] => [ 173  92  77 ] (YUV: [ 109 113 164 ])
GREEN: [   0 255   0 ] => [ 111 165 103 ] (YUV: [ 144 106 107 ])
BLUE:  [   0   0 255 ] => [  64  60 182 ] (YUV: [  76 181 125 ])

WHITE_0:  [   0   0   0 ] => [   6   6   6 ] (YUV: [  21 128 128 ])
WHITE_1:  [  16  16  16 ] => [  55  60  54 ] (YUV: [  66 126 126 ])
WHITE_8:  [ 128 128 128 ] => [ 124 130 124 ] (YUV: [ 126 126 126 ])
WHITE_16: [ 255 255 255 ] => [ 161 165 162 ] (YUV: [ 157 127 126 ])

The dynamic range is compressed to roughly 63% (255 → 161). This appears to be caused by the Ezcoo SP12H21 converting the HDR signal to SDR on Output 2 before it reaches the grabber. The calibrator's error tolerance is exceeded by this compression.

The calibration successfully captures all 8 test boards (0–7) every time. It fails during the computation phase after all boards are captured.

Colorspace info from v4l2-ctl (with HyperHDR stopped)

NV12 at 3840x2160 (Ezcoo scaler OFF):

Format Video Capture:
    Width/Height  : 3840/2160
    Pixel Format  : 'NV12' (Y/UV 4:2:0)
    Colorspace    : sRGB
    Transfer Function : Rec. 709
    YCbCr/HSV Encoding: Rec. 709
    Quantization  : Default (maps to Limited Range)

P010 at 1920x1080 (Ezcoo scaler OFF):

Format Video Capture:
    Width/Height  : 1920/1080
    Pixel Format  : 'P010' (10-bit Y/UV 4:2:0)
    Colorspace    : sRGB
    Transfer Function : Rec. 709
    YCbCr/HSV Encoding: Rec. 709
    Quantization  : Default (maps to Full Range)

Both show Rec. 709 / sRGB — no HDR metadata. The Ezcoo SP12H21 converts the signal to SDR on Output 2 regardless of input format. Note that NV12 reports Limited Range while P010 reports Full Range.

Question

Is there a way to calibrate the LUT for this setup where the splitter always outputs SDR on the grabber port? Do I do something wrong with the splitter? The live preview with the default LUT + automatic tone mapping looks surprisingly good — is a custom LUT calibration even necessary in this case, or is the default LUT sufficient for SDR-converted P010 signals?

Any guidance would be appreciated.

Screenshot and full log:

HyperHDR_log.md

[awawa-dev]

Garbage in, garbage out. Even the video player could play a role in that scenario, and the AI should suggest it to you. UGREEN 25173 + Ezcoo SP12H21 are not the problem (unless their manufactures changed something) but they only a part of the longer path that produced it.

[pappaq]

Thanks for the pointer. Since my last post I've done more testing to narrow down the issue.

What I changed

I flashed the xnappo custom firmware EZ-SP12H21_CS-BT2020_ML-385_hdr10+.hex onto my Ezcoo SP12H21 using the GD32 All-In-One Programmer v5.0.6.

What I tested

DIP switch positions on the Ezcoo after flashing:

• DIP 000 (EDID Copy): The live preview in HyperHDR shows a pink image. This suggests the Ezcoo is now outputting LLDV on this position. However, calibration breaks immediately — it cannot read the test boards at all.

• DIP 111 (4K@60Hz 7.1 — needed for Dolby Vision + Dolby Atmos + variable frame rates): The live preview shows the same grey/washed-out image as before the flash. No change compared to factory firmware on this position.

• Other DIP combinations: Tried all of them, none produce a usable HDR signal for calibration.

Direct connection test (no Ezcoo)

When I connect the Apple TV 4K directly to the UGREEN 25173 (bypassing the Ezcoo entirely), the live preview image looks perfect — bright, correct colors, full dynamic range. This confirms the Ezcoo SP12H21 is the component compressing/converting the signal on Output 2.

v4l2 verification

With HyperHDR stopped, DV content playing on Apple TV, Ezcoo in the chain, scaler off:

$ v4l2-ctl -d /dev/video0 --set-fmt-video=width=1920,height=1080,pixelformat=P010
$ v4l2-ctl -d /dev/video0 --get-fmt-video

Format Video Capture:
    Width/Height  : 1920/1080
    Pixel Format  : 'P010' (10-bit Y/UV 4:2:0)
    Colorspace    : sRGB
    Transfer Function : Rec. 709
    YCbCr/HSV Encoding: Rec. 709
    Quantization  : Default (maps to Full Range)

It shows Rec.709 / sRGB — no HDR metadata (no SMPTE 2084, no BT.2020) reaches the grabber through the Ezcoo, regardless of DIP switch position or firmware.

Summary

The Ezcoo SP12H21 converts the HDR signal to SDR on Output 2 in every configuration I've tested, except DIP 000 with the xnappo firmware where it outputs LLDV (pink image) but the calibration won't work with that signal? The EDID position I actually need for daily use (DV + Atmos + VRR) always produces the compressed grey image.

Does anyone with an Ezcoo SP12H21 + UGREEN 25173 have a working LUT calibration?

I use AI to ride these posts in a good and understandable manner. Sorry, if that concerns you. Any suggestions appreciated.

[awawa-dev]

Using AI is fine, I even recommend it! But you need to draw your own conclusions from its output and ask specific questions. I’m not going to read long AI-generated ramblings or analyze them for you ;-)

[pappaq]

That's fair — and honestly not what I was expecting either. I was mainly hoping someone else might have run into the same issue with a similar setup and could share what fixed it. So far I haven't found anyone online running this exact chain (Apple TV 4K → Denon AVR → Ezcoo SP12H21 → UGREEN 25173 → HyperHDR in a Proxmox LXC container).

My next step will be to connect the grabber to a Windows machine and see if the calibration behaves differently there. Trial and error it is.

I would have appreciated some input on the codec and video standard side of things — specifically why the Ezcoo might be outputting a compressed SDR signal on Output 2 even with the scaler disabled and custom firmware flashed, or why the calibrator's error threshold is exceeded by that signal. But I understand that's a deep rabbit hole.

Thanks for your reply regardless — appreciate the work you put into HyperHDR.

[awawa-dev]

I already gave you a hint about the video player. By the way, you should change your AI agent because your current one failed to recognize this (it’s definitely not the Ezcoo, and most likely not the Ugreen either, so that only leaves...): WHITE_16: [ 255 255 255 ] => [ 161 165 162 ] (YUV: [ 157 127 126 ]); I don't own an Apple TV, so unless someone funds one for me, I have no way of analyzing it further and adjust the calibrator.

[pappaq]

Thanks for the follow-up. I took your hint about the video player seriously and did another round of testing — this time removing the Apple TV from the equation entirely.

Windows test setup

I connected my Windows 10 PC (AMD 9070 XT, HDR enabled) through the same chain:

PC → Denon AVR-X2800H → Ezcoo SP12H21 → Output 2 → UGREEN 25173 → same PC (USB 3.0) → HyperHDR for Windows

I played the HDR calibration video (calibration_HDR_yuv420_limited_range.mp4) via VLC on Windows in fullscreen with HDR active on the display. The result: same grey/washed-out image in the HyperHDR live preview. Same compressed signal. Same behavior as with the Apple TV.

This rules out the Apple TV as the cause — the issue reproduces identically with a completely different source device and OS.

The only scenario where the live preview looks correct is when the source is connected directly to the UGREEN 25173 with no Ezcoo in the chain or when the UGREEN is connected to Output 1 of the Ezcoo. Probably because only a SDR signal is delivered to the UGREEN.

As soon as the Ezcoo SP12H21 is between the source and the grabber (Output2) and a HDR signal is going from Input to Output 1, it delivers a compressed signal regardless of:

• Source device (Apple TV 4K or Windows PC)
• Video player (VLC, Infuse)
• DIP switch / EDID position
• Scaler on or off
• Factory firmware or xnappo custom firmware

So it's not the video player and not the source device. It's specifically the Ezcoo SP12H21's Output 2 that compresses the dynamic range before it reaches the grabber when HDR material is going through Output 1.

Additionally: All cables are new 8k certified HDMI cables. I switched them already.

Is there anything else I should test, or is this potentially a hardware limitation of the SP12H21's second output that the calibrator can't compensate for? I hope today arrives a spare SP12H21, to rule out a hardware defect.

[awawa-dev]

Seriously man, now I'm fed up with this AI stream. Ask it about EDID. And no: Apple TV is still not rule out. This Splitter is "too dumb" to make any adjustment into the video content, beside changing the video codec and apply scaling. But it can modify EDID and Aplle TV can read it and adjust.. And cables...in the digital era? Unless you have some connectivity issue...

[pappaq]

I appreciate you taking the time to respond, but I'd appreciate it even more if you actually read my posts before dismissing them. My last message explicitly stated that I tested with a Windows PC as the source — not the Apple TV. Two different source devices, two different operating systems, identical result. The Apple TV is ruled out.

I understand you're frustrated with AI-assisted posts, but I've been nothing but polite and systematic in my troubleshooting. I used AI to help me document my setup clearly and communicate in English — that's it. Every test was performed by me, every log is real, every screenshot is mine. The systematic approach of isolating each component in the chain is just good debugging methodology, regardless of who suggested it.

Your attitude towards users asking for help has been noted elsewhere online as well, and frankly, it's discouraging for someone who genuinely wants to get your software working and has spent considerable time and money on hardware to do so.

Anyway — I found a workaround on my own: Switching the grabber to YUYV instead of P010 allowed the LUT calibration to complete successfully. So P010 calibration doesn't work through the Ezcoo SP12H21 in my setup, but YUYV does. The Ambilight effect with the calibrated YUYV LUT + tone mapping looks good in the live preview and the LED performance is flawless now and good enough for my needs.

Thanks for HyperHDR — it's genuinely great software. I just wish the support experience matched the quality of the product.