bcm2835-codec H.264 decode: last ~100 frames never dequeued at end of stream (Chromium V4L2, Pi 3B+, kernel 6.12)

What happens

A <video> element playing H.264 in Chromium stops advancing roughly 3.3 s before the end of the file and never reaches the end. The element stays in a healthy state: readyState 2, paused false, error null, the whole file buffered. Because the ended event never fires, loop never restarts and any code waiting on ended waits forever. The rest of the page keeps rendering normally.

Playback runs to the end and loops correctly when Chromium is started with --disable-accelerated-video-decode.

Environment

• Raspberry Pi 3 Model B Plus Rev 1.3
• Raspberry Pi OS (Trixie), arm64, kernel 6.12
• Chromium 152, kiosk under cage (Wayland), 1280x720
• gpu_mem=128
• Hardware decode confirmed in use: the GPU process holds /dev/video10 open (bcm2835-codec-decode), verified with ls -l /proc/$(pgrep -f -- --type=gpu-process)/fd | grep video

Where it stalls

Element state sampled every 2 s over the DevTools protocol.

Both stall points sit about 3.3 s before the end, and both sources are 30 fps. That is roughly 100 frames in each case, which suggests a fixed queue rather than a fixed amount of time: the last ~100 frames appear to stay in the decoder and are never dequeued.

What has been ruled out

• The file: ffmpeg decodes it without error or warning.
• Container layout: moving moov to the front changes nothing.
• Stream structure: no B-frames, and a keyframe every 2 s, change nothing.
• Delivery: bypassing the service worker changes nothing.
• Duration: the same behaviour at 20 s and 40 s, at the same offset from the end.

Possibly related

This looks like the same class of problem as #5059 (frames left un-dequeued after CMD_STOP because V4L2_BUF_FLAG_LAST arrives early), but the trigger differs: #5059 is about mid-stream caps renegotiation on a Pi 4 through GStreamer, while this is at end of stream through Chromium's V4L2 decoder on a Pi 3. It is not established that it is the same bug.

Why it matters here

This is a digital signage fleet. A video that never reaches its end never loops, and a playlist that waits for ended stops advancing. The two workarounds available to us both cost something: software decoding drops 34% of frames at 720p30 at 84% CPU and 73 °C with soft thermal limiting active, and working around it in the player means dropping the last three seconds of every video.

Reproducing

Any H.264 file reproduces it. A self-contained sample:

ffmpeg -f lavfi -i testsrc2=size=1280x720:rate=30:duration=20 \
       -c:v libx264 -profile:v high -pix_fmt yuv420p -crf 23 -an sample.mp4

Load it in a <video loop> element in Chromium on a Pi 3B+ with hardware decode active and watch currentTime and readyState. It stops advancing around 16.7 s and stays there.