[x86-64][CroqueMr Builds] Dolby Vision w/FEL, HDR10+, and 3D

    Quote from Vertox

    I've already upgraded to RC3, but I just saw your note about the FEL seeking regression and that RC3 has been withdrawn.

    To be honest, I'm a bit confused now, especially with the R1.0.0-RC3 Preview release. I'm not sure which version I should be installing anymore.

    Would you recommend going back to RC2 for now, staying on my current RC3 build, or installing the RC3 Preview instead?

    Just want to make sure I'm using the right version until the fixes are ready. Thanks again for all your hard work.

    No it is very small keep using it, it concerns some niche FEL DT, RC3 with the fix will be push tomorrow.

    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.

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

    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

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

    Quote from CroqueMr

    I decided to make the circuit selected in the settings menu the default on startup, as I find it more user-friendly.

    Absolutely, while I respect and share ht2tweak's desire to tinker endlessly with conversions, results, etc., a normal usage pattern for sure sees a user testing the different modes available, deciding what's right for them, putting that in settings and forgetting about it.

    Please do not change this.

    Quote from ashlar

    Absolutely, while I respect and share ht2tweak's desire to tinker endlessly with conversions, results, etc., a normal usage pattern for sure sees a user testing the different modes available, deciding what's right for them, putting that in settings and forgetting about it.

    Please do not change this.

    Agree. I was only testing as the functionality is there. I've tried VS10 and all kinds of processing solutions for years and settled on pure/direct, and just watch the content in the native format.

    Edited once, last by ht2tweak (November 6, 2026 at 6:45 PM).

    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.
    01_KODI.log

    Quote from CroqueMr

    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

    Hi CroqueMr,

    Haha, thanks for the honest reply! It totally makes sense now. Sometimes a bunch of accumulated patches happens to fix a specific case (like Transformers 2) without being a clean architectural solution.

    This perfectly explains why you decided to rework the entire FEL/EL pipeline for RC4. I completely understand that Hades needs a different approach rather than copying your patchwork.

    Take your time with the RC4 rebuild. I'll be here ready to test the new architecture as soon as it's ready!