Skip to content

[EXPERIMENTAL] CoreELEC 22 · samurihl DV build (20260728200740)

Pre-release
Pre-release

Choose a tag to compare

@SamuriHL SamuriHL released this 29 Jul 00:13
· 461 commits to samurihl-ce22 since this release

⚠️ EXPERIMENTAL · UNSUPPORTED · USE AT YOUR OWN RISK

This is an unofficial, experimental CoreELEC 22 build. It is NOT an official
CoreELEC release and it is NOT a supported CE22 port.
I am not a CoreELEC 22
port maintainer, and I will not be providing support, bug fixes, updates, or
ongoing maintenance for this build.

The only purpose of this build is to give Amlogic AM9 Pro-class users a more
complete Dolby Vision experience than stock CoreELEC 22, by carrying a set of
custom Kodi features I built for my own device. That is the entire scope.

READ THIS BEFORE YOU FLASH ANYTHING

  • USE ENTIRELY AT YOUR OWN RISK. There is no warranty of any kind, express
    or implied. It may fail to boot, misbehave, break Dolby Vision, or do nothing
    useful on your hardware.
  • BACK UP YOUR CURRENT INSTALLATION FIRST. Take a full CoreELEC backup
    (Settings → CoreELEC → Backup) and/or image your existing boot media before
    you install anything from here. Assume you may have to restore it.
  • Prefer a SEPARATE SD card or USB stick you can boot from, instead of
    overwriting a working internal (eMMC) install.
  • Do NOT report problems with this build to the CoreELEC team or forums.
    This is not their build; it is not their responsibility. Do not ask them to
    support it.
  • I am also not offering support. If it breaks, you keep both pieces.

By downloading or using any file in this release you accept all of the above.

Install

  • Clean install (recommended): flash the *.img.gz to an SD card or USB with
    balenaEtcher (or the Amlogic USB Burning Tool for eMMC), then boot from it.
  • In-place update: copy the *.tar to the /storage/.update folder on an
    existing CoreELEC install and reboot. (Back up first — see above.)
  • Verify your download against the SHA256 sums below before flashing.

What's changed in this update

This is an incremental update to
v22.0-samurihl-20260725153731
(see that release and its predecessors for the standing feature set: Blu‑ray disc
menus, HDR10+ → Dolby Vision conversion, DV → HDR10 that stays in HDR10, FEL
profile‑7 reconstruction on non‑DV displays, VS10 output on non‑DV displays, VSVDB
override, tone‑mapping target controls).

Two things: the last release's two known limitations are both gone, and Dolby
Vision CMv4.0 metadata gained proper shadow handling.

The previous notes warned that graphics authored brighter than 80 nits would clip, and
that older‑style HDMV disc menus weren't corrected at all. Both are fixed — and the
first turned out to be the reason the second was so hard to get right.

⚠️ Still experimental and completely unsupported — see the disclaimer above.
Back up your current install before flashing.

Dolby Vision still requires dovi.ko (the CE22 5.15 build) installed on your
device — it is not bundled; install it yourself as on stock CoreELEC 22.


⚠️ Read this first: menus will look different, and that's the fix

Disc menus and subtitles on HDR titles have been rendering about 2½× brighter than
the disc intended
. They now render at the brightness actually authored, which on
some discs is noticeably dimmer than what you have been seeing.

That is the correction, not a regression. Menus authored dim were designed to be dim.

If you prefer more brightness, the control is Settings → System → Display → GUI peak
luminance
. It now raises graphics and the reference they are decoded against
together, so it brightens the picture‑over‑menu without reintroducing the colour
errors below. Previously those two halves disagreed, which is what caused all of this.


🎨 Menu and subtitle colour is now correct, not just "less wrong"

The colour correction introduced over the last few releases decodes disc graphics from
the wide‑gamut PQ space they're authored in, so the display pipeline can encode them
exactly once instead of twice. That correction was decoding against a fixed 80‑nit
reference white
while the display pipeline encoded against roughly 202 nits.

Because PQ describes absolute brightness, a mismatch like that isn't a subtle
inaccuracy — it's a straight 2½× gain applied to every menu, overlay and subtitle. It
produced two symptoms that looked unrelated:

  • Discs authoring dim menus merely came out too bright, with colour intact. This is
    what "graphics above 80 nits will clip" in the last release was really describing.
  • Discs authoring bright menus were pushed past what the graphics layer can
    represent, so all three colour channels hit the ceiling together. Once they do, the
    ratios that carry hue are gone and the artwork collapses toward a flat, desaturated
    near‑white.

Both sides now resolve the same reference white from the same setting, so the decode is
a true inverse of the encode and authored brightness survives the trip end to end.

Verified on a reference player showing the same discs: menus that were previously
"close" now match, and menus that were previously washed out are correct.

🎬 HDMV disc menus are corrected now too

The other limitation from last time. Only Java (BD‑J) menus and subtitles were being
corrected; older‑style HDMV interactive menus weren't touched, because no disc with
genuine HDMV menus on an HDR playlist had been available to test against.

One turned up. On it, menu chrome authored between 106 and 294 nits was landing at
46–68 nits — roughly a quarter of intended. Bright elements lose the most in this
failure mode, which is why the highlight around the selected button was the part
that looked almost missing while duller chrome still looked plausible.

HDMV menu palettes now get the same correction as BD‑J artwork. Menus on SDR
playlists are untouched — that path is byte‑for‑byte identical to before, so discs
whose menus already looked right cannot have moved.

🌗 Dolby Vision CMv4.0: proper shadow detail from CMv2.9 sources

CMv4.0 metadata carries a trim block (L8) that CMv2.9 discs don't have. When
synthesising it, the older trims are now carried across so the generated metadata
describes the same picture instead of a neutral default, which is what makes CMv4.0
worth using on these sources: it fixes the raised‑black and shadow problems CMv2.9 has
on many displays.

  • Smart remains the default, deliberately. The trim transfer is faithful at the
    low end — where CMv4.0 earns its keep — but upper‑range tone‑mapping trims do
    not transfer cleanly, and highlights are better served by leaving those alone.
    Smart is what chooses between the two per scene. Setting append to Always will
    give you worse highlights, not better ones.
  • The append mode and Smart threshold now apply live, without restarting playback.
  • Dolby Vision RPU metadata is now processed on single‑stream files that previous
    builds skipped, so those titles get the same treatment as the rest.
  • On player‑led Dolby Vision output, Smart is pinned to a plain append, avoiding a
    per‑frame decision the box's display mapping doesn't act on anyway.

Where this actually lands. On display‑led (TV‑led) output the improvement
applies fully — that path was verified on two different panels. On player‑led
output (LLDV, or Dolby Vision converted to HDR10) the box's own display mapping
suppresses these trims on letterboxed content, for the reason described in the next
section. That isn't a limitation of the metadata work; it's the hardware below it.

🎞️ Letterboxed Dolby Vision: what the L5 setting can and can't do

This has been investigated at length this cycle and is worth stating plainly, because
the Level 5 (active area) mode setting has two options and neither is universally
"correct" — the trade‑off is real and cannot be engineered away on this hardware.

Dolby Vision metadata can describe an active area: the part of the frame that's
actual picture, excluding letterbox bars. When that's present, the Dolby Vision engine
in the box deliberately refuses to raise black level. That is intentional design,
not a defect — lifting black inside a letterboxed frame would turn the matte bars grey,
which is precisely what the active‑area signal exists to prevent. Only raising black
is blocked; crushing it still works, and the asymmetry is what proves it's deliberate.

The consequence on player‑led output is a genuine either/or:

  • L5 mode = Source — bars stay properly black, and a disc's positive shadow lift is
    discarded.
  • L5 mode = Zero — the shadow lift works, and the letterbox bars lift to grey along
    with the picture.

There is no third option. The correct fix would be for the player to mask the bars so
the lift becomes safe, and the Dolby Vision engine does implement exactly that on its
TV‑facing path — but the registers are not implemented on the set‑top path on
either SoC family tested here (S922X/G12B and S6). That was verified directly by
driver instrumentation and confirmed by eye, so it's a hardware limitation rather than
something a future build can address.

Display‑led (TV‑led) output has none of this. The TV's own display mapping scopes
trims to the active area correctly, so the picture lifts and the bars stay black — no
choice to make. If you care about shadow detail on letterboxed Dolby Vision, that is
the path to use.

🔧 Under the hood

  • Tone‑mapping target overrides now actually reach the hardware. The min/max
    luminance controls were being applied at only one of the two places the Dolby Vision
    driver takes that path, so on many streams they silently did nothing. If you tried
    those controls in an earlier release and concluded they had no effect, try again —
    they are live now.
  • Low‑latency Dolby Vision output no longer advertises more brightness than the
    content has
    , capping the signalled peak to the content's own mastering peak.
  • Rebased onto current upstream CoreELEC/Kodi, which brings in a substantial batch of
    upstream fixes — including the Amlogic windowing and mode‑switch rework, subtitle
    crash fixes, and nfo‑parsing performance work.

Known limitations

Being explicit about what is not fixed:

  • Graphics authored brighter than the GUI peak still clip. The ceiling is now the
    graphics layer's own white point (~202 nits at the default setting) rather than an
    arbitrary internal constant, and raising GUI peak luminance raises it. One test
    disc authors menu chrome at 294 nits, so its brightest elements still clip at default
    settings.
  • HDMV menu correction is validated on exactly one disc. It's the only disc on hand
    with HDMV menus on an HDR playlist. The SDR path is provably unchanged, so the risk
    is confined to HDR HDMV titles.
  • Subtitles were not separately re‑verified this cycle. They use the same corrected
    transform and benefit by construction, but only menus were checked by eye.
  • Player‑led Dolby Vision cannot both lift shadows and keep letterbox bars black
    see the Level 5 section above. Hardware limitation, confirmed on both G12B and S6,
    not addressable by the player. Display‑led (TV‑led) output is unaffected.
  • The CMv4.0 shadow improvement is therefore display‑led‑first. On player‑led
    output with letterboxed content, the same suppression applies to the synthesised
    trims. Nothing is broken; the trims simply aren't acted on by the box's display
    mapping in that combination.
  • Dolby Vision → HDR10 conversion can look over‑bright if your display or EDID
    advertises a peak at or above ~3000 nits, where the conversion engine switches to an
    aggressive up‑mapping curve. Below that it renders correctly. A cap for this is
    identified but not implemented here.
  • A CoreELEC logo frame can still flash when a disc opens. Traced to the display
    surface being torn down on an HDR‑triggered mode switch even when resolution and
    refresh rate are unchanged; not fixed here.
  • 3D (MVC) and VC‑1 Blu‑rays still don't decode. Both are upstream Amlogic/CoreELEC
    limitations rather than anything this fork introduced.

Source

  • CoreELEC (distro): SamuriHL/CoreELEC tag v22.0-samurihl-20260728200740
  • Kodi: SamuriHL/coreelec-xbmc tag v22.0-samurihl-20260728200740

Checksums (SHA256)

252ebe23139ea2dce3c4b45d9d60ccd460d0041f2f5880b654ab82856fe8d07a  CoreELEC-Amlogic-no.aarch64-22.0-Piers-samurihl-EXPERIMENTAL_20260728200740.tar
c526ff102912d824afb258db5bb840ab1173d88c4ca288d3aea1684ca1e536b8  CoreELEC-Amlogic-no.aarch64-22.0-Piers-samurihl-EXPERIMENTAL_20260728200740-Generic.img.gz