Pi 5 / 6.18.39: rpi_hevc_dec VIDIOC_STREAMOFF blocks forever (hevc_d_h265_stop) after a decode request stalls on a missing reference picture — process unkillable, decoder lost until reboot

Abierto
  • ¿Algo no está bien?
#7,609 3 comentarios 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
48/100
Tipo de issue
Error
Claridad
Bien especificado
Estado de actividad
Activo
Stack tecnológico
c, linux, raspberry-pi
Área
audio-video-rtc, embedded-iot, operating-systems

Línea de trabajo

Search the kernel source for hevc_d_h265_stop() and hevc_d_stop_streaming(), then reproduce the failure with the supplied gst-launch-1.0 command and missing-reference HEVC stream. Trace the stalled request through STREAMOFF and verify that timeout and recovery leave the process killable and allow the decoder to be reopened without rebooting.

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

Descripción

Describe the bug

On a Raspberry Pi 5, when the stateless HEVC decoder (rpi_hevc_dec, /dev/video19, used through GStreamer's v4l2slh265dec) is asked to decode a P-frame whose reference picture is missing, the hardware never completes that request. That part may be expected (garbage in). The bug is what happens next: VIDIOC_STREAMOFF on the device then blocks forever in hevc_d_h265_stop(). The calling process goes to D state, cannot be killed, and every later open of the decoder blocks as well — the HEVC decoder is gone until a reboot.

In practice any UDP packet loss on a live HEVC stream (RTSP → v4l2slh265dec) triggers it, because the picture after the loss references a frame that never arrived. A GStreamer client sees Decoding frame N took too long from gstv4l2codech265dec.c, tears the pipeline down, and hangs in the teardown.

To reproduce

Deterministic, no network involved:

  1. Take any HEVC Annex-B elementary stream (I used a 1280×720p60 Main-profile stream from an NVENC encoder, P-frames only; an x265 testsrc2 clip behaves the same).
  2. Remove one P-frame (one VCL NAL of type TRAIL_R plus its prefix SEI) from the file, e.g. the first P-frame after the IDR.
  3. Decode it on the hardware: 
    gst-launch-1.0 filesrc location=gap.hevc ! h265parse ! decodebin3 ! videoconvert ! video/x-raw,format=BGRx ! fakesink sync=false
  4. After ~1 s: v4l2slh265dec0: Decoding frame 1 took too long (gstv4l2decoder.c: Request 31 took too long.). gst-launch tries to shut the pipeline down and never returns; ps shows it in D state. After 120 s the hung-task detector fires (trace below). v4l2-ctl --list-devices and any further decoder open also block. Only a reboot recovers.

The same file with the P-frame present decodes fine at full speed, so the hardware and the driver are otherwise healthy.

Expected behaviour

VIDIOC_STREAMOFF must not block indefinitely. If the hardware does not finish a decode request, the driver should time out, reset the block and fail the request, so that a userspace client can recover (drop until the next IDR, reopen the device) without a reboot. Userspace cannot guarantee gap-free bitstreams on a lossy link.

Kernel trace

INFO: task gst-launch-1.0:14570 blocked for more than 120 seconds.
      Not tainted 6.18.39+rpt-rpi-2712 #1 Debian 1:6.18.39-1+rpt1
task:gst-launch-1.0  state:D stack:0     pid:14570 tgid:14570 ppid:14568  task_flags:0x400000 flags:0x00000009
Call trace:
 __switch_to+0xf0/0x1c8 (T)
 __schedule+0x3c8/0xc18
 schedule+0x3c/0xf0
 hevc_d_h265_stop+0xe4/0x120 [rpi_hevc_dec]
 hevc_d_stop_streaming+0x78/0x90 [rpi_hevc_dec]
 __vb2_queue_cancel+0x34/0x2e0 [videobuf2_common]
 vb2_core_streamoff+0x2c/0xd8 [videobuf2_common]
 vb2_streamoff+0x20/0x80 [videobuf2_v4l2]
 v4l2_m2m_streamoff+0x50/0x160 [v4l2_mem2mem]
 v4l2_m2m_ioctl_streamoff+0x20/0x40 [v4l2_mem2mem]
 v4l_streamoff+0x2c/0x40 [videodev]
 __video_do_ioctl+0x354/0x410 [videodev]
 video_usercopy+0x2c8/0x760 [videodev]
 video_ioctl2+0x20/0x40 [videodev]
 v4l2_ioctl+0x48/0x78 [videodev]
 __arm64_sys_ioctl+0xb4/0x120
 invoke_syscall+0x4c/0x100
 el0_svc_common.constprop.0+0x48/0xf0
 do_el0_svc+0x24/0x38
 el0_svc+0x38/0x120
 el0t_64_sync_handler+0xa0/0xe8
 el0t_64_sync+0x198/0x1a0

The same trace appears when the process is killed with SIGKILL while a decode is stalled (the v4l2_release path instead of the ioctl).

System

  • Raspberry Pi 5 Model B Rev 1.0, Raspberry Pi OS (Debian 13 / trixie), 64-bit
  • Linux 6.18.39+rpt-rpi-2712 #1 SMP PREEMPT Debian 1:6.18.39-1+rpt1 (2026-07-29) aarch64
  • linux-image-rpi-2712 1:6.18.39-1+rpt1, raspi-firmware 1:1.20260521-3, rpi-eeprom 28.30-1
  • GStreamer 1.26.2 (gstreamer1.0-plugins-bad 1.26.2-3+rpt3+deb13u2), v4l2slh265dec
  • Device registered as rpi-hevc-dec 1000800000.codec: Device registered as /dev/video19

Possibly related: #7537 (Pi 4B, v4l2slh265dec pipeline unkillable in D state after a seek). This one is on the Pi 5 and needs no seek, just a missing reference picture.

Lenguaje dominante
C
Estrellas
13.3k
Forks
5.5k
Merge medio
3 d 20 h
PR fusionados (30 d)
27

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.