[x86-64][CroqueMr Builds] Dolby Vision w/FEL, HDR10+, and 3D

Small update (smaller than other beta release but still important) https://github.com/CroqueMr/libre…ag/R1.0.0-Beta5

R1.0.0 Beta5 - Playback stability and wider format support

Compared with Beta4

Playback

• Improved scaling and placement for non-4K video across the shared rendering pipelines.
• Improved Master Reference presentation with GUI
• Added shared BL/EL assembly for declared dual-track MKV/MP4 and dual-PID TS/M2TS sources.
• Fixed stale enhancement-layer data after seeking and preserved original packet framing during seek-point detection.
• Improved FEL decoder-surface allocation and VAAPI context reuse.
• Improved audio recovery after temporary output loss.
• Corrected HDR state handling after a rejected metadata request.
• Improved extended EDID handling and recovery of available Dolby Vision modes.
• Prefer 3840x2160 over 4096x2160 when selecting a Dolby Vision output mode.
• Added stream-selection diagnostics for ISO/STRM playback without forcing Dolby Vision on unverified streams.

Player information and settings

• Player information now uses shared Kodi resources and native fonts.
• Disabling enhanced information restores the active skin's native panel.
• Quick rendering selection uses the active skin's native selector layout.
• Corrected the consistency of generated L3 metadata and HDR10-to-Dolby Vision AI information.

Known limitations

• HDR10 on some older Intel HDMI configurations remains under investigation.
• Heavy conversions and visible menus can exceed low-power GPU capacity.
• Adaptive HDR Mapping remains subject to visual refinement.
• Dedicated NVIDIA GPU support remains experimental.

Quote from ht2tweak

CroqueMr, looks like we've lost the enhanced player info w/beta4:

---

Also, re-tested DV FEL playback of actual UHD rips on both AMD 5800H and Intel N150, and playback is excellent on both. Dramatic improvements in latter.

Thank you for the feedback, I think it's fixed in beta5

Quote from Creator44

I also disabled DV once and then all the DV modes became unavailable until I rebooted. I did the same later and I did not have that problem.

I improved the HDR10/DV detection in beta5 if you have still this issue please report it

Quote from klinsmn

A laptop powered by intel i7-1260p works fine with SONY TV X90L and beta4, FEL and all RPU response no issues.

However, the laptop defaults to the internal display. You need to modify the cfg file to output signal correctly to the TV and activate Sony's Dolby mode.
It is recommended to add a script to switch between the laptop's internal display and external display.

Thank you for your feedback, I did not test the build on a laptop. I will try to fix that this WE.

Quote from Creator44

According to the issue report, the person cannot playback DT DV. I have the DT test file of "This Device Can Play DV" but for the DT test file specifically, it only displays black screen on my AM6B+ on CoreElec NG AND on your builds same thing. I thought this was normal and unsupported by ffmpeg or something. If you fixed that too that's pretty neat.

Beta5 is out and try to fix that, if you can send me your feedback it would be great.

Quote from kangarooremarkable21

Hey CroqueMr I have an rtx 4080 gaming laptop. I flashed the latest beta 4 on my usb and connected to tv via hdmi. I am not getting output to tv. Only the initial one line libreelec r1.0.0 beta 4 shows up on both tv and laptop, but after that everything is on laptop screen. I have tried libreelec hades build before and I was able to get output to my tv , I tested fel files and everything worked properly on that build. Any idea what's going on?

I will have a laptop with a 5080 this WE I will try to fix that. Complicated to fix it blindely.

Quote from Vertox

Thanks for the explanation, I understand the limitations of Master Reference mode, and I'd definitely prefer to keep the picture quality intact. I'll test Debug2 when it's available and let you know if the frame drops improve. Really appreciate your work.

Beta5 increase the GUI performance in master reference mode, thanks for your test feedback.

CroqueMr you do mention K17 mini pc with 226V chip. Will your builds work alright on it or does it need some modified drivers to run?

Might get one of those as I'm running couple docker images already so a bit more power horse would be great 😉

Quote from Borygo77

CroqueMr you do mention K17 mini pc with 226V chip. Will your builds work alright on it or does it need some modified drivers to run?

Might get one of those as I'm running couple docker images already so a bit more power horse would be great 😉

I never installed LE on my 226V, I am running Kubuntu with a lot of container for my intensive NAS/media server setup. And I installed my custom DV engine with modified drivers to play Dolby Vision through Jellyfin using the HDMI output.

All modified drivers (Intel, Xe, AMD, Nvidia...) are included inside the build

N100 Dolby Vision Master Reference:

https://paste.libreelec.tv/evanescent-zola.log

J5040 Dolby Vision Master Reference:

https://paste.libreelec.tv/unrecusant-zainab.log

Works fine, no dropped frames.

Quote from ht2tweak

This question may have been answered, but should DV Master Reference be expected to work fine on lower end h/w like MatteN shared logs for? Haven't looked at the logs; not that I could figure out what's what anyway.

I do not know I need to check with this precious log. A N100 is ok for the master reference mode but the headroom is small.

To be honest, this mode is pretty overkill, but I guess purists/geek might appreciate it. There are no compromises here, just full-precision calculations throughout. I'm not even sure certified Dolby Vision devices go this far, I am pretty sure these devices make some compromise.

And I challenge anyone to spot the difference compared to Standard mode. You can pause on any frame and switch between modes in real time with "O". Even on frames where I know there's a measurable difference is at its maximum (still less than 0.8% in chrominance), I honestly can't see anything different

The only obvious difference is that one uses twice as much processing power Don’t be frustrated if your device doesn’t support this mode, you aren’t missing out on much. The standard mode was designed with very minor, imperceptible compromises to ensure it runs smoothly on less powerful hardware.

Quote from MatteN

Works fine, no dropped frames.

Really that's very nice I do not think your CPU will handle a 60fps DV file in this mode, but at least if it can handle a Remux/Iso with FEL it's amazing.

Quote from DMDreview

Yes, to ensure 100% accuracy in the analysis, I need all players to use the same color space. Otherwise, I’d have to convert ITP to YUV or vice versa, and that isn’t a lossless process—I need a lossless process without any color conversions.
I’m testing on an Intel i3-12100 (UHD730)—it seems to be sufficient for 30 fps tests.

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.

Lucky I didn't waste money on that extra ram, you were right! Thank you again.

Is there any chance of being able to use vertical shift in 3d playback? Currently changing the values doesn't do anything.

Quote from elstr

Lucky I didn't waste money on that extra ram, you were right! Thank you again.

Is there any chance of being able to use vertical shift in 3d playback? Currently changing the values doesn't do anything.

Yeah I think I can give it a try, alors I think you was interested in DV to HDR10 expert conversion I saw some issue, black are crushed I will investigate to see the cause behind.

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.

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?

Is it possible to run this version of Kodi in a virtual machine and retain the FEL compatibility with nVidia gpus?

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