GStreamer: H.265 hardware decoding (v4l2slh265dec) fails on Trixie with 'format UNKNOWN'

[Falldaemon]

Describe the bug

GStreamer H.265 hardware decoding (v4l2slh265dec) appears to be broken on the latest Raspberry Pi OS (Trixie) builds. This bug manifests in two ways:

1. Local H.265 Files (.mkv): Attempting to play a local H.265 file (e.g., a 4K .mkv) causes GStreamer to fail completely with a GStreamer-CRITICAL ... format UNKNOWN error.

2. Adaptive H.265 Live Streams (HLS): Attempting to play an adaptive 4K H.265 live stream does not crash. Instead, playbin fails to negotiate the 4K H.265 stream (due to the same bug) and automatically falls back to a lower-resolution H.264 stream (e.g., 1440p).

The end result is that GStreamer does not use H.265 hardware acceleration on Trixie, making 4K playback impossible as it either crashes or downgrades the quality.

This bug does not exist on Raspberry Pi OS (Bookworm), where the same hardware decoding works correctly. This confirms it is a software regression in the Trixie packages.

Steps to reproduce the behaviour

1. Use a Raspberry Pi 4 Model B.
2. Install a fresh image of Raspberry Pi OS (Trixie) (64-bit).
3. Install GStreamer tools:

   sudo apt-get update
   sudo apt-get install gstreamer1.0-tools gstreamer1.0-plugins-bad gstreamer1.0-libav

4.Test 1: Local H.265 File (CRASH) Run gst-launch-1.0 on a known H.265 .mkv file.
gst-launch-1.0 playbin uri=file:///path/to/my/4K_H265_file.mkv
Result: The pipeline fails and prints the "format UNKNOWN" error (see Logs section).
5.Test 2: Adaptive H.265 Live Stream (DOWNGRADE) Run gst-launch-1.0 -v on a 4K HLS stream (e.g., TRT1 4K).
gst-launch-1.0 -v playbin uri=https://tv-trt1.medya.trt.com.tr/master.m3u8
Result: The stream plays, but the verbose output shows GStreamer selected a 1440p stream, not the 4K stream (see Additional context).

Device (s)

Raspberry Pi 4 Mod. B

System

• Device: Raspberry Pi 4 Model B
• OS Details (from /etc/os-release):
  PRETTY_NAME="Debian GNU/Linux 13 (trixie)"
  NAME="Debian GNU/Linux"
  VERSION_ID="13"
  VERSION="13 (trixie)"
  ID=debian
• Architecture: arm64 (aarch64)

Logs

(python3:4492): GStreamer-CRITICAL **: 00:15:41.268: gst_caps_filter_and_map_in_place: assertion 'gst_caps_is_writable (caps)' failed

(python3:4492): GStreamer-CRITICAL **: 00:15:41.268: gst_caps_append: assertion 'IS_WRITABLE (caps1)' failed
2025-11-13 00:15:41,269 - root - ERROR - GStreamer Hatası: Unsupported pixel format (../sys/v4l2codecs/gstv4l2codech265dec.c(434): gst_v4l2_codec_h265_dec_negotiate (): /GstPlayBin:playbin2/GstURIDecodeBin:uridecodebin1/GstDecodeBin:decodebin1/v4l2slh265dec:v4l2slh265dec0:
No support for 3840x2160 format UNKNOWN)

Additional context

Log output from "Test 2" (Adaptive HLS stream) confirms that playbin failed to negotiate the 4K H.265 stream and fell back to a 1440p (H.264?) stream:

.../GstPlayBin:playbin0/GstPlaySink:playsink/GstBin:vbin.GstGhostPad:sink.GstProxyPad:proxypad12: caps = video/x-raw, format=(string)I420, width=(int)2560, height=(int)1440, interlace-mode=(string)progressive, pixel-aspect-ratio=(fraction)1/1, chroma-site=(string)mpeg2, colorimetry=(string)bt709, framerate=(fraction)25/1

[Falldaemon]

UPDATE 2 (CRITICAL):
The bug is not limited to H.265. Hardware acceleration for H.264 also fails on Trixie.

I tested the same adaptive HLS stream (https://tv-trt1.medya.trt.com.tr/master.m3u8) in VLC.

VLC also failed to play the 4K H.265 stream and fell back to the 1440p H.264 stream. However, VLC then also failed to start the H.264 hardware decoder (h264_v4l2m2m) and fell back to CPU/software decoding.

This resulted in 75% CPU usage just to play a 1440p stream.

VLC Log confirming the H.264 hardware failure:
[0000007f6440cfd0] avcodec decoder error: cannot start codec (h264_v4l2m2m)

VLC Log confirming fallback to 1440p:
[0000007f34001ce0] wl_dmabuf vout display: <<< Open: I420 2560x1442(2560x1440 ...

This proves that both v4l2slh265dec (H.265) and h264_v4l2m2m (H.264) hardware decoders are broken in Trixie.

[6by9]

GStreamer's v4l2slh265dec doesn't have support for the pixel format used by the Pi HEVC decoder.
I have an open MR at https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/9247 that adds this, but it is also against the driver as it is being upstreamed and not the current downstream version. There will be a rationalisation once things are reviewed.

There is basic support for DMAbuf passthrough which maps a DRM format and modifier through from V4L2 to some renderers.

Testing with a current Trixie release with 6.12.47-v8 kernel under labwc.
Playback of local 8bit HEVC clips is fine.
10bit files will throw an "unsupported pixel format" error as there is no GStreamer mapping from the pixel format.
Playback of H264 is fine.

gst-launch-1.0 -v playbin uri=https://tv-trt1.medya.trt.com.tr/master.m3u8 gives me an H264 stream, not HEVC/H265.
It appears to try and dynamically change resolution up to 2560x1440. The H264 decoder is limited to 1080p (always has been), so that will fail, and a fall back to software is inevitable.
VLC on that uri also is fine with the initial 640x360, and then switches to software for 2560x1440.

Trying outside of labwc for some reason playbin can't determine a suitable rendering pipe.
Manually configuring my pipeline with gst-launch-1.0 -ev filesrc location=h264.mkv ! matroskademux ! h264parse ! v4l2h264dec ! kmssink gives me perfect decoding. Same with gst-launch-1.0 -ev filesrc location=h265.mkv ! matroskademux ! h265parse ! v4l2slh2645dec ! kmssink
Adding a video-sink=kmssink to the playbin line make 8bit HEVC work, but not H264 for some reason.

I haven't tried against Bookworm, but I would be amazed if there was any difference there - the 1080p limit on H264 decode and no GStreamer support for 10bit HEVC aren't new things.