And I don't understand why in the version you gave me the image looks black.
It's a work in progress code that is known to work on some Intel hardware. It does not seem to work on AMD yet.
And I don't understand why in the version you gave me the image looks black.
It's a work in progress code that is known to work on some Intel hardware. It does not seem to work on AMD yet.
You probably also need the RTL8125B firmware.
I haven't noticed any color inaccuracies as described by smp
Try this test.
All bars (66-120) should look grey. But when using the EGL render method - bars 68-88 look green.
They look correct with direct to plane method (http://github.com/lrusak/xbmc/commits/drmprime-vaapi-hdr branch).
LibreELEC-Generic.x86_64-10.0-devel-20210427181309-090e00d.img.gz
On my AMD Athlon 200GE (Vega 3) HDR does not work. - just a black screen.
Though that could very well be a quirk of my TV, handling native HDR poorly.
I understand you have a Samsung 2019 model TV?
I use these settings for HDR to get an acceptable picture on my Samsung:
Game Mode: On
Backlight: 50
Contrast: 45
Sharpness: 0
Colour: 25
Contrast Enhancer: Low
Colour Tone: Standard
ST.2084: 2
Contrast Enhancer and ST.2084 are important. With default settings the picture is indeed too dark.
AMD Ryzen 5 3500H and apu radeon vega 8 and it does not work for me
I compiled it without radeonsi mesa drivers.
I can do another build with AMD support if you want.
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;
Display More
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.