rpivid: "phase1_cb: Post wait: 0xffffffff" on every frame with GStreamer v4l2slh265dec, broken decode — ffmpeg works fine on same driver (Pi 4B & Pi 5)

[youssefqarri]

test_hevc_1080p25.mp4

Describe the bug

Describe the bug

Decoding 1080p25 HEVC (Main, yuv420p) through GStreamer's stateless decoder v4l2slh265dec triggers a kernel error from the rpivid driver on every single frame (250 frames → 250 errors) and produces broken output. The same file decodes flawlessly on the same device/driver via ffmpeg's V4L2 request-API hwaccel (zero kernel errors), so the hardware and the stream are fine — this looks like an incompatibility between GStreamer's v4l2codecs plugin and rpivid.

Environment

• Raspberry Pi 4B and Raspberry Pi 5 — both reproduce, identical signature (feb00000.codec / 1000800000.codec)
• Raspberry Pi OS (Debian 13 trixie), kernel 6.12.47+rpt-rpi-v8
• GStreamer 1.26.2 (gstreamer1.0-plugins-bad 1.26.2-3+rpt3+deb13u2)
• Test file attached: 10 s SMPTE bars, 1080p25, HEVC Main (libx265, keyint=50, hvc1)

Steps to reproduce

gst-launch-1.0 filesrc location=test_hevc_1080p25.mp4 ! qtdemux ! h265parse ! v4l2slh265dec ! fakevideosink sync=false

Result — dmesg shows one error per decoded frame (250 for this 10 s clip, on both models):

rpi-hevc-dec feb00000.codec: phase1_cb: Post wait: 0xffffffff
With a real sink (kmssink), playback runs at ~41 % of realtime with corrupted fr

https://github.com/user-attachments/assets/07a97b8e-97f9-4cd1-8e6f-3690159a337d

ames.

Control test — same file, same device, same driver, via ffmpeg: realtime hardware decode, exit 0, zero kernel errors:

ffmpeg -hwaccel drm -i test_hevc_1080p25.mp4 -f null -

Notes

• Possibly related to #6873 (same message appears there as log spam, but that reporter has smooth playback under Kodi; here the decode output is actually broken).
• Possibly related to missing SAND (NC12/NC30) format support in GStreamer v4l2codecs (discussed on GStreamer Discourse).
• We can reproduce at will on both models and are happy to test any diagnostic patch.

Steps to reproduce the behaviour

gst-launch-1.0 filesrc location=test_hevc_1080p25.mp4 ! qtdemux ! h265parse ! v4l2slh265dec ! fakevideosink sync=false

Device (s)

Raspberry Pi 5, Raspberry Pi 4 Mod. B

System

Raspberry Pi OS (Debian 13 trixie), kernel 6.12.47+rpt-rpi-v8

Logs

No response

Additional context

No response

[6by9]

The GStreamer v4l2slh265dec support requires the 6.18 kernel which is standard with Raspberry Pi OS Trixie.

Updating your system should be the first step before even considering raising an issue.

[youssefqarri]

Confirmed. Upgrading to kernel 6.18.39 (linux-image-rpi-v8 / linux-image-rpi-2712, 1:6.18.39-1+rpt1) fixes it on both Pi 4B and Pi 5: same test file, same pipeline, zero kernel errors (was one phase1_cb: Post wait error per frame on 6.12.47). Closing. Thanks!

[youssefqarri]

Follow-up: 6.18.39 does fix the per-frame phase1_cb errors reported here — plain playback is now clean on both Pi 4B and Pi 5. However, while validating the fix we hit a different issue on Pi 4B only: an accurate seek before playback wedges the process in unkillable D state (sometimes with a WARNING at drivers/media/mc/mc-request.c:470), reboot required. Since the symptom, the code path and the affected models all differ, I'm opening a separate issue for it: #7537. This one can stay closed.