4k Gets Broken After linux-rpi 6.12.18-1 update on PI4

[dinobagio]

Describe the bug

Hi,

I am currently running kodi-rpi over linux-rpi on arch arm os.

I've been watching 4k items for weeks now, perfectly fine.

Yesterday after a major update, 4k decoding was not OK anymore, with huge lags and freezes.

After trying a lot of things, it appears the only thing that brings back the system stable is downgrading linux-rpi to 6.12.17-1.

Just doing this and reboot fixes the 4k capacity.

Let me know what I should provide to understand why.

Thanks in advance,

Steps to reproduce the behaviour

update to linux-rpi 6.12.18-1,
go to kodi, try to play 4k movie.
It fails rendering correctly (lags and freezes)

Device (s)

Raspberry Pi 4 Mod. B

System

[root@kodi ~]# cat /etc/os-release NAME="Arch Linux ARM" PRETTY_NAME="Arch Linux ARM" ID=archarm ID_LIKE=arch BUILD_ID=rolling ANSI_COLOR="38;2;23;147;209" HOME_URL="https://archlinuxarm.org/" DOCUMENTATION_URL="https://archlinuxarm.org/wiki" SUPPORT_URL="https://archlinuxarm.org/forum" BUG_REPORT_URL="https://github.com/archlinuxarm/PKGBUILDs/issues" LOGO=archlinux-logo

[root@kodi ~]# vcgencmd version Feb 17 2025 20:03:07 Copyright (c) 2012 Broadcom version da7125f985dfe3cb0cf91e3c47f1ace88018e466 (clean) (release) (start)

Being in the stable mode I now run
[root@kodi ~]# uname -a Linux kodi 6.12.17-1-rpi #1 SMP Fri Feb 28 16:25:50 MST 2025 armv7l GNU/Linux
in non stable mode it's 6.12.18-1.

Logs

No response

Additional context

No response

[popcornmix]

I think an ffmpeg update is needed to go with the switch to the upstream hevc decoder.
See #6666

I think the important ffmpeg commit is jc-kynesim/rpi-ffmpeg@a4f8d3f (updating to the latest version of whichever downstream ffmpeg version is used by arch should include it).

[dinobagio]

OK @popcornmix thanks for sharing this.
But eventually, who could do what you suggest ?

[popcornmix]

You need to report this to the arch maintainers.
They may check here, but I'd imagine here would be a better place.

[dinobagio]

You need to report this to the arch maintainers.
They may check here, but I'd imagine here would be a better place.

But I see no ffmpeg in my arch arm distribution, could it be possible it's embedded in kodi-rpi ?

And therefore that means the issue should be adressed to kodi-rpi maintainers ?

[popcornmix]

I believe the arch maintainers build the kodi package themselves.
I don't know if arch uses the system ffmpeg, or an embedded one.
But in either case they need to handle including the updated patch.

[graysky2]

I see the update and rebuilt the patch. Thanks for the ping. FYI - ArchARM uses the internal ffmpeg.

[mkreisl]

I'll join in here
HEVC accelleration also no longer works for me with kernel 6.12.20, with 6.12.12 everything still works.
The new kernel module is loaded and the output of v4l2-compliance also looks ok (see below).
Of course I have updated the ffmpeg patches, but from the branch dev/7.1.1/rpi_import_1. Of course I have checked if it also contains the necessary adjustments, which is the case.
Kodi 22 Apha with buildin ffmpeg was rebuilt.
However, the HEVC videos are still decoded in software.

I can't tell you how annoyed I am about such a procedure, to make such changes in the middle of a kernel release. You just don't do that

When I go back to the older kernel, the HEVC videos are decoded into hardware again even with the updated Kodi
But why does this no longer work with the new kernel module?

In the logfile of kodi I find these entries

Mar 29 13:34:33 kmpifive 2025-03-29 13:34:33.199 T:6892    debug <general>: ffmpeg[0x0]: [hevc] Failed to find a V4L2 device for H265
Mar 29 13:34:33 kmpifive 2025-03-29 13:34:33.199 T:6892    error <general>: ffmpeg[0x0]: [hevc] Failed setup for format drm_prime: hwaccel initialisation returned error.

v4l2-compliance -d /dev/video19
v4l2-compliance 1.28.1, 64 bits, 64-bit time_t

Compliance test for rpi-hevc-dec device /dev/video19:

Driver Info:
        Driver name      : rpi-hevc-dec
        Card type        : rpi-hevc-dec
        Bus info         : platform:rpi-hevc-dec
        Driver version   : 6.12.20
        Capabilities     : 0x84204000
                Video Memory-to-Memory Multiplanar
                Streaming
                Extended Pix Format
                Device Capabilities
        Device Caps      : 0x04204000
                Video Memory-to-Memory Multiplanar
                Streaming
                Extended Pix Format
        Detected Stateless Decoder
Media Driver Info:
        Driver name      : rpi-hevc-dec
        Model            : rpi-hevc-dec
        Serial           : 
        Bus info         : platform:rpi-hevc-dec
        Media version    : 6.12.20
        Hardware revision: 0x00000000 (0)
        Driver version   : 6.12.20
Interface Info:
        ID               : 0x0300000c
        Type             : V4L Video
Entity Info:
        ID               : 0x00000001 (1)
        Name             : rpi-hevc-dec-source
        Function         : V4L2 I/O
        Pad 0x01000002   : 0: Source
          Link 0x02000008: to remote pad 0x1000004 of entity 'rpi-hevc-dec-proc' (Video Decoder): Data, Enabled, Immutable

Edit:
Maybe it's because of this commit: 7821b6a
I have Mesa 24.2.8 (Debian Bookworm Backport) or 25.0.2 (Debian Trixie) here.
in use

What a mess

[6by9]

I can't tell you how annoyed I am about such a procedure, to make such changes in the middle of a kernel release. You just don't do that

Raspberry Pi haven't declared 6.12 as being stable yet, therefore changes like this will be made. It's also why the branch is still being rebased instead of using merge commits.
If others have chosen to adopt it before it's been declared as stable, then IMHO that's down to their decision.

With #6666 the conscious decision was made to backport what will hopefully be fairly close to the driver that will get merged to mainline, hopefully within the next 6 months. If we didn't make that call now, then as we'll be sticking with 6.12 due to it being LTS, we wouldn't be able to move closer to that end goal until the next LTS release. It would also mean that the Trixie release due later this year would end up using the old driver. Jumping now was viewed as being worth the small amount of pain now to those who have chosen to be on the bleeding edge.

AIUI Mainline have decreed that the flags that were being searched for to identify an HEVC decoder were incorrect, so the driver (and FFmpeg) have been updated to correct that. You won't find a specific kernel commit for that as it is implicit behaviour of the new driver vs the old (reverted) driver. I believe https://github.com/jc-kynesim/rpi-ffmpeg/tree/test/7.1/main is the current branch that is released in Raspberry Pi OS.

In upstreaming the driver, the V4L2_PIX_FMT needed to change to account for their requirements. Support for both pixel formats was added downstream to reduce the pain in changing, and 7821b6a is a temporary revert of the new formats to make pixel choice easier. It won't inherently change the choosing of a suitable decoder.

[graysky2]

@dinobagio - did the update I pushed resolve the issue you reported?

[dinobagio]

Yes it did the job.

[graysky2]

Glad to hear it. @popcornmix thanks for the guidance, safe to close.