And for SDR to DV for me it is useless it is just a SDR track wrap up in a DV container, I do not see any gain with this kind of conversion but maybe I am wrong.
For what it's worth, I wholeheartedly agree.
In a world with infinite developers taking care of this, why not. In this world, where there's you and a couple of other people... better concentrate on stuff that makes sense.
Very complicated. I already have a DV-to-HDR10 mode that works somewhat like LLDV, but outputs HDR10. Of course this mode is not a real DV output but it manages the more important DV adjustment.
However, doing true LLDV would require significantly more processing power on the PC side. It would only be feasible on much more powerful hardware, or with some massive optimizations that I honestly have no idea how to pull off without impacting image quality.
Well you and Hades opened the box for Gaming and Workstation PCs now, so why not see where it goes?
We might not have the super specific chips of the small boxes, but some of us have raw power 600W GPUs and high core 3D Cache CPUs.
PC users are used to not being able to run the latest and heaviest graphic settings all the time, sometimes a hardware update needs to happen first, so as long as those heavy modes get declared correctly, I wouldn't see the issue with it.
If it means my heavy weight PC can deliver an even better experience to my projector, then I'll gladly take it.
I wonder if the 3 devs working on this will consider buy me a beer link, help support their work for those able to
Well you and Hades opened the box for Gaming and Workstation PCs now, so why not see where it goes?
We might not have the super specific chips of the small boxes, but some of us have raw power 600W GPUs and high core 3D Cache CPUs.
PC users are used to not being able to run the latest and heaviest graphic settings all the time, sometimes a hardware update needs to happen first, so as long as those heavy modes get declared correctly, I wouldn't see the issue with it.
If it means my heavy weight PC can deliver an even better experience to my projector, then I'll gladly take it.
I understand your need but it's clearly not my priority in term of dev.
I'd rather focus on offering a viable alternative to Amlogic based devices, delivering perfect Dolby Vision playback at a lower cost and/or much better responsiveness for a similar price.
I wouldn't spend time implementing LLDV if it could only run on NVIDIA or dedicated GPUs. I just don't see the point compared to a $300 Amlogic box that already does LLDV. We'd end up with a much more expensive solution.
If I ever implement LLDV, it'll only be if we can make it work on hardware priced similarly to Amlogic devices, and finding new optimization lever to manage to fit LLDV on small iGPU it's not my top priority. Maybe in the futur after my stable release.
If it means my heavy weight PC can deliver an even better experience to my projector
By any objective measure, I doubt a SDR-->DV conversion would bring a better experience to your projector. In any case, CroqueMr has spoken, so any discussion about this is kinda useless anyway. 
For what it's worth, I wholeheartedly agree.
In a world with infinite developers taking care of this, why not. In this world, where there's you and a couple of other people... better concentrate on stuff that makes sense.
+2. When I first tried VS10 on Zidoo boxes and then Amlogic, I was impressed. The colors seemed punchier vs in original SDR, and PQ seemed better. But, felt it was mostly just changing the color profile, making it more saturated and leaning red, and half the time it looked off and unnatural. I've since been watching movies in their original grading, SDR or whichever HDR format.
Believe DMDreview did analyses with VS10 processing using AM6B+ before and would be best to educate us :).
By any objective measure, I doubt a SDR-->DV conversion would bring a better experience to your projector. In any case, CroqueMr has spoken, so any discussion about this is kinda useless anyway.
Yeah I don't know what discussion you're reading, but you're way out of line.
By any objective measure, I doubt a SDR-->DV conversion would bring a better experience to your projector. In any case, CroqueMr has spoken, so any discussion about this is kinda useless anyway.
No not useless, I do not see any good use case, but that doesn't mean that no use case is relevant for that kind of conversion.
And regarding your quote we were talking about LLDV not SDR to DV
I understand your need but it's clearly not my priority in term of dev.
I'd rather focus on offering a viable alternative to Amlogic based devices, delivering perfect Dolby Vision playback at a lower cost and/or much better responsiveness for a similar price.I wouldn't spend time implementing LLDV if it could only run on NVIDIA or dedicated GPUs. I just don't see the point compared to a $300 Amlogic box that already does LLDV. We'd end up with a much more expensive solution.
If I ever implement LLDV, it'll only be if we can make it work on hardware priced similarly to Amlogic devices, and finding new optimization lever to manage to fit LLDV on small iGPU it's not my top priority. Maybe in the futur after my stable release.
Oh of course you taking care of the timeline and what makes it into the build, is your prerogative after all as the dev. I respect that fully.
But as you said, so far we don't know the cost for LLDV with your solution right? So that means for now we don't know if it can run on an iGPU or not. There is still a chance for it to not need anything too heavyweight, even if it can't reach a specialized chip in economy.
Also to bring in a point or perspective:
Again not trying to force it, just wanted to help to see the perspective of someone already with a PC and no box.
If you ever implement it, after the stable build is released, I will still be a happy camper.
No not useless, I do not see any good use case, but that doesn't mean that no use case is relevant for that kind of conversion.
And regarding your quote we were talking about LLDV not SDR to DV
My bad. In any case, it's your decision. I cannot add anything to it.
LLDV can be useful, of course. SDR to DV... I'm baffled by people wanting it. HDR10+ / HDR10 to DV, I'm in favour (and I believe HDR10 to DV already works and hopefully HDR10+ to DV will come).
By any objective measure, I doubt a SDR-->DV conversion would bring a better experience to your projector. In any case, CroqueMr has spoken, so any discussion about this is kinda useless anyway.
You could pay the subscription and actually convert your SDR to HDR10 using something like Tekno3D VESAI. The professional version will also generate DV metadata, so you could just run your local SDR clips through and transform them into HDR versions that way.
CroqueMr I'm intrigued. AIUI Dolby make DV from HDR10 by analysing each scene which generates Level 1 and then applying a black-box algo to generate default Level 2 trims. (After that, the colourist has the option to adjust the trims.)
If you do that on the fly,
Oh of course you taking care of the timeline and what makes it into the build, is your prerogative after all as the dev. I respect that fully.
But as you said, so far we don't know the cost for LLDV with your solution right? So that means for now we don't know if it can run on an iGPU or not. There is still a chance for it to not need anything too heavyweight, even if it can't reach a specialized chip in economy.
Also to bring in a point or perspective:
- Not having to import a 300€ box
- Not having to import in a more and more hostile and expensive import environment
- Not having to worry about spending 300€ on something with shaky if not non existent warranty
- Not having to buy and setup another HDMI cable
- Already owning a PC anyway
- Not already owning those boxes
Again not trying to force it, just wanted to help to see the perspective of someone already with a PC and no box.
If you ever implement it, after the stable build is released, I will still be a happy camper.
I already see the processing cost in my DV-to-HDR10 and Master Reference IPT pipelines.
LLDV would require player side display mapping and tone mapping, plus the necessary colour transforms.
Today, an N100 handles Master Reference IPT at 30 fps with limited headroom. That doesn’t leave the necessary room for additional processing to convert it to an LLDV output. We need to add a processing comparable in complexity to HDR10 Expert + another color transformation. I’d need substantial optimisation to make LLDV practical on small iGPU.
CroqueMr I'm intrigued. AIUI Dolby make DV from HDR10 by analysing each scene which generates Level 1 and then applying a black-box algo to generate default Level 2 trims. (After that, the colourist has the option to adjust the trims.)
If you do that on the fly,
- are you loading each scene into a buffer to calculate Level 1 and the trims before passing that scene out to the display?
- how do you determine scene breaks? (in the mixing suite there can be some intervention from the colourist)
- how much memory does that entail, given scene segments might be about 50 frames (IIRC Dolby mandates new metadata at max 2 second intervals)? and
- have you cracked what Dolby do in their black box (and presumably in VS10) to apply the default trims?
No, I only generate L1 and L3, the more "technical" metadata. I also tried to recreate L2 and L8, but since they're tied to the creator's artistic intent, even with 100 TB of movies and an IA trained it wasn't enough to reproduce them reliably. They're simply not predictable so I don't try to generate L2/L8
My approach is to analyze the image and make an initial technical estimate of L1 and L3. Then, a small LightGBM model trained on 100 TB of movie data runs on the CPU to refine and fine-tune that estimate.
I deliberately avoided looking at any decompiled VS10 code until recently because I absolutely don't want to incorporate any proprietary Dolby code into my implementation. My approach is fundamentally different from Dolby's, both overall and specifically for HDR10-to-DV conversion.
I expected VS10 to do something fairly sophisticated, but from what I've seen, its HDR10-to-DV conversion is pretty much just HDR10 wrapped in DV. I my opinion my conversion is better than Dolby own HDR to DV conversion
You have the detail here :
Impressive! But I wonder what displays make of just level 1 + level 3. Levels 1 and 2 are CMv2.9 while Level 3 and 8 are CMv4 and I thought a display would expect to see either level 2 or level 8 to do any sensible trim adjustments. For sure, an older DV display (CMv2.9 only) won't be getting any trim metadata.
I suppose VS10 exists in the dovi.ko AML boxes use. You might not learn much from REing it (actually someone has already done that) as all it does is program the special DV cores in AML's hardware for which documentation is ..... elusive.
Repo will be updated later but release is up
R1.0.0 RC1 - Performance improvements, DV-to-HDR10+ and wider hardware support
Changes since Beta5.
Performance
Major AMD performance improvements, including Standard, Master Reference and conversion pipelines.
Reduced redundant rendering passes, surface imports and memory copies.
Improved FEL decoding, BL/EL scheduling and asynchronous frame preparation.
Optimized HDR10-to-Dolby Vision AI and Dolby Vision-to-HDR10 Basic/Expert.
Dedicated Profile 5 IPT paths: accurate processing in Master Reference and a lighter implementation in Standard.
Dolby Vision
Extended TV-Led V1 compatibility across Intel, AMD and NVIDIA.
Improved Standard and Master Reference resource management and presentation timing.
Added Master Reference IPT-PQc2 output, selectable in Expert settings; YCbCr remains the default.
Removed the Fast On/Off/Auto selector. Each rendering mode now uses its own fixed processing path.
Added optional automatic Master Reference → Standard recovery, disabled by default.
Added Disable L2 trims, disabled by default and limited to Standard and Master Reference.
HDR10+
Added native HDR10+ playback and Dolby Vision-to-HDR10+ conversion.
Added output paths for Intel, AMD and NVIDIA, including Pascal.
Added receiver V0/V1 handling and frame-associated dynamic metadata.
Improved output-depth validation, packet synchronization and HDR10+/HDR10/Dolby Vision/SDR transitions.
Added HDR10+ capability reporting in Kodi.
Native Kodi integration
Process video at source resolution before using Kodi’s native scaler and filters.
Preserve native zoom, view modes, picture placement, resolution whitelist and refresh-rate selection.
Keep native playback and fallback behavior outside active CB1 processing.
Playback and stability
Corrected chroma positioning and HDR10 Expert near-black handling.
Improved dual-layer MP4/MKV and dual-PID TS/M2TS detection, pairing and seeking.
Corrected startup timestamps, decoder replay and rendering-mode transitions.
Improved return to SDR after stopping playback or a failed start.
Corrected VAAPI import-cache sizing and surface retention, targeting FEL stalls reported with PGS subtitles.
Fixed mixed PGS subtitles and SDR GUI composition in Master Reference.
Fixed subtitles disappearing in black bars and missing scrolling notifications.
Hardware
Added NVIDIA GTX 10 / Pascal R580 support in the same image, with automatic matching of kernel drivers and libraries at boot.
Added AMD Radeon Vega M output support.
Improved Intel compatibility and Arc A/B firmware coverage.
Corrected NVIDIA PQ/HLG capability handling and deep-colour output validation.
Interface and diagnostics
Improved Player information, source/output reporting and skin compatibility.
Expanded bounded diagnostics for decoding, FEL pairing, output acceptance and HDMI failures.
Licensing
Migrated project-owned CB1 components and the L1/L3 AI model to GPL-2.0-or-later, with compatible replacements for affected helpers.
Third-party licenses remain unchanged. The selected FFmpeg/Kodi builds still carry GPLv3 requirements; the complete image is not GPLv2-only.
Known limitations
Intel N100/N150 and older AMD APUs, including Ryzen 3200U: heavy conversions and visible menus can exceed GPU capacity.
Intel Core 6th–9th generation and 10th-generation Comet Lake, using Display9: native HDMI HDR10/HLG/HDR10+ is not covered. This does not include 10th-generation Ice Lake.
NVIDIA GTX 10, GTX 16 and RTX 20/30 series: some HDMI-VIC, 3D or vendor-packet combinations prevent native HDR10/HLG signaling.
Next focuses
Bug fixing following new issues.
LibreELEC Hades 1.0 RC4 is out: release page
Dolby Vision
HDR10+, HDR10 and the display
Faster, same bytes
Each of these leaves the output identical, checked with the Dolby Vision bridge running in software: fewer row reads and half floats in the enhancement layer's resampling (24.9 to 12.4 MB per 4K FEL picture), 16-bit composed planes, both 4:2:2 rows of each 4:2:0 row from one shader invocation, repeated pictures recommitted instead of redrawn on NVIDIA, Dolby Vision as HDR10 kept at 10 bits, and the windows over a video loaded ahead while the menus are idle.
Smoother on modest GPUs
Frames that keep missing their refresh are presented a frame ahead, frames with menus over profile 7 FEL step down only on GPUs that can't keep up and only while the menus are up, and the enhancement layer's decoder waits for a free surface instead of restarting the layer. On the 7950X3D's integrated Radeon, profile 5 with the player info up went from 32, 31, 58 and 6 late frames per 10 s in RC3 to 26, 8 and 0.
Disks, sound, graphics
Up to date and safer
Linux 7.3, LibreELEC and Kodi 22 "Piers" at their latest commits, OpenSSL 4.1.0 and Python 3.14.10. Known security issues fixed in avahi (17 CVEs), expat, OpenSSL, glibc, BlueZ, BusyBox, FFmpeg and MariaDB Connector/C, plus two that upstream hasn't fixed yet, fixed in Hades: connman (CVE-2026-115863) and avahi (CVE-2025-59529).
Tested
With this image on my Ryzen 9 7950X3D: Dolby Vision 5, 7 FEL and 8.1, HDR10 and TrueHD Atmos with an LG C5 on both the RTX 4080 SUPER and the integrated Radeon, and HDR10+ plus a profile 7 FEL film sent as HDR10+ on a Samsung Odyssey OLED G6 from the 4080. Everything not tried yet is listed in the release notes.
If you have a GTX 900 or GTX 10 card, a 2016 LG OLED, an HDR10+ TV or Intel Arc B graphics, I'd especially like to hear how it goes.
Display Morehttps://github.com/CroqueMr/libre…/tag/R1.0.0-RC1
Repo will be updated later but release is up
R1.0.0 RC1 - Performance improvements, DV-to-HDR10+ and wider hardware support
Changes since Beta5.
Performance
Major AMD performance improvements, including Standard, Master Reference and conversion pipelines.
Reduced redundant rendering passes, surface imports and memory copies.
Improved FEL decoding, BL/EL scheduling and asynchronous frame preparation.
Optimized HDR10-to-Dolby Vision AI and Dolby Vision-to-HDR10 Basic/Expert.
Dedicated Profile 5 IPT paths: accurate processing in Master Reference and a lighter implementation in Standard.
Dolby Vision
Extended TV-Led V1 compatibility across Intel, AMD and NVIDIA.
Improved Standard and Master Reference resource management and presentation timing.
Added Master Reference IPT-PQc2 output, selectable in Expert settings; YCbCr remains the default.
Removed the Fast On/Off/Auto selector. Each rendering mode now uses its own fixed processing path.
Added optional automatic Master Reference → Standard recovery, disabled by default.
Added Disable L2 trims, disabled by default and limited to Standard and Master Reference.
HDR10+
Added native HDR10+ playback and Dolby Vision-to-HDR10+ conversion.
Added output paths for Intel, AMD and NVIDIA, including Pascal.
Added receiver V0/V1 handling and frame-associated dynamic metadata.
Improved output-depth validation, packet synchronization and HDR10+/HDR10/Dolby Vision/SDR transitions.
Added HDR10+ capability reporting in Kodi.
Native Kodi integration
Process video at source resolution before using Kodi’s native scaler and filters.
Preserve native zoom, view modes, picture placement, resolution whitelist and refresh-rate selection.
Keep native playback and fallback behavior outside active CB1 processing.
Playback and stability
Corrected chroma positioning and HDR10 Expert near-black handling.
Improved dual-layer MP4/MKV and dual-PID TS/M2TS detection, pairing and seeking.
Corrected startup timestamps, decoder replay and rendering-mode transitions.
Improved return to SDR after stopping playback or a failed start.
Corrected VAAPI import-cache sizing and surface retention, targeting FEL stalls reported with PGS subtitles.
Fixed mixed PGS subtitles and SDR GUI composition in Master Reference.
Fixed subtitles disappearing in black bars and missing scrolling notifications.
Hardware
Added NVIDIA GTX 10 / Pascal R580 support in the same image, with automatic matching of kernel drivers and libraries at boot.
Added AMD Radeon Vega M output support.
Improved Intel compatibility and Arc A/B firmware coverage.
Corrected NVIDIA PQ/HLG capability handling and deep-colour output validation.
Interface and diagnostics
Improved Player information, source/output reporting and skin compatibility.
Expanded bounded diagnostics for decoding, FEL pairing, output acceptance and HDMI failures.
Licensing
Migrated project-owned CB1 components and the L1/L3 AI model to GPL-2.0-or-later, with compatible replacements for affected helpers.
Third-party licenses remain unchanged. The selected FFmpeg/Kodi builds still carry GPLv3 requirements; the complete image is not GPLv2-only.
Known limitations
Intel N100/N150 and older AMD APUs, including Ryzen 3200U: heavy conversions and visible menus can exceed GPU capacity.
Intel Core 6th–9th generation and 10th-generation Comet Lake, using Display9: native HDMI HDR10/HLG/HDR10+ is not covered. This does not include 10th-generation Ice Lake.
NVIDIA GTX 10, GTX 16 and RTX 20/30 series: some HDMI-VIC, 3D or vendor-packet combinations prevent native HDR10/HLG signaling.
Next focuses
Bug fixing following new issues.
Avatar The Way of Water, Master Reference on the N100:
https://paste.libreelec.tv/absorptiometric-keely.log
Same movie on J5040, DV Standard:
