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

    I had this issue once and I never managed to reproduce it. Could you run all your file that not work properly and share the log file please :) for HDR10+ I am on it the pipeline does not work as expected and I do not have my HDR10+ screen to properly fix it.

    Quote from hadesdevls

    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.

    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.

    Yeah, but as I said, ETSI was already in my pipeline from the very first Kubuntu PoC, before LibreELEC and from R0.1.0. I added SMPTE and other standards starting with Beta 1. I do not communicate on norms because it is not interesting for users

    Honestly, I find it a bit ridiculous to see you replicate features just hours after my releases, even Vega M support, which I originally added for a close friend.

    You're free to maintain a separate build, but to me it's just duplicated effort, especially when you could benefit from all the AMD and Intel optimizations already done that your build does not have.

    Anyway, you're free to go your own way, but I'd always be happy to collaborate on the engine through PRs rather than duplicating the work.

    i am trying to test old hardware.

    hardware (hp prodesk 400 G1)

    i3-4160t, 8gb ddr3, video output is displayport (with active cable connected to hdmi of philips oled808). my philips tv is comparable with lg c2 or c3.

    issue: Libre-Elec says: no HDR display


    i guess my issue is displayport (converted to hdmi with active cable).... axagon rvd-hi14c2

    RVD-HI14C2 DP > HDMI cable 1.8 m, 4K/30Hz | AXAGON
    Active cable for connecting HDMI display to DisplayPort output. Support 4K/30Hz.
    www.axagon.eu


    EDIT: i have the same issue (non-HDR display) with Hades and CroqueMr builds. Ybold build not tested, but i guess same issue....either displaport or cpu could be the reason

    Exactly it is your DP output, It is not possible to have DV outside HDMI native port.

    and I need to check your CPU but I think support is not possible since your cpu do not have a hardware HEVC 10bit support.

    Quote from CroqueMr

    Yeah, but as I said, ETSI was already in my pipeline from the very first Kubuntu PoC, before LibreELEC and from R0.1.0. I added SMPTE and other standards starting with Beta 1. I do not communicate on norms because it is not interesting for users

    Honestly, I find it a bit ridiculous to see you replicate features just hours after my releases, even Vega M support, which I originally added for a close friend.

    You're free to maintain a separate build, but to me it's just duplicated effort, especially when you could benefit from all the AMD and Intel optimizations already done that your build does not have.

    Anyway, you're free to go your own way, but I'd always be happy to collaborate on the engine through PRs rather than duplicating the work.

    CroqueMr Fair enough on ETSI. To be clear, my list was what Hades does its own way, not a claim that your build doesn't follow the standards.

    I don't see it as copying, in either direction. Your Beta4 credited Hades for its NVIDIA support, and thank you for that. HDR10+ shipped in Hades first and then came to yours, written your own way. And Vega M on Hades started from your linux-9925, which I'm grateful for: our patch says so, and I'll add the credit to the release notes as well. The code is Hades' own, and it goes further, to Polaris and Vega 10, 12 and 20.

    I think we've been pushing each other forward, and not only the two of us: cinema-ONE with the 3D work for AMD and very thorough issues, Dangerouslaser with YBLOD's ideas and implementations (Dolby Vision for the menus in Hades comes from there), DMDreview's measurements of what licensed players send, which is why Hades now sends IPT, and everyone here reporting issues and suggestions, which is where much of each release comes from. The people testing both builds are the ones who come out ahead, and I'd like it to keep happening on purpose.

    So yes, let's do it through PRs, both ways. Next week I'll start sending some, beginning with fixes that apply to your build as well, and I'll gladly look at any of your optimizations that could help Hades, just as I hope Hades' work can help yours.

    Tested on RTX 3050 & Z390 ITX & i7 8600 = HLG & HDR & DV All Working

    The only issue I have is that I need to use the DisplayPort on the graphics card to connect to an AV receiver, so that the audio can be processed separately from the display. However, it seems that the system turn off all other ports whenever a display is connected via HDMI—even the HDMI ports on the Intel motherboard stop working.

    Direct connect to AVR not good for me limit 4K@30 not @50 or 60

    Quote from hadesdevls

    CroqueMr Fair enough on ETSI. To be clear, my list was what Hades does its own way, not a claim that your build doesn't follow the standards.

    I don't see it as copying, in either direction. Your Beta4 credited Hades for its NVIDIA support, and thank you for that. HDR10+ shipped in Hades first and then came to yours, written your own way. And Vega M on Hades started from your linux-9925, which I'm grateful for: our patch says so, and I'll add the credit to the release notes as well. The code is Hades' own, and it goes further, to Polaris and Vega 10, 12 and 20.

    I think we've been pushing each other forward, and not only the two of us: cinema-ONE with the 3D work for AMD and very thorough issues, Dangerouslaser with YBLOD's ideas and implementations (Dolby Vision for the menus in Hades comes from there), DMDreview's measurements of what licensed players send, which is why Hades now sends IPT, and everyone here reporting issues and suggestions, which is where much of each release comes from. The people testing both builds are the ones who come out ahead, and I'd like it to keep happening on purpose.

    So yes, let's do it through PRs, both ways. Next week I'll start sending some, beginning with fixes that apply to your build as well, and I'll gladly look at any of your optimizations that could help Hades, just as I hope Hades' work can help yours.

    Yeah I credit your Nvidia support because I took it from your build (and unfortatenly I redo this work to be in GPLv2 or later), the remaining part not. my backlog is public I always communicate on what I am working : HDR10+, Extended support ... and now stable build then LLDV and optimisation of the different precessing pipeline. I am in GPLv2 or Later licencing, I can not grab your code because you are on GPLv3

    I won’t be spending time pushing PRs to your build. The simplest and cleanest approach, from an architectural standpoint, would be for you to fork my build. That way, you could easily pull in all future updates, push PRs upstream, and integrate changes on your side.

    What you're proposing isn't really how this should work. The whole point is to maintain one central codebase and build on top of it. Maintaining two separate builds and duplicating the work makes no sense to me.

    But if you ever change your mind, I'd be more than happy to collaborate.

    Quote from CroqueMr

    Yeah I credit your Nvidia support because I took it from your build (and unfortatenly I redo this work to be in GPLv2 or later), the remaining part not. my backlog is public I always communicate on what I am working : HDR10+, Extended support ... and now stable build then LLDV and optimisation of the different precessing pipeline. I am in GPLv2 or Later licencing, I can not grab your code because you are on GPLv3

    I won’t be spending time pushing PRs to your build. The simplest and cleanest approach, from an architectural standpoint, would be for you to fork my build. That way, you could easily pull in all future updates, push PRs upstream, and integrate changes on your side.

    What you're proposing isn't really how this should work. The whole point is to maintain one central codebase and build on top of it. Maintaining two separate builds and duplicating the work makes no sense to me.

    But if you ever change your mind, I'd be more than happy to collaborate.

    CroqueMr Thanks for explaining, the licence part helps. In Hades, the Kodi code outside the Dolby Vision module is GPL-2.0-or-later, like Kodi itself; the module is GPL-3.0-or-later because it started from the dvbridge of your fork, which was GPLv3 when Hades took it, and Hades kept that licence. I'm happy to offer what Hades wrote under GPL-2.0-or-later as well, so you can take anything that's useful to you.

    I value the work you and everyone else here have put into this, and I'd appreciate the same respect for mine. Hades is the result of a great deal of work: its own implementations, written and tested before they ship, and shaped by the reports people send. Where an idea came from someone else, it says so. That's why it will stay a build of its own: it's what I run, and it exists for its security model (internal disks hidden, verified sources, a locked-down kernel), which reaches the whole system rather than the engine.

    That doesn't stop me from contributing to yours: I'll fork it and send PRs upstream where something fits your engine, starting next week. Different paths, same goal, and I'm glad to keep sharing the road.

    Appreciate both your builds, but to @ CroqueMr's point, how best to guide new users on key differences? Less focusing on the very technical or how, but practically what they may see or experience.

    Will be working on a new YT video shortly to draw awareness and socialize the great work here, but I'm unsure how best to position the two builds. That is, other than just saying try both and pick the one you like 😉. Maybe it's simple as that.

    Tried Chat and Gemini to get key distinctions, a summary, and I could get was start with CroqueMr's for lower-end hardware and conversion flexibility, and use hadesdevls for Dolby Vision-to-SDR mapping and compatibility advantage for some older Radeon GPUs. Did AI correctly call out the key differences?

    Release R1.0.0 RC1.1 YBLOD1 - YBLOD engines for Master Reference · dangerouslaser/intel-dv-libreelec
    R1.0.0 RC1.1 YBLOD1 - YBLOD's engines for Master Reference CroqueMr's R1.0.0 RC1.1 Debug with YBLOD's Dolby Vision engines added as alternative Master…
    github.com


    Build with Vulkan and OpenCL rendering engines - TV-Led / master reference mode only.

    AMD users should see performance improvements with this build using vulkan.

    The first time you play a video with vulkan the shaders need to compile.

    This is for testing only.

    Thanks a lot, I know what I’m going to have fun with :)


    Quote from ht2tweak

    Appreciate both your builds, but to @ CroqueMr's point, how best to guide new users on key differences? Less focusing on the very technical or how, but practically what they may see or experience.

    Will be working on a new YT video shortly to draw awareness and socialize the great work here, but I'm unsure how best to position the two builds. That is, other than just saying try both and pick the one you like 😉. Maybe it's simple as that.

    Tried Chat and Gemini to get key distinctions, a summary, and I could get was start with CroqueMr's for lower-end hardware and conversion flexibility, and use hadesdevls for Dolby Vision-to-SDR mapping and compatibility advantage for some older Radeon GPUs. Did AI correctly call out the key differences?

    Yes it's a good summary, on my engine we also have HDR to DV conversion with IA, Adaptative HDR mapping and DV to HDR10 with dolby vision processing including FEL rendering.


    Quote from hadesdevls

    CroqueMr Thanks for explaining, the licence part helps. In Hades, the Kodi code outside the Dolby Vision module is GPL-2.0-or-later, like Kodi itself; the module is GPL-3.0-or-later because it started from the dvbridge of your fork, which was GPLv3 when Hades took it, and Hades kept that licence. I'm happy to offer what Hades wrote under GPL-2.0-or-later as well, so you can take anything that's useful to you.

    I value the work you and everyone else here have put into this, and I'd appreciate the same respect for mine. Hades is the result of a great deal of work: its own implementations, written and tested before they ship, and shaped by the reports people send. Where an idea came from someone else, it says so. That's why it will stay a build of its own: it's what I run, and it exists for its security model (internal disks hidden, verified sources, a locked-down kernel), which reaches the whole system rather than the engine.

    That doesn't stop me from contributing to yours: I'll fork it and send PRs upstream where something fits your engine, starting next week. Different paths, same goal, and I'm glad to keep sharing the road.

    Of course, I respect your work. All effort even not perfectly coordinated is usefull, and I think everyone sees your contribution and your build philosophy and proposal. You have some really good ideas, like your Level 0/1/2 quality system. I don't really need it for my build since I don't compromise on quality in Master Reference mode.

    I'm considering bringing DV to other devices once my x86 build is stable and complete. On lower end hardware, these kinds of quality compromise are necessary to make things run smoothly, and we can clearly see that even official Dolby devices make them.

    I'll probably take inspiration from your approach and implement a similar adaptive system, but at the moment my priority is to finish the x86 build

    And again, I'd be more than happy to see you contribute!

    Quote from ht2tweak

    Appreciate both your builds, but to @ CroqueMr's point, how best to guide new users on key differences? Less focusing on the very technical or how, but practically what they may see or experience.

    Will be working on a new YT video shortly to draw awareness and socialize the great work here, but I'm unsure how best to position the two builds. That is, other than just saying try both and pick the one you like 😉. Maybe it's simple as that.

    Tried Chat and Gemini to get key distinctions, a summary, and I could get was start with CroqueMr's for lower-end hardware and conversion flexibility, and use hadesdevls for Dolby Vision-to-SDR mapping and compatibility advantage for some older Radeon GPUs. Did AI correctly call out the key differences?

    ht2tweak Thanks for doing a video on this. Both builds are good and worth trying, and since each runs from its own USB drive, people can boot one, then the other, and keep what suits their setup best.

    I have a lot of respect for CroqueMr and the work behind that build: it has its own engine and its own HDR10 analysis for conversions to Dolby Vision, and CroqueMr can describe its strengths better than anyone.

    On the Hades side, the AI got the SDR mapping and the older Radeons right, but it leaves most of it out. In practical terms:

    • Picture: Dolby Vision goes out the way licensed players send it (IPT, profiles 5, 7 with FEL or MEL, and 8), composed as the published Dolby Vision specification defines it. On graphics that can't keep up, it steps down only as far as it needs to, and the log says so.
    • Hardware: NVIDIA from the GTX 900 series on, AMD Radeon with DCN display hardware plus Polaris and Vega (those not tried on a TV yet), and Intel, down to modest machines: it has run on an Intel N100, a Core i3-1005G1 and Ryzen APUs, native Dolby Vision has started on a GeForce GT 1030 with driver 580 (4K FEL still needs work there), and FEL plays on the integrated graphics of a Ryzen 9 7950X3D, a Ryzen 7 5800H and a Core 5 255H.
    • Displays without Dolby Vision: Dolby Vision as HDR10 or HDR10+, HDR10+ passed through, and on SDR screens a reference mapping (BT.2390) of HDR10 and Dolby Vision.
    • Options: Dolby Vision Low-Latency (LLDV) for a TV input or a box that only takes that, adapted to the display by Hades and seen working on the integrated graphics of a Ryzen 9 7950X3D; HDR10 and HDR10+ as Dolby Vision; Dolby Vision for the menus; and Blu-ray 3D.
    • Installing it on your own PC: a Windows installer for a USB drive or a partition next to Windows, internal disks hidden by default, Samba off, a locked-down kernel, every source verified, and a diagnostics switch for when something doesn't work.

    In plain words, for your viewers: Hades aims to show Dolby Vision on a PC the way a licensed player would, on NVIDIA, AMD and Intel graphics, from big cards to small mini PCs, and to be safe to install on the computer you already use. And the best advice is the one you gave: try both. Every report, diagnostic and comparison that comes out of it helps both builds get better, and I hope we'll see more of the two working together soon.

    CroqueMr Thank you, that means a lot, and the same goes for your work. On quality, Hades doesn't compromise either: on graphics that keep up, every frame is the exact picture, bit for bit the reference. The levels only come in where a GPU can't draw a frame in time, where the alternative isn't the full picture but dropped frames, and even then, in test pictures, most of the pixels that change move by the smallest step of a 12-bit picture. Anyone who prefers the exact picture whatever happens can set the step-down to Never. I'm glad the idea may be useful to you, that's exactly how it should work, and the licence offer for what Hades wrote is now in its NOTICE.

    dangerouslaser YBLOD1 looks really interesting. Moving the engines to Vulkan and OpenCL is a big change, and if it gives AMD the headroom you expect, people on integrated graphics will feel it straight away. YBLOD has already given Hades some good ideas (Dolby Vision for the menus, and Dolby Vision starting sooner without losing its first pictures, both began there), so I'll be following this one closely, and I'd love to see the GPU times once people start testing it.

    Do any of these have the option to upgrade cmv2.9 to 4.0 as the custom coreelec builds? This is one of my favorite options as it fixes so many cmv2.9 issues, such as black crush. thank you

    Quote from CroqueMr

    I have some inside it's promising :) this might be the missing piece for LLDV on x86 on iGPU and Dolby vision on ARM port

    damn things are moving so fast! looking forward to your work :), wow I missed out the arm port, damn, this is going to be good. take your time and have fun