Dolby Vision w/FEL + 3D for PC (AMD/Intel/nVidia)

  • The chroma is never taken to 4:4:4 for P and T; only the intensity uses an interpolated chroma value, so nothing has to be filtered back down.

    For each pair of pixels, from the composed picture:

    The 4:2:0 chroma goes to 4:2:2 vertically (the same 12-tap Lanczos step the YCbCr tunnel already does).
    P and T are computed at the even pixel, which sits on the 4:2:2 chroma sample: its own Y and that chroma, through the RPU's matrix to R'G'B', then linear light, LMS, PQ and IPT. No horizontal filter touches them.
    I is needed for both pixels. For the odd one, its chroma is interpolated horizontally with the same Lanczos, and only its I is kept.

    hadesdevls Thanks for the details and reference.

    Is that not identically equivalent to upsampling to 4:4:4, doing the conversion, and then dropping the odd chroma pixels rather doing standard chroma downsampling that first runs an anti-aliasing filter?

  • DMDreview Your investigation of 12-bit handling is excellent. Could you explain in more detail what you did? What does the test video consist of (ie what is in the BL and what in the EL). Presumably, both layers are 10-bit 4:2:0 YUV. Can you make those videos public, perhaps?

    You say DaVinci can't generate the necessary test file. Can you expand on that? It's what professionals use to make DV films with 12-bit precision so what can't it do?

    I suppose you are capturing the HDMI as IPT and feeding that into your custom software. Then for the colour gradient test converting that back to RGB for display?

  • I made a small hotfix in rc1.1 for those who had issues on HDR10+ and DV to HDR10 expert conversion.

    Hi! Since you mention just HDR10+ and DV to HDR10 conversions I think I can safely report even though I'm still running the first RC you released yesterday. EDIT: in the meantime I updated to rc1.1 and nothing changed.

    I am getting a strange effect when invoking either the menu or the stream play info (using O). Basically nothing appears and there's a tiny "miniature thumb" of the portion that should appear, in the bottom left corner. I show it in this picture I took with my phone. This happens when playing a HDR10 UHD Remux. Dolby Vision conversion happens but the menu and play info are shown like that. Also subtitles don't seem to be working (or are being displayed in that miniature thumb in the corner, quite likely). Dolby Vision native content does not exhibit this problem.

    I'm also experiencing something strange with a HDR10+ Remux, this is its MediaInfo video section:

    Format                                   : HEVC
    Format/Info                              : High Efficiency Video Coding
    Format profile                           : Main [email protected]@High
    HDR format                               : SMPTE ST 2094 App 4, Version 1, HDR10+ Profile B compatible
    Codec ID                                 : V_MPEGH/ISO/HEVC
    Duration                                 : 2 h 19 min
    Bit rate                                 : 56.4 Mb/s
    Width                                    : 3 840 pixels
    Height                                   : 2 160 pixels
    Display aspect ratio                     : 16:9
    Frame rate mode                          : Constant
    Frame rate                               : 23.976 (24000/1001) FPS
    Color space                              : YUV
    Chroma subsampling                       : 4:2:0 (Type 2)
    Bit depth                                : 10 bits
    Bits/(Pixel*Frame)                       : 0.284
    Stream size                              : 55.0 GiB (91%)
    Default                                  : Yes
    Forced                                   : No
    Color range                              : Limited
    Color primaries                          : BT.2020
    Transfer characteristics                 : PQ
    Matrix coefficients                      : BT.2020 non-constant
    Mastering display color primaries        : BT.2020
    Mastering display luminance              : min: 0.0001 cd/m2, max: 1000 cd/m2
    Maximum Content Light Level              : 1000 cd/m2
    Maximum Frame-Average Light Level        : 400 cd/m2

    What I see happening is the picture constantly switching "on and off", intermittently. It doesn't appear to follow a specific time interval, let's say every few seconds. The TV loses the signal and then locks onto it once more, on and off.

    No conversion happens on this file, the TV is receiving a regular HDR10 stream (it's a LG C1, so not HDR10+ compatible). On an Ugoos AM6B+, using p3i T4c build, the movie is detected as HDR10+ and converted to Dolby Vision without problems.

    The system I'm testing this on is a NUC 11 with an i3 processor and 16GB of dual channel RAM.

    An extra, general, question: why is it that the rendering load appears higher on DV Profile 8 than on DV Profile 7 with FEL? Over 80% with Profile 8, around 50% with Profile 7 FEL, as measured by your "O" overlay.

  • CroqueMr

    Hi, Just wanted to share some really great feedback after spending more time with R1.0.0 RC1.1.

    Honestly, this is by far the best experience I've had with your build!

    I've been testing several movies, including some that were particularly demanding in previous releases, and the results have been fantastic.

    Gemini Man (4K 60fps Dolby Vision FEL) was always one of my toughest tests, with dropped frames in earlier builds. But for the first time, I'm now seeing no dropped frames during my playback tests! That's a huge improvement!

    I also tested Billy Lynn's Long Halftime Walk (4K 60fps HDR10), and it played beautifully without any dropped frames either.

    And it's not just these two movies. I've tested several other titles as well, and so far, playback has been incredibly smooth across everything I've tried.

    The picture quality on my LG G6 is absolutely gorgeous. Dolby Vision FEL looks fantastic, HDR10 looks excellent too, and I'm really impressed with the overall presentation.

    Another thing I've noticed is how fast and responsive Kodi feels. Navigating through menus, browsing my movie library, and switching between different sections is noticeably smoother and quicker. The whole system feels much more polished now.

    What makes this release special for me is the combination of excellent picture quality, smooth playback, and overall system responsiveness. It's exactly the kind of experience I've been hoping for since I first started testing your builds.

    So far, RC1.1 has been running beautifully without a single issue in my testing. I'm really enjoying RC1.1, and it's been an absolute pleasure using it for my everyday movie watching!

    I'll continue using it and report back if I notice anything unusual, but right now, I just wanted to share some positive feedback because I think you really deserve it.

    Thank you so much, CroqueMr, for your dedication, patience, and all the hard work you've put into this project. The progress has been incredible, and it's genuinely a pleasure to use your build every day.

    Fantastic work, my friend! 🌹👏

  • not surprised it's smoother


    CPU: Intel Core i9-13900K

    • GPU: NVIDIA RTX 5090


    damn you threw the whole kitchen at this. your hardware wouldn't even notice the GPU work for this. it's good to see Kodi is not restricted anymore. this will attract allot more to x86 and maybe more development as a result and plus 1 to what Vertox wrote. CroqueMr work has put him in legendary status.

  • not surprised it's smoother


    CPU: Intel Core i9-13900K

    • GPU: NVIDIA RTX 5090


    damn you threw the whole kitchen at this. your hardware wouldn't even notice the GPU work for this. it's good to see Kodi is not restricted anymore. this will attract allot more to x86 and maybe more development as a result and plus 1 to what Vertox wrote. CroqueMr work has put him in legendary status.

    Haha, thanks for the kind words! 😄

    Just a small clarification: my testing of RC1.1, including Gemini Man 4K 60fps Dolby Vision FEL and Billy Lynn's Long Halftime Walk 4K 60fps HDR10, was actually done on my ASUS Mini PC with an Intel Core i7-1360P and integrated Iris Xe graphics, not the RTX 5090!

    That's what makes the results even more impressive to me. Seeing such smooth playback without dropped frames on integrated graphics really shows how much progress CroqueMr has made with this build.

    I completely agree with you. His work is truly amazing, and he deserves all the recognition he's getting! 🌹👏

  • Thank you for the work being done here.

    So, what's the best mini PC to get if money really isn't a problem? I don't care if it's overkill; I just want the best hardware to run those builds.

  • Thank you for the work being done here.

    So, what's the best mini PC to get if money really isn't a problem? I don't care if it's overkill; I just want the best hardware to run those builds.

    anything past AMD Ryzen 3500U will meet requirements of running it. getting a more powerful system won't improve image, just give you a faster experience on kodi, but there comes a point of diminishing returns. I think look out gor a gmktek k12 in aliexpress sales on 11.11. most likely barebones and just add your own ram and ssd. some great deals will come up.
    go on a deal site like slickdeals (usa) hotukdeals (uk).

    should be able to get a beast of a system for $350. more power than you know what to do with.

  • Thanks for checking. It is still worth it, and not only for your card: that presenting a frame ahead hurt instead of helping on a GTX 10 card with driver 580 has nothing to do with memory bandwidth, and it likely affects other modest NVIDIA cards too. A diagnostic will show why.

    If you have a moment with RC5: switch the diagnostic on, play the same high bitrate file for a minute with Present frames a frame ahead on its default, then another minute with it on Never, and attach the hades-diag folder. The log measures every late frame both ways, which is exactly what I need to fix it.

    Diagnostics attached. Just an FYI before I did anything, I first defaulted the display settings in system. 1st playback is with defaults, and 2nd is with NEVER on the frame ahead setting. Let me know if you have any questions or want me to run any other tests. Thanks!

  • A question for both devs, CroqueMr and hadesdevls: I am currently testing on the aforementioned hardware (NUC 11 i3) and the machine is not "in production" (I'm keeping my Ugoos as daily driver until I have a rocks solid alternative in the NUC).

    If I want to switch between your two versions, to check both them out... do I have to start from scratch every time I switch? I hope not as that would require an inordinate amount of wasted time and I have a single machine to test them on.

    Or can I simply place your release in .update and reboot?

  • you say DaVinci can't generate the necessary test file. Can you expand on that? It's what professionals use to make DV films with 12-bit precision so what can't it do?

    I'm not sure what he meant, but Resolve can definitely work with and output 12-bit 4:4:4(prores) or RGB(jpeg2000).

  • hadesdevls Thanks for the details and reference.

    Is that not identically equivalent to upsampling to 4:4:4, doing the conversion, and then dropping the odd chroma pixels rather doing standard chroma downsampling that first runs an anti-aliasing filter?

    doppingkoala Yes. Converting at 4:4:4 and keeping the even P and T gives the same numbers, because the Lanczos interpolation passes through the co-sited samples: it is a drop, with no anti-alias filter. That filter is there for chroma that had full resolution before it was subsampled, and this never had it: the stream's chroma is 4:2:0, so above the 4:2:2 grid P and T only move where the luma changes under a coloured area, through the nonlinear steps (PQ and back). A filter would take some of that out, and it would also mix the exact co-sited value with one built from interpolated chroma. Which of the two a TV rebuilds closer depends on how it upsamples, and I haven't measured that, so I'll run both against the full 4:4:4 conversion, with a TV-style upsampling, and post the numbers. The co-sited choice is also what YBLOD reports from licensed Amlogic players.

    Diagnostics attached. Just an FYI before I did anything, I first defaulted the display settings in system. 1st playback is with defaults, and 2nd is with NEVER on the frame ahead setting. Let me know if you have any questions or want me to run any other tests. Thanks!

    ApexAftermath Thanks, this is exactly what was needed, and it changes the diagnosis.

    • Presenting a frame ahead never ran on your card, in either run. Right after the first one the log says the output has no third buffer, and from then on every frame is presented the way that waits. The reason is in NVIDIA's GBM layer (egl-gbm), which Kodi draws through on NVIDIA: each surface sits on an EGL stream with a queue of two, the buffer on the screen and the one just committed, so there is never a third one to draw the next frame in. So the setting couldn't change anything, and what I read as the frame ahead hurting wasn't the setting.
    • Your GT 1030 needs 46 to 49 ms of GPU time for a 4K P7 FEL frame at full fidelity, and 35 to 38 ms at the lowest step-down level, against 41.7 ms per refresh at 23.976 Hz. Without that third buffer a frame waits for the next refresh after it's drawn, and the next one only starts after that, so most frames take two refreshes: about 100 reach the screen every 10 s, of the 240 of the film.
    • A few enhancement-layer pictures also fail to import (enhancement-dmabuf-import drm-prime-map in the log), each one a frame without its FEL residual.

    The third buffer is what would make the difference on your card: with it, a 35 ms frame is drawn while the one before it is on the screen. That's what I'm looking into now, together with those imports.

    ashlar For switching, the easy way is a drive for each build: Hades starts from a USB drive just as it does from an internal disk (the Windows installer writes one), so switching is choosing which drive to boot, and each one keeps its own settings and add-ons.

    .update replaces the kernel and the system, but not the boot files, so it doesn't make a clean switch either way:

    • Hades placed in .update on another build starts, but with that build's boot menu, so what Hades sets up when it's installed isn't there: its boot entries (such as the one that keeps the internal disks hidden when it starts from USB) and the diagnostics switch.
    • Another build placed in .update on Hades is refused on purpose, because it would quietly drop Hades' features. Forcing it with .nocompat would start that build with Hades' boot menu, which I haven't tested and wouldn't recommend.
  • ashlar For switching, the easy way is a drive for each build: Hades starts from a USB drive just as it does from an internal disk (the Windows installer writes one), so switching is choosing which drive to boot, and each one keeps its own settings and add-ons.

    Hmmm... ok. Thank you. Not the answer I was hoping for (and it reinforces my initial idea that having two different development paths would have been bad for testing) but let's see if I can work around it. Is there a way for me to have a USB key having the "full install"? Normally you use the Windows tool (but I have access to a Linux machine too) to create the USB key which installs on the internal disk. Is there a way to have the tool write to a different key? Like, I boot from an hades key built with Libre-ELEC USB-SD Creator, while having a second usb key in a different port. Does the installer allow me to select the second key as the install disk?

  • I'm not sure what he meant, but Resolve can definitely work with and output 12-bit 4:4:4(prores) or RGB(jpeg2000).

    Quite. What I have found though is if you capture IPT and load that into Resolve as if it was YUV Resolve can't give you the proper pixel values because so many fall outside the RGB colour cube when it converts to RGB. Maybe that's what he's referring to?

  • Hmmm... ok. Thank you. Not the answer I was hoping for (and it reinforces my initial idea that having two different development paths would have been bad for testing) but let's see if I can work around it. Is there a way for me to have a USB key having the "full install"? Normally you use the Windows tool (but I have access to a Linux machine too) to create the USB key which installs on the internal disk. Is there a way to have the tool write to a different key? Like, I boot from an hades key built with Libre-ELEC USB-SD Creator, while having a second usb key in a different port. Does the installer allow me to select the second key as the install disk?

    ashlar Yes, and you don't even need the second key: the key you write is already a full install. Started with "run", which is the default entry of its boot menu, Hades runs from the key itself, with its own storage partition for settings, add-ons and library. Installing to the internal disk is just one option in that menu, not something it has to do.

    That's how I use it myself: my build runs from an external USB-C SSD, started with run, and it's easy to keep up to date. LibreELEC-Hades-Installer.exe has an option to update a drive that already has Hades: it replaces only the system and keeps everything else. From your Linux machine you can do the same by putting the release's .tar in the .update folder of the key's storage partition and booting it.

    So a key for each build works well: one for Hades, one for CroqueMr's, and switching is just choosing which one to boot. A fast key or a small USB SSD makes it feel like an internal install.

  • ApexAftermath Thanks, this is exactly what was needed, and it changes the diagnosis.

    The third buffer is what would make the difference on your card: with it, a 35 ms frame is drawn while the one before it is on the screen. That's what I'm looking into now, together with those imports.

    Am I correct in assuming that changing this buffer setting in the menu from 2 to 3 either has nothing to do with this, or won't do anything unless changes are made in the back end?

  • Hmmm... ok. Thank you. Not the answer I was hoping for (and it reinforces my initial idea that having two different development paths would have been bad for testing) but let's see if I can work around it. Is there a way for me to have a USB key having the "full install"? Normally you use the Windows tool (but I have access to a Linux machine too) to create the USB key which installs on the internal disk. Is there a way to have the tool write to a different key? Like, I boot from an hades key built with Libre-ELEC USB-SD Creator, while having a second usb key in a different port. Does the installer allow me to select the second key as the install disk?

    I can only encourage this approach. I've encouraged Hades to submit PRs to improve the engine and fork it to had his security features, but he seems to prefer replicating the features I've implemented in his own build instead. I personally don't really get it. It only creates confusion for users and duplicate work.

    It will be my pleasure to review PRs from Hades and propose a shared build to everyone with all optimization and DV coverage possible

  • Am I correct in assuming that changing this buffer setting in the menu from 2 to 3 either has nothing to do with this, or won't do anything unless changes are made in the back end?

    ApexAftermath Right, it won't help, so leave it as it is. On this kind of system Kodi doesn't make buffers from that setting: it only uses it to estimate how late the picture reaches the screen, for audio sync, so changing it would at most shift the sound. The buffers that matter here are made by NVIDIA's GBM layer, and that's where the change has to happen.

    I can only encourage this approach. I've encouraged Hades to submit PRs to improve the engine and fork it to had his security features, but he seems to prefer replicating the features I've implemented in his own build instead. I personally don't really get it. It only creates confusion for users and duplicate work.

    CroqueMr Thank you, first of all, for starting this. Hades exists because your fork showed it could be done on a PC, and the README says so, along with what came from it.

    It has never been my intention to push anyone's work aside. I've been grateful to everyone who has moved this forward, starting with you, and I've always given credit. I've put the effort into my own implementations and my own tests, and I've never talked down your build or anyone else's, or called one better and another outdated: I've cheered every step forward, whoever made it.

    I'd genuinely like to work together. Ideas have already gone both ways, which is how it should be: NVIDIA and HDR10+ are in both builds now, and Hades has taken things from yours and credited them. To me that isn't duplicate work, it's two builds getting better from each other. I wanted to add my own grain of sand too, and some of what Hades does sits underneath the engine rather than on top of it: the composer as ETSI GS CCM 001 defines it, the output inside the NVIDIA, AMD and Intel kernel drivers, a base built only from pinned and verified sources, and the safe defaults. That's why it became a build of its own rather than a set of PRs.

    I don't see why two builds should be a problem. CoreELEC has had several side by side, and people have always enjoyed trying each one and watching them move forward. If you're open to it, I'd be glad to share measurements, test clips and fixes both ways, so both builds come out better.