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

    Quote from CroqueMr

    Nice we can continue our discussion here :) I sent you a mail but I will past my answer here also :


    I use YCbCr inside the RGB 8bit tunnel to avoid unnecessary conversions and rounding and help small GPUs. I send the matching YCbCr to RGB and RGB to LMS matrices for the TV to handle the conversion in TV-Led mode, following ETSI specs

    For your comparison, do you need IPT PQ c2 inside the RGB tunnel, like the earlier Yblod build? Just tell me what output and tunnel format you need, I can adapt the Master Reference circuit to match your need. Other circuits deliberately modify the signal and aren’t intended as exact references and I think do not deserved to be deeply analyzed

    CroqueMr Similarly, I assume that to maximise quality and efficiency that profile 5 content is using the native IPT PQ c2 and not being converted to YCbCr?

    Quote from cinemaONE

    CroqueMr a pointer for elstr's vertical shift question, in case it saves you time: in Kodi a vertical shift between -1 and 1 only moves the picture inside the black bars Kodi itself adds (see the comment in CBaseRenderer::CalcDestRect). Each eye of a 3D Blu-ray is a full 1920x1080 frame with the letterbox inside the picture, so there are no Kodi bars and that range does nothing. Values beyond ±1 should still move the whole picture towards the screen edge. Upstream Kodi behaves the same, and so does a 2D file with baked-in bars. If values beyond ±1 do nothing in 3D either, that part would be a real 3D issue.

    You're right, 1.13 vertical shift working in 3d. Doesn't seem to do anything when playing DV at this stage.

    Quote from doppingkoala

    CroqueMr Similarly, I assume that to maximise quality and efficiency that profile 5 content is using the native IPT PQ c2 and not being converted to YCbCr?

    I don't have Profile 5 IPT passthrough yet, a dedicated circuit for Profile 5 is planned for the next engine update. I pooled as many engine components as possible, so I process everything in YCbCr. I tested a side circuit doing direct Profile 5 vs converted to YCbCr, and the differences were imperceptible. But it's definitely planned to skip this conversion for Profile 5 in the stable release, which can be avoided even though in reality it involves almost no loss in quality. (this will only be skipped for Master reference & Standard circuit)

    Quote from ht2tweak

    Yes, on my N150 as well, but getting slight lip synch audio issue w/DV Master. Tested w/'Saving Private Ryan' UHD rip. With DV Standard, it's perfect.

    I tried to reproduce that but I don't see any desync with audio/video.

    Quote from CroqueMr

    I process everything in YCbCr

    I'm curious about this. So YCbCr is a "legal" path for Dolby Vision? Everybody uses RGB 8 bit but they could be using YCbCr equally?
    And you say it saves on processing power, right? I wonder why nobody else does it (considering it would let them get away with less powerful hardware).

    (I am NOT questioning your choices, I'm just curious about this whole thing)

    Quote from ashlar

    I'm curious about this. So YCbCr is a "legal" path for Dolby Vision? Everybody uses RGB 8 bit but they could be using YCbCr equally?
    And you say it saves on processing power, right? I wonder why nobody else does it (considering it would let them get away with less powerful hardware).

    (I am NOT questioning your choices, I'm just curious about this whole thing)

    RGB8 describes the HDMI transport container here, not necessarily an ordinary RGB image and can be easely misunderstood. Dolby Vision RGB8 tunnelling can carry packed YCbCr or IPT-PQc2 values inside that container, which is where the confusion can arise.

    YCbCr is a valid Dolby Vision signal representation. For example, your Profile 7 Iso BL is in YCbCr. These are the two TV-led paths in my build for that type of source and both of them are legit and follow ETSI & SMPTE norms

    Master Reference:

    • PC: decode YCbCr > reconstruct Dolby Vision, including FEL if present > RGB8 HDMI tunnel containing packed 12bit YCbCr values and DV metadata.
    • TV: unpack YCbCr > apply the colour conversions described by the transmitted matrices (and inside this block transform YCbCr to IPT PQc2) > Dolby Vision display mapping > panel output.

    Master Reference IPT, available in Beta5 Debug:

    • PC: decode YCbCr > reconstruct Dolby Vision, including FEL if present > convert to IPT-PQc2 > RGB8 HDMI tunnel containing packed 12bit IPT PQc2 values and DV metadata.
    • TV: unpack IPT PQc2 > internal colour processing > Dolby Vision display mapping > panel output.

    Both are valid TV-led approaches. The main difference is where the color conversion happens, either predominantly on the TV side or on the PC side

    Quote from CroqueMr

    The main difference is where the color conversion happens, either predominantly on the TV side or on the PC side

    And if it happens on the PC side inevitably it leads to a performance hit (more stuff to do, after all). Correct?

    But the output on the TV (the actual pixels lighting up, I mean) is supposed to be identical?

    Quote from ashlar

    And if it happens on the PC side inevitably it leads to a performance hit (more stuff to do, after all). Correct?

    But the output on the TV (the actual pixels lighting up, I mean) is supposed to be identical?

    Yes, performing the conversion on the PC adds GPU work and has a performance cost in our implementation.

    Both paths are intended to produce the same final picture, but I wouldn’t claim "bit identical" output at the panel. The TV’s internal processing isn’t fully documented, and differences in calculation precision, rounding and quantization can introduce slightly different results.

    I’d expect those differences to be almost invisible, Hardware acceleration itself doesn’t necessarily reduce accuracy, what matters is the arithmetic and precision used by each implementation. In the Master reference circuit, I used the most accurate calculation possible accelerated by GPU.

    Quote from CroqueMr

    Hello DMD :)
    I released a debug version with a "Dolby vision Master Reference IPT" pipeline, It’s the same as the Master reference (Non IPT) in the non-beta version, though in a different format to help you to compare this output with other player. If you need any modification nor format is not what you excpected please let me know.

    I’d be interested in your feedback on this circuit, it will be rolled out more broadly in the next release. It isn’t fully optimized yet, an N100 processor can just manage 30 fps with FEL enabledwith 2,8ms headroom, but it can’t sustain 60 fps. I made sure that not a single bit changes between each modification. As I mentioned, it’s a very "overkill" circuit, featuring full-resolution calculations and the cleanest possible filters, the changes vs standard dolby vision output in the build are almost invisible, the implementation is similar the difference are in the rounding and precision.

    https://github.com/CroqueMr/libre…0.0-Beta5-debug

    Thank you, I’ll continue testing. I think that although the standards allow both color representation options, for some reason all players output ITP in an RGB 8‑bit tunnel. This may be due to the need or desire to send the same ITP Full range signal to the TV so that the TV perceives it identically. Since both DV P7 with Ycbcr and DV P5 with ITP are presented in the same ITP Full range in the tunnel.

    LibreELEC Hades 1.0 RC3 is up: https://github.com/hadesdevls/Lib…es/tag/v1.0-rc3

    Changes since RC2, mostly from logs posted here and on GitHub:

    - Dolby Vision: two-track MKV and MP4, MEL that locks, per-picture metadata after seeks, and Blu-ray folders and ISOs without the 9 second gap between clips.
    - Dolby Vision TVs from 2017 and 2018 that use display management 2 or 3 now get native output.
    - More hardware: Intel UHD 6xx, AMD RDNA4, and laptop HDMI ports wired as dual-mode outputs of the NVIDIA GPU. On AMD, HDR10 in 4:2:2 at 12 bits, and the right RGB range on TVs without quantization range support.
    - HDR10+ on NVIDIA, AMD and Intel. The HDR10+ Gaming FAQ says PC monitors only take it over HDMI for now, so that is the cable to try.
    - Player-led Dolby Vision (Low-Latency) as a setting, off by default. Through an HDMI sync box that only accepts Low-Latency, it played here as native Dolby Vision on the AMD integrated GPU.
    - The diagnostics now also strip local addresses, MACs and SSH fingerprints, can copy themselves to a USB stick, and the installer keeps them when it updates a drive.
    - Linux 7.2.12, Kodi Piers, Python 3.14.9, NSS and Mozilla's latest root certificates. Hardening flags only where a measurement showed no cost.

    Tested here on an RTX 4080 SUPER and on the 7950X3D's integrated Radeon, with an LG C5: profile 7 FEL, 8.1 and 5, HDR10, seeking, leaving Dolby Vision at 120 Hz, TrueHD and streaming Atmos, add-ons and the info pages. Everything else is new and has only been tested on the bench. A diag with any report helps a lot.

    LibreELEC master moved to Linux 7.3 today. Hades stays on 7.2.12 for this release; 7.3 comes once its amdgpu patches are ported and tested.

    LibreELEC Hades is not certified by Dolby or HDR10+ Technologies. Dolby Vision and HDR10+ are named here only as formats.

    Quote from ashlar

    Is this HDR10+ --> DV conversion or simply outputting HDR10+ to compatible TVs?

    Both, as two separate things.

    By default it simply outputs HDR10+: on a display that declares HDR10+, the dynamic metadata of each frame goes out with that frame, on NVIDIA, AMD and Intel.

    HDR10+ to Dolby Vision is a separate setting, off by default: Settings > System > Display > HDR10+ as Dolby Vision (Advanced level, and it needs "Native Dolby Vision output" on). It is meant for TVs that have Dolby Vision but no HDR10+, like LG's: Hades builds the Dolby Vision metadata from the film's HDR10+ metadata and sends it as native Dolby Vision. That one hasn't been tried on a TV yet, so reports are welcome.


    Nice for your works on HDR10+ when it will be tested I will integrated it in my build. :)
    What algorithm and decision did you take to convert DV metadata to HDR10+? it's not a simple conversion, of course it's lossy.

    __________________

    For those who want a bit more insight into the difference between Master Reference and Standard in my build you have my detailed analysis and the impact on the picture here : https://github.com/CroqueMr/libre…d-2026-10-21.md as I said, impact is invisible, screenshot are taken when the difference is at its maximum in a 10min sample. Yes the screenshot are in SDR (but the movie was in DV), you need to be in DV to see the real impact, but do not trust me, you have the timestamp you can pause on the frame and switch the mode during the pause with the small submenu accessible through "O" ;)

    Overall, "Dolby Vision Standard" I think runs on pretty much any x86 CPU with an iGPU supported in the build (so an AMD or Intel CPU released within the last 7-8 years or so). "Dolby Vision Master Reference" can even handle lowend ones like MatteN’s J5040

    60fps movies can be a little bit complicated to play properly, but in my opinion it's not a big concern, a N100 handle it but the headroom is not that big.

    As soon as I get more feedback, I'll add a "recommended hardware" section.

    And I received my 3200U, I will focus the stable build on this setup.

    There's no DV to HDR10+ conversion in Hades at the moment. HDR10+ output sends the film's own HDR10+ metadata, frame by frame, to displays that declare HDR10+. Nothing is taken from the Dolby Vision RPU.

    The one conversion there is goes the other way, HDR10+ to Dolby Vision, off by default. It builds a profile 8.1 RPU per scene from the HDR10+ metadata, and on 166 frames its L1 stays within about 11 nits-codes of what ST 2094-10 gives from the pictures, without clipping the maximum. In practice it rarely matters, since most HDR10+ titles carry Dolby Vision too. Dolby Vision to HDR10+, for TVs like Samsung's, is the more useful direction, and it's what I'm looking at next.

    On fidelity: on the 14 FEL frames I compared, Hades' default output matches the CCM 001 composer exactly, the same as your Master Reference. Where a GPU can't keep up, Hades steps down automatically, only as far as it measures it has to, and says so in the log. On GPUs that keep up, nothing changes.