Posts by Deathcrow

Quote from smp

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.

Quote from HomerJau

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.

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

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.

Quote from lrusak

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:

Quote

You 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)

Quote from smp

What about direct to plane? Does it produce HDR?

Just tried it out. Yeah, looks fine as well. Same subtitle problems though:

Quote from smp

Both using direct to plane. When EGL is selected HDR does not work.

That's incorrect. I'm using the drmprime-2img-no-ffmpeg-bump branch diff applied onto current kodi master and gbm+egl produces HDR perfectly (aside from the weird subtitle problems) on my NUC (coffee lake)

Quote from HomerJau

The red subtitle block is just the video stretched to fit in the subtitle frame but shaded red.

There's something more going on since ASS subtitles are also broken (white block instead of text). I suspect it has something to do with the layering stuff or shader color conversion, but have no experience in graphics and gl programming, so I'm definitely to stupid to figure this out. Interestingly this bug also affects subtitle rendering when not using the GBM frontend and running kodi in wayland (but maybe that's not surprising to kodi devs).

First things first: I don't use libreELEC but I came across this thread when searching for HDR on intel nuc with Kodi.

Maybe this is useful to someone, I think a success report can't hurt:

HDR works perfectly for me when using the drm-tip kernel branch from freedesktop (drm-tip - DRM current development and nightly trees) and applying the kodi patches from lrusak's branch (Commits · lrusak/xbmc · GitHub) on my Samsung TV (RU8009) with a NUC8i5BEH.

The only issue currently seems to be the frame drop commit, as mentioned by smp. As everyone else noticed, this breaks DRM on intel entirely. Removing the offending line fixes things neatly.

pVideoPicture->iFlags |= m_pFrame->data[0] ? 0 : DVP_FLAG_DROPPED;

Thanks to everyone who made this possible ( lrusak, smp, ...)!

Edit: I can also confirm the subtitle issues described somewhere earlier in this thread. The subtitles are either a red stretched image of the film (PGS subtitles) or just a white bar instead of text (ASS subtitles)