[x86-64] Dolby Vision Development for PC (Intel & AMD)

    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?

    Quote from gizmomelb

    I apologise for my confusion, but which is the latest version please - R0.2.1a-opt1 or R0.3.0?

    I have N5095, N100 and N150 mini PCs I can test on.

    The R0.3.0 is a pre-release with added features not perfectly stable (DV to HDR10 conversion, and Player Panel information). For testing R.0.3.0 will be better because of more precise log.

    Feel free to test it and report any issue and if possible with the kodi.log attached. I will investigate and fix it for my next release in a few days. ;)

    I will probably have my new NUC with N150 ready in a couple of days, looking forward to test your new build.

    I also have a ASRock N100 DC-ITX with 16GB DDR4 RAM that i could run tests with.

    Edited 2 times, last by MatteN (October 5, 2026 at 11:44 AM).

    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.

    Edited 3 times, last by CroqueMr (October 5, 2026 at 10:37 AM).

    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.

    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.

    Edited once, last by CroqueMr (October 5, 2026 at 8:50 PM).

    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

    Also my small finding when I compare a 226V and a 11390H : even if the GPU is far stronger on the 226V the rendering engine that handle all the workload is similar in term of performance.

    I will compare with a N100 and a N95, I think it is also similar. If it's the case, iGPU support will be wider than I expected and trying to improve the performance will not be as important as expected.

    Tomorrow I will perform a detailed benchmark with a N95/N100/11390H



    I am very happy to share the new build R1.0.0 Beta1 :) https://github.com/CroqueMr/libreelec-x86-DV/

    Curious to hear your feedback and see how the DV and HDR10 rendering modes perform.

    Maybe I should start a new dedicated thread to collect more feedback now that AMD is supported too (the AMD drivers are really in beta; I have a feeling there will be a lot of compatibility issues to fix).

    Known issues : Still having that frame drop issue on the N100/N150 on few DV profil 7 FEL

    cinemaONE Unfortunately, the repository is still under GPLv3. I will try to remove the GPLv3 components in an upcoming release.

    dangerouslaser Feel free to push any PRs I will test and merge as fast as possible :) unfortunately I can not edit the repo to fork LE

    Edited 3 times, last by CroqueMr (October 6, 2026 at 10:43 PM).

    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).

    Release yblod 0.2-pre1 — experimental dual-QSV P7 playback · dangerouslaser/libreelec-yblod
    yblod 0.2-pre1 — experimental Profile 7 dual-QSV playback Unofficial LibreELEC 13 Generic x86_64 testing build. This is a prerelease, not a stable upgrade or…
    github.com

    Edited once, last by dangerouslaser: Merged a post created by dangerouslaser into this post. (October 7, 2026 at 3:01 AM).

    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!

    Edited 7 times, last by CroqueMr (October 7, 2026 at 11:00 AM).

    yes - I was testing VA-API vs QSV for decoding - and while I was getting minor performance improvements with QSV vs VA-API the biggest improvements were from planar output and switching decoding and FEL upscaling to VA-API.

    If playback is smooth with just VA-API upscaling on an n100 then no need for QSV - was just trying to eek out every last bit I could!

    There is a branch with this in my repo - but essentially I got the best performance from:

    Movie + Dolby instructions
    │
    FFmpeg / QSV decodes both layers
    │
    Intel media engine scales the enhancement layer
    │
    Reconstruction engine combines the layers using Dolby instructions
    │
    Colour conversion + DV packing
    │
    HDMI -> TV performs final brightness/color mapping

    To reduce reliance on libplacebo, specialized reconstruction code:

    • Interprets the Dolby reconstruction instructions.
    • Reshapes the base-layer picture.
    • Turns enhancement-layer values into corrections and combining them with the base layer.
    • Handles color-sample positioning and filtering.
    • Passes GPU-held frames through reconstruction efficiently, including planar output that avoids unnecessary copying and repacking.

    The engine is written in C, with GPU shaders doing the pixel work.

    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)

    Quote from CroqueMr

    I am very happy to share the new build R1.0.0 Beta1 :) https://github.com/CroqueMr/libreelec-x86-DV/

    Tried it but curiously all DV and HDR related stuff appeared as "/unavailable" on my N100... on the same hardware that had everything working in release R0.3.0. So I can't even play test it.

    As a side note. I tried both dangerouslaser and R0.3.0 CroqueMr build on "Tron Ares" (a DV P7 highbitrate REMUX) and on both I get the same 1 frame drop per second. So it seems that lightweight file test or gigantic movie file size really don't matter.

    Quote from dangerouslaser

    I think that AMD cards can support vaapi via mesa - but I don't have an AMD card to test / confirm on. If we can confirm that works then we should be able to use one path for both playback paths.

    Yes AMD card support VAAPI, DV playing works great on my 7430U (just a small issue on Profile 5 but it is easy to fix), this is why I prefer to not use a 2nd path for Intel, and try to capitalize on optimization that benefit both Intel and AMD.

    I have some free time, so I’d like to integrate your changes as soon as possible while waiting for the fixes coming via the issues. If that works for you, I’ll go ahead and integrate your two major enhancements; it shouldn't take long, as I can see how to do it cleanly.


    Quote from w46n3r

    Tried it but curiously all DV and HDR related stuff appeared as "/unavailable" on my N100... on the same hardware that had everything working in release R0.3.0. So I can't even play test it.

    As a side note. I tried both dangerouslaser and R0.3.0 CroqueMr build on "Tron Ares" (a DV P7 highbitrate REMUX) and on both I get the same 1 frame drop per second. So it seems that lightweight file test or gigantic movie file size really don't matter.

    The issue on the frame dropping is almost fixed, the next release will address it.

    Could you send me the kodi.log file? I ramped up the fallback mechanisms so that even devices without DV support could use the build and play DV content via HDR10, I might have been a bit too aggressive with that.

    Quote from CroqueMr

    Yes AMD card support VAAPI, DV playing works great on my 7430U (just a small issue on Profile 5 but it is easy to fix), this is why I prefer to not use a 2nd path for Intel, and try to capitalize on optimization that benefit both Intel and AMD.

    I have some free time, so I’d like to integrate your changes as soon as possible while waiting for the fixes coming via the issues. If that works for you, I’ll go ahead and integrate your two major enhancements; it shouldn't take long, as I can see how to do it cleanly.


    The issue on the frame dropping is almost fixed, the next release will address it.

    Could you send me the kodi.log file? I ramped up the fallback mechanisms so that even devices without DV support could use the build and play DV content via HDR10, I might have been a bit too aggressive with that.

    Yes - you can integrate my changes!

    edit:

    One thing I have been trying to figure out is how we can scale the FEL layer with nearest neighbor. Based on my reading, that seems to be how the mediatek chipsets in the high-end UHD players scale the layer. Unfortunately neither vaapi or qsv has an out of the box nearest neighbor scaling option. It is possible to do it with the CPU - but then we lose the performance gains from offloading this upscale to the GPU.

    I am not entirely sure how much of a difference it actual makes but some people have complained about chroma and tearing issues when upscaling with bilinear etc.