Posts by smp

Quote from chewitt

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

Quote from mitzsch

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.

Quote from chewitt

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 · GitLab

What 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.

Maybe https://github.com/LibreELEC/LibreELEC.tv/pull/7280 is 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.

Quote from HiassofT

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.

Quote from sebden

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.

Quote from sebden

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.

Quote from sebden

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:

1 2

Update: try this image - LibreELEC-Generic.x86_64-13.0-devel-20260617041849-5ea4510.img.gz

Quote from sebden

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.

Quote from sebden

and the picture information of the Sony clearly stated BT.2020 mode

BT.2020 does not mean HDR.

Quote from chewitt

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.

Quote from sebden

Libreelec HTPC = Asus Prime H310i-Plus 2.0 MoBo (HDMI 1.4)

HDMI 1.4 cannot possibly pass through HDR metadata.

Quote from sebden

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?

Quote from joe65

wrong settings on my end ?

Yes, DRM Prime should not be enabled on x86 hardware.

Quote from wedok

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.

Quote from yamcenutzer

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/xbmc

Description Fixes #25383 VAAPI creates NV12 (8-bit) surfaces instead of P010 (10-bit) for HEVC Main10 content played via inputstream addons, because…

github.com

This should now be fixed in current LE13 nightlies.

Quote from wedok

Is this really true?

n5105 (Jasper Lake) does not support VAAPI-MADI and VAAPI-MCDI methods. VAAPI-BOB is low quality.

Quote from wedok

why intel, a company with huge $$$ problems, destroys all new cpus for watching proper deinterlaced video content?

All new Intel CPUs except EHL/JSL can do proper hw deinterlacing. See here. "* EHL/JSL only support BOB DI"

The good news is that you can enable high quality "BWDIF" software deinterlacing. Switch "Deinterlace method" to "Deinterlace", that would enable BWDIF.

Quote from e123enitan1

there is always a blank screen

A blank screen for a second during a channel switch? This is normal.

Quote from e123enitan1

but when used Hardware decoding Inactive there is no black screen

There is a frozen frame instead of a black screen. I don't see how this is better than a black screen.