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.
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:
https://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
Wow, RC1 is finally here! 😄
Thanks a lot, CroqueMr, for all the hard work you've put into this project. Really appreciate the time and effort you've spent improving things and listening to everyone's feedback.
I'm really looking forward to trying RC1, especially the FEL improvements and the playback fixes. I'll be testing your new build and sharing my feedback if I come across anything.
Great work as always, and thanks again for keeping this project moving forward.👍
Great work CroqueMr and hadesdevls
Just want to be sure I understand things correctly. Neither build currently supports HDR10+ ----> Dolby Vision conversion. Correct? As an LG TV owner I'm interested in that. Not that much content has HDR10+ and no DV but some exists.
Pc vs Oppo, Dune HD, CEAM S922x. FEL and 12 bit.
In case anyone is interested in taking a look.
Thanks CroqueMr and hadesdevls for your awesome work on that. One thing that seems to fail on both releases is bluetooth connecting and disconneting all the time. My Nvidia SHIELD 2019 Remote works without configuring or remap anything which is great but it disconnet and connect, my bet is, old drivers, I can provide logs.
I see some regression for some people on my build, very strange I do not have that in my test hardware. I will try to fix that quickly
