Posts by mitzsch

I compiled myself a version with your PR included and it works perfectly!!!! HDR metadata is updated on the fly without a hitch! Thanks very much!!
Hopefully it’s merged soon!

I have seen your PR (https://github.com/xbmc/xbmc/pull/29063) - Does this fix the stuck static HDR metadata issue?

Sorry for the late answer. I wanted to wait until the kodi git version was updated in the LE13 nightlies, so the linked commit was included.

I tested version 2026-08-22 (f014c59), and yup, it works! No more green intermittent image! Very nice!!

(The other "issue" of the static not changing hdr10 metadata is still present, but this is probably fine)

Thanks very much!!

What hardware are you using?
Is this with sdr or hdr movies?

Can you please share a debug log?

This issue is a difficult one...

As the title says, I´m experiencing intermittent green images on HDR files where HDR metadata changes with vaapi hw decoding on. This is on a system with an AMD RX6600 and LE13 nightly.

This happens on UHD BD rips that come from multi branch/seamless branching discs. The problem is that not every seamless branching disc rip exhibits this issue on LE. For example, the 4K disc of Alita Battle Angel is a seamless branching title (the movie has different opening titles in different languages; these are different segments) with changing metadata; this disc does NOT exhibit an intermittent green image on the merging spot.

The new Arrow Video box set of Stranger Things is a seamless branching release. They have a Netflix intro and outro that are added to every episode. The problem is, they have different HDR metadata, so whenever an episode is played, playback starts - the intro plays, and briefly before the actual episode plays, I get a green image...

About the HDMI output... I checked with my HDFury Arcana what happens with the metadata - if it changes or so. It stays with the metadata of the intro until playback stops. This is identical to the behavior of my bluray player. The question is: Is this the preferred way of playing back such media? (In my opinion, such media is wrongly mastered, as we don´t have any chance of changing this; this is probably fine, although not ideal... different problem)

For example, this issue gets worse when looking at other platforms. On Windows, dynamic HDR metadata changes are working, and with Kodi this triggers a complete resync of the display signal when such a merging spot is being played... An absolutely unwatchable experience; that was actually a reason why I have switched over to LE... (Similar issue https://github.com/mpv-player/mpv/issues/11538) I have no idea what would happen when LE/linux would be able of dynamic HDR metadata changes on playback... I guess this would introduce many more regressions...

As for 4K rips from seamless branching discs, where every segment has the same HDR metadata, those play just fine. (on all platforms)

Anyway, back to the issue with the green image - is it possible to avoid this (without transcoding all files)? In my understanding, it's the decoder that doesn´t like it; however, sometimes it's okay? (Is this an I, P, and B-frame mismatch?) Or is it possible to make this green image just black?

If needed, I can upload some debug logs or probably DM someone a small sample.

Quote from Creator44

Yes I tried LibreElec 13 May 16th 2026 and the HDR is still the same wrong colors unfortunately.

Can you describe this issue a bit more? Do you have any reference scenes where this is noticeable? Is this any different with the latest LE 13 nightly?

Does your AMD Ryzen mini pc use any HDMI conversion chip? Is this issue only present with integrated graphics?

I'm kinda curious, as I'm also using AMD graphics hardware (although a dedicated GPU, RX 6600) for my daily LE (13 nightly) experience, and on my end everything looks wonderful. (At least I think it's correctly displayed)

First of all, thanks for doing awesome work on 3D playback and MVC decoding! 3D is not dead! (... yet)

Quote from popcornmix

If they are full-SBS or full-TAB then you ideally want FP mode.

Does this mean full-SBS (3840x1080) files are processed on the fly "to" frame-packed, and sent as frame-packed video (1920 x 2205) to the display or projector? Is the RPI4/5 fast enough to do this conversion on the fly?

(What are the chances that we see this 3D implementation working on x86 hardware? What would be missing? If I understand it correctly, MVC streams are software-decoded, so no special hardware decoder is needed? Does the drm/gbm display stack on x86 need fixes, or is this "only" a Kodi fix?)

Is there anything new regarding the HBR audio passthrough issue?

I missed that part in your earlier answer, sorry! Changed it all!

Thanks, guys!

If it's okay, I will draft a PR with the -Dvideo-codecs=all option?

Quote from smp

In any case, vaapi-mpeg2 is problematic on AMD, image quality-wise. At least that's how it was a few years ago but I don't think anything changed.

I thought of something like this as an explanation why it wasn't enabled in the first place. Do you have sample media that exhibits those problems or a link to a thread discussion such? Would like to test such media on my rx 6600...

Hi!

As the title states, there is no hw accleration of mpeg2 content on AMD GPUs, even though it's supported by the GPU silicon. For newer (RX7000+) chips, it does not matter as they do not support hw decoding mpeg2 (and vc-1) content, but for older generations? (in my case, Vega 8 and RX6600)

Is there a reason why it's disabled/missing in the Mesa package.mk?

=> https://github.com/LibreELEC/Libr…package.mk#L106

I compiled myself an LE version with mpeg2 enabled and it works fine...

Enable jpeg and mpeg2 decoding for amdgpu vaapi · LibreELEC/LibreELEC.tv@aa9eabd

github.com

Quote from HiassofT

The nightly with the fix is now available:

Tested the build on my system and it's fixed! Thanks a lot!

Quote from smp

Do I understand correctly - if on current LE master you remove nvidia-ng from options then it works ok?

Yes, exactly.

Quote from smp

No frame skips when GUI is opened.

Once opened, everything is fine. The "opening" process causes a massive frame drop.

Here is my (working) build with nvidia-ng removed...

<download removed, no longer needed>

I will try the "Generic image" from Chewitt.

As the title says, opening the playback ui (hitting enter) or the playback info (pressing o) is not smooth and causes massive frame drops on a system with an AMD GPU since build 13.0-nightly-20260517-7374d38. The last working build is 13.0-nightly-20260516-ba37c30.

My system:

Ryzen 5 5600x | 16Gb Ram | RX 6600 | 16Gb Optane M10 boot disk

First, I thought it was due to a Kodi change, so I compiled myself different versions of LE with different Kodi commits from May 16 and 17 with the latest set of LE patches.

All showed the same behavior. I then compiled the Kodi version (c685f9c0efe9439f16018d450a78aa7ed25c2b8a) that comes with the last working build on top of the latest LE patches. I expected perfect results, as I thought it must be a Kodi issue... but also with that build, I also experienced the mentioned issue. So, no Kodi issue but a LE one?

I checked the commit history on what has changed between May 16 and May 17. The most obvious was the inclusion of NVIDIA GBM drivers. (which also made the image size 200mb bigger)

So I compiled a version with the latest Kodi and with nvidia-ng removed from the "GRAPHIC_DRIVERS=" OpenGLES option, and now it's smooth again. I don't know why excluding drivers that aren't even loaded fixes the issue... Or are they loaded??

I also added the logs from the official LE builds

Quote from chewitt

Nothing specificially targetting the unknown problem.

Hm, okay, I also just tested the latest build (17/04/26 - fresh install) and both the issue with the LPCM wrong channel mapping and hbr passthrough persist. Hopefully, they can get sorted out.

About HDMI 2.1 - now that AMD wants to upstream HDMI 2.1 bits into the mainline kernel - this could open the gates for (rk) HDMI 2.1 open source implementations legally.

Thanks!

Are there any fixes for the HBR audio dropout issue in that new build?

Thanks!

Memory cap removed - nice!

About HDMI 2.1 - nothing special, just resolutions like 4K60 with 10bit and RGB/Ycbcr444 or for the future 8K things...

thanks!

Just two more questions about (the future of) the rk platform.

- Is the memory cap "fix" still needed?

- The rk3588 has an HDMI 2.1 out port. Will we ever see HDMI 2.1 being supported by that platform? I have seen that there have been some HDMI FRL patches made, but with the HDMI association blocking all HDMI 2.1 work and implementations on Linux ( at least with AMD and Intel..), will we ever get HDMI 2.1?