Old versions eg. LE 9.2.8 should work.
Posts by smp
-
-
GL is generally better for x86. Kodi's GL renderer has an improved HQ upscaling compared to GLES. It also allows using high quality BWDIF sw deinterlacing when VAAPI hw decoding is used. This is important for devices that lack advanced VAAPI deinterlacing capabilities (eg. Intel Jasper Lake). In GLES renderer this is broken/not implemented.
5 years ago LE had to switch to GLES because HDR passthrough is not possible when x11 windowing system is used. LE needed to go with Kodi-GBM. Back then it was only possible to build Kodi-GBM with GLES.
Since then there were changes in Mesa that allowed using libglvnd GL library instead of x11 GL libraries. Also, there were changes in Kodi's GL renderer that made HDR passthrough possible.
-
LE10 and older Generic and all Generic-legacy images use GL + x11.
LE11/12/13 use GLES + GBM.
It is currently possible to build GL + GBM image (Generic-gl). LE14 would probably use that.
-
Code
2025-04-30 01:27:46.173 T:1258 info <general>: CDVDVideoCodecDRMPRIME::Open - using decoder HEVC (High Efficiency Video Coding)Am i doing something wrong?
Don't enable DRM PRIME on Generic.
-
even 4K 24 fps HDR videos playback at 4:4:4 8 bits
This means that for whatever reason it refuse to use high TMDS frequencies for HDMI. Also, the fact that you get black screens after switching inputs indicate a possible compatibility issue. Try to test without AVR.
-
Is there a fix someone can think of or that is already known for the HDR being always in 8 bits on Intel Arc?
Diff
Display Morediff --git a/intel_hdmi.c b/intel_hdmi.c index ed29dd0..ef293a3 100644 --- a/drivers/gpu/drm/i915/display/intel_hdmi.c +++ b/drivers/gpu/drm/i915/display/intel_hdmi.c @@ -2060,7 +2060,7 @@ intel_hdmi_mode_valid(struct drm_connector *connector, if (clock > 600000) return MODE_CLOCK_HIGH; - ycbcr_420_only = drm_mode_is_420_only(&connector->display_info, mode); + ycbcr_420_only = drm_mode_is_420_only(&connector->display_info, mode) || clock > 500000; if (ycbcr_420_only) sink_format = INTEL_OUTPUT_FORMAT_YCBCR420; @@ -2265,8 +2265,9 @@ static int intel_hdmi_compute_output_format(struct intel_encoder *encoder, struct intel_connector *connector = to_intel_connector(conn_state->connector); const struct drm_display_mode *adjusted_mode = &crtc_state->hw.adjusted_mode; const struct drm_display_info *info = &connector->base.display_info; - bool ycbcr_420_only = drm_mode_is_420_only(info, adjusted_mode); - int ret; + int clock = adjusted_mode->clock; + bool ycbcr_420_only = drm_mode_is_420_only(info, adjusted_mode) || clock > 500000; + int ret; crtc_state->sink_format = intel_hdmi_sink_format(crtc_state, connector, ycbcr_420_only);^ This kernel patch would force 4:2:0 12-bit for 4K 50/60Hz. You'll have to build your own custom LE image to apply this.
-
Probably some AMD-specific issue in Mesa or kernel driver. Try to disable VAAPI hw acceleration and check if the colors are still wrong.
-
Some TVs would switch to "PC" mode when fed with 60Hz 4K or 1080p signal. Could that be the case here?
-
Just run that command from ssh and see if it works. If it works add it to /storage/.config/autostart.sh
echo 1 > /sys/kernel/debug/dri/0/HDMI-A-1/force_yuv420_output
-
do you think if I use a dp to hdmi 2.1 adapter it would work and go to 4:4:4 on 4k 50/60?
I see no obvious reasons why it wouldn't work.
-
my Beelink has hdmi 2.1 and will have the bandwidth for that if I am not mistaken?
Maybe it has something to do with this.
-
My test files are 59.94 fps files.
4K 50/60Hz HDMI modes are limited to 8-bit RGB or YCbCr 4:4:4.
4:2:2 or 4:2:0 10/12-bit are possible in theory but not supported by AMD or Intel driver. At least there was no easy way to force those modes last time I checked.
-
with 2 processors and 4 GB RAM
Less CPU threads = less RAM requirements. On a 20-thread machine 32GB is barely enough.
-
Well I was finally able to get a test recording
The video is HEVC 4:2:2. Is it a broadcast feed?
Kodi cannot play any 4:2:2 streams with VAAPI hw decoding, it falls back to sw.
For whatever reason Kodi detects it as an interlaced stream but the video is progressive. It plays properly if deinterlacing is manually disabled.
-
This is a known issue. No fix as of yet.
VAAPI hw decode failure with 4K HEVC HLG DVB stream · Issue #23699 · xbmc/xbmcBug report Describe the bug Here is a clear and concise description of what the problem is: I'm having an issue with "Hot Bird 4K1" TV channel that is…github.comDisney+ Addon not playing properly the stream when VAAPI is enabled · Issue #25383 · xbmc/xbmcBug report Describe the bug Here is a clear and concise description of what the problem is: Disney+ Addon creator and Inputstream.Adaptive maintainers think…github.com -
Given that http streaming might work wouldn't the problem be TVHeadend or pvr.hts and not Kodi (ffmpeg building aside)
Some more discussion about that issue. HTTP streaming does indeed work and the affected HEVC streams work with VAAPI hw acceleration. However, those streams also work with HTSP + sw decode (VAAPI disabled).
-
Looks like this change is also needed
-
Support for that chip revision was added by this linux commit. Kernel 6.12.x does not include it.
