Dolby Vision w/FEL + 3D for PC (AMD/Intel/nVidia)

    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!

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

    Hi @CroqueMr, Feedback on RC3 with Intel Arc B570: 1. **OSD Scaling:** Fully resolved. The player info overlay scales properly without flickering or shrinking into the corner. 2. **HDR-to-DV Conversion:** Working as intended. (Needed to ensure the default rendering preference was saved globally across all HDR10 media). 3. **Playback Stop Hang:** Still deadlocking. Stopping playback on native HDR10 or HDR-to-DV causes Kodi to freeze on the final video frame instead of returning to the SDR GUI. The OS remains alive in the background (SSH works, and `systemctl restart kodi` unfreezes the GUI). Captured logs during the freeze:https://paste.libreelec.tv/retardative-mervin.log - **kodi log:** <KODI_PASTE_URL>https://paste.libreelec.tv/unretaliating-fausto.log

    Hi CroqueMr,

    Following up on the initial log submission with detailed observations on the Intel Arc B570 (`xe` kernel driver) connected to a Sony OLED:

    ### 1. HDMI Modeset & Display Dropout Failures
    - **Refresh Rate Switching:**
    - With `Adjust display refresh rate` set to `On start / stop` or `Always`, starting 23.976p playback causes the HDMI carrier clock to fail handshake, resulting in a persistent blank/black screen.
    - **Teardown / Stop Hang (Even with Rate Switching OFF):**
    - Even when `Adjust display refresh rate` is locked to `Off` (desktop kept at 60Hz), pressing **Stop** on an HDR or DV stream causes the display to drop signal or freeze indefinitely on the last frame.
    - The atomic modeset deadlock appears triggered by the DRM pipeline transitioning color planes (10-bit HDR/DV colorspace back to 8-bit SDR GUI).
    - The OS and kernel remain fully responsive over SSH; running `systemctl restart kodi` immediately restores the SDR GUI without a system reboot.

    ### 2. HDR10-to-Dolby Vision Conversion Inconsistency
    - Only a small subset of HDR10 files trigger the CB1 HDR-to-DV conversion pipeline automatically; the majority fall back to standard native HDR10 passthrough.
    - It appears container flags or static metadata without dynamic metadata (unlike HDR10+) are being treated as pure passthrough rather than defaulting to the global Dolby Vision rendering target.
    - Setting "Dolby Vision" as default in the OSD video menu does not reliably persist across different source containers (mkv vs mp4 / different scrapers).

    ### 3. Motion Judder
    - Disabling refresh-rate switching avoids the startup blank-screen issue, but playing 23.976p content at 60Hz introduces noticeable 3:2 pulldown judder unless the entire desktop is permanently locked to 23.98Hz.

    Ready to test the custom support build and authentication key whenever your agent/pipeline is ready.

    Edited once, last by lvasan: Merged a post created by lvasan into this post. (November 5, 2026 at 4:35 AM).

    Yes, RC3 is still compiling, my bot will push it in gthub once everything is done, after that it will switch to the support build.
    I will send you a message in the issue thread once everything is finished.
    For the judder it's normal, do not force 3:2 pulldown or anything like that.

    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.

    I tried both builds on the same machine (Geekom A5 Pro Ryzen 5 7430U)

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

    CroqueMr: The overlay/info panel causes no stutter here. However, playing a video recorded on my Samsung Galaxy S24 (HDR10+) causes an immediate, complete crash of Kodi (need hard reset). The same file plays without any problem on Hades with DV.

    Another point that interests me and I’m unable to judge is whether CB1, with its "Dolby Vision Master Reference" option (offering state-of-the-art Dolby Vision output with uncompromised precision), is technically superior to the Hades `dvbridge` module (which uses FFmpeg and `libplacebo`).

    Thanks for your work on both projects!

    Quote from DolbyVisionFriend

    I tried both builds on the same machine (Geekom A5 Pro Ryzen 5 7430U)

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

    CroqueMr: The overlay/info panel causes no stutter here. However, playing a video recorded on my Samsung Galaxy S24 (HDR10+) causes an immediate, complete crash of Kodi (need hard reset). The same file plays without any problem on Hades with DV.

    Another point that interests me and I’m unable to judge is whether CB1, with its "Dolby Vision Master Reference" option (offering state-of-the-art Dolby Vision output with uncompromised precision), is technically superior to the Hades `dvbridge` module (which uses FFmpeg and `libplacebo`).

    Thanks for your work on both projects!

    DVbridge is my first implementation and my engine CB1 still use it and rely also a lot on FFmpeg and libplacebo. HDR10+ is known to not be perfect on my release I will work on it next week, I will be very interested in your feedbacks

    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:

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

    @hadesdevls  CroqueMr Hi everyone,

    I just finished testing LibreELEC Hades 1.0 RC7 using the exact same hardware and configuration as before, to compare it with the CroqueMr build.

    Environment:

    • CPU/GPU: Intel Core i7-12700 (Alder Lake, UHD Graphics 770)
    • System: LibreELEC x86_64 (Tested on both bare metal and PVE VM with iGPU passthrough)

    Test Results:

    1. FEL_test_for_AVS (m2ts, mkv, mp4, iso):
    Everything works perfectly! All four formats play normally, successfully trigger Dolby Vision, and seeking (fast-forward/rewind) works flawlessly.

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

    Important note: CroqueMr has already fixed this specific issue in their R1.0.0 RC2 build. The Transformers movie played perfectly and stayed in DV on RC2.

    Therefore, this means the fix is likely already in the CroqueMr codebase. Maybe hadesdevls could look into the changes made in CroqueMr's RC2 regarding BL/EL pairing or metadata handling for this specific movie, as it might save a lot of debugging time.

    Please let me know if either of you needs a full kodi.log or a specific sample clip from the Transformers playback. Thanks to both of you for the continuous hard work!

    CroqueMr, RC3 is a noticeable improvement in performance on my N150. My 5800H was great even w/previous builds, but N150 felt a bit lacking in performance, and felt a bit buggy. Much better now.

    But, did find HDR switching buggy w/60p. Tested w/this 'Sony Camp' clip. Bringing up the 'O' overlay a 2nd time for HDR switching, choosing DV will sometimes engage DV, other times stay in HDR. If I stop playback and go to say a different 24p HDR clip, it'll start playing in DV. Now, go back to that Sony Camp clip again, now it's DV. Debug log here.

    Also, a suggestion if possible: Disengage any processing when playback is stopped. Don't think we want that lingering when we go choose the next video to play, which should play in whatever native format it is. User can choose again if they want to have it processed as DV or HDR.

    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.

    hadesdevls 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? There are no such problems when playing in HDR.

    Another thing I noticed in terms of comparison: with CroqueMr, skipping between chapters doesn't really work, the image usually just stays frozen when using mkv DV FEL whereas with Hades, you can jump through the chapters without any issues.

    Quote from ht2tweak

    CroqueMr, RC3 is a noticeable improvement in performance on my N150. My 5800H was great even w/previous builds, but N150 felt a bit lacking in performance, and felt a bit buggy. Much better now.

    But, did find HDR switching buggy w/60p. Tested w/this 'Sony Camp' clip. Bringing up the 'O' overlay a 2nd time for HDR switching, choosing DV will sometimes engage DV, other times stay in HDR. If I stop playback and go to say a different 24p HDR clip, it'll start playing in DV. Now, go back to that Sony Camp clip again, now it's DV. Debug log here.

    Also, a suggestion if possible: Disengage any processing when playback is stopped. Don't think we want that lingering when we go choose the next video to play, which should play in whatever native format it is. User can choose again if they want to have it processed as DV or HDR.

    Yes it's a perfromance issue for HDR, If you stay in HDR it's a fallback mechanism. I prefer to have that than a crash, to fix it I need to optimize a lot all circuit at 60fps


    Normally, the circuit selected is the last one used that didn't involve a fallback, however, in my own usage, I decided to make the circuit selected in the settings menu the default on startup, as I find it more user-friendly.

    My BL/EL code is very sketchy, it has accumulated a lot of patches I really don't like this part of my code, I plan to redo it later