[x86-64][dangerouslaser Builds] Dolby Vision w/Vulkan Engine Builds

dangerouslaser, just tested on my N150. Nice implementing player process info.:

With the scaling options you added, I'm not seeing any difference in performance subjectively. In terms of GPU load, didn't check. Tried off, Enhancement, and Enhancement and color:

Feel like you or CroqueMr can solve the frame drops issue on lower-end Intel like N150/N150. It's weird. With 'Saving Private Ryan' DV P7, none, and it's playing well:

And fine with 'Alien' DV P7 as well:

But, with '1917' DV P7 about 1 drop every second... wonder why? Because of its higher bitrate?

Enabling 'Enhancement' or 'Enhancement and color' didn't help w/frame drops.

Quote from dangerouslaser

A new build to test.

libreelec-yblod

• CroqueMr's Intel Dolby Vision engine (CroqueMr/intel-dv-libreelec) : Standard (TV-led) Dolby Vision output from Kodi's own player, including Profile 7 FEL, on supported Intel GPUs.
• Video output calibrated to licensed Dolby hardware: IPT tunnel signal like Dolby players, a chroma siting fix, co-sited 4:2:2 packing and Gaussian chroma upsampling.
• Quick Sync enhancement-layer offload: Profile 7 FEL playback scales the enhancement layer on the Intel media engine (Quick Sync, via VA-API) instead of in shaders. On an i5-1135G7 this cut GPU render load during FEL playback from about 46% to about 12%, with no dropped frames, and the HDMI output stays within about one 12-bit code of the shader path. It is aimed at making FEL playable on smaller Intel GPUs. It can be switched off, and falls back to the shader path automatically when the media engine or driver can't do it.
• Seamless refresh rate changes (QMS-VRR): on TVs with HDMI 2.1 Quick Media Switching, a change between 24, 25, 30, 50 and 60 Hz (and 23.976, 29.97, 59.94) no longer blanks the screen.
• Dolby Vision menu (optional): the menu is sent in Dolby Vision too, so a Dolby Vision film starts without the TV switching picture format. With QMS, starting and stopping a Dolby Vision film causes no blackout at all.
• And more......

https://github.com/dangerouslaser/libreelec-yblod

I really don’t understand the point of your release... If you see things that need fixing or improving, just open PRs.

This approach is clearly counterproductive. I had already mentioned that my internal build has been completely reworked, with a dedicated Dolby Vision engine, support for more GPUs, and many new features.

You’re basically going to have to redo a large part of your work, while also creating unnecessary confusion by maintaining another build that essentially does the same thing.

It’s extremely frustrating to see someone working on a project you created without communicating what they’re doing, and then suddenly releasing something that directly overlaps with and interferes with your own work.

Quote from ht2tweak

dangerouslaser, just tested on my N150. Nice implementing player process info.:

With the scaling options you added, I'm not seeing any difference in performance subjectively. In terms of GPU load, didn't check. Tried off, Enhancement, and Enhancement and color:

Feel like you or CroqueMr can solve the frame drops issue on lower-end Intel like N150/N150. It's weird. With 'Saving Private Ryan' DV P7, none, and it's playing well:

And fine with 'Alien' DV P7 as well:

But, with '1917' DV P7 about 1 drop every second... wonder why? Because of its higher bitrate?

Enabling 'Enhancement' or 'Enhancement and color' didn't help w/frame drops.

Display More

Player process info came from my build
I have a N100 I will test your file on it, but I think the issue came from your file it will be complicated to fixed it without it.

Appreciate dangerouslaser's efforts, but agree w/you CroqueMr, that instead of having forks, better to collaborate on what you started.

dangerouslaser I’m not pushing commits to my repo? I pushed both of your commits once I had reviewed and tested them in 24h

The only one I haven’t merged is your RPs to move to Kodi 22RC1 ahead of your other PRs. You’ll understand that a change like that takes more than a day to properly test, especially with all the required regression testing.

In any case, I really don’t have to justify myself here.

Regarding your repo, this part “Video output calibrated to licensed Dolby hardware” is clearly not aligned with my approach. it raises legal questions, and beyond that, the approach is technically ugly. At the end of the chain, you're essentially tuning the output to make it look as close as possible to an Ugoos AM9, without really understanding why your rendering diverges from it in the first place.

That's fundamentally different from what I'm trying to achieve, you're right it is open source, and it's your right to create confusion and to be conterproductive.

This will be my last message on this. I’ll continue working on my project and simply ignore approaches that don’t align with mine.

Quote from dangerouslaser

CroqueMr Lets just set a few things straight here:

1) You described this as a project you created, but neither of us is doing anything novel. We're both building on other people's research.
2) I did open PRs, as you suggested. You merged two, which I appreciate. The RC1 one is still pending, and fair enough on wanting regression testing there. FWIW my build tracks the latest LibreELEC main and playback has been solid so far, if that's useful data.
3) You said my build "directly overlaps with and interferes with" yours, but the reworked build you described hasn't been published. I can't coordinate around code I can't see. What specifically is it interfering with?

What overlaps:

• RC1: I merged it once my DV engine had been completely reworked. I also extracted the engine from my Kodi-specific code so it can be reused more easily on other platforms/OS. This should make it much easier to port the same changes to something like MPV, for example.
• Architecture: Most of the implementation in my initial branch was honestly quite sketchy and heavily vibe-coded. It was meant as a POC, not as a reliable or maintainable architecture, so a lot of it has now been rebuilt properly.
• QMS-VRR: As you can see, I’m also working on QMS/VRR in parallel.

I do most of my development locally because it’s simply easier for me. I don’t push every single modification directly to the repo. I now push changes only once the regression tests have been completed and the full image has been rebuilt and validated, which can take several hours after every major modification. (GPT Astra worked 12h only on non-regression testing for the DV engine rebuild and code reduction)

Yes, I could have pushed an intermediate version containing some of the changes that were already ready, such as the rebuilt DV engine with a dedicated API, or the beta AMD drivers or some HDR10 to DV conversion algorythms. I didn’t, simply because I had no idea someone else was actively working on the exact same project at the same time.q

The simplest approach would have been to say that you also wanted to work on the project, and we could have agreed on a workflow that was beneficial for everyone. Instead, we now have quite a lot of duplicated work, which is a shame and could easily have been avoided.

The next step on my side : I’ll push my internal build earlier, most likely tonight, so you can have full visibility on the code. If you want, you’re of course free to submit PRs or continue working in a separate repo.

In any case, in my repo, I’ll remain strict about testing. Every PR needs to be tested end to end, including proper non regression testing, if you don't know how to do it properly no worries I can take in charge this part when you submit a PR. I don’t want quick and dirty patches.

Quote from dangerouslaser

More than willing to work with you directly on this. We can probably make some changes to both of our workflows so that collaboration is easier.

I typically use branches for features which are PR'ed to main after testing - and have master set to track upstream so that keeping main up to date is easier without having to rebase. If the goal is to target LE 13, I would set master to track the LE 13 branch once it is published.

CI can be setup for PRs to main so that broken features aren't merged - and if you need to offload builds for quicker testing I have a server with an i9-14900k that can build kodi from source in minutes.

Perfect if we can find a good way to work

Don't worries about hardware I have a 9950X3D + 5090 + 96Gb RAM, I’m currently doing the final merge of all macro feature. It’s taking longer than expected, so the code may only be ready tomorrow if GPT behaves tonight

The time-consuming part isn’t really compilation itself, it’s running the full end to end test suite and making sure there are no regressions across the different playback and conversion paths.

At a high level, the next release will be stable, but some features might not work as expected since I won't have time to complete functional testing beforehand. I'd rather make the code available to you earlier and I'll run the tests in parallel. It will effectively be a pre-release, and I'm going to fork LE.

What will be the changelog :

Technical :

• Merge with Kodi 22 rc1
• Rebuild of the repo with the Dolby Vision processing logic is now separated from the playback layer, making it easier to reuse, test, evolve independently and with a dedicated API.

Rendering option for Dolby Vision input

• DV Native - standard Dolby Vision playback while preserving the original intent and metadata.
• DV Enhanced - dynamically adjusts the existing Dolby Vision metadata to better exploit the display’s peak brightness. The goal is to extend highlights and overall dynamic range in a controlled way, while preserving black levels and shadow detail rather than simply stretching the image and crushing the lower end.
• HDR10 Basic / Expert - conversion from Dolby Vision to HDR10, with an Expert mode using additional display characteristics such as peak brightness and use all DV metadata to dynamically tone map the picture into an HDR10 output for non compatible DV display
• HDR10 Fallback - standard Kodi / vanilla HDR10 path.

Rendering option for HDR10 input

• DV Reconstructed (AI) - reconstructs Dolby Vision metadata from the HDR10 source using image analysis and AI (I trained a small LightGBM ML model to reproduce L1 & L3 metadata it should be better than the VS10 conversion from dolby, the model is very small and fit in any CPU)
• DV Enhanced - reconstructs a Dolby Vision representation and then applies the same controlled metadata enhancement, extending the usable dynamic range while preserving blacks and shadow detail.
• HDR10 Native - untouched/native HDR10 playback.

Quick switch rendering settings : playback panel that lets you switch between the different output modes while the video is playing, so you can compare the rendering directly on the same scene. (This feature is actually blocking the build, it's VERY complicated to be able to switch on the fly the rendering path without any instability)

Drivers:

• Intel : Extended support for older iGPU
• AMD : First version of AMD DV Driver

Once everything is merged and published, I’ll mainly focus on

1- Fixing and refining the conversion algorithms, especially DV Enhanced, which is by far the most complexe rendering path since I use all metadata and it's personally the feature I’m most interested in. And DV -> HDR10 Expert conversion is also very complex I will investigate deeply into it after the pre-release push.

2- Start an optimization audit for the 7430U

3- Start an optimization audit for N100 and N95 (I have both CPU) and try to finally fix the frame drop seen on DV 7 FEL. Since you will receive a N100 I will prioritze the support of AMD driver, and I will stop the implementation of the VRR-QMS with DV interface rendering.

I think your improvements to the processing pipeline will be very welcome and should also help us support a wider range of hardware, but non-regression test will be huge to include that properly, push your PR I will applied my testing framework and protocol.

i tested short time ybold build.

my cpu is i5-12400, with igpu uhd 730.

when i enable QUCK SYNC, inside O i see gpu kodi around 30-35%.

disabling QUICK SYNC gpu is around 75%.

gui resolution is set to 4k

menu set as DoVi

just my findings

Quote from dangerouslaser

Congrats

I am working on some improvements for intel hardware - specifically for playing high bitrate L7. I have made a lot of progress - I will take a look at your code and see if a PR is possible against your updated codebase without requiring too many changes!

---

If folks with n100/n150's can test P7/FEL playback of high-bitrate files (1917 seems to be one that gives some people trouble) with this and report their findings it would be much appreciated. You can just drop the .tar in /storage/.update/ and roll back to CroqueMr's build when you are done.

This build uses Intel QSV to decode both layers and upscale the EL. It is far more efficient on my testing machine - but I am still waiting for the ali express guy to drop off the n150 box I ordered.

If it is working as it should, I will start to shape a PR into CroqueMr's repo. It will take a bit of time though I will need to refactor to match his updated playback pipeline(s).

https://github.com/dangerouslaser…/yblod-0.2-pre1

Display More

Nice I have a N100 I will give a try

Edit : Unfortunately all my Remux Profile 7 FEL do not start at all on your build, I do not have this issue on more compact profile 7 FEL that was working smoothly before.

I did a deeper audit while benchmarking the issue on the N100, and the results are quite strange.

First, the rendering engine is clearly not saturated, and increasing the GPU frequency does not reduce the issue. That’s why I initially thought this wasn’t a performance bottleneck.

However, when testing with a more compact file that puts roughly the same load on the rendering engine, the problem disappears completely.

So I think we may be looking in the wrong place. The rendering stage itself doesn’t seem to be the bottleneck. I will try the opposite : reduce some waiting time and start to prepare the next frame as soon as possible, the rendering engine workload will increase I will see if it reduce/remove the probleme

Edit 2 : Yes, the problem is fixed with the N100 : reducing the wait time was the solution. There are no more regular frame drops every 70 seconds on Profile 7 FEL remux, but it create another issue :

I render the next frame asynchronously while the previous frame is displayed over HDMI, but the rendering engine workload rises to 95% and causes some rare and irregular frame drops. Now we are definitely hitting the limits of the N100, so your dangerouslaser optimizations will be very useful. The N100 without optimisation is very close to perfectly read every DV files we just need an optimisation of 5 or 10%

I took a closer look at the optimizations and your tests. Switching decoding from VAAPI to QSV doesn’t seem to bring meaningful performance gains in your measurements, while adding complexity. Both APIs ultimately use the same Intel hardware decoding blocks, so that makes sense.

However, two optimizations look very promising: VAAPI based FEL upscaling and the planar output

dangerouslaser I can integrate those changes with full credit to you, of course, or you’re welcome to submit a PR. Whichever you prefer!

Thanks for the precision, that’s what I was seeing as well.

What mainly bothers me about bypassing VAAPI is that we then have to maintain a separate Intel path, whereas AMD is now supported too.

So, do you want me to handle the integration of the two significant upgrades into the build (VAAPI FEL upscaling & planar output), or would you rather take care of it yourself?

dangerouslaser I can confirm VA-API on AMD: RX 7600 (Navi 33) on LibreELEC 13 with Mesa 26.2.3 (radeonsi). vainfo lists HEVC Main/Main10 and AV1 decode plus VideoProc, and Kodi plays 4K HDR10 HEVC through ff-hevc-vaapi. I haven't tried a Dolby Vision path on top of it, so I can't say how the FEL steps behave there.

Prepared with Claude Code (Anthropic)