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

Quote from NUCi7

Kodi log attached

Thanks, Gen 10th is complicated to support, but I will try to force something, maybe it will not work but at least we can try.

Quote from CroqueMr

Thanks, Gen 10th is complicated to support, but I will try to force something, maybe it will not work but at least we can try.

Thank you my friend, funny, I get the HDR badge, get audio, but no video. Also, having trouble playing .mp4 file. Whatever you do, I totaly appreciate your effort.

Have a good eveing

Quote from ht2tweak

No, when it's playing. Look forward to HDR formats overlay for other skins being more like how it is with Estuary. Thanks!

I've run all my tests while playback was paused, it's extremely stable and it was actually quite challenging to have no crash at all.

It hadn't occurred to me that people might try switching modes during playback. I'll prevent that for now by automatically pause/play the feed whenever the output format (HDR/DV/HDR10+) is changed.

Quote from CroqueMr

Thanks for your feedback, I am finalizing the RC2, I will push the release tomorrow, regarding your issues :

- FEL on transformer has been fixed
- OSD player information is more stable
- HDR10+ has been improved a lot, and since Hades is in GPLv2 I will audit the code and take what's work well.

For the OSD with the quick switching, on my N100 it's clean, I do not have any issue, do you switch with the film paused?
For the theme I will check what I am exposing to be better integrated with themes and if it's not possible to ensure a good visibility regardless of the theme I will fix my pannel and no theme will be applied

Hi brother do RC2 fixes my issues https://github.com/CroqueMr/libreelec-x86-DV/issues/73

Quote from CroqueMr

Thanks for your feedback, I am finalizing the RC2, I will push the release tomorrow, regarding your issues :

- FEL on transformer has been fixed
- OSD player information is more stable
- HDR10+ has been improved a lot, and since Hades is in GPLv2 I will audit the code and take what's work well.

For the OSD with the quick switching, on my N100 it's clean, I do not have any issue, do you switch with the film paused?
For the theme I will check what I am exposing to be better integrated with themes and if it's not possible to ensure a good visibility regardless of the theme I will fix my pannel and no theme will be applied

Hi CroqueMr,

Thanks for the update and looking forward to testing RC2!

Regarding the OSD behavior:
- **Pause vs Live:** The coordinate shrinking/flickering happens while the video is playing live (not paused), specifically when target luminance triggers HDR-to-DV Adaptive conversion.
- **Hardware difference:** The N100 uses standard UHD (`i915`), while on Arc/Iris Xe hardware using the `xe` kernel driver, atomic modeset commits fail (`Admission checked (not committed)` in `dmesg`), leading to total signal loss on stop/refresh-rate changes.

I'm traveling today, but the test machine is powered on and connected. Once you push RC2 tomorrow, I'll update via SSH and report back on whether the OSD and modeset stability hold on Arc/Xe!

Quote from CroqueMr

this might be the missing piece for LLDV on x86 on iGPU and Dolby vision on ARM port

Greetings! An intriguing development has emerged: an ARM port! Could this mean that it might now be possible to implement full Dolby Vision (DV) FEL (Full Enhancement Layer) support on an ARM-based architecture—specifically on an SoC like the Rockchip RK3588S2? Up until now, DV FEL playback on platforms lacking native hardware support has been a challenge, but with this Rockchip chip entering the picture, I’m curious: to what extent might this simplify, improve, or accelerate the realization of DV FEL playback on such a platform? Apologies for bringing this up in an off-topic thread—I know it’s a bit of a departure from the usual order—but then again, without breaking a few rules, there’s no progress, right? 😊

Quote from lvasan

Hi CroqueMr,

Thanks for the update and looking forward to testing RC2!

Regarding the OSD behavior:
- **Pause vs Live:** The coordinate shrinking/flickering happens while the video is playing live (not paused), specifically when target luminance triggers HDR-to-DV Adaptive conversion.
- **Hardware difference:** The N100 uses standard UHD (`i915`), while on Arc/Iris Xe hardware using the `xe` kernel driver, atomic modeset commits fail (`Admission checked (not committed)` in `dmesg`), leading to total signal loss on stop/refresh-rate changes.

I'm traveling today, but the test machine is powered on and connected. Once you push RC2 tomorrow, I'll update via SSH and report back on whether the OSD and modeset stability hold on Arc/Xe!

I do not forget your issue, only a part of it will be fixed in RC2, I will check deeply after RC2, I need to investigate the drivers/kernel.

Quote from kigba

Greetings! An intriguing development has emerged: an ARM port! Could this mean that it might now be possible to implement full Dolby Vision (DV) FEL (Full Enhancement Layer) support on an ARM-based architecture—specifically on an SoC like the Rockchip RK3588S2? Up until now, DV FEL playback on platforms lacking native hardware support has been a challenge, but with this Rockchip chip entering the picture, I’m curious: to what extent might this simplify, improve, or accelerate the realization of DV FEL playback on such a platform? Apologies for bringing this up in an off-topic thread—I know it’s a bit of a departure from the usual order—but then again, without breaking a few rules, there’s no progress, right? 😊

Yes it's possible, I do not have this chip but in term of raw power, I think it can handle the open source engine including the same Master Reference output as x86 in term of fidelity
When I said "ARM" I was more thinking about low powered chip.

Quote from CroqueMr

I do not forget your issue, only a part of it will be fixed in RC2, I will check deeply after RC2, I need to investigate the drivers/kernel.

Thanks a lot brother

Quote from CroqueMr

When I said "ARM" I was more thinking about low powered chip.

I get the general idea. When I mentioned the RK3588S2-DV, I was referring to an example of hardware-based decoding—much like how it was handled with the Amlogic X922 in the Ugoos AM6+ when running CoreELEC (CE). It seems we just need to wait for the current "technology" for processing FEL Dolby Vision to become more established and reach the mainstream

Quote from DMDreview

The task was to strictly output 2 bits of data to the EL layer. Therefore, a solution involving direct editing of only the EL layer was necessary, since it is impossible to control how the DEE encodes the data—or what it decides to classify as residual data.

You absolutely can control what's in the EL and BL using DEE. You just have to do it manually rather than using their all-in-one Python script. This is the only proper way to ensure the NAL units(and rpu) are correct between the EL and BL is to use Dolby's Properties Tool.

dee_dv7_preproc -i "D:\mezzanine12bit-jpeg2000.mxf" --input-format jpeg2000_mxf:range=auto:framerate=23.976 -m "d:\metadata.xml" --input-bl f:\BL.yuv --input-bl-format raw:pix_fmt=yuv420p10le:width=3840:height=2160:target=hdr10:streaming=1:frame_count=8315 --progress 1 --el-type full -r D:\P7.rpu -o F:\EL.yuv

dee_video_encoder --bl-yuv F:\BL.yuv --el-yuv F:\EL.yuv --encoder x265 --metadata D:\staticHDR10.txt --rpu D:\P7.rpu --fps 23.976 --frames 8315 --use-case fel --el-bitrate 5000 --el-buffer 5500 --bl-bitrate 85000 --bl-buffer 99000 --preset slower --passes 2 --out-bl D:\BL_final.hevc --out-el D:\EL_final.hevc

Quote from kigba

I get the general idea. When I mentioned the RK3588S2-DV, I was referring to an example of hardware-based decoding—much like how it was handled with the Amlogic X922 in the Ugoos AM6+ when running CoreELEC (CE). It seems we just need to wait for the current "technology" for processing FEL Dolby Vision to become more established and reach the mainstream

My build is fully open source and will never incorporate proprietary Dolby code. ARM port will be based on the existing x86 engine, without relying on dovi.ko file, even on licensed SoCs, the facts that a SoC is capable natively to read and send a DV stream is not important for a port of my build.

Of course, what I’ve said reflects only my own personal view and my builds, others might do things differently

R1.0.0 RC2 - Stability improvement, HDR10+ fixes, BD-J Menu experimental support

Changes since R1.0.0-RC1

Dolby Vision

• Renamed Dolby Vision Standard to Dolby Vision Reference to reflect its precision-oriented output rather than an entry-level mode. The optimized processing path is retained.
• Added optional CM2.9 to CM4.0 controls, including Auto/Auto 2 and independent L2-trim suppression. Selection rules adapted from avdvplus; neutral blocks and PQ formulas from quietvoid/dovi_tool.
• Fixed Master Reference startup readiness and per-file failure counters for YCbCr and IPT output.
• Fixed HDR10 Expert startup when the required TV profile is incomplete.
• Corrected tiny or misplaced OSD during HDR10-to-Dolby Vision playback.
• Fixed in-band MP4 FEL headers, BL/EL seek recovery in M2TS/ISO and valid duplicate luma pivots in the reported Transformers FEL sample.
• Reduced intermediate storage and redundant processing in HDR10 Basic/Expert and source analysis improving stability and performance

HDR10+

• Added HDR10+ to Dolby Vision: preserve decoded film pixels and use compatible source metadata, with LightGBM AI assistance working on your CPU when source statistics are incomplete. Distribution estimation and scene comparison adapted from Hades.
• Corrected native HDR10+ V1 metadata validation and HEVC/Matroska metadata handling.
• Improved Dolby Vision-to-HDR10+ metadata generation and creative-control handling, with targeted packet-progression diagnostics.

Playback and stability

• Improved return to SDR after playback stops or fails, without artificial audio/video offsets.
• Improved native resolution and refresh-rate selection for cropped and nonstandard source dimensions.
• Added an Auto view mode that avoids unnecessary near-native UHD enlargement while retaining normal Kodi scaling for smaller sources.
• Integrated Christian Hewitt's libplacebo shader-stage correction. Retained the shared rendering optimizations contributed by dangerouslaser.

Blu-ray menus, subtitles and 3D

• Add experimental HDMV and BD-J menus support
• Added PGS/DVB subtitle controls for brightness, saturation, size, placement and vertical offset, adapted from avdvplus.

GPU and HDMI support

• Added AMD DCN4 / RX9000 admission and improved Vega M colour-state preservation.
• Improved NVIDIA R615/R580 HDR/SDR packet handling, extended EDID ownership and native-TMDS detection; corrected the Pascal return-thunk build contract, adapted from Hades.
• Improved Intel EDID ownership, BT.2020 YUV signalling, neutral tunnel checks and advertised-CTA HDR10+ selection.
• Added bounded Intel Display9 Skylake/Kaby Lake HDR handling, retaining native output-depth and bandwidth checks. Other Display9/LSPCON restrictions remain unchanged.

Interface and diagnostics

• Kept the compact Quick Switch independent of the active skin while retaining native Kodi controls.
• Fixed Quick Switch availability during paused HDR10+ / Dolby Vision transitions, using native source identity separately from per-picture output validation.
• Shortened some player information labels.
• Added bounded diagnostics for decoder stalls, BL/EL imports, HDR10+ progression, audio settings and HDMI transitions.

Player information and audio

• Expanded audio source information: codec/immersive format, source format and channels, declared bed/objects, presentation, dialnorm, bitrate and language, when available.
• Separated source audio from actual Kodi output: passthrough/RAW, decoded or native PCM, transcode and effective output format/channels. Read-only metadata parsing adapted from avdvplus.
• Compact Video/Audio headings, readable labels across the panel, slightly smaller text and video dimensions without thousands separators.

Known issues

• RX7600 FEL vertical-detail loss and repeated DV-to-HDR10+ packets remain under investigation.
• Arc B570 black-screen transitions, RTX4070 HDR10 reception and GTX1000 boot compatibility still require confirmation on affected hardware.
• Some disc-specific MP4/BDMV and authored menu paths remain unverified.
• HDR10+ target curves, colour controls and multiple spatial windows cannot all be translated directly into Dolby Vision metadata, work is ongoing to improve current algorithm.

Next focuses

• Bug fixing following new issues
• Improve HDR10+ support and processing
• Improve hardware support
• Improve BD-J support
• Improve Player Information pannel UI

Quote from CroqueMr

R1.0.0 RC2

One simply has to copy the release to .update and reboot to install, correct? No special procedure needed.

Quote from ashlar

One simply has to copy the release to .update and reboot to install, correct? No special procedure needed.

yes

Quote from CroqueMr

• Added optional CM2.9 to CM4.0 controls, including Auto/Auto 2 and independent L2-trim suppression.

Thanks, but no ''always'' option ?

Or is that what you meant by ''independent L2-trim suppression'' since forcing cmv4.0 disables the L2 trims?

Quote from CroqueMr

https://github.com/CroqueMr/libreelec-x86-DV/releases

R1.0.0 RC2 - Stability improvement, HDR10+ fixes, BD-J Menu experimental support

Hi CroqueMr.

First of all, a huge thank you for all the amazing work you've put into RC2!

I'm really happy to see that you've added experimental Blu-ray HDMV and BD-J menu support. This is something I've been hoping to see for quite a while, especially with my large collection of Blu-ray ISOs. I really appreciate you taking the time to work on it!

And I've got some exciting news! My new ASUS NUC 15 Pro AI Mini PC with an Intel Core Ultra 7 255H and Intel Arc graphics has finally arrived! 😍

I'm really excited to test RC2 on this new machine, especially Dolby Vision FEL, 4K60 playback, full Blu-ray ISO menus, picture quality, and overall system performance and stability.

Once I've spent some time testing everything, I'll be happy to share my experience and feedback with you, including any issues I might come across.

RC1.1 was already fantastic in my experience, so I'm really looking forward to seeing what RC2 brings, especially with all the new improvements and Blu-ray support!

Thanks again, my friend, for your dedication, patience, and all the effort you've put into this project. It's truly impressive how far your build has come, and I really appreciate everything you're doing for the community.

Keep up the fantastic work. 🌹👏