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

    Last updated November 13, 2026

    Download hadesdevls LE builds here.

    Video using hadesdevls RC8 build:

    External Content youtu.be
    Content embedded from external sources will not be displayed without your consent.
    Through the activation of external content, you agree that personal data may be transferred to third party platforms. We have provided more information on this in our privacy policy.

    All the issues shown in it have been resolved, with significant new features and enhancements, as of post-RC v1.0. See examples later in this thread.

    Recommended general settings:

    SettingRecommended
    Hardware acceleration — VAAPION
    DRM PRIME decoderOFF
    DRM PRIME hardware accelerationOFF
    PRIME Render MethodEGL
    Render pathEGL / VAAPI
    Kodi support for DRMPRIME was designed for ARM SoC hardware using direct-2-plane rendering. With Intel/AMD, only use EGL/VAAPI
    Direct-to-Plane / D2POFF

    📖 Read here for all Hades' specific settings and what they mean ⚙️

    Guidance from hadesdevls:

    Installing
    For an easy install from Windows, you can use the installer made for Hades (LibreELEC-Hades-Installer.exe, from the release page, with the .img.gz and .sha256 next to it). Any other image writer like Rufus or balenaEtcher works too with the .img.gz.

    Reporting problems
    Please report problems in the GitHub issues, not to LibreELEC or Kodi. Say which graphics card and TV you have, how they're connected, and what you were playing, and attach a diagnostic report from Settings > LibreELEC > System > Submit Log > Create a diagnostic report.

    CroqueMr's builds thread can be found here.

    Edited 42 times, last by ht2tweak (November 13, 2026 at 5:55 PM).

    Hi everyone. This thread and CroqueMr's fork got me started, so I'd like to share where it led: LibreELEC Hades, an unofficial LibreELEC build for x86_64 PCs that sends native Dolby Vision (Standard, TV-led) over HDMI from NVIDIA, AMD and Intel graphics, dedicated or built into the processor, profile 7 with the full enhancement layer included.

    It began from CroqueMr's dvbridge module and Intel output (credited in the README) and adds:

    - NVIDIA output with NVIDIA's open kernel modules (GTX 16, RTX 20 and newer), through the driver's vendor InfoFrame property, 8 bpc and dithering off.
    - AMD output (amdgpu, recent display hardware, not DCN 1 or 2). It needs an HDMI TMDS link.
    - Profiles 7 FEL, 8.1 and 5, and Dolby Vision in two video tracks (Blu-ray .m2ts structure).
    - For integrated graphics: where a frame takes most of the refresh period it is prepared one refresh ahead, and the faster of two drawing paths is measured and remembered.
    - Kodi's refresh rate is kept, exact rates included. On NVIDIA it adds the exact 24, 30, 60 and 120 Hz modes the driver did not offer.
    - It fails closed: if the video, TV, link or driver does not qualify, the video plays the normal way, no black screen.
    - Dolby Vision shown as HDR10 (no tone mapping) where native output is not possible, profile 5 by default.
    - Safer defaults for a PC with other disks (internal disks hidden when started from USB), a small Windows installer and a diagnostic switch.

    Seen working so far, with the test builds that led to this RC, on an LG C5: RTX 4080 SUPER, the integrated Radeon of a Ryzen 9 7950X3D, and an Intel Core i5-12450H laptop. Profile 7 FEL on all three (measured on the 4080 and the Radeon: 240 frames every 10 s, none dropped, FEL in every one), 8.1 and 5 on the 4080, TrueHD Atmos passed through on all three and DD+ Atmos on the 4080.

    Everything else is untested, and that is where help would be great: other NVIDIA, AMD and Intel graphics, other TVs, and 3D (new in this version: 3D Blu-ray MVC decoding and switching a 3D display over HDMI, never tried on a 3D display).

    Repository: https://github.com/hadesdevls/LibreELEC-Hades
    Release 1.0 RC1 (image, update .tar, Windows installer and the complete source): https://github.com/hadesdevls/Lib…es/tag/v1.0-rc1

    Before trying: Secure Boot has to be off, and the TV input must advertise Dolby Vision Standard (on the LG C5, Quick Frame Transport off on that input; Hades tells you when an input offers only low-latency Dolby Vision). A USB SSD is much smoother than a stick.

    It is unofficial: please report problems in the GitHub issues, not to LibreELEC or Kodi. A report with the diagnostic switch on helps a lot (a tick box in the installer, or rename DIAG-OFF.TXT to DIAG-ON.TXT on the boot partition); docs/diagnostics.md explains.

    Many thanks to CroqueMr for the fork this grew from, to Dom Cobley and cinema-ONE for the 3D work it uses, and to everyone in this thread.

    Quote from hadesdevls

    Hi everyone. This thread and CroqueMr's fork got me started, so I'd like to share where it led: LibreELEC Hades, an unofficial LibreELEC build for x86_64 PCs that sends native Dolby Vision (Standard, TV-led) over HDMI from NVIDIA, AMD and Intel graphics, dedicated or built into the processor, profile 7 with the full enhancement layer included.

    Hi, thank you for sharing your project and for all the hard work you've put into it.

    I'm really looking forward to trying your build. I'll definitely give it a try and share my feedback and any issues I come across.

    I also hope you can collaborate with CroqueMr and other developers in the future. It would be great to see everyone working together towards a LibreELEC build that supports a wider range of hardware, including Intel and AMD integrated graphics, as well as dedicated NVIDIA and AMD GPUs.

    Most importantly, I hope we can achieve full Dolby Vision Profile 7 FEL support, with the entire enhancement layer properly processed without any compromises.

    Really appreciate your efforts, and I wish you all the best with this project. Keep up the great work.

    Edited once, last by Vertox (October 15, 2026 at 6:51 AM).

    Nice :)

    I will open your build and integrate what can be integrated in the next release. I am interested in your Nvidia/AMD GPU Support.

    I've reviewed your code, and unfortunately, it's based on an old version of my build. We've made significant progress since then, particularly in performance optimization. As it stands, your build will struggle quite a bit on weak CPUs.

    Your NVIDIA integration looks good, though. I'll incorporate it into my release this weekend :)

    Quote from CroqueMr

    I've reviewed your code, and unfortunately, it's based on an old version of my build. We've made significant progress since then, particularly in performance optimization. As it stands, your build will struggle quite a bit on weak CPUs.

    Your NVIDIA integration looks good, though. I'll incorporate it into my release this weekend :)

    Hey Croque, glad you took a look at it and that you're planning to implement some things in your build!!!

    I actually started working on this the very day you first shared your code, trying to get it running on my hardware and experimenting with other implementations. I've also made quite a few general updates to the code since then, but I'll check out the latest changes in your fork to see if there are any useful optimizations I might have missed. Thanks for the heads-up!

    So far, it's been running pretty well on the hardware I've tested, although I haven't tested it on that many different setups, and none of them have been particularly low-end since I don't really have any modest hardware at home. I guess that could explain why I haven't encountered the issues you mentioned, which would make sense.

    The lowest-end hardware it's been tested on so far is a borrowed laptop with an Intel i5-12450H. I also want to test it on a couple of laptops I have at home, but neither is exactly representative of lower-end hardware (one has a Ryzen 9 5980HX with an RX 6800M, and the other has an i7-12650H with an RTX 3080 Ti Mobile).

    So if anyone else gives it a try and notices any performance issues, please let me know!

    Hi everyone,

    LibreELEC Hades 1.0 RC2 is out, and it is a big step from RC1. It is still native Dolby Vision (TV-led) from a PC over HDMI, on NVIDIA, AMD and Intel graphics, dedicated or built into the processor.

    What changed most:

    - **The Dolby Vision picture is now rebuilt exactly as the published specification (ETSI GS CCM 001) defines it**, and sent to the TV the way certified players send it. Every profile: 5, 7 FEL, 7 MEL and 8.1.
    - **Lighter on modest graphics.** Repeated frames are not redrawn, shaders are cached and prepared before the first frame, and profile 7 MEL no longer decodes its empty enhancement layer. On hardware that still cannot keep up, there is an automatic, measured fidelity step-down that only kicks in when frames are actually being missed. Hardware that keeps up stays bit-exact.
    - **Menus at 119.88/120 Hz**, starting and stopping Dolby Vision/HDR with a single display change, and Dolby Vision working even if the TV is switched on after the PC.
    - **A new "Overview" page** in the player info showing what is really sent to the TV, plus a mode for projectors and non-Dolby Vision displays.
    - **Native Dolby Vision on older AMD APUs and GPUs** (Raven, Picasso, Navi 1x, Renoir, Cezanne), HDR10 at 10 bits on Intel and AMD, and live TV fixes.

    I tested this version on my own PC (Ryzen 9 7950X3D + RTX 4080 SUPER, both the NVIDIA card and the integrated Radeon, LG C5, TCL Q85H Pro): profiles 5, 7 FEL, 7 MEL and 8.1, HDR10, menus at 119.88 and 120 Hz, TrueHD/DD+ Atmos and DTS-HD MA passthrough.

    **What I'd really like now is feedback from other hardware**, especially smaller iGPUs (N100 and similar, older AMD APUs). The Dolby Vision page in the player info shows the GPU time per frame and the headroom, so a screenshot of it tells a lot. Logs help even more: tick "Save diagnostics" in the installer.

    Release, changelog and what has been tested: https://github.com/hadesdevls/Lib…es/tag/v1.0-rc2

    Secure Boot has to be off. As always, it is unofficial: please report problems on GitHub, not to LibreELEC or Kodi.

    Thanks to everyone working on Dolby Vision on PC. The README credits the builds whose ideas I took.

    Couldn't you all join efforts and work collaboratively towards a common goal? hadesdevls

    Having multiple builds to test, on a different development path seems to be a waste of resources. Both from a development point of view and, maybe more importantly, from a testing point of view.

    What do you think?

    Quote from bang gun

    I could try to send logs if that helps but all I can see is only a simple DV=0 or DV=1 mention in the log files not sure if that's too helpful

    First of all you have to activate debug logging (sorry, you might be aware of this but you never know). Then devs could then point you to activate different detailed logging options in settings, in order to get more information.

    Edited once, last by ashlar: Merged a post created by ashlar into this post. (October 16, 2026 at 11:21 AM).

    Quote from ashlar

    Couldn't you all join efforts and work collaboratively towards a common goal? hadesdevls

    Having multiple builds to test, on a different development path seems to be a waste of resources. Both from a development point of view and, maybe more importantly, from a testing point of view.

    What do you think?

    First of all you have to activate debug logging (sorry, you might be aware of this but you never know). Then devs could then point you to activate different detailed logging options in settings, in order to get more information.

    I completely agree with you; it feels like a lot of work has been duplicated, AMD support, CPU optimization, and so on. (and I received the log from bang gun by PM, don't worry I see the issue)

    I’ve already integrated Nvidia support into the build coming this weekend, along with a few other interesting additions. As for performance adjustments via bilinear filtering, that’s an intriguing idea. It seems I’m getting the same performance on an N100 without needing such filters, which would otherwise compromise image fidelity. Still, it’s a solid concept, because you can reduce a little bit the fidelity to something very small, almost invisible that makes it possible to read a file that couldn't be read before. I already have something like this with "fast" mode, but the Hades build takes the concept further.

    Quote from hadesdevls

    Hi ashlar, CroqueMr,

    I'm glad to collaborate, with CroqueMr and with anyone else working on Dolby Vision on PC. All of the Hades code is on GitHub, so CroqueMr, use whatever helps your build, and ask me if you want to know why something is done the way it is. Hades started from your work, and the README says so.

    That said, Hades is a hobby project I started for my own setup, and much of it has nothing to do with Dolby Vision. It has privacy and safer defaults, like hiding the internal disks when booting from USB, Samba off unless you turn it on (and then with a password), no update server that could replace the build, and logs kept on the device unless you choose to upload them. There's also a Windows installer. That probably doesn't fit your build, so I'll keep working on Hades in parallel and share what works.

    On bilinear: I agree it costs fidelity, which is why Hades only steps down when it has to. It isn't a mode you choose. It starts only when the GPU is actually missing refreshes, goes back up as soon as frames fit again, is remembered per GPU and driver, and can be turned off. A GPU that keeps up gets the full picture, bit-exact, so if the N100 keeps up it never steps down there either.

    That full picture is also more faithful in RC2. It now follows the normative composer of ETSI GS CCM 001 and matches an integer reference of the spec bit for bit in every case I tested. On the profile 7 FEL stream I measured, libplacebo's reshaping, which mpv and the PC builds use (Hades too, until this release), differs from it by 4 to 15 codes out of 4095 on almost every pixel and by hundreds at high-contrast edges. If you want it, the composer and the exact Lanczos weights are libplacebo patches in the repo, and the chroma siting fix is a small change in the bridge.

    I noticed the different adjustment levels you implemented using bilinear filtering. Unfortunately, a large part of what you've done had already been explored on my side. If you look at the Fast mode in R1.0.0.Beta3, it follows a very similar approach, with comparable impacts in image fidelity, ( chrominance and high-contrast edges)

    Performance speaking, your build seems to be roughly on par with Beta 3 on the N100, where it falls back to your Level 2. I believe R1.0.0.Beta3 might preserve slightly better image fidelity, but that still needs to be confirmed through proper comparisons.

    Regarding the project itself, my goal with the Dolby Vision build in my repository isn't to integrate every possible feature, particularly things like security enhancements that fall outside the scope of the DV engine.

    That said, I'd really encourage you to contribute directly to the main repository when working on the DV engine itself. PRs would allow everyone to benefit from your improvements and help us avoid duplicating efforts, you can push PRs and I will perform all non-regression tests. Of course, you're absolutely free to maintain your own fork for additional features, such as your security enhancements.

    I think this would be a much more productive approach for everyone, and I'd be happy to see your contributions integrated into the main project.

    Edited 2 times, last by CroqueMr: Merged a post created by CroqueMr into this post. (October 16, 2026 at 9:11 PM).

    hadesdevls a hardware report for RC2 on a discrete AMD card, since "other AMD" is still untested in your list.

    ASUS NUC 12 with a Radeon RX 7600 (Navi 33), HDMI straight to a Panasonic TV (TV-led DV), clips played from local storage:

    • P7 FEL, two test clips (CM v2.9 and CM v4.0): native DV, Dolby Vision logo on the TV, the FEL text is visible
    • P7 MEL: detected as MEL, native DV
    • P8.1 and P5 (59.94): native DV
    • 240 of 240 frames per 10 s at 4K 23.976, 600 of 600 at 59.94, no step-down, about 5 ms GPU time per frame
    • Start and stop each in one mode change
    • Connector during DV: max bpc 8, full-range RGB, no HDR metadata, DVBRIDGE_REFUSED 0 (DVBRIDGE_LINK_FORMAT also reads 0)

    Two things I noticed:

    • With a settings window over the video, every frame is composed with the GUI and output drops to about 16 fps (43-47 ms GPU time per frame). Closing it brings back 240 of 240.
    • The log repeats "DVBridge libplacebo: Trying to call pl_opengl_unwrap on a pseudo-texture", with no visible effect.

    Happy to send the log.

    Thanks for testing it on the N100, and I'm glad the NVIDIA work helps your next release. Good luck with it.

    If you still have the log from that N100 run, I'd like to see it. Knowing why it stepped down to level 2 there would help me tune it.

    On fidelity, I agree with you that it needs proper comparisons. The way I measure is written up in the descriptions of the libplacebo patches in the repo (9930 for the composer, 9940 for the step-down levels): frames of a profile 7 FEL stream drawn on a software renderer, the composer compared with two separate transcriptions of the spec, and each step-down level with the full-quality picture. Happy to compare on the same frames whenever it's useful.

    And when I have something in the DV engine that could help your build, I'll send it as a PR or point you to it. Hades will keep going in parallel for the things outside the DV engine, and anything in it is yours to use.

    I'm away from home until Tuesday, so I'll follow up then.

    Quote from cinemaONE

    hadesdevls a hardware report for RC2 on a discrete AMD card, since "other AMD" is still untested in your list.

    ASUS NUC 12 with a Radeon RX 7600 (Navi 33), HDMI straight to a Panasonic TV (TV-led DV), clips played from local storage:

    • P7 FEL, two test clips (CM v2.9 and CM v4.0): native DV, Dolby Vision logo on the TV, the FEL text is visible
    • P7 MEL: detected as MEL, native DV
    • P8.1 and P5 (59.94): native DV
    • 240 of 240 frames per 10 s at 4K 23.976, 600 of 600 at 59.94, no step-down, about 5 ms GPU time per frame
    • Start and stop each in one mode change
    • Connector during DV: max bpc 8, full-range RGB, no HDR metadata, DVBRIDGE_REFUSED 0 (DVBRIDGE_LINK_FORMAT also reads 0)

    Two things I noticed:

    • With a settings window over the video, every frame is composed with the GUI and output drops to about 16 fps (43-47 ms GPU time per frame). Closing it brings back 240 of 240.
    • The log repeats "DVBridge libplacebo: Trying to call pl_opengl_unwrap on a pseudo-texture", with no visible effect.

    Happy to send the log.

    Thanks, this is a great report, and the first one on a discrete AMD card.

    The drop with a settings window open is the important one. Frames with the GUI go through the composited path, and 43 to 47 ms on an RX 7600 is far more than I'd expect from it. The pl_opengl_unwrap message has no visible effect, as you say, but it shouldn't be there either.

    Yes, please send the log. On the LIBREELEC partition, rename DIAG-OFF.TXT to DIAG-ON.TXT, play a Dolby Vision file with the settings window open for half a minute, shut down from Kodi, then zip the hades-diag folder and attach it to an issue on GitHub.

    I'm away from home until Tuesday. I'll look into both and try to fix them, and there will be a new update between Tuesday and Wednesday.

    LibreELEC Hades 1.0 RC3 is up: https://github.com/hadesdevls/Lib…es/tag/v1.0-rc3

    Changes since RC2, mostly from logs posted here and on GitHub:

    - Dolby Vision: two-track MKV and MP4, MEL that locks, per-picture metadata after seeks, and Blu-ray folders and ISOs without the 9 second gap between clips.
    - Dolby Vision TVs from 2017 and 2018 that use display management 2 or 3 now get native output.
    - More hardware: Intel UHD 6xx, AMD RDNA4, and laptop HDMI ports wired as dual-mode outputs of the NVIDIA GPU. On AMD, HDR10 in 4:2:2 at 12 bits, and the right RGB range on TVs without quantization range support.
    - HDR10+ on NVIDIA, AMD and Intel. The HDR10+ Gaming FAQ says PC monitors only take it over HDMI for now, so that is the cable to try.
    - Player-led Dolby Vision (Low-Latency) as a setting, off by default. Through an HDMI sync box that only accepts Low-Latency, it played here as native Dolby Vision on the AMD integrated GPU.
    - The diagnostics now also strip local addresses, MACs and SSH fingerprints, can copy themselves to a USB stick, and the installer keeps them when it updates a drive.
    - Linux 7.2.12, Kodi Piers, Python 3.14.9, NSS and Mozilla's latest root certificates. Hardening flags only where a measurement showed no cost.

    Tested here on an RTX 4080 SUPER and on the 7950X3D's integrated Radeon, with an LG C5: profile 7 FEL, 8.1 and 5, HDR10, seeking, leaving Dolby Vision at 120 Hz, TrueHD and streaming Atmos, add-ons and the info pages. Everything else is new and has only been tested on the bench. A diag with any report helps a lot.

    LibreELEC master moved to Linux 7.3 today. Hades stays on 7.2.12 for this release; 7.3 comes once its amdgpu patches are ported and tested.

    LibreELEC Hades is not certified by Dolby or HDR10+ Technologies. Dolby Vision and HDR10+ are named here only as formats.

    Quote from ashlar

    Is this HDR10+ --> DV conversion or simply outputting HDR10+ to compatible TVs?

    Both, as two separate things.

    By default it simply outputs HDR10+: on a display that declares HDR10+, the dynamic metadata of each frame goes out with that frame, on NVIDIA, AMD and Intel.

    HDR10+ to Dolby Vision is a separate setting, off by default: Settings > System > Display > HDR10+ as Dolby Vision (Advanced level, and it needs "Native Dolby Vision output" on). It is meant for TVs that have Dolby Vision but no HDR10+, like LG's: Hades builds the Dolby Vision metadata from the film's HDR10+ metadata and sends it as native Dolby Vision. That one hasn't been tried on a TV yet, so reports are welcome.

    Nice for your works on HDR10+ when it will be tested I will integrated it in my build. :)
    What algorithm and decision did you take to convert DV metadata to HDR10+? it's not a simple conversion, of course it's lossy.