- Official Post
Just tried it out. Yeah, looks fine as well. Same subtitle problems though:
Please post a debug log, it's likely that it's falling back to EGL
Just tried it out. Yeah, looks fine as well. Same subtitle problems though:
Please post a debug log, it's likely that it's falling back to EGL
Please post a debug log, it's likely that it's falling back to EGL
Yeah I think you're right on the money, I'm seeing lots of messages like this in the log:
2021-04-23 20:47:08.706 T:29302 DEBUG <general>: CEGLImage::CreateImage - attributes:
EGL_WIDTH: 3840
EGL_HEIGHT: 2160
EGL_LINUX_DRM_FOURCC_EXT: R16
EGL_DMA_BUF_PLANE0_FD_EXT: 40
EGL_DMA_BUF_PLANE0_OFFSET_EXT: 0
EGL_DMA_BUF_PLANE0_PITCH_EXT: 7680
EGL_DMA_BUF_PLANE0_MODIFIER_LO_EXT: 2
EGL_DMA_BUF_PLANE0_MODIFIER_HI_EXT: 16777216
Even though direct to plane was selected in settings. But I would've assumed that EGL is the preferred/desired render method anyway, no?
PS:
QuoteYou have already written a post within the last 2,400 seconds. You must wait at least 926 seconds before attempting to write a new post.
How silly. Can I fill out some captchas please? (first time for everything I guess)
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?
is it simple to switch between these builds and official?
as in just flash official over these builds or will clean install be needed?
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?
There is no reason to support both. The EGL method will be universal and the direct-to-plane method doesn't offer any benefits. With the direct to plane method you also can't do things like tonemapping, brightness/contrast adjustment, etc.
After spending a weekend wasting WAY too much time by reverting random commits, comparing diffs, recompiling kodi a million times (thanks ccache btw) I finally figured out the reason for the messed up subtitles:
diff --git a/xbmc/cores/VideoPlayer/VideoRenderers/HwDecRender/RendererDRMPRIMEGLES.cpp b/xbmc/cores/VideoPlayer/VideoRenderers/HwDecRender/RendererDRMPRIMEGLES.cpp
index bb5a6734bf..883b81d32c 100644
--- a/xbmc/cores/VideoPlayer/VideoRenderers/HwDecRender/RendererDRMPRIMEGLES.cpp
+++ b/xbmc/cores/VideoPlayer/VideoRenderers/HwDecRender/RendererDRMPRIMEGLES.cpp
@@ -371,6 +371,7 @@ void CRendererDRMPRIMEGLES::RenderUpdate(
layers = 3;
}
+ glActiveTexture(GL_TEXTURE0);
if (layers == 1)
renderSystem->EnableGUIShader(SM_TEXTURE_RGBA_OES);
else
Display More
My current working branch/commit is here: subtitle bugfix: reset glActiveTexture to TEXTURE0 so that subtitles … · Deathcow/xbmc@d11c5b6 · GitHub
In retrospect this is super simple, but it's always like this, isn't it? Anyhow: After the different if cases in the multi layer code the glActiveTexture remains at GL_TEXTURE2 or GL_TEXTURE1, which causes the subtitles to render incorrectly. Resetting it to GL_TEXTURE0 after the glBind stuff seems to alleviate the situation.
ping lrusak , this might be of interest to you, if you want to continue work on the multilayer branch some day.
I'm going to get some sleep. Bute force bug fixing sucks.
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.
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
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.
smp The build earlier today in post #620 looks ok on my NUC8i3BEH. I’ve watched two different HDR movies and they both look great to me. Blacks look black. Subtitles working now, HBR audio too.
Thanks for today’s build!
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.
Hi!
The dropbox link is not working.
Edit: This LibreELEC-Generic.x86_64-10.0-devel-20210427035557-090e00d.img.gz?dl=1 it works perfectly. Im sorry
I’ve watched two different HDR movies and they both look great to me. Blacks look black. Subtitles working now, HBR audio too.
I haven't noticed any color inaccuracies as described by smp either, but sometimes the picture seems a bit too dark. Though that could very well be a quirk of my TV, handling native HDR poorly. Cranking the brightness (in kodi) to 55-60% looks more correct to my eyes.
Hi, I have tested this image on a PC with AMD Ryzen 5 3500H and apu radeon vega 8 and it does not work for me, neither install, nor run, nor live.
And I have tried a minipc asrock beebox N3000 and if it has let me install but HDR does not jump.
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.
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.
I compiled it without radeonsi mesa drivers.
I can do another build with AMD support if you want.
If you could I would appreciate it, most of them use Intel but recently I got a minipc with ryzen 5 3500 h and vega 8 which I am very happy even for games.
I would appreciate it infinite.
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.
I understand you have a Samsung 2019 model TV?
Yes. I think it's a bit trash. I hope my next TV will be better (aka more expensive).
Thanks for the tips with the settings, I'll definitely try those out.