[x86-64][hadesdevls Builds] LibreELEC Hades - native Dolby Vision, HDR10+ and 3D

doppingkoala The chroma is never taken to 4:4:4 for P and T; only the intensity uses an interpolated chroma value, so nothing has to be filtered back down.

For each pair of pixels, from the composed picture:

• The 4:2:0 chroma goes to 4:2:2 vertically (the same 12-tap Lanczos step the YCbCr tunnel already does).
• P and T are computed at the even pixel, which sits on the 4:2:2 chroma sample: its own Y and that chroma, through the RPU's matrix to R'G'B', then linear light, LMS, PQ and IPT. No horizontal filter touches them.
• I is needed for both pixels. For the odd one, its chroma is interpolated horizontally with the same Lanczos, and only its I is kept.

So at the picture's own size, the only horizontal interpolation is the one any display has to do to turn 4:2:2 into RGB. With the YCbCr tunnel the TV does it with its own filter, and the intensity between the pairs depends on that filter. With IPT it's done once, before the conversion, and every TV receives the same intensity for every pixel. P and T come from the co-sited pixel rather than an average of the pair, so they carry the chroma sample that is there and nothing mixed in from its neighbour; YBLOD reports the same from captures of licensed Amlogic players. A picture that has to be scaled (a 1080p one) is scaled first, in the composer's YCbCr, from 4:2:0 straight to the 4:2:2 of the frame, and converted after that.

Measured as the bridge draws it on a software renderer, on 14 P7 FEL frames: against a float64 run of the same chain, never more than 1 code of 4096 off on any sample (0.58% of the I samples, 3.62% of P and 0.97% of T are 1 code off, from float arithmetic). Against the composed picture converted with its chroma interpolated in float, the co-sited samples are within 1 code and the ones between them within 4. The only bigger gaps are at hard colour edges, where the float interpolation rings past the range of codes and ours, in integers, is clamped to it. Profile 5 is already IPT in the file and keeps the same bytes as before. More in how it works.

Vertox Thanks for the details. The Iris Xe test is what pins this down.

Hades prints that line when neither of its two readers, ours and libdisplay-info, finds a Dolby Vision block in the EDID the driver gave it. If the G6 were offering only Low-Latency, the message would say so (you're right, it isn't game mode), and a block that libdisplay-info reads but our rule turns down gets a message of its own.

The same RC5 on the Iris Xe read a Dolby Vision Standard block from the same G6. Same code, same TV: the EDID that reaches Kodi on the 5090 is not the one that reaches it on the mini PC. To see exactly where the block goes missing I need the EDID and the kernel log from both machines, and the diagnostics have both:

• Tick "Save diagnostics there" in the installer when you update (on a USB drive you can also rename DIAG-OFF.TXT to DIAG-ON.TXT on its LIBREELEC partition).
• Start Hades, play a Dolby Vision file, wait five minutes and turn the PC off from its menu.
• Attach the hades-diag folder. On a USB drive it's on the LIBREELEC partition; on an internal disk, use LibreELEC settings, System, "Copy the diagnostics to a USB drive". Passwords, keys and addresses are removed before anything is written, and the README.txt inside says what each part is.

From the mini PC too, if you can: putting the two EDIDs side by side shows the difference straight away.

Quote from doppingkoala

hadesdevls Thanks for the details and reference.

Is that not identically equivalent to upsampling to 4:4:4, doing the conversion, and then dropping the odd chroma pixels rather doing standard chroma downsampling that first runs an anti-aliasing filter?

doppingkoala Yes. Converting at 4:4:4 and keeping the even P and T gives the same numbers, because the Lanczos interpolation passes through the co-sited samples: it is a drop, with no anti-alias filter. That filter is there for chroma that had full resolution before it was subsampled, and this never had it: the stream's chroma is 4:2:0, so above the 4:2:2 grid P and T only move where the luma changes under a coloured area, through the nonlinear steps (PQ and back). A filter would take some of that out, and it would also mix the exact co-sited value with one built from interpolated chroma. Which of the two a TV rebuilds closer depends on how it upsamples, and I haven't measured that, so I'll run both against the full 4:4:4 conversion, with a TV-style upsampling, and post the numbers. The co-sited choice is also what YBLOD reports from licensed Amlogic players.

Quote from ApexAftermath

Diagnostics attached. Just an FYI before I did anything, I first defaulted the display settings in system. 1st playback is with defaults, and 2nd is with NEVER on the frame ahead setting. Let me know if you have any questions or want me to run any other tests. Thanks!

ApexAftermath Thanks, this is exactly what was needed, and it changes the diagnosis.

• Presenting a frame ahead never ran on your card, in either run. Right after the first one the log says the output has no third buffer, and from then on every frame is presented the way that waits. The reason is in NVIDIA's GBM layer (egl-gbm), which Kodi draws through on NVIDIA: each surface sits on an EGL stream with a queue of two, the buffer on the screen and the one just committed, so there is never a third one to draw the next frame in. So the setting couldn't change anything, and what I read as the frame ahead hurting wasn't the setting.
• Your GT 1030 needs 46 to 49 ms of GPU time for a 4K P7 FEL frame at full fidelity, and 35 to 38 ms at the lowest step-down level, against 41.7 ms per refresh at 23.976 Hz. Without that third buffer a frame waits for the next refresh after it's drawn, and the next one only starts after that, so most frames take two refreshes: about 100 reach the screen every 10 s, of the 240 of the film.
• A few enhancement-layer pictures also fail to import (enhancement-dmabuf-import drm-prime-map in the log), each one a frame without its FEL residual.

The third buffer is what would make the difference on your card: with it, a 35 ms frame is drawn while the one before it is on the screen. That's what I'm looking into now, together with those imports.

ashlar For switching, the easy way is a drive for each build: Hades starts from a USB drive just as it does from an internal disk (the Windows installer writes one), so switching is choosing which drive to boot, and each one keeps its own settings and add-ons.

.update replaces the kernel and the system, but not the boot files, so it doesn't make a clean switch either way:

• Hades placed in .update on another build starts, but with that build's boot menu, so what Hades sets up when it's installed isn't there: its boot entries (such as the one that keeps the internal disks hidden when it starts from USB) and the diagnostics switch.
• Another build placed in .update on Hades is refused on purpose, because it would quietly drop Hades' features. Forcing it with .nocompat would start that build with Hades' boot menu, which I haven't tested and wouldn't recommend.

Quote from ashlar

Hmmm... ok. Thank you. Not the answer I was hoping for (and it reinforces my initial idea that having two different development paths would have been bad for testing) but let's see if I can work around it. Is there a way for me to have a USB key having the "full install"? Normally you use the Windows tool (but I have access to a Linux machine too) to create the USB key which installs on the internal disk. Is there a way to have the tool write to a different key? Like, I boot from an hades key built with Libre-ELEC USB-SD Creator, while having a second usb key in a different port. Does the installer allow me to select the second key as the install disk?

ashlar Yes, and you don't even need the second key: the key you write is already a full install. Started with "run", which is the default entry of its boot menu, Hades runs from the key itself, with its own storage partition for settings, add-ons and library. Installing to the internal disk is just one option in that menu, not something it has to do.

That's how I use it myself: my build runs from an external USB-C SSD, started with run, and it's easy to keep up to date. LibreELEC-Hades-Installer.exe has an option to update a drive that already has Hades: it replaces only the system and keeps everything else. From your Linux machine you can do the same by putting the release's .tar in the .update folder of the key's storage partition and booting it.

So a key for each build works well: one for Hades, one for CroqueMr's, and switching is just choosing which one to boot. A fast key or a small USB SSD makes it feel like an internal install.

Quote from ApexAftermath

Am I correct in assuming that changing this buffer setting in the menu from 2 to 3 either has nothing to do with this, or won't do anything unless changes are made in the back end?

ApexAftermath Right, it won't help, so leave it as it is. On this kind of system Kodi doesn't make buffers from that setting: it only uses it to estimate how late the picture reaches the screen, for audio sync, so changing it would at most shift the sound. The buffers that matter here are made by NVIDIA's GBM layer, and that's where the change has to happen.

Quote from CroqueMr

I can only encourage this approach. I've encouraged Hades to submit PRs to improve the engine and fork it to had his security features, but he seems to prefer replicating the features I've implemented in his own build instead. I personally don't really get it. It only creates confusion for users and duplicate work.

CroqueMr Thank you, first of all, for starting this. Hades exists because your fork showed it could be done on a PC, and the README says so, along with what came from it.

It has never been my intention to push anyone's work aside. I've been grateful to everyone who has moved this forward, starting with you, and I've always given credit. I've put the effort into my own implementations and my own tests, and I've never talked down your build or anyone else's, or called one better and another outdated: I've cheered every step forward, whoever made it.

I'd genuinely like to work together. Ideas have already gone both ways, which is how it should be: NVIDIA and HDR10+ are in both builds now, and Hades has taken things from yours and credited them. To me that isn't duplicate work, it's two builds getting better from each other. I wanted to add my own grain of sand too, and some of what Hades does sits underneath the engine rather than on top of it: the composer as ETSI GS CCM 001 defines it, the output inside the NVIDIA, AMD and Intel kernel drivers, a base built only from pinned and verified sources, and the safe defaults. That's why it became a build of its own rather than a set of PRs.

I don't see why two builds should be a problem. CoreELEC has had several side by side, and people have always enjoyed trying each one and watching them move forward. If you're open to it, I'd be glad to share measurements, test clips and fixes both ways, so both builds come out better.

Quote from CroqueMr

Yeah, but as I said, ETSI was already in my pipeline from the very first Kubuntu PoC, before LibreELEC and from R0.1.0. I added SMPTE and other standards starting with Beta 1. I do not communicate on norms because it is not interesting for users

Honestly, I find it a bit ridiculous to see you replicate features just hours after my releases, even Vega M support, which I originally added for a close friend.

You're free to maintain a separate build, but to me it's just duplicated effort, especially when you could benefit from all the AMD and Intel optimizations already done that your build does not have.

Anyway, you're free to go your own way, but I'd always be happy to collaborate on the engine through PRs rather than duplicating the work.

CroqueMr Fair enough on ETSI. To be clear, my list was what Hades does its own way, not a claim that your build doesn't follow the standards.

I don't see it as copying, in either direction. Your Beta4 credited Hades for its NVIDIA support, and thank you for that. HDR10+ shipped in Hades first and then came to yours, written your own way. And Vega M on Hades started from your linux-9925, which I'm grateful for: our patch says so, and I'll add the credit to the release notes as well. The code is Hades' own, and it goes further, to Polaris and Vega 10, 12 and 20.

I think we've been pushing each other forward, and not only the two of us: cinema-ONE with the 3D work for AMD and very thorough issues, Dangerouslaser with YBLOD's ideas and implementations (Dolby Vision for the menus in Hades comes from there), DMDreview's measurements of what licensed players send, which is why Hades now sends IPT, and everyone here reporting issues and suggestions, which is where much of each release comes from. The people testing both builds are the ones who come out ahead, and I'd like it to keep happening on purpose.

So yes, let's do it through PRs, both ways. Next week I'll start sending some, beginning with fixes that apply to your build as well, and I'll gladly look at any of your optimizations that could help Hades, just as I hope Hades' work can help yours.

Quote from CroqueMr

Yeah I credit your Nvidia support because I took it from your build (and unfortatenly I redo this work to be in GPLv2 or later), the remaining part not. my backlog is public I always communicate on what I am working : HDR10+, Extended support ... and now stable build then LLDV and optimisation of the different precessing pipeline. I am in GPLv2 or Later licencing, I can not grab your code because you are on GPLv3

I won’t be spending time pushing PRs to your build. The simplest and cleanest approach, from an architectural standpoint, would be for you to fork my build. That way, you could easily pull in all future updates, push PRs upstream, and integrate changes on your side.

What you're proposing isn't really how this should work. The whole point is to maintain one central codebase and build on top of it. Maintaining two separate builds and duplicating the work makes no sense to me.

But if you ever change your mind, I'd be more than happy to collaborate.

CroqueMr Thanks for explaining, the licence part helps. In Hades, the Kodi code outside the Dolby Vision module is GPL-2.0-or-later, like Kodi itself; the module is GPL-3.0-or-later because it started from the dvbridge of your fork, which was GPLv3 when Hades took it, and Hades kept that licence. I'm happy to offer what Hades wrote under GPL-2.0-or-later as well, so you can take anything that's useful to you.

I value the work you and everyone else here have put into this, and I'd appreciate the same respect for mine. Hades is the result of a great deal of work: its own implementations, written and tested before they ship, and shaped by the reports people send. Where an idea came from someone else, it says so. That's why it will stay a build of its own: it's what I run, and it exists for its security model (internal disks hidden, verified sources, a locked-down kernel), which reaches the whole system rather than the engine.

That doesn't stop me from contributing to yours: I'll fork it and send PRs upstream where something fits your engine, starting next week. Different paths, same goal, and I'm glad to keep sharing the road.

Quote from ht2tweak

Appreciate both your builds, but to @ CroqueMr's point, how best to guide new users on key differences? Less focusing on the very technical or how, but practically what they may see or experience.

Will be working on a new YT video shortly to draw awareness and socialize the great work here, but I'm unsure how best to position the two builds. That is, other than just saying try both and pick the one you like 😉. Maybe it's simple as that.

Tried Chat and Gemini to get key distinctions, a summary, and I could get was start with CroqueMr's for lower-end hardware and conversion flexibility, and use hadesdevls for Dolby Vision-to-SDR mapping and compatibility advantage for some older Radeon GPUs. Did AI correctly call out the key differences?

ht2tweak Thanks for doing a video on this. Both builds are good and worth trying, and since each runs from its own USB drive, people can boot one, then the other, and keep what suits their setup best.

I have a lot of respect for CroqueMr and the work behind that build: it has its own engine and its own HDR10 analysis for conversions to Dolby Vision, and CroqueMr can describe its strengths better than anyone.

On the Hades side, the AI got the SDR mapping and the older Radeons right, but it leaves most of it out. In practical terms:

• Picture: Dolby Vision goes out the way licensed players send it (IPT, profiles 5, 7 with FEL or MEL, and 8), composed as the published Dolby Vision specification defines it. On graphics that can't keep up, it steps down only as far as it needs to, and the log says so.
• Hardware: NVIDIA from the GTX 900 series on, AMD Radeon with DCN display hardware plus Polaris and Vega (those not tried on a TV yet), and Intel, down to modest machines: it has run on an Intel N100, a Core i3-1005G1 and Ryzen APUs, native Dolby Vision has started on a GeForce GT 1030 with driver 580 (4K FEL still needs work there), and FEL plays on the integrated graphics of a Ryzen 9 7950X3D, a Ryzen 7 5800H and a Core 5 255H.
• Displays without Dolby Vision: Dolby Vision as HDR10 or HDR10+, HDR10+ passed through, and on SDR screens a reference mapping (BT.2390) of HDR10 and Dolby Vision.
• Options: Dolby Vision Low-Latency (LLDV) for a TV input or a box that only takes that, adapted to the display by Hades and seen working on the integrated graphics of a Ryzen 9 7950X3D; HDR10 and HDR10+ as Dolby Vision; Dolby Vision for the menus; and Blu-ray 3D.
• Installing it on your own PC: a Windows installer for a USB drive or a partition next to Windows, internal disks hidden by default, Samba off, a locked-down kernel, every source verified, and a diagnostics switch for when something doesn't work.

In plain words, for your viewers: Hades aims to show Dolby Vision on a PC the way a licensed player would, on NVIDIA, AMD and Intel graphics, from big cards to small mini PCs, and to be safe to install on the computer you already use. And the best advice is the one you gave: try both. Every report, diagnostic and comparison that comes out of it helps both builds get better, and I hope we'll see more of the two working together soon.

Quote from CroqueMr

Thanks a lot, I know what I’m going to have fun with

Yes it's a good summary, on my engine we also have HDR to DV conversion with IA, Adaptative HDR mapping and DV to HDR10 with dolby vision processing including FEL rendering.

Of course, I respect your work. All effort even not perfectly coordinated is usefull, and I think everyone sees your contribution and your build philosophy and proposal. You have some really good ideas, like your Level 0/1/2 quality system. I don't really need it for my build since I don't compromise on quality in Master Reference mode.

I'm considering bringing DV to other devices once my x86 build is stable and complete. On lower end hardware, these kinds of quality compromise are necessary to make things run smoothly, and we can clearly see that even official Dolby devices make them.

I'll probably take inspiration from your approach and implement a similar adaptive system, but at the moment my priority is to finish the x86 build

And again, I'd be more than happy to see you contribute!

Display More

CroqueMr Thank you, that means a lot, and the same goes for your work. On quality, Hades doesn't compromise either: on graphics that keep up, every frame is the exact picture, bit for bit the reference. The levels only come in where a GPU can't draw a frame in time, where the alternative isn't the full picture but dropped frames, and even then, in test pictures, most of the pixels that change move by the smallest step of a 12-bit picture. Anyone who prefers the exact picture whatever happens can set the step-down to Never. I'm glad the idea may be useful to you, that's exactly how it should work, and the licence offer for what Hades wrote is now in its NOTICE.