Really appreciate the detailed answer. I think the primary benefit (and the reason I raised this topic) is having the UI run at a higher refresh rate, for example 60Hz or 100Hz and easily play back content at different frame rates without mode switches.
For anybody that is interested, mode switching for wayland doesn't seem to be on the horizon so maybe VRR is the way forward after all https://github.com/xbmc/xbmc/issues/20614
Does LE support VRR or Freesync? Would this be a better alternative to doing a mode switch every time a file that does not match the current refresh rate is played?
Thanks everyone.
Does LE not force full RGB at the GPU level? I thought it did
Although this is generally useful information, I don't know that it answers my questions.
Hello,
For displaying SDR content accurately on x86 intel, should we be setting our TVs to full range or limited range? What about our GPUs (via modetest), and Kodi itself (via the limited color range option)?
Would the answers to these questions be any different for HDR content?
I have seen this wiki page but I am not sure if it is up to date (it mentions Kodi 17, and we were probably on X11 when it was written): https://kodi.wiki/view/Video_levels_and_color_space
Thank you
There are some interesting threads on the Kodi forum where the developers state that none of the official Kodi builds, LE nightlies or the builds in this topic can do real HDR on x86. Any comments on this?
General HDR on Kodi v20 Linux builds discussion
Is there a tutorial that shows how to get HDR working with Ubuntu 22.04/Xorg/Nexus?
current LE11 nightlies include now everything that is required to have HDR at LE, no more special builds are required
Does this also ring true for Kodi master running on general purpose OSes? Or is it due to recent changes in LE?
HDR is partially working without DRM PRIME. It seem to be limited to HEVC 24p videos. In fact, this limited HDR functionality now present in current Kodi master/LE nightly.
Thanks for that, it does seem to work for some files. Wonder why it doesn't for this one: https://downloads.ddigest-dl.com/movies/clip_sa…_demo_clip.html
Is there a github issue I can follow that tracks the non-DRM-PRIME HDR activation? What is the advantage of DRM PRIME if HDR can work without it?
chcore I also run archlinux on my intel nuc 8i3beh and was about to try compiling a hdr nexus build like you did. Before I go to all that bother, would you consider posting your pre-compiled binaries (zst files) somewhere?
Sure, here it is: https://www115.zippyshare.com/v/dXPKI1Gl/file.html
Does anyone else get a strange fade-to-black effect at the top/bottom of the screen with Estuary when switching PVR channels? This is with DRM PRIME disabled, and the channel switch being performed with the up/down arrows + Enter key while watching PVR content.
Did some testing, and it seems to work pretty well (thanks again smp). Did notice a couple of issues though:
1. Deinterlacing does not work/cannot be enabled when DRM PRIME is enabled. This means I will need to manually turn on DRM PRIME whenever I intend to watch HDR content, then turn it back off. Not ideal, how far off is deinterlacing support? Maybe a good idea to have an option or advancedsetting that uses DRM PRIME only for HDR content until it is implemented.
2. Is it just me, or is text noticeably more aliased when HDR is active? Both subtitles and OSD are affected
Is there anything extra special I need to do during compile? I have added -DCMAKE_INCLUDE_PATH=/usr/include and -DENABLE_OPENGLES=ON but the "Allow using DRM PRIME decoder" option still does not show.
EDIT: Think I got it to work (yet to do proper testing), just needed -DAPP_RENDER_SYSTEM=gles
Does it switch to HDR with my LE build?
It does, after enabling the "Allow using DRM PRIME decoder" option. The build I compiled based on your branch (on Archlinux) doesn't have that option though. Any clues as to why?
Also, what's the difference between the "EGL" and "Direct To Plane" render methods? Found an answer to this question: RE: Intel true 10bits/HEVC/HDR support... ?
Looking at the code (as a novice) it looks for a HAS_GLES property when deciding to display the option in the UI. This property is set during compile time (??), if it finds "gl3.h". My system does have "gl3.h" as provided by the "libglvnd" package, located at "usr/include/GLES3/gl3.h". Maybe it's not finding it and I need to carefully read the output when I'm compiling.
Thanks for that. I was able to compile and run it just fine on my Tiger Lake NUC, but my LG G1 never switched to HDR mode no matter the content. As far as I know the system meets all of the requirements: kernel 5.19.7, up to date system packages, using GBM windowing, compatible cable, the "use HDR" kodi setting enabled, HDMI deep colour set to 4k (a TV setting), etc.
Not sure where to go from here, any tips?
I can't think of a reason why it wouldn't work, as long as you use Kodi-gbm.
Thanks for your insight. I see that Irusak's branch does not rebase cleanly onto v20 master. Before I try (and likely fail) to correctly resolve the conflicts, do you happen to have a branch that already integrates these changes?
smp, would you happen to know how I would go about getting HDR working on Archlinux? Does the latest vanilla linux kernel release have everything we need? Is it just a matter of compiling Kodi 19 (or 20?) with Irusak's drmprime-2img-no-ffmpeg-bump changes included?
I would love to use LE, but I use my NUC for many other things that are outside of LE's scope.
Thanks!
Ok, scratch that. That's not normal. I can now see the issue too. It's not noticeable in all games but in side scrollers like Mario it is pretty obvious.
This is something of a relief, thanks for that (and your comment on the Github issue).
I guess I'm blind. I'm watching it on a Dell U2412M Monitor @ 60 Hz, 1920 X 1200 / 59.950 Hz using Media Player Classic - BE.
Maybe your media player does some funky stuff with regards to frame interpolation? I would try VLC or MPV. I know back in the day when I was running Windows I would use MPC HC with MadVR to reduce judder and resizing artifacts.
There is obvious stuttering, easy to spot.
chcore is this issue specific only to Kodi retroplayer?
Yes I am ony seeing this in Kodi Retroplayer. If I use standalone Retroarch on LibreELEC (or standalone snes9x on Windows) there is no stuttering at all.
I watched it 3 times and saw no drops at all
This is very surprising to me. How are you watching it? The stutters show up very clearly for me when playing in MPV and VLC on a 60Hz display.
tx this time it worked
tbh I can't see the fps issues (I am rather picky and usually see those stuff), can you point me to the timestamps where it happens ?
I you watch the clip on a 60Hz display there are some (obvious, to my eyes) drops at 16s and 26s.
http error 403, I think because zippyshare is blocking several locations
Here's an alternate link: WeTransfer
