Posts by hadesdevls

Quote from SunnySnacksALot

hadesdevls Thank you for reading the CroqueMR log too, stumbled upon that while reading the logs myself - very curious what he thinks about the attached log, but i also want him to take breaks to not overwork himself - both you guys please take breaks if you feel like you need to (and even if you do not feel like you need to but your loved ones tell you to).
I did the tests you wanted me to (and some mistakes along the way) and sent you the logs on github.
For now i will keep the Denon AVC-x3800H out of the equation - as i feel it would overcomplicate things unneccessarily.
If you guys are able to make it work on a direct connection, then i will happily test it with my Denon in between.
Very excited about both your approaches, i like my homatics Box with coreELEC, but even just scrolling the menu you can tell its performance is not up to my (way too high) standard.

SunnySnacksALot Thank you for the extra tests and for sending the logs to the GitHub issue. I will go through them there. Thank you as well for the kind note about taking breaks.

Leaving the Denon out for now is the right call. Once native output works over the direct HDMI connection, your offer to test it with the receiver in between will be very useful.

Haha, I understand about the Homatics. I also have one with my own custom build based on the nightlies, which I have not uploaded, but I do appreciate the performance difference a PC can give.

Quote from DolbyVisionFriend

I’ve noticed one little bug: when I play a video from my S24 (HDR10+)—processed as Dolby Vision—and then stop the clip, the screen remains black. The PC hasn’t crashed, though; I can tell because I can hear the audio feedback as I navigate through the menu.
Is this a known issue, or should I provide a log?

DolbyVisionFriend Yes, please capture this with diagnostics on. The menu sounds show that Kodi is still responding, but I need the state after stopping to see whether the Dolby Vision signal was removed and the normal output restored.

Rename DIAG-OFF.TXT to DIAG-ON.TXT on the boot partition, play the S24 clip as Dolby Vision, then stop it and leave the black screen for at least 30 seconds before restarting. Attach the hades-diag folder from that run. It records the output state 5 and 30 seconds after Dolby Vision ends, which is the part I need here.

If possible, please include a short original S24 clip that reproduces it, without re-encoding. Please also say whether the TV still reports Dolby Vision while the menu is black. I cannot yet say whether this shares anything with the overlay stutter. Good to hear chapter skips work on FEL MKV here.

Quote from ApexAftermath

Diagnostics attached.

ApexAftermath One remaining test for the HDR depth option: the attached RC8 run is native Dolby Vision on the GT 1030, so it does not establish the HDR10 rendering depth on either card.

When you next test HDR10, enable System > Display > "HDR at more than 8 bits where the card sends RGB at 8 (NVIDIA)" at Expert level and capture a diagnostic for each card separately. Please identify which is the GTX 1060 and which is the GT 1030.

I need both the rendering-buffer depth and the HDMI output depth. RC8 can report a 10-bit link while still drawing at 8 bits if the display plane rejects the vertical reflection required by its own HDR buffers, as the GTX 1060 report in issue #17 showed.

Quote from SunnySnacksALot

Hi, many thanks for the good read and your efforts the last few weeks, really awesome what you have built in such a short time frame.
Both your builds do not seem to work with my newly aquired AMD RX550 LP. Dolby Vision does fallback to HDR on CroqueMRs Build, and on HADES build the tv shows the Dolby Vision logo and i can hear Audio,
Attached is a log from CroqueMR build, i tested two scenarios: plugged directly into the TVs HDMI4 Port and also with my Denon AVC-x3800H in between. Hope i can contribute to this project by testing and shareing my logs.
Please let me know if i did something wrong or if you want me to test anything.

SunnySnacksALot Thank you for testing both builds on the RX550. I already reviewed the Hades diagnostic you opened as https://github.com/hadesdevls/LibreELEC-Hades/issues/20, and I left the next comparison there.

The attachment here is from CroqueMr RC3, not from Hades. I read it as a comparison. On this card his kernel reports the AMD family as unsupported for native Dolby Vision (family_supported=0), so native output is not started (native_dv=false, native_eligible=false). Playback then sets HDR at 3840x2160. That matches the fallback you described. Both sessions in the file see the G3 (LG TV SSCR2) on HDMI; I do not see a Denon EDID in this log.

Hades takes the other path on the same card: it does start native Dolby Vision, which is why the TV shows the Dolby Vision logo and why you still hear audio. The picture staying black is the fault I am investigating. The Godzilla capture in that diagnostic is MEL, so the black screen is not limited to FEL reconstruction.

The comparison I still need is the same Godzilla file, over the same direct HDMI connection, with "Dolby Vision as HDR10" selected, plus whether opening the playback controls during native Dolby Vision leaves those black as well. Please keep diagnostics on and attach the folder on the GitHub issue.

Quote from lfemperor

Transformers 2 Revenge of the Fallen 2009 (UHD BDMV/ISO): Unfortunately, this movie has the same issue: when playback starts, the TV initially triggers the Dolby Vision logo, but shortly after, it drops back to HDR10 playback.

lfemperor Thanks for testing RC7 so thoroughly, and good to hear the FEL test plays in all four formats, seeking included. Transformers 2 dropping to HDR10 is a fault in Hades. ht2tweak saw the same with the Transformers and Tron samples on an N150, so both reports are on Intel graphics. I'll reproduce it with those samples and fix it for the next version.

Yes please, the kodi.log of a playback that drops would help, ideally with the diagnostic on (rename DIAG-OFF.TXT to DIAG-ON.TXT on the boot partition, play the film until it drops, then zip the hades-diag folder from that partition). When Hades leaves native Dolby Vision, it writes the reason in kodi.log and on the Dolby Vision page of the player information. I'll start with the samples from ht2tweak and ask for a clip only if they don't show it. Thanks also for pointing to RC2 of CroqueMr.

Quote from DolbyVisionFriend

Hades: playback stutters while the media info overlay (O key) is open. Without the overlay, playback is smooth.

DolbyVisionFriend Thanks for testing it on the Geekom. That stutter is a fault in Hades, and I am working on it for the next version. While anything of the interface is on screen, each Dolby Vision frame is composed with it before it goes out, because the TV gets the interface inside the Dolby Vision signal. The info overlay redraws itself all the time, so every frame takes that longer way, and on integrated graphics it costs about twice the GPU time of the picture alone (on Intel graphics at 60 Hz: 35 to 40 ms per frame with the interface, 16.5 ms without). The next version makes the frames with the interface cheaper, so that an overlay no longer makes the video stutter. If you have a minute, a diagnostic with the overlay open would let me measure it on your Radeon as well, but the work does not wait for it.

Quote from DolbyVisionFriend

whether CB1, with its "Dolby Vision Master Reference" option, is technically superior to the Hades dvbridge module

CB1 is the work of CroqueMr, and he is the right person to explain it. Here is what Hades does, in short. Each picture is rebuilt the way ETSI GS CCM 001 describes the composer: the base layer, the reshaping of its RPU and, in profile 7 FEL, the residual of the enhancement layer, at 12 bits. It goes to the TV in the IPT-PQ-c2 transport used for TV-led displays. FFmpeg decodes the video and reads the RPU, and libplacebo runs the reshaping on the GPU. The ways of drawing (direct, composed with the interface, a frame ahead) are checked against each other with a software renderer, and at full fidelity they give the same bytes. A step-down happens only where the GPU cannot keep up, and the log says so.

ApexAftermath Thanks, the diagnostic has what I needed (start-2 is your RC8 run; start-1 is an older one from RC5). Your GT 1030 played the profile 7 FEL film at about 12 frames per second instead of 24, and two things in the log explain it. Both are faults in Hades.

Frames. The GT 1030 takes about 31 ms of GPU time per frame, and a refresh at 23.976 Hz lasts 41.7 ms, so the frames fit. But each one went out the way that waits for its flip, which on your card took about two refreshes per frame. Presenting frames a frame ahead removes that wait (it is what made integrated AMD graphics play at full speed). On NVIDIA, Hades turns it on only after it has measured missed refreshes in two runs of 240 frames, which at half speed takes about 40 seconds, and your test stopped at 47. The next version turns it on within a few seconds when most frames miss their refresh like this. You can try it now: add this inside <advancedsettings> in /storage/.kodi/userdata/advancedsettings.xml and restart Kodi:

<video>
 <dvaheadalways>true</dvaheadalways>
</video>

It has not run on a GeForce 10 card yet. If the driver refuses it, Hades goes back to the usual way and kodi.log says so.

Enhancement layer. 133 times in those 47 seconds, the VAAPI driver could not hand Kodi a picture of the enhancement layer ("resource allocation failed"), so about a third of the frames went out without their FEL residual. With 2 GB on the card, video memory is the likely reason. The next version records the memory of the card in the diagnostic, and I am going through what Hades keeps in video memory during Dolby Vision, to bring it down on 2 GB cards.

The run has no HDR10 video, so nothing yet on the 10-bit option. As sat4all found (issue #17), on GeForce 10 cards RC8 sends 10 bits but still draws the picture at 8; the next version fixes that.

sat4all Thanks for confirming. One correction from your photos on GitHub: on the GTX 1060 the link is 10 bits, but the picture is still drawn at 8 bits, because the plane of that card cannot flip the 10-bit buffers Hades draws into. Details and the fix for the next version are in issue #17.

Quote from hadesdevls

LibreELEC Hades 1.0 RC7 is out

Download and release notes: v1.0-rc7 on GitHub

An update that fixes faults found since 1.0 RC6, which came out earlier the same day, and adds a few smaller things.

Fixes

• A film no longer ends when its drive stops answering for a while: the picture waits while the drive is reset and goes on when it answers, also with Blu-ray and DVD images and folders.
• Limited colour range on NVIDIA is right from the start of Kodi and when the setting changes: no more crushed blacks.
• The output that carries the sound stays on, found by itself, so a receiver or sound bar on another output keeps its sound. A file can name more outputs to keep on, from the patch of harment.
• Each UEFI boot entry starts the kernel of its own drive, so a second drive with another build no longer gets in the way. An update in place fixes the menu too.
• A Blu-ray played with its menus no longer pauses at the seamless joins of a film with several cuts.
• Dolby Vision whose level 5 metadata do not fit the picture keeps native Dolby Vision, and an open-matte film with the metadata of its letterboxed master shows whole.

Smaller things

• "Dolby Vision as HDR10+" for one video in the player, next to "Dolby Vision as HDR10", to compare the two. On Intel, HDR10+ chosen while a video plays now goes out.
• During native Dolby Vision, the output depth says "8 bits: Dolby Vision carries its 12 bits in them".
• HDR10 at 10 bits with NVIDIA driver 580 (GTX 900, GTX 10, TITAN V), through buffers that Kodi allocates itself, where the driver takes them.
• Dolby Vision decoded by the processor (single layer, AV1 included) goes out natively, with the same bytes as from a hardware decoder.
• An empty /opt for Entware, and diagnostics that record the USB controllers and every disk.
• Up to date: the Piers branch of Kodi (HEIF and AVIF photos made of tiles, as most iPhone photos are, shown whole) and LibreELEC.

Every change was tested on the host with the code that the image runs, and the changelog says how for each item. Reports with the diagnostic switch on confirm them on more hardware.

What is new in this version is written for Hades, apart from the updates of LibreELEC and Kodi and the code of others that it takes, which keeps its author. Two features follow ideas seen in the build of CroqueMr, written anew here: Dolby Vision decoded by the processor, and level 5 metadata that do not fit the picture. Thanks to everyone who reported and tested 1.0 RC6.

Thanks for trying it. A clean install should not be needed: an update keeps your settings, and the diagnostic shows them. With RC7, turn the diagnostic on (rename DIAG-OFF.TXT to DIAG-ON.TXT on the boot partition of the drive, or tick the diagnostic box in the installer), play a file that struggles for about a minute, then zip the hades-diag folder from that partition and attach it here or in an issue, with what the file is (Dolby Vision profile or HDR type, and resolution). The log says whether the decoder or the GPU of the card falls behind, and what Hades did about it.

Thanks, glad you like the installer, and thanks for making a video: RC7 is the one to use for it. When a Dolby Vision video does not go out as native Dolby Vision, the Dolby Vision page of the player information says why. Could you play one of those samples on RC7 and post a photo of that page? With that I can tell whether it is something about how those files are made or about the N150, and fix it.

Display More

LibreELEC Hades 1.0 RC8 is out

Download and release notes: v1.0-rc8 on GitHub

An update that fixes faults found in 1.0 RC7, which came out earlier the same day, and adds a few smaller things.

Fixes

• HDR10 is upright again with NVIDIA driver 580 (GeForce GTX 900 and GTX 10, TITAN V): in 1.0 RC7 it went out upside down, menus and subtitles too.
• No GRUB error after an update with the .tar: the update now replaces GRUB on the boot partition too, so a drive installed before 1.0 RC6 no longer stops at "can't find command `['".
• Seeking, the arrows and the player information work again during a Blu-ray played with its Java menus. The menus still get the keys while they are on screen.
• The thin text of Blu-ray menus is no longer faint at 3840x2160.

Smaller things

• HDR at 10 bits over HDMI on GeForce GTX 10 cards and the TITAN V, as an option. Over HDMI, driver 580 sends RGB at 8 bits at most on these cards (the 1.0 RC7 post said 10 bits there: over HDMI that was not right), but they do drive YCbCr 4:2:2 at 10 bits. Turn on System > Display > "HDR at more than 8 bits where the card sends RGB at 8 (NVIDIA)" (settings level Expert). The same setting turns on the 12 bits of GeForce GTX 16 and RTX 20 graphics, which needed a kernel parameter until now. It stays off by default until someone confirms it on one of those cards.
• How long the boot menu waits: 10 seconds as before, 3 or 1, in LibreELEC Settings > System > Boot menu.
• Up to date: LibreELEC (NSS 3.133, LLVM 23.1.5, HarfBuzz 15.1.0, lz4 1.11.0, hwdata 0.413) and the Piers branch of Kodi, whose new commit keeps the display clock running through a change of mode.

Every change was tested on the host with the code that the image runs. None of them has been seen yet on the hardware it is for, so reports with the diagnostic switch on are very welcome.

sat4all  ApexAftermath your GTX 1060 and GT 1030 are among these cards: HDR10 is upright again, and the new option is the way past 8 bits on them over HDMI. A diagnostic with it on would be very welcome.

Thanks to sat4all1-dev and roronoazoro-blip for their reports and photos. If you missed 1.0 RC7 or 1.0 RC6, the release notes sum them up at the end.

Quote from mauro145

Hi hadesdevls for those of us using a projector with LLDV edid spoof, the best option would it be to disable "native DV output" (LLDV goes gray) and enable "DV as hdr10" or viceversa? Or both? (Dont remember if it's possible)

Thank you!

For one video it is one or the other, not both. "Dolby Vision as HDR10 when needed" only acts where Dolby Vision is not sent natively, so leaving it on does no harm. Both ways below are meant for projectors (Settings > System > Display, with the settings level at Expert):

1. Low-Latency, with native Dolby Vision on
Turn on "Dolby Vision Low-Latency (player-led)", then "Low-Latency: peak and colours set here", and set the peak, colours and black of your projector as measured. Hades maps each scene to those values with the BT.2390 curve, guided by the Dolby Vision metadata of the scene, in place of the values that the spoofed EDID claims.

2. HDR10, with native Dolby Vision off
Set "Dolby Vision as HDR10: map to the display" to "To this display", with the peak and colour gamut of your projector under it. Every Dolby Vision video, profile 7 with its enhancement layer included, is then rebuilt from its Dolby Vision data and mapped shot by shot with the tone and gamut mapping of libplacebo. The projector is told that the picture already fits it, so turn its own dynamic tone mapping off. Hades does not need the spoof for this one. For plain HDR10 films, "HDR10: limit the luminance told to the display" tells the projector at most the peak you set.

I can't tell you which one looks better on your projector: they have not been compared on one. To compare them without going back to the settings, play a Dolby Vision film and switch "Dolby Vision output (this video)" in the video settings of the player between native and "Dolby Vision as HDR10".

LibreELEC Hades 1.0 RC7 is out

Download and release notes: v1.0-rc7 on GitHub

An update that fixes faults found since 1.0 RC6, which came out earlier the same day, and adds a few smaller things.

Fixes

• A film no longer ends when its drive stops answering for a while: the picture waits while the drive is reset and goes on when it answers, also with Blu-ray and DVD images and folders.
• Limited colour range on NVIDIA is right from the start of Kodi and when the setting changes: no more crushed blacks.
• The output that carries the sound stays on, found by itself, so a receiver or sound bar on another output keeps its sound. A file can name more outputs to keep on, from the patch of harment.
• Each UEFI boot entry starts the kernel of its own drive, so a second drive with another build no longer gets in the way. An update in place fixes the menu too.
• A Blu-ray played with its menus no longer pauses at the seamless joins of a film with several cuts.
• Dolby Vision whose level 5 metadata do not fit the picture keeps native Dolby Vision, and an open-matte film with the metadata of its letterboxed master shows whole.

Smaller things

• "Dolby Vision as HDR10+" for one video in the player, next to "Dolby Vision as HDR10", to compare the two. On Intel, HDR10+ chosen while a video plays now goes out.
• During native Dolby Vision, the output depth says "8 bits: Dolby Vision carries its 12 bits in them".
• HDR10 at 10 bits with NVIDIA driver 580 (GTX 900, GTX 10, TITAN V), through buffers that Kodi allocates itself, where the driver takes them.
• Dolby Vision decoded by the processor (single layer, AV1 included) goes out natively, with the same bytes as from a hardware decoder.
• An empty /opt for Entware, and diagnostics that record the USB controllers and every disk.
• Up to date: the Piers branch of Kodi (HEIF and AVIF photos made of tiles, as most iPhone photos are, shown whole) and LibreELEC.

Every change was tested on the host with the code that the image runs, and the changelog says how for each item. Reports with the diagnostic switch on confirm them on more hardware.

What is new in this version is written for Hades, apart from the updates of LibreELEC and Kodi and the code of others that it takes, which keeps its author. Two features follow ideas seen in the build of CroqueMr, written anew here: Dolby Vision decoded by the processor, and level 5 metadata that do not fit the picture. Thanks to everyone who reported and tested 1.0 RC6.

Quote from ApexAftermath

I just tried this out on my GTX1030 and performance was sadly the same with the struggling playback. I did an upgrade install of the image. Do you want me to try a clean fresh image and test again with diagnostics?

Thanks for trying it. A clean install should not be needed: an update keeps your settings, and the diagnostic shows them. With RC7, turn the diagnostic on (rename DIAG-OFF.TXT to DIAG-ON.TXT on the boot partition of the drive, or tick the diagnostic box in the installer), play a file that struggles for about a minute, then zip the hades-diag folder from that partition and attach it here or in an issue, with what the file is (Dolby Vision profile or HDR type, and resolution). The log says whether the decoder or the GPU of the card falls behind, and what Hades did about it.

Quote from ht2tweak

So, RC6 has played everything I've thrown at it, except the 'Transformers' and 'Tron' DV FEL samples. No matter which options I select for DV in settings, they only play in HDR.

Thanks, glad you like the installer, and thanks for making a video: RC7 is the one to use for it. When a Dolby Vision video does not go out as native Dolby Vision, the Dolby Vision page of the player information says why. Could you play one of those samples on RC7 and post a photo of that page? With that I can tell whether it is something about how those files are made or about the N150, and fix it.

Quote from testmest

hadesdevls can you explain what each option in CMv4 means?

english is not my native language, so my reading speed is not that fast so i keep up reading of explanations in LE on tv.

maybe an idea to put CMv4 explanation for each option on the release page on Github?

and....thanks for everyone for hard work getting rhis done 👍👍

Display More

testmest Sure. The Dolby Vision metadata of a film come with a "content mapping" in one of two versions: 2.9, the older one, and 4.0, the newer one, which many recent TVs can use to fit the picture to their own brightness in a more refined way. Many films carry only 2.9. The setting Dolby Vision content mapping v4.0 (shown at the Expert settings level) decides what Hades sends to the TV:

As in the video (the default): exactly what the file carries, nothing added or removed.

Add v4.0 where the video has none: a film with only 2.9 gets a neutral 4.0 part added, the same one that dovi_tool adds by default, so the TV can use its 4.0 mapping. The picture itself is not changed, only the metadata.

Automatic: adds that part only where the film was mastered brighter than the peak your TV declares, which is where the mapping matters most.

Automatic 2: no trims in the video: adds it only where the film carries no trims from the colourist, so nothing the colourist set is put aside.

Version 2.9 only: sends only the 2.9 part, also for films that carry 4.0. It is for a TV that shows a black or wrong picture with 4.0.

The choice is made once per video, from its first metadata, and the player information shows what is being sent. If the picture looks right with the default, there is no need to change it.

Every setting is explained in the documentation too: https://github.com/hadesdevls/Lib…ocs/settings.md

Quote from sat4all

hadesdevls

Thanks to 1.0 RC6, the GTX 1060 issue is resolved, and DV works as expected at all refresh rates. The only issue remaining is that the HDR output signal is 8-bit rather than 10-bit.

Really appreciate your fantastic work!

sat4all Thanks for testing and for the photo, good to hear that Dolby Vision works at every refresh rate on the GTX 1060 now.

About HDR at 8 bits: your card and its driver can show a 10-bit picture (your RC5 log lists 10-bit and floating point formats for the display plane), but the 580 driver gives Kodi only 8-bit windows to draw in, and the driver sends HDR10 at the depth of that window. On the GTX 16 and later, with the 615 driver, Kodi draws in a floating point window and HDR10 goes out at 10 bits. So it is a limit of the way Kodi draws with the 580 driver, not of the card, and I'm looking at a way around it: drawing into a 10-bit buffer directly instead of a window. I can't promise it yet. What you see now is still HDR10 (PQ, BT.2020), with 8 bits per colour on the cable.

LibreELEC Hades 1.0 RC6 is out

Download and release notes: v1.0-rc6 on GitHub

Dolby Vision and HDR

• "Dolby Vision output (this video)" applies while the video plays, for HDR10 and HDR10+ videos too, and is kept for each file.
• For a video that has both Dolby Vision and HDR10+, a setting chooses which one is sent.
• The content mapping v4.0 as a setting, with "Version 2.9 only" for a TV that shows a wrong picture with v4.0.
• For projectors: Low-Latency mapped to a peak, colours and black set by hand, a limit on the luminance that HDR10 tells the display, and HDR10 and HDR10+ mapped to the display in the player.
• Dolby Vision sent as HDR10+ version 1 carries DistributionY99 and DistributionY100nit as they are defined, and HDR10+ sent as Dolby Vision measures the scenes that come without statistics.
• HDR10 through the HDMI port of Intel HD and UHD 6xx graphics goes out as Dolby Vision where the TV takes it.
• Menus over Dolby Vision cost less GPU time on light graphics, with the same bytes sent.
• Dolby Vision also with a long "Delay after change of refresh rate", Dolby Vision in two tracks a constant apart, and a more exact IPT tunnel.

Display and HDMI

• A TV switched off and on in a 4K mode at 50 or 60 Hz, or one that goes by FRL, gets its picture back on NVIDIA and AMD.
• Limited colour range is compressed once, by the driver, on Intel, AMD and NVIDIA.
• The HDMI patches of big-fella from YBLOD for Intel and AMD: short drops of the hot-plug signal held, the TV told that the source is a player, and a black background on Ryzen with Vega graphics.
• On NVIDIA: Dolby Vision in the 4K modes that the driver names by their HDMI VIC (also with driver 580), three buffers for the window, and a change of resolution on an HDMI port driven through DisplayPort.
• A change of mode that the driver refused is asked for again, and whole-number multiples of the frame rate can be kept under the whitelist.
• An EDID extension block that is not valid is skipped, the same in Kodi and in the kernel.

Subtitles, files and sound

• Picture subtitles (PGS and VobSub) can be resized, moved and dimmed, from the pull request of cinemaONE to Kodi.
• Text subtitles come back after a seek, also when the line started before the place the player reads from.
• Editions of Matroska files, as an option.
• Dialogue normalisation at 0 dB in passthrough, the compression of Dolby Digital in the audio settings, the centre level and the LFE up to 300 % for a downmix, and audio settings that apply during playback.
• The player information says more of the sound (the bed and objects of Atmos, the dialogue level), and kodi.log says why a stream is not passed through.
• CEC fixes for Pulse-Eight adapters.

Interface
A dialog that does not finish closing no longer leaves Kodi ignoring the remote and the keyboard, the settings window no longer saves the mode of a video as the resolution of the interface, and only what changes is drawn again when the focus moves in a list.

A new boot menu
Drawn for LibreELEC Hades: the eclipse of its mark on black, and the four entries, each with a line that says what it does: Run (recommended, first, starts by itself after 10 s), Run (internal disks read-only), Live and Installer. With several displays connected, the notice that Kodi uses one of them is now a picture on the start screen.

Blu-ray
Blu-ray playlists played directly keep one timeline across their seamless joins, so a film with several cuts no longer freezes or skips at each join. Menus are kept apart from subtitles, a 3D display can be simulated for discs that need one, 3D subtitles keep their depth, and movies on discs are kept right in the library.
Blu-ray Java menus now play with nothing to install, in a service of the system, never inside Kodi: one process for each disc, with the Java runtime that comes with the image, a user of its own without privileges, a filter of system calls and no network, reading the disc only through Kodi. The idea of Java menus with nothing to install comes from the build of CroqueMr; the service that isolates them is written for Hades. BD-Live is there as an option, off by default, and with it the menus reach the Internet and nothing else: never this machine or your home network.

Also: a diagnostic that keeps the log of a start that hung and filters the names of your drives and folders, a firewall that no longer stays open on a damaged setting, the Dolby Vision module of Kodi now under GPL-2.0-or-later, Linux 7.3.1, the latest of the Piers branch of Kodi, and many fixes from upstream.

What is new in RC6 has not been tried on hardware yet, so reports in the issues are very welcome.

What is new in this version is written for Hades, apart from the code of others that it takes, which keeps its author. Several features follow ideas seen in other builds, written anew here: from the build of CroqueMr, the CoreELEC builds of pannal (p3i), avdvplus and SamuriHL, matthane, YBLOD and Sebastiii. Thanks to them, to quietvoid and cinemaONE for definitions and measurements, to everyone who reported in the issues and here, and to the LibreELEC and Kodi teams.

Quote from sat4all

Indeed, disabling "Adjust display refresh rate" allows DV output to work. However, connecting the PC directly to the display doesn't change anything—DV output still fails when "Adjust display refresh rate" is ON.

Thank You!

sat4all Thanks for the logs with the PC straight to the TV. They show the same thing as through the Denon: at 3840x2160 23.976 Hz the driver wants its own HDMI vendor InfoFrame for the mode and turns down the Dolby Vision frames (275 times there), so the receiver is not the cause. I said before that the EDID of the Denon was why the driver picked the HDMI VIC; with the TV directly it picks it too, so that part was wrong. The fix stays the same: the mode goes in the AVI InfoFrame instead, which leaves the vendor InfoFrame free for Dolby Vision. It is in the next version.

Quote from Khazar

hadesdevls  CroqueMr

Tried one last time before going to sleep, finally got Hades to start and this time I got a message in the black void window:

systemd[1]: iptables.service: Failed with result 'exit-code'

after that I got the message that my main monitor will be disabled and it will switch to the HDMI output, which is the correct thing to happen and I was able to use Hades normally as before.

I have no idea if that message is in any way related to why all my other starts with Croques RC2 or Hades RC5 failed, but for some reason it worked this time.

Sadly I didn't get a debug output for the failed startup, but now with a succesful startup it finally wrote log files.

Hades has got my debug zip in another issue for my USB dongles for my mouse & keyboard, so maybe there could be a hint on that startup problem. https://github.com/hadesdevls/LibreELEC-Hades/issues/13

Display More

Khazar Thanks for the diagnostic and for finding the sound card. I answered on GitHub, in #13 and #14: a quick test for the receivers, a firewall problem the log showed, and a question about the card.

I'm tied up at the moment, but I'm keeping track of the reports and suggestions here. I expect to release the next version before Wednesday, and I'll review these for it.

sat4all Thanks for trying both the direct connection and the refresh-rate setting, and for attaching the logs. The direct connection is useful to know: the Denon is not necessary to reproduce the problem.

I'll compare the direct-to-TV logs with the earlier ones and check whether the same InfoFrame conflict occurs there. For now, leaving refresh-rate switching off lets Dolby Vision play at 4K60, as you confirmed.

Khazar Thanks for trying Hades, and I'm glad the installation went smoothly. I've noted both input problems and will look into them.

The diagnostics need to be enabled first. In Windows, open the LIBREELEC partition on the Hades drive and rename DIAG-OFF.TXT to DIAG-ON.TXT. If Windows hides file extensions, you'll see DIAG-OFF and can rename it to DIAG-ON.

Then start Hades, reproduce the mouse problem and try the keyboard, and shut down from Kodi. A hades-diag folder should appear on the LIBREELEC partition. Please review its contents, zip it and attach it to an issue here:

Issues · hadesdevls/LibreELEC-Hades

Unofficial LibreELEC build for x86_64 PCs with native Dolby Vision over HDMI, profile 7 FEL included, from NVIDIA, AMD and Intel graphics, dedicated or…

github.com

If you can, also try the receivers closer to the PC and let me know whether the keyboard and mouse use the same receiver. That will help narrow down what is happening.

siriusbox Thanks for explaining the tests you did on the PX1 Pro. Comparing the individual L2 target blocks is useful, especially since you found a difference with the 100-nit block on some films.

The Hades setting was added after a report on the Kodi forum about a projector whose picture improved when the L2 trims were removed with dovi_tool. It is broader than removing one L2 target: it leaves out L2 and L8 trims, as well as L10, which contains the targets for L8.

I can't yet say why that particular block changes the result on some films and not others on your projector. I've noted your findings and will review them.

ht2tweak Thanks for taking the time to run the full set of tests and write up the results. It's great to hear that HDR10+, the Transformers sample, the FEL films and the 3D formats played well on RC5.

About switching formats during playback: Hades has a "Dolby Vision output (this video)" option in the video settings and on the player information page. It is intended for changing the output of a Dolby Vision video, but there is a bug in RC5 that prevents the change from taking effect. I plan to fix that, and I've noted your request for a quicker way to switch formats.

I've also noted the pauses at the start of the anime clips and the sample you linked. If you get a chance to reproduce the pause with diagnostics enabled, the log would help too.

Khazar Thanks for pointing out the video settings menu as well. That is where the per-video Dolby Vision output option is; the bug above is why changing it currently has no effect.

Creator44 Thanks! I'd be interested to hear how the Transformers clip and the other files work on your setup when you get a chance.

DMDreview Thanks for explaining the capture and analysis, and for sharing djnice77's test files. I understand you already have plenty of testing planned, so no pressure about comparing builds. The details you've shared are useful.

Quote from ashlar

hadesdevls I tested through USB key. One thing I could suggest: make the options clearer when one boots from it.
I have a dedicated NUC (NUC11TNKI3) for this, so I prepared the key on a different, Windows 10, machine. Once I booted the NUC with usb key inserted, I was trying to understand what the different "Run/Run*/Installer/Live" options meant and it autostarted as Run almost immediately (a few seconds, really). Maybe it was on your github page, I don't know, but I found it alarming.

The HDR10+ movie that was giving me trouble on CroqueMr build played fine, converted to Dolby Vision. And, generally speaking, everything seemed to work ok. I connect the NUC to a Denon X3800H AVR and that to an LG C1 (I mention this as I saw on your github that you keep track of hardware tested and you mentioned no AVR tested yet). Both Atmos and DTS-X played ok.

I noticed the GPU was always or almost always sitting at 100% and headroom was most definitely not ample (and this on 24fps movies). Not something I'd be comfortable with if we were talking madVR profiles optimization. It looked like it could easily drop frames on "complicated" scenes.

Considering my hardware should be a fair bit more powerful than the N100 which works fine for 24p content on CroqueMr, I wonder if I am missing something or if, simply, your builds are more targeted toward more powerful hardware (I come from a past where the last HTPC I used for media purposes had a RTX 4070, but I'd very much like to remain fanless).

ashlar Thanks for testing it, and for the AVR detail: a Denon X3800H with an LG C1, Atmos and DTS:X working, goes on the tested list, and so does HDR10+ as Dolby Vision on your NUC.

You're right about the boot menu, it should say more. What each entry does: Run, the default, starts Hades from the key with the internal disks hidden; "Run (internal disks read-only)" shows them, read-only; Live starts without keeping anything; and Installer only installs if you pick it, and asks which disk and for confirmation before it writes. Five seconds is short for a first look, so I'll give the menu a longer wait and plainer names.

On the GPU: Hades draws every frame at full fidelity for as long as the graphics keep up, so the meter sits high, and what matters is whether frames arrive in time, not the percentage. In madVR terms, the number to watch is the render time against the 41.7 ms of a 24p frame: kodi.log gives the average GPU time per frame every 10 s, much like the render times in madVR, along with how many frames came late, and the automatic step-down works like a profile that switches itself to a lighter one only when frames stop fitting. All of that GPU time goes into the picture and the menus, and the log accounts for it frame by frame. HDR10+ converted to Dolby Vision is a 4K picture rebuilt and sent as Dolby Vision on every frame, which is heavy work for UHD Graphics with 48 units, and bringing that load down on graphics like yours is on my list. If you'd like a firm answer for your NUC, a diagnostic of that film would show the GPU time per frame and every frame that came late.

Quote from Creator44

CroqueMr , I tested RC1.1 and I am happy to report the freeze when PGS subtitles are on the screen at the same time as any GUI in DV movies is gone! All seems fine now!

My guess is that fixed it?:

Fixed mixed PGS subtitles and SDR GUI composition in Master Reference.

In any case, I want to thank CroqueMr and hadesdevls for their work on this it's really exciting! I didn't test HADES yet because no time but I will check it out too!

Congrats to CroqueMr to making the most accurate DV of any player according to DMDreview ! This is great to see and makes it so my am6b+ will not be used anymore probably but I'll keep it as an option!

Open source is so great, especially lately with AI's help it's so refreshing compared to big corpos who makes half-assed products just to make money. The passion in open source projects will always make more refine products in the end because the makers actually care about the end result product.

Display More

Creator44 Thank you, that's kind, and you're right about open source: a lot of people here clearly care about the result. When you find the time, Hades runs from a USB drive, so it's easy to try next to what you already have, and I'd love to hear how it does on your setup. And if DMDreview runs another round, Hades would be glad to be part of it.

Quote from sat4all

Hi,

CroqueMr Unfortunately, your build isn't working on my Zotac ZBOX EN1060K. it gets stuck on the boot splash screen same as official LE image.

hadesdevls Dolby Vision is falling back to HDR on my setup. Could you please check the attached logs?

Thanks in advance!

sat4all Thanks, the logs show exactly what happens. Dolby Vision does start, but at 3840x2160 23.976 Hz the driver of your GTX 1060 wants to send its own HDMI vendor InfoFrame for that mode (the HDMI VIC of a 4K 24 Hz mode), and that is the same InfoFrame the Dolby Vision signal travels in. So the driver turns down every Dolby Vision frame, 268 times in two seconds, and then Hades goes back to HDR10, as it's meant to. That one is on Hades to handle: the way is to give the mode in the AVI InfoFrame instead, as Hades already does for HDR10+ on those modes, so the vendor InfoFrame stays free for Dolby Vision. Your Denon shows the PC its own EDID, which is why the driver picks the HDMI VIC there.

Two things you can try meanwhile, and both tell me more: turn "Adjust display refresh rate" off so the video plays at 4K60, which has no HDMI VIC, and Dolby Vision should go out; and, if you can, connect the PC straight to the TV once.

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.

Quote from dangerouslaser

https://github.com/dangerouslaser….0-RC1.1-YBLOD1

Build with Vulkan and OpenCL rendering engines - TV-Led / master reference mode only.

AMD users should see performance improvements with this build using vulkan.

The first time you play a video with vulkan the shaders need to compile.

This is for testing only.

Display More

dangerouslaser YBLOD1 looks really interesting. Moving the engines to Vulkan and OpenCL is a big change, and if it gives AMD the headroom you expect, people on integrated graphics will feel it straight away. YBLOD has already given Hades some good ideas (Dolby Vision for the menus, and Dolby Vision starting sooner without losing its first pictures, both began there), so I'll be following this one closely, and I'd love to see the GPU times once people start testing it.

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 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 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.