It will not work with LE. HW deinterlacing require Amlogic BSP kernel.
Posts by smp
-
-
I think this may be outdated and no longer correct?
Yes, interlaced is always doubled.
QuoteFor this rate doubling to work, we need to ensure the whitelisted 1080p modes do not contain 1080p @ 25/29.97/30Hz rates, else Kodi will see an exact match against resolution and refresh rate and you will see high CPU loads and 50% of frames being dropped.
As far as I remember that was true for Generic-X11 (Legacy).
-
Post the debug log. AV1 plays fine on my pc with hw decode.
-
Our general preference with packages is to always be explicit in what we enable.
I don't see how this is relevant to this particular case. The only use case for setting codecs explicitly is to disable non-free codecs. That was the only reason for the 2022 Mesa change.
In 2022 codecs were set explicitly in LE only because there was no other choice due to that questionable Mesa change. It already caused MPEG2 breakage (unnoticed for years), then it caused av1 and vp9 breakage, it would cause more breakage in the future when new codecs will arrive.
In 2023 PR Mesa tried to fix their mess by introducing "all" and "all_free" options. "all" is the safest option, it simply brings back the old behaviour (pre-2022 changes).
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
That was in circa 2020 when I still had Vega 3 APU. I don't remember which MPEG2 videos caused issues. Try some random DVDs with vaapi on and off. I remember there was a discussion about this but I can't find it.
-
Our preference has always been to be explicit
In this case "all" is the correct option for LE. This is the "video codec support option" PR in Mesa that was the reason for this change. "all" option didn't exist back then, so it was needed to set codecs explicitly.
This Mesa PR introduced the "all" option, so "-Dvideo-codecs=all" would restore the old behaviour.
-
meson: Add all, all_free (default) options for video-codecs option (!26320) · Merge requests · Mesa / mesa · GitLabWhat does this MR do and why? What: Adds two new possible values to the -Dvideo-codecs build option: 'all' and 'all_free'...gitlab.freedesktop.org
Looks like it should changed to -Dvideo-codecs=all to enable all codecs rather than list them individually. Current Mesa defaults to "all_free" if "video-codecs=' is not used.
-
Maybehttps://github.com/LibreELEC/LibreELEC.tv/pull/7280is not needed anymore. What happens if you revert it rather than add mpeg2?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.
-
So I guess kodi outputs a standard BT709/gamma SDR image, but signals BT2020 colorspace which doesn't quite match.
I'll ping reardonia with this. Does indeed look like a Kodi bug.
-
The TV don't switch official to HDR.
The log shows that HDR passthrough is now enabled. If the TV does doesn't switch to HDR mode then the theory that HDMI 1.4 can output HDR metadata is wrong.
Is it a technically different thing now to disable "Adjust display HDR mode" and leave the tonemapping to Kodi - or is it the same thing as the default build, no HDR path, and then playing HDR content?
It should be the same. Did you try switching different tonemap methods with the default build (Video settings -> Tone mapping)? Each method would look different.
-
OK then I will give up
If you're able to compile your own LE image you can try to remove those 2 checks and see what happens:
Update: try this image - LibreELEC-Generic.x86_64-13.0-devel-20260617041849-5ea4510.img.gz
-
The official HDMI 1.4 spec does not technically support HDR, but the physical layer does not seem to have any reason not to
Even if that were true - the only way to make it work is to hack the Intel driver so it would actually use HDR_OUTPUT_METADATA property.
-
and the picture information of the Sony clearly stated BT.2020 mode
BT.2020 does not mean HDR.
I'm not aware of anything in the kernel/DRM layer that would block HDR metadata from being used.
DRM layer checks for the presence of HDMI 2.0. HDR passthrough is disabled on anything below Gen 9.5 (Gemini Lake) unless a HDMI 2.0 compatible LSPCON is used. His motherboard does not have an LSPCON.
-
Libreelec HTPC = Asus Prime H310i-Plus 2.0 MoBo (HDMI 1.4)
HDMI 1.4 cannot possibly pass through HDR metadata.
old TV = Sony 55XH9505 (2019 Top Model with HDMI 2.0) with 4K, HDR working well !
HDR would never work with that mobo on any TV.
-
I built 2 images - with nvidia-ng and without. I see no difference. No frame skips when GUI is opened. That's on Intel Celeron 6305.
-
Do I understand correctly - if on current LE master you remove nvidia-ng from options then it works ok?
-
wrong settings on my end ?
Yes, DRM Prime should not be enabled on x86 hardware.
-
This is a lie!
What is a lie? I have a Tiger Lake (gen 11 gpu) and Alder Lake (gen 12 gpu). Both can do vaapi-mcdi with no issues.
As I said - Jasper Lake is the only Intel hw that does not support advanced vaapi deinterlacing.
-
Out of curiosity, what was the cause?
VAAPI: fix 10-bit surface format for HEVC/VP9/AV1 via inputstream addons by reardonia · Pull Request #28103 · xbmc/xbmcDescription Fixes #25383 VAAPI creates NV12 (8-bit) surfaces instead of P010 (10-bit) for HEVC Main10 content played via inputstream addons, because…github.com
