I missed that part in your earlier answer, sorry! Changed it all!
Posts by mitzsch
-
-
Thanks, guys!
If it's okay, I will draft a PR with the -Dvideo-codecs=all option?
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...
-
The nightly with the fix is now available:
Tested the build on my system and it's fixed! Thanks a lot!
-
Do I understand correctly - if on current LE master you remove nvidia-ng from options then it works ok?
Yes, exactly.
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
-
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?
-
Any news for an updated build?
-
For anyone interested.
While testing the custom EDID, I found that Kodi in its "default" version does not accept those custom 23p modes due to the calculation done by the Kodi code.
I made a fix and opened a PR, there I also explained the problem in more detail => https://github.com/xbmc/xbmc/pull/28080
With that fix applied, Kodi now "accepts" new custom modes.
I'm currently testing an EDID created with CRU with a slightly altered 23p mode.
This site is very useful for custom mode timings => https://www.monitortests.com/pixelclock.php
I noticed how important the blanking values (horizontal and vertical) are... Vertical above 80 and horizontal above 180 for audio passthrough to be working fine...
-
With the build from 22.02.2026, HBR passthrough works on my end with DTS-HD and TrueHD, with the already mentioned dropouts. However, the channel mapping issue with PCM audio is still present.
I watched a whole movie (with passthrough on) and only had one skipped frame in a runtime of about 90minutes... (and this one could have been triggered by me opening the debug info overlay). No idea what was wrong with the earlier build on my setup...
However, at the end of the movie screen output crashed somehow. Audio was running, the screen was black, but the TV signaled that the link was still active. Here is the (truncated? => the same outlines again and again spammed the output so I just copied that part that I was able to grab) dmesg output... (dmesg1.txt)
After exiting playback, the UI came back on, but after selecting a different movie file, the screen was all black again and would also not come back on exiting playback...
dmesg2.txt => Unfortunately, also just a snippit - that's all I could grab...
-
oke, update - I just tested the latest build (21/02/2026) and audio passthrough of at least Dolby Digital works fine (dts untested); however, with my UHD bd rip streamed from a smb share, I had some severe frame dropping. Multiple frames at a time...
I will retest with some more time, with passthrough enabled and without...
What I also noticed, was pcm output seems wrong in regard to channel mapping. The center channel was played by the right channel speaker.
-
Thanks for your response!
I have adjust-refreshrate enabled with all the modes I need selected... LE/Kodi also switches to them just fine... but while playback is running, it drops frames constantly. Audio (with passthrough) is not a problem... it's all about video framedrops...
I guess I need to tinker with modified EDID...
-
Thanks for providing all these builds chewitt!
I will need to test the latest build. Last weekend I tested the builds from 23/01/26 on my Radxa Rock 5 itx+, and playback was pretty good... and HDR worked perfectly (so far)! I rechecked with my HDfury Aracana to see if all HDR metadata values are transmitted correctly, and they are! The bt.2020 flag was correctly set, min/maxLum was transmitted, maxCll,maxFALL, whitepoint, and content mastering colorspace were also correctly transported! ... and all that with a 10Bit HDMI link and HEVC hardware decoding.
PCM audio was also working remarkably better than before... At that pace of developement the rk3588 could become a pretty decent media playback powerhouse soon. The only thing left for me would be HBR audio passthrough support.
The HDMI timings, however, do still seem a bit off - my AVR still cannot overlay its info screen... not an issue though.
About HEVC decoding and your problematic files... Are those publicly available? Or could you explain what is broken with them? chewitt
I'm also collecting such samples to test any kind of hardware...
-
I'm currently running a Dg2 (Arc A310) system with LE 13, and it works pretty well. HDR and audio passthrough works! (... with the HDMI 10-bit max patch applied)
But I have an issue where the playback of 23.976p 2160p HDR content drops frames (= av corrections) pretty constantly every 12 to 18 minutes. The hardware is more than capable of decoding even AV1 8k60 hdr content, so it shouldn't be a hardware "is too slow" issue.
The logs also do not indicate anything wrong. The 23p HDMI mode, "3840x2160 with 3840x2160 @ 23.976025 Hz," looks good.
I know with passthrough enabled, Kodi is not able to resample the audio on the fly to accommodate for drifting due to framerates not matching (content =/= display). But is this even a thing on the hardware? I was under the impression that Intel (and AMD) have pretty good HDMI timings, so a frame-drop-less playback is pretty much plug and play. Whereas Nvidia needs hdmi clock tunings...
Did this change? Is this different on Linux?
Is there anything I can do? It drops frames regardless of the audio codec used for passthrough.
Does the setting "maxpassthroughoffsyncduration" help?
Or is the only thing i should test an EDID mod with different HDMI timings?
Any help is appreciated! Thanks!
(The attached log is with playback through a plugin (pm4K) - however, the dropped frame issue also happens with playback through Kodi without any plugin in the chain. It was just the log that I had flying around.)
-
email to chewitt@ our domain or Kodi domain.
Mail has just been sent! I hope I have used the correct email address...
And thanks for your fast reply!
About the dropped frames issue - i will keep an eye on what media "triggers" this...
