Hacktoberfest 2026: los issues que los mantenedores marcaron para octubre, abiertos y aptos para principiantes. Explorar issues de Hacktoberfest

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

Abierto
  • ¿Algo no está bien?
#7,674 1 comentario 0 reacciones 0 asignados Ver en GitHub

Los mantenedores suelen responder en 1 día

Nadie ha tomado este issue todavía.

Evaluación

Dificultad
4/5
Tiempo estimado
3-5 días
Aptitud para principiantes
32/100
Tipo de issue
Error
Claridad
Bien especificado
Estado de actividad
Activo
Stack tecnológico
c
Área
operating-systems

Línea de trabajo

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.

Escrito por el modelo de indexación a partir del texto del issue.

Descripción

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.

Lenguaje dominante
C
Estrellas
13.2k
Forks
5.5k
Merge medio
2 d 2 h
PR fusionados (30 d)
19

Preparar el entorno

Este proyecto no incluye contenedor de desarrollo, Dockerfile ni guía de contribución, así que la configuración corre por tu cuenta: empieza por su README y consulta nuestra guía para la primera contribución para los pasos generales.

Primeros pasos

  1. Lee el issue completo y luego la guía de contribución del proyecto.
  2. Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
  3. Haz un fork del repositorio y trabaja en una rama.
  4. Abre un pull request que haga referencia al número del issue.

Más de raspberrypi/linux

Todos los issues de raspberrypi/linux

Issues similares

Más issues de C

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.