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

    Quote from bang gun

    Thanks a lot for all the work on this. I am just trying this out today, but strangely every time after rebooting libreelec for some reason Dolby Vision content stops working while HDR/SDR all keeps on playing fine. It seems the issue probably happens when trying to trigger Dolby Vision mode on my LG C5 as I do hear the audio playing but video output seems stuck on the Kodi interface it's pretty weird.. The only warning I can find in kodi.log is this but that's probably not saying a lot.

    OutputPicture - timeout waiting for buffer

    Using this Ryzen 7 7840HS with 780M gpu. Any idea what might be causing this or how even how to better troubleshoot ?

    Send me the complete log please. I will check

    Quote from CroqueMr

    That's normal, as the GUI puts a heavy load on the GPU. We worked with Dangerouslaser to include dedicated optimizations for this in beta 3.

    Beta 4 won't include additional changes for this. However, I plan to investigate AMD specific optimizations next week. Intel is currently performing slightly better with FEL, whereas AMD has a limitation I'm trying to fix.

    It is in my backlog but this will be adressed after the release of R1.0.0 Stable.


    I would particularly like to render Dolby Vision in HDR10+ for Samsung TVs (algo are different, picture will not be the same but we can try something), Since I don't own a HDR10+ TV, I won't be working on that.

    There are more optimizations possible for the OSD - but it is becoming overly complicated. Visual artifacting and general instability from trying to cache static OSD textures / portions of the frame are just and endless rabbit hole.

    The builds in my repo will play a remux of gemini man at 60fps with the OSD open, but it still drops a few frames when the OSD is first opened up or you are navigating around playback controls. It also only works with Intel GPUs.

    This also is heavily skin dependent. I think taking a version of esturary and stripping all gradient overlays from it could help.

    At the end of the day there are like 2 films in 60fps UHD that I know of (gemini man and billy lynns long halftime walk) - certainly neither of which people are queuing up to watch every weekend.

    Quote from CroqueMr

    Don't buy extra RAM, it won't help. This conversion process is just a draft in Beta3 and will be optimized in Beta4, maybe your hardware will be good enough

    I've already updated the basic HDR10 conversion in my internal beta4 preview build, but since it's heavy on the GPU, I think low end chips like the N100 won't handle it, but we will see after the rebuild of the pipepline. In the next release Beta4 the performances and optimization will not moved we will be close to the R1.0.0 stable. Important point, in Expert mode, tone mapping is managed by the rendering engine in LE, so be sure to disable tone mapping on your TV/projector.

    Determining whether a CPU/iGPU is powerful enough is tricky. Performance relies heavily on the rendering engine in the GPU, which is hard to benchmark, and other limiting factors are still not perfectly understand.

    Brilliant I'll wait then! Thought maybe it was the memory bus/bandwidth from single stick of ram instead of 2. Thanks for all your efforts I've genuinely got a smile on my face finally something works.

    Quote from CroqueMr

    Send me the complete log please. I will check

    Was finally able to solve my own issue. Turns out changing the refresh rate to 120Hz messes up Libreelec recognising the TV's ability to play dolby vision. Switching it back to 60Hz and now all is well again. Funny enough if you switch to 120Hz within the Kodi it still works as long as you don't reboot ;)

    Quote from bang gun

    Was finally able to solve my own issue. Turns out changing the refresh rate to 120Hz messes up Libreelec recognising the TV's ability to play dolby vision. Switching it back to 60Hz and now all is well again. Funny enough if you switch to 120Hz within the Kodi it still works as long as you don't reboot ;)

    That's possibly the same "bug" that I saw in CoreElec NO when I was talking to Portisch. He pointed me to a line of code that checks if a certain bit in the Dolby Vision VSVDB (Vendor Specific Video Data Block) in the EDID of the display is not ON then this says that the display cannot do DV at 120Hz. I have an older TV that cannot do DV at 120Hz and one that can and the bit was different on both, that's how I found out about the bit.

    The problem is, it seems that CoreELec NO is checking the GUI Hz wrongly and thinks the video that you are starting the playback is a 120Hz video even if it's the GUI that is 120Hz and not the video. Probably something about when the video starts the playback because I was seeing 2 or 3 times switching res and/or Hz in the kodi log.

    I still have the picture of the bit it's this one:

    dv_reserved_bit.png

    It says "reserved" but it's in fact called "Parity" and it'S a 120Hz compatibility bit for DV for the display. That picture is just from an older DV Header when it didn't yet serve any purpose.

    I said to Portisch maybe this should be fixed but he just said use 60Hz in GUI so I did that on my AM9 Pro. I also think it may be from LibreElec 13 since CoreElec NO is a fork of LibreElec 13 if I am not mistaking. So that's why we see it here too maybe?

    On my AM6B+ with CoreElec NG I do NOT have that problem and am using 1080p 120Hz and DV works fine so they changed or added the check for this bit in CoreElec NO / LibreELec 13.

    Portisch replied with the line of code for the check here:

    Amlogic-NO discussion
    This is your bit: So don’t use higher than 60Hz! And read Wiki how to provide logs:
    discourse.coreelec.org

    The line of code is here:

    common_drivers/drivers/media/vout/hdmitx_common/hdmitx_edid_parse.c at 5.15.196_20260225 · CoreELEC/common_drivers
    Contribute to CoreELEC/common_drivers development by creating an account on GitHub.
    github.com

    I don't see "common_drivers" in LibreELec's git repos though... I will try to put 1080p 120Hz and see if I have the same problem.

    ...

    tested and I do NOT have a problem playing back DV while my GUI is at 1080p 120Hz. This may be a CoreElec NO only problem and maybe this has nothing to do with bang gun 's problem? It sure looks like the same problem from what he his experiencing though but I don't experience that like I did on CoreElec NO. Also, if I do a search for "dv->parity" in LibreElec's repo I find nothing.

    Which file were you trying to play bang gun ?

    Edited 4 times, last by Creator44 (October 16, 2026 at 3:44 AM).

    hello, new to libreelec, I felt the need to change my player after my shield tv tube started stuttering with high bitrate mkvs (thought the problem was my nas )

    my humble contribution

    I was able to see the red sign screen "this device can decode fel", the white font credits and the character from mortal engines on the sample videos, using this gear.

    i5 7600/ 9070xt pc

    marantz sr7012 AVR

    Hdfury drHDMI4k - set to LLDV display

    tw9400 projector


    Hope that indeed everything was working. I read that receivers were not part of any test so far, in my case they seem to work fine.

    Not sure if I followed everything you mentioned there. Anyway as far as I can tell it used to happen on any file with Dolby Vision though I usually refer to the (in)famous DV FEL All Layers Test (Womxn at 80s) file. The issue is somewhat more annoying then I initially surmised because detection happens every time Kodi starts. Which means if you use add-ons like vacuumtube which exit and restart Kodi on exit I need to ensure it stays fixed on 60Hz to ensure Dolby Vision files will play back. I'm not nearly technical enough to understand any of this but it feels like Kodi simply won't play back the file cause on initial startup of the app it has decided the TV is incapable of playing back dolby vision (as a false negative in this case). Would there be a not so elegant solution as to ignore this detection and still force DV playback maybe as a setting toggle in the options. Of course it would be nicer if DV detection could be improved I could try to send logs if that helps but all I can see is only a simple DV=0 or DV=1 mention in the log files not sure if that's too helpful

    Quote from bang gun

    Not sure if I followed everything you mentioned there. Anyway as far as I can tell it used to happen on any file with Dolby Vision though I usually refer to the (in)famous DV FEL All Layers Test (Womxn at 80s) file. The issue is somewhat more annoying then I initially surmised because detection happens every time Kodi starts. Which means if you use add-ons like vacuumtube which exit and restart Kodi on exit I need to ensure it stays fixed on 60Hz to ensure Dolby Vision files will play back. I'm not nearly technical enough to understand any of this but it feels like Kodi simply won't play back the file cause on initial startup of the app it has decided the TV is incapable of playing back dolby vision (as a false negative in this case). Would there be a not so elegant solution as to ignore this detection and still force DV playback maybe as a setting toggle in the options. Of course it would be nicer if DV detection could be improved I could try to send logs if that helps but all I can see is only a simple DV=0 or DV=1 mention in the log files not sure if that's too helpful

    Yes DV=0 is the issue, I added for the next release a better audit in the log to see where this issue happen. The issue is not on DV detection side, your TV said properly that it can play TV-led and LLDV Dolby Vision, but for an unknown reason, your mini PC does not send a DV signal.

    Quote from ashlar

    Hopefully you'll be able to join forces. From a regular user's point of view (mine), you're all heroes anyway. Keep up the good work!

    Hi ashlar, CroqueMr,

    I'm glad to collaborate, with CroqueMr and with anyone else working on Dolby Vision on PC. All of the Hades code is on GitHub, so CroqueMr, use whatever helps your build, and ask me if you want to know why something is done the way it is. Hades started from your work, and the README says so.

    That said, Hades is a hobby project I started for my own setup, and much of it has nothing to do with Dolby Vision. It has privacy and safer defaults, like hiding the internal disks when booting from USB, Samba off unless you turn it on (and then with a password), no update server that could replace the build, and logs kept on the device unless you choose to upload them. There's also a Windows installer. That probably doesn't fit your build, so I'll keep working on Hades in parallel and share what works.

    On bilinear: I agree it costs fidelity, which is why Hades only steps down when it has to. It isn't a mode you choose. It starts only when the GPU is actually missing refreshes, goes back up as soon as frames fit again, is remembered per GPU and driver, and can be turned off. A GPU that keeps up gets the full picture, bit-exact, so if the N100 keeps up it never steps down there either.

    That full picture is also more faithful in RC2. It now follows the normative composer of ETSI GS CCM 001 and matches an integer reference of the spec bit for bit in every case I tested. On the profile 7 FEL stream I measured, libplacebo's reshaping, which mpv and the PC builds use (Hades too, until this release), differs from it by 4 to 15 codes out of 4095 on almost every pixel and by hundreds at high-contrast edges. If you want it, the composer and the exact Lanczos weights are libplacebo patches in the repo, and the chroma siting fix is a small change in the bridge.

    I’m currently finalizing the next release, it doesn’t improve performance for the native DV circuit, it features a complete rewrite of the other circuits (DV Enhanced etc...) and incorporates some of your elements, such as Nvidia support. If all goes well, it will be pushed tomorrow.

    Quote from Creator44

    CroqueMr , did my log about the DV freeze and black screen help find the issue?

    Unfortunately not so much. We can see the issue, but we can't identified the root cause. I ran an intensive AMD stress test on my 7430U and fixed a few minor issues, which might help with yours. In the meantime, I’ve adjusted the logs to capture more detailed information so we can pinpoint the root cause.

    Edited 2 times, last by CroqueMr: Merged a post created by CroqueMr into this post. (October 16, 2026 at 9:11 PM).

    I installed R1.0.0-Beta3 on my backup Libreelec box (GK3V Pro + LG C9). Still a bit flaky for everyday use but its getting there!

    For some reason, the "All Layers Test" was showing in the wrong aspect ratio. Looked like cinemascope. Also, as has been previously mentioned, the on-screen menu and Player Process/Player Debug displays were cut off.

    I did install over the top of standard Libreelec v13, not sure if that was a good idea?

    Quote from CroqueMr

    Unfortunately not so much. We can see the issue, but we can't identified the root cause. I ran an intensive AMD stress test on my 7430U and fixed a few minor issues, which might help with yours. In the meantime, I’ve adjusted the logs to capture more detailed information so we can pinpoint the root cause.

    Do you want a test clip?