Not sure if it's a bug or not but the HDR black level tests look wrong. Like this one for example.
That test looks correct with Commits · lrusak/xbmc · GitHub branch using direct to plane method. It looks exactly the same when played on TV's internal media player.
But with Commits · lrusak/xbmc · GitHub branch using EGL method some of the bars that supposed to look grey look greenish.
LibreELEC-Generic.x86_64-10.0-devel-20210427181309-090e00d.img.gz
- Partially reverted this commit because HDR stop working after the TV is power cycled:
diff --git a/xbmc/cores/VideoPlayer/VideoRenderers/HwDecRender/VideoLayerBridgeDRMPRIME.cpp b/xbmc/cores/VideoPlayer/VideoRenderers/HwDecRender/VideoLayerBridgeDRMPRIME.cpp
index fbe41cf9b8f3a..ca6711bf2313e 100644
--- a/xbmc/cores/VideoPlayer/VideoRenderers/HwDecRender/VideoLayerBridgeDRMPRIME.cpp
+++ b/xbmc/cores/VideoPlayer/VideoRenderers/HwDecRender/VideoLayerBridgeDRMPRIME.cpp
@@ -266,7 +266,7 @@ void CVideoLayerBridgeDRMPRIME::Configure(CVideoBufferDRMPRIME* buffer)
uint8_t eotf = GetEOTF(picture);
- if (edid.SupportsEOTF(eotf))
+
{
m_hdr_metadata.hdmi_metadata_type1.eotf = eotf;Updated image with the subtitles fix:
LibreELEC-Generic.x86_64-10.0-devel-20210427000230-090e00d.img.gz
Upd: current kodi master (58df0ff) crashes and burns, so I removed the file. Will reupload the fixed one later.
The motion is not butter smooth like you would see in a modern game with vsync on. IMO that's normal.
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.
There is obvious stuttering, easy to spot.
chcore is this issue specific only to Kodi retroplayer?
Create an issue report on Kodi github.
the direct-to-plane method won't be merged for intel
So there is no way to keep both methods? E.g. EGL as the default one and direct to plane for the hardware that can support YUV planes?
gbm+egl produces HDR perfectly
What about direct to plane? Does it produce HDR?
When EGL is selected HDR does not work.
I mean it does not work on image #2. On image #1 HDR works with both direct to plane and EGL.
Someone in this thread tested on Apollo Lake with direct to plane + LSPCON kernel patches and HDR worked.
is image 1 using the direct to plane and image 2 using the EGL rendering?
Both using direct to plane. When EGL is selected HDR does not work.
This is only useful for Gemini lake (and Ice lake?)
I don't believe so. Direct to plane even works on an old Apollo Lake SoCs, not to mention the new Tiger Lake (already confirmed working), Rocket Lake, Elkhart/Jasper Lake.
it may not do HDR on this system
I'm not 100% sure about this. Someone tried my build with Kodi compiled from that branch some time ago and it didn't work for them, so I assume it works only on Gemini Lake.
For Gemini Lake is there one build you would recommend over the other?
The second one does not have the subtitle issue.
1. LibreELEC-Generic.x86_64-10.0-devel-20210422040736-13c3cc6.img.gz
2. LibreELEC-Generic.x86_64-10.0-devel-20210422041617-13c3cc6.img.gz
- Updated with the changes from current Kodi and LE master branches.
- Linux kernel 5.12-rc8
- Fixed Retroplayer glitches (CONFIG_DMABUF_HEAPS)
Image #1: lrusak/drmprime-2img-no-ffmpeg-bump branch (HDR known to work on Tiger Lake, Gemini Lake and some other Intel hardware)
Image #2: lrusak/drmprime-vaapi-hdr branch (HDR probably works only on Gemini Lake)
It doesn't matter, there won't be HDR in nightly builds anytime soon.
subtitle issues described somewhere earlier in this thread
This branch does not have that subtitles issue. But I'm not sure that it will work on anything other than Gemini Lake.
HDR works perfectly for me when using the drm-tip kernel branch from freedesktop
5.12 will work too. LSPCON HDR support was finally merged into kernel 5.12.
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.
There is an issue with VP9 10-bit videos and Intel media-driver. It affects both X11 and GBM. I reported it here. Media-driver person say it is a Kodi issue.
This does actually two different things. Can you please each one separately?
It fails with this part:
pVideoPicture->iFlags |= m_pFrame->data[0] ? 0 : DVP_FLAG_DROPPED;