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

未關閉
  • 哪裡不對？
#7,618 0 則留言 0 個 reaction 已指派 0 人 在 GitHub 檢視

維護者通常 1 天內回覆

還沒有人認領這個 Issue。

評估

難度
4/5
預估耗時
3-5 天
新手友好度
48/100
Issue 類型
缺陷
描述清晰度
基本清楚
活躍度
活躍
技術堆疊
c, linux
領域
audio-video-rtc, operating-systems

研究方向

Reproduce the stall with the provided ffmpeg sample in Chromium on a Pi 3B+ with hardware decoding enabled, then inspect the bcm2835-codec V4L2 end-of-stream and buffer-dequeue handling around /dev/video10. Compare the behavior with the early V4L2_BUF_FLAG_LAST case described in #5059. Done means playback reaches the final frame and the video element emits ended without disabling hardware decoding.

由索引模型根據 Issue 內容生成。

描述

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.

source stalls at duration
original, H.264 High, B-frames, moov at end 16.76 s 20 s
same stream, moov moved to front 16.81 s 20 s
re-encoded without B-frames 16.77 s 20 s
keyframe every 2 s (last at 18.0 s) 16.75 s 20 s
40 s version of the same content 36.67 s 40 s
original, service worker bypassed 16.75 s 20 s
original, --disable-accelerated-video-decode plays to end, loops 20 s

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.

主要語言
C
星號
13.3k
分支
5.5k
平均合併
3 天 20 小時
30 天內合併 PR
27

環境準備

這個專案沒有提供開發容器、Dockerfile 或貢獻指南，環境需要你自己搭建：先看它的 README，通用步驟見我們的新手貢獻指南。

從這裡開始

  1. 先讀完整個 Issue，再讀專案的貢獻指南。
  2. 在 Issue 下留言說明你要接手 —— 這能避免兩個人做同樣的事。
  3. Fork 儲存庫，在一個分支上完成修改。
  4. 送出 Pull Request，並在描述裡引用這個 Issue 編號。

raspberrypi/linux 的其他 Issue

查看 raspberrypi/linux 的全部 Issue

相似的 Issue

更多 C Issue

把新 issue 寄到你的電子郵件信箱

精選適合新手參與的 GitHub issue 摘要。