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
Create an issue report on Kodi github.
Done Retroplayer is dropping frames every 10 seconds · Issue #19622 · xbmc/xbmc · GitHub
can you make a video while the problem appears ?
just to make sure we are looking for the same problem
This was a good suggestion I think. After capturing a video I noticed it happens predictably, every 10 seconds or so. It is just sometimes not very noticeable when there is less motion. Here's a video, the issue can be seen clearly at around 16s and 26s.
I was able to try Retroplayer on an entirely different machine/network/display/controller: Intel i5 2500k, Geforce GTX 1060, Windows 10, brand new Kodi 19 install. Tried every available SNES core, all had the same exact problem with FPS drops as described in the OP.
What am I to make of this, if apparently nobody else can reproduce it? I'm yet to see any working Retroplayer configuration. I suppose I have definitively confirmed this is not a LibreELEC issue and may take it to Github, but hard to say when nobody else is complaining about it.
I ran some games on my J4105 box including that Mario rom. I don't see any major problems.
The motion is not butter smooth like you would see in a modern game with vsync on. IMO that's normal.
In my case it's smooth most of the time, but will randomly, and very noticeably, drop a bunch of frames for about a second then go back to being smooth. This might happen 5-6 times over the course of playing the first level of Super Mario Bros at a good pace.
It seems I'm the one having to say sorry, according an LE colleague, it seems that Archive.org has got some official exception for it.
So there you go.
No harm done, I was also very surprised (and delighted) when I found out about their DMCA exemption.
(Possible) Pirated or copyrighted material in any form, including links to suspected downloads, is not accepted on this forum.
Stick to the forum rules.
Sorry about that, for some reason I thought it was OK because it was on archive.org
The sha-1 hash of the SFC file is c05817c5b7df2fbfe631563e0b37237156a8f6b6 (Super Mario All-Stars USA)
