Hacktoberfest 2026：メンテナが10月に向けて印を付けた、オープンで初心者向けの issue。 Hacktoberfest の issue を見る

bcm2835-codec: SOURCE_CHANGE queued after last_buffer_dequeued, decoder stops without error

オープン
  • 何か問題がありますか？
#7,674 コメント 1 件 リアクション 0 件 担当者 0 名 GitHub で見る

メンテナーはふだん 1 日以内に返信

まだ誰も着手していません。

評価

難易度
4/5
見積もり時間
3〜5日
初心者へのやさしさ
32/100
issue の種類
バグ
明瞭さ
明確に書かれている
活発さ
活発
技術スタック
c
領域
operating-systems

調査の方向性

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 1920x1088 and, 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() sets vq->last_buffer_dequeued = true, then calls queue_res_chg_event().
  • v4l2_m2m_poll reports EPOLLIN from the flag under done_lock, and EPOLLPRI from the event under fh_lock. A poll between the two writes returns EPOLLIN without EPOLLPRI.
  • gst_v4l2_object_poll checks POLLPRI first. Without it, the pool calls DQBUF, gets EPIPE and returns GST_V4L2_FLOW_LAST_BUFFER. v4l2videodec then 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日 4時間
マージ済み PR（30日）
20

環境構築

このプロジェクトには開発コンテナ、Dockerfile、コントリビューションガイドがありません。まず README を読み、一般的な手順ははじめてのコントリビューションガイドを参照してください。

はじめの一歩

  1. issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
  2. 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
  3. リポジトリをフォークし、ブランチを切って変更します。
  4. issue 番号を参照したプルリクエストを送ります。

raspberrypi/linux のほかの issue

raspberrypi/linux の issue をすべて見る

似ている issue

C の issue をもっと見る

新しい issue をメールで受け取る

初心者向けの GitHub issue を短くまとめたダイジェスト。