bcm2835-codec: SOURCE_CHANGE queued after last_buffer_dequeued, decoder stops without error
维护者通常 1 天内回复
还没有人认领这个 Issue。
评估
- 难度
- 4/5
- 预计耗时
- 3-5 天
- 新手友好度
- 32/100
- Issue 类型
- 缺陷
- 描述清晰度
- 描述清楚
- 活跃度
- 活跃
- 技术栈
- c
调研方向
Start from handle_fmt_changed() in the bcm2835-codec driver: it sets vq->last_buffer_dequeued before queue_res_chg_event(), so a v4l2_m2m_poll landing between the two writes reports EPOLLIN without EPOLLPRI and the decoder exits via GST_V4L2_FLOW_LAST_BUFFER. The proposed fix reorders the event before the flag and adds wake_up(&vq->done_wq); validate it against v4l2_m2m_poll and gst_v4l2_object_poll. Done means no silent stop across many looped starts on bcm2835 hardware with debug=1. Note the reporter is already testing this and will open a PR, so coordinate before starting.
由索引模型根据 Issue 内容生成。
描述
Pi 4 Model B Rev 1.5 4 GB, kernel 6.18.39-v8 (raspberrypi/linux 8307cc8d), GStreamer 1.26.11, playbin3 → v4l2h264dec → glimagesink under sway. H.264 High 4.1 1920x1080 25 fps + AAC, MP4 over HTTPS.
Our player loops a fixed playlist: the same images and the same two MP4 files, hundreds of times a day. At each start of the H.264 decoder, the firmware reports Format changed to 1920x1088 with an unchanged format (Format was 1920x1088). Most starts play fine. 1 start in 40 to 300 stops and never resumes: no bus error, the pipeline never prerolls, the screen stays on the last frame until a restart. The file and the firmware event stay the same, so we looked for a timing race. We see the freeze on 6 display units and reproduce it on a test unit with a different screen.
Sequence (bcm2835_codec debug=1, GST_DEBUG v4l2*:5):
- capture STREAMON (
bcm2835_codec_start_streaming: type: 9) - 18 to 28 ms later,
handle_fmt_changed: Format changed to 1920x1088and, in the same ms,gst_v4l2_video_dec_loop: Leaving output thread: custom-success - no
Sending EOS event; the decoder loop never dequeues the SOURCE_CHANGE event - on one more start, a flush dequeued the event 1 s later and playback recovered: 2 hits in 86 starts
Cause
handle_fmt_changed()setsvq->last_buffer_dequeued = true, then callsqueue_res_chg_event().v4l2_m2m_pollreports EPOLLIN from the flag underdone_lock, and EPOLLPRI from the event underfh_lock. A poll between the two writes returns EPOLLIN without EPOLLPRI.gst_v4l2_object_pollchecks POLLPRI first. Without it, the pool calls DQBUF, gets EPIPE and returnsGST_V4L2_FLOW_LAST_BUFFER.v4l2videodecthen leaves its output thread and posts no error.- During start-up, each returned input buffer wakes the capture poller, every millisecond or so, which keeps the window busy.
Proposed fix: queue the event first, then set the flag and wake the capture queue pollers.
+ /* A poll that sees the LAST state must also see the event */
+ queue_res_chg_event(ctx);
+
vq = v4l2_m2m_get_vq(ctx->fh.m2m_ctx, V4L2_BUF_TYPE_VIDEO_CAPTURE_MPLANE);
- if (vq->streaming)
+ if (vq->streaming) {
vq->last_buffer_dequeued = true;
-
- queue_res_chg_event(ctx);
+ wake_up(&vq->done_wq);
+ }
We're testing it now and will open a PR once it holds.
Related: #5059 shows the same start-up Format changed with an unchanged format. It's the same trigger and a different bug; neither fix covers the other.
- 主要语言
- C
- 星标
- 13.2k
- 派生
- 5.5k
- 平均合并
- 2 天 9 小时
- 30 天内合并 PR
- 21
环境准备
这个项目没有提供开发容器、Dockerfile 或贡献指南,环境需要你自己搭建:先看它的 README,通用步骤见我们的新手贡献指南。
从这里开始
- 先读完整个 Issue,再读项目的贡献指南。
- 在 Issue 下留言说明你要接手 —— 这能避免两个人做同样的事。
- Fork 仓库,在一个分支上完成修改。
- 提交 Pull Request,并在描述里引用这个 Issue 编号。
raspberrypi/linux 的其他 Issue
-
难度 2/5 1-3 小时 新手友好度 68/100
raspberrypi/linux#7415 · 2 条评论 · 1 个 reaction ·
维护者通常 1 天内回复
-
rp1-cfe doesn't forward V4L2_EVENT_SOURCE_CHANGE event from csi-2 sensor driver to userspace app未关闭
难度 2/5 1-3 小时 新手友好度 72/100
raspberrypi/linux#7399 · 1 条评论 ·
维护者通常 1 天内回复
-
难度 1/5 1 小时以内 新手友好度 82/100
raspberrypi/linux#7357 · 1 条评论 ·
维护者通常 1 天内回复
-
难度 2/5 1-3 小时 新手友好度 68/100
raspberrypi/linux#7054 · 2 条评论 ·
维护者通常 1 天内回复
-
难度 5/5 一周以上 新手友好度 32/100
raspberrypi/linux#7675 · 2 条评论 ·
维护者通常 1 天内回复
查看 raspberrypi/linux 的全部 Issue
相似的 Issue
-
难度 2/5 1-3 小时 新手友好度 72/100
EchoTools/nevr-runtime#264 ·
维护者通常 1 天内回复
-
category:port-update
难度 2/5 1-3 小时 新手友好度 72/100
维护者通常 2 天内回复
-
难度 2/5 1-3 小时 新手友好度 75/100
mypaint/libmypaint#209 ·
-
难度 2/5 1-3 小时 新手友好度 78/100
维护者通常 1 天内回复
-
[LOGO] Keenetic OS可能已有人在做 @Ivan-Alone 今天认领。 未关闭logo request
难度 2/5 1-3 小时 新手友好度 72/100
fastfetch-cli/fastfetch#2646 ·
维护者通常 1 天内回复