CM4: bcm2835-codec / bcm2835_mmal_vchiq timeouts and videobuf2 "driver bug" when stopping broken live H.264
Describe the bug
I have noticed the following error. I start an RTP stream from our TV provider. After a few seconds or minutes, the image freezes, but the sound continues to play.
I can confirm this with a high degree of certainty on CM4, Bookworm, kernel 6.12.47+rpt-rpi-v8. CM4, Bullseye, kernel 5.x also has this error, but it takes longer. CM5, Bookworm, kernel 6.12.47+rpt-rpi-v8 has this error never.
play the stream from rtp://@239.186.68.1:10000, after a few seconds or minutes the screen freezes, audio still go on cvlc rtp://@239.186.68.1:10000 --audio-track=0 --aspect-ratio=16:9 --network-caching=1000 -f --no-osd --vout=opengles --width=1920 --height=1080
dmesg [ 414.295487] vc4-drm gpu: swiotlb buffer is full (sz: 1572864 bytes), total 32768 (slots), used 1619 (slots) [ 414.314773] vc4-drm gpu: swiotlb buffer is full (sz: 3121152 bytes), total 32768 (slots), used 1 (slots) [ 414.366952] vc4-drm gpu: swiotlb buffer is full (sz: 327680 bytes), total 32768 (slots), used 1 (slots) [ 415.647809] vc4-drm gpu: swiotlb buffer is full (sz: 1290240 bytes), total 32768 (slots), used 73 (slots) [ 418.120075] vc4-drm gpu: swiotlb buffer is full (sz: 524288 bytes), total 32768 (slots), used 1119 (slots) [ 421.383858] vc4-drm gpu: swiotlb buffer is full (sz: 524288 bytes), total 32768 (slots), used 3463 (slots) [ 423.464651] vc4-drm gpu: swiotlb buffer is full (sz: 524288 bytes), total 32768 (slots), used 1143 (slots) [ 424.469852] vc4-drm gpu: swiotlb buffer is full (sz: 524288 bytes), total 32768 (slots), used 2117 (slots) [ 425.471839] vc4-drm gpu: swiotlb buffer is full (sz: 524288 bytes), total 32768 (slots), used 2697 (slots) [ 430.172846] vc4-drm gpu: swiotlb buffer is full (sz: 524288 bytes), total 32768 (slots), used 3511 (slots) [ 444.847048] vc4-drm gpu: swiotlb buffer is full (sz: 524288 bytes), total 32768 (slots), used 3521 (slots) [ 446.855413] vc4-drm gpu: swiotlb buffer is full (sz: 348160 bytes), total 32768 (slots), used 63 (slots) [ 467.464871] vc4-drm gpu: swiotlb buffer is full (sz: 524288 bytes), total 32768 (slots), used 3339 (slots) [ 527.467992] vc4-drm gpu: swiotlb buffer is full (sz: 524288 bytes), total 32768 (slots), used 3375 (slots) [ 658.066479] vc4-drm gpu: swiotlb buffer is full (sz: 524288 bytes), total 32768 (slots), used 1043 (slots) [ 664.052385] bcm2835_mmal_vchiq: timed out waiting for sync completion [ 664.052406] bcm2835-codec bcm2835-codec: bcm2835_codec_stop_streaming: Failed disabling i/p port, ret -62 [ 667.124422] bcm2835_mmal_vchiq: timed out waiting for sync completion [ 667.124443] bcm2835-codec bcm2835-codec: bcm2835_codec_stop_streaming: Failed disabling o/p port, ret -62
Steps to reproduce the behaviour
Use a CM4 with Bookworm and kernel 6.12.47+rpt-rpi-v8
Since my TV signal from our provider is only available locally here, I logged this for about 5 minutes so that you can reproduce it.
Download Teststream from: http://www.dreidb.ch/stream_239.186.68.1_10000_2025-12-03_13-20-51.ts
Play stream with:
cvlc stream_239.186.68.1_10000_2025-12-03_13-20-51.ts -f
After a few seconds or minutes, the videopicture freezes, but the sound continues to play. If this does not happen, restart Raspberry Pi and try again.
In case of an error, check the logs below the cvlc call and in dmesg.
Example: play the ts-stream, after a few seconds or minutes the screen freezes, audio still go on cvlc stream_239.186.68.1_10000_2025-12-03_13-20-51.ts -f VLC media player 3.0.21 Vetinari (revision 3.0.21-0-gdd8bfdbabe8) Fernsteuerungs-Interface initialisiert. `help' für Hilfe eingeben. [00a395b0] dummy interface: using the dummy interface module... [e81060e8] avcodec decoder error: unspecified video dimensions [00a2de80] main audio output error: too low audio sample frequency (0) [e8120200] main decoder error: failed to create audio output [e81060e8] main decoder error: buffer deadlock prevented [00a2de80] vlcpulse audio output error: digital pass-through stream connection failure: Eingabe/Ausgabe-Fehler [00a2de80] main audio output error: module not functional [e8120200] main decoder error: failed to create audio output status change: ( audio volume: 256 ) [00a88b88] wl_xdg_shell window: <<< WL XDG: 1280x720 fs 1 standalone 0 [e810e360] wl_dmabuf vout display: <<< Open: DPV0 1280x720(1280x720 @ 0,0 0/0), cfg.display: 1280x720, source: 1280x720(1280x720 @ 0,0 1/1), scale=0/0 [e81060e8] avcodec decoder: Using DRM Video Accel for hardware decoding status change: ( audio volume: 256 ) status change: ( audio volume: 256 ) status change: ( audio volume: 256 )
dmesg: [ 184.293578] bcm2835_mmal_vchiq: timed out waiting for sync completion [ 184.293602] bcm2835-codec bcm2835-codec: bcm2835_codec_stop_streaming: Failed disabling i/p port, ret -62 [ 187.365732] bcm2835_mmal_vchiq: timed out waiting for sync completion [ 187.365751] bcm2835-codec bcm2835-codec: bcm2835_codec_stop_streaming: Failed disabling o/p port, ret -62 [ 189.381863] bcm2835-codec bcm2835-codec: bcm2835_codec_flush_buffers: Timeout waiting for buffers to be returned - 19 outstanding [ 192.486049] bcm2835_mmal_vchiq: timed out waiting for sync completion [ 192.486067] bcm2835-codec bcm2835-codec: bcm2835_codec_stop_streaming: Failed enabling component, ret -62 [ 192.486143] ------------[ cut here ]------------ [ 192.486148] WARNING: CPU: 3 PID: 2751 at drivers/media/common/videobuf2/videobuf2-core.c:2215 __vb2_queue_cancel+0x238/0x2d8 [videobuf2_common] [ 192.486177] Modules linked in: cfg80211 rfcomm snd_seq_dummy snd_hrtimer snd_seq uinput cmac algif_hash aes_arm64 aes_generic algif_skcipher af_alg bnep sg binfmt_misc vc4 snd_soc_hdmi_codec snd_usb_audio hci_uart v3d btbcm drm_display_helper rpi_hevc_dec cec gpu_sched bcm2835_codec(C) drm_dma_helper drm_shmem_helper snd_hwdep bluetooth snd_soc_core bcm2835_v4l2(C) drm_kms_helper uvcvideo snd_usbmidi_lib bcm2835_isp(C) joydev uvc snd_rawmidi snd_bcm2835(C) snd_compress ecdh_generic snd_seq_device bcm2835_mmal_vchiq(C) snd_pcm_dmaengine snd_pcm ecc vc_sm_cma(C) videobuf2_vmalloc v4l2_mem2mem videobuf2_dma_contig videobuf2_memops rfkill videobuf2_v4l2 libaes videodev videobuf2_common snd_timer raspberrypi_hwmon mc i2c_brcmstb i2c_bcm2835 snd pwm_bcm2835 raspberrypi_gpiomem nvmem_rmem hid_multitouch uio_pdrv_genirq uio i2c_dev ledtrig_pattern drm fuse dm_mod drm_panel_orientation_quirks backlight ip_tables x_tables ipv6 [ 192.486358] CPU: 3 UID: 1000 PID: 2751 Comm: vlc Tainted: G C 6.12.47+rpt-rpi-v8 #1 Debian 1:6.12.47-1+rpt1~bookworm [ 192.486368] Tainted: [C]=CRAP [ 192.486372] Hardware name: Raspberry Pi Compute Module 4 Rev 1.1 (DT) [ 192.486376] pstate: 80000005 (Nzcv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--) [ 192.486381] pc : __vb2_queue_cancel+0x238/0x2d8 [videobuf2_common] [ 192.486395] lr : __vb2_queue_cancel+0x34/0x2d8 [videobuf2_common] [ 192.486407] sp : ffffffc08bc83a30 [ 192.486410] x29: ffffffc08bc83a30 x28: ffffff808a792100 x27: 0000000000000009 [ 192.486421] x26: 0000000000000001 x25: 0000000000000000 x24: ffffff808a792700 [ 192.486430] x23: ffffff80408b8da0 x22: ffffff8084451428 x21: ffffff8044f0fd48 [ 192.486440] x20: ffffff80844514d0 x19: ffffff8084451428 x18: 00000000fffffffe [ 192.486449] x17: 656c696146203a67 x16: 6e696d6165727473 x15: 5f706f74735f6365 [ 192.486459] x14: 646f635f35333832 x13: 32362d2074657220 x12: 2c746e656e6f706d [ 192.486468] x11: 6f6320676e696c62 x10: ffffffddd589d4f0 x9 : ffffffddd411e820 [ 192.486477] x8 : 00000000ffffefff x7 : ffffffddd589d4f0 x6 : 80000000fffff000 [ 192.486487] x5 : ffffff80f7be2408 x4 : 0000000000000000 x3 : 0000000000000000 [ 192.486496] x2 : 0000000000000000 x1 : 0000000000000000 x0 : 0000000000000013 [ 192.486505] Call trace: [ 192.486509] __vb2_queue_cancel+0x238/0x2d8 [videobuf2_common] [ 192.486522] vb2_core_queue_release+0x2c/0x88 [videobuf2_common] [ 192.486534] vb2_queue_release+0x18/0x30 [videobuf2_v4l2] [ 192.486546] v4l2_m2m_ctx_release+0x28/0x50 [v4l2_mem2mem] [ 192.486562] bcm2835_codec_release+0x64/0x110 [bcm2835_codec] [ 192.486571] v4l2_release+0xec/0x100 [videodev] [ 192.486617] __fput+0xd0/0x2e0 [ 192.486632] ____fput+0x1c/0x30 [ 192.486640] task_work_run+0x80/0xe8 [ 192.486647] do_exit+0x2f0/0x9b8 [ 192.486654] do_group_exit+0x3c/0xa0 [ 192.486660] get_signal+0x9b4/0x9d0 [ 192.486667] do_signal+0x100/0x1128 [ 192.486673] do_notify_resume+0xd0/0x150 [ 192.486680] el0_svc_compat+0x6c/0x80 [ 192.486690] el0t_32_sync_handler+0x98/0x140 [ 192.486698] el0t_32_sync+0x194/0x198 [ 192.486703] ---[ end trace 0000000000000000 ]--- [ 192.486708] videobuf2_common: driver bug: stop_streaming operation is leaving buffer 0 in active state [ 192.486714] videobuf2_common: driver bug: stop_streaming operation is leaving buffer 1 in active state [ 192.486718] videobuf2_common: driver bug: stop_streaming operation is leaving buffer 2 in active state [ 192.486722] videobuf2_common: driver bug: stop_streaming operation is leaving buffer 3 in active state [ 192.486726] videobuf2_common: driver bug: stop_streaming operation is leaving buffer 4 in active state [ 192.486729] videobuf2_common: driver bug: stop_streaming operation is leaving buffer 5 in active state [ 192.486733] videobuf2_common: driver bug: stop_streaming operation is leaving buffer 6 in active state [ 192.486737] videobuf2_common: driver bug: stop_streaming operation is leaving buffer 7 in active state [ 192.486741] videobuf2_common: driver bug: stop_streaming operation is leaving buffer 8 in active state [ 192.486744] videobuf2_common: driver bug: stop_streaming operation is leaving buffer 9 in active state [ 192.486748] videobuf2_common: driver bug: stop_streaming operation is leaving buffer 10 in active state [ 192.486752] videobuf2_common: driver bug: stop_streaming operation is leaving buffer 11 in active state [ 192.486756] videobuf2_common: driver bug: stop_streaming operation is leaving buffer 12 in active state [ 192.486759] videobuf2_common: driver bug: stop_streaming operation is leaving buffer 13 in active state [ 192.486763] videobuf2_common: driver bug: stop_streaming operation is leaving buffer 14 in active state [ 192.486767] videobuf2_common: driver bug: stop_streaming operation is leaving buffer 15 in active state [ 192.486771] videobuf2_common: driver bug: stop_streaming operation is leaving buffer 16 in active state [ 192.486774] videobuf2_common: driver bug: stop_streaming operation is leaving buffer 18 in active state [ 192.486778] videobuf2_common: driver bug: stop_streaming operation is leaving buffer 19 in active state [ 195.558223] bcm2835_mmal_vchiq: timed out waiting for sync completion [ 198.630386] bcm2835_mmal_vchiq: timed out waiting for sync completion
Device (s)
Raspberry Pi CM4 Lite
System
Raspberry Pi reference 2025-05-13 Generated using pi-gen, https://github.com/RPi-Distro/pi-gen, f548f25325e28bea61904f5038a9b9fd0c92b07b, stage4 Aug 20 2025 17:02:31 Copyright (c) 2012 Broadcom version cd866525580337c0aee4b25880e1f5f9f674fb24 (clean) (release) (start) Linux trinity-65281-CM4 6.12.47+rpt-rpi-v8 #1 SMP PREEMPT Debian 1:6.12.47-1+rpt1~bookworm (2025-09-16) aarch64 GNU/Linux
Logs
See above
Additional context
I can imagine that the stream is not entirely compliant, but this kind of behavior should not occur. CM4 with kernel 5 can handle it for hours before showing the error externally, while CM5 is not affected at all.
CM5, Bookworm, kernel 6.12.47+rpt-rpi-v8 has this error never.
CM5 has no hardware H264 decoder, so that's just using software decode.
Are you running with a GUI running, or direct to DRM for fullscreen? And does the display refresh rate match the 50fps of your stream? And at what resolution?
Are you running with a GUI running, or direct to DRM for fullscreen? And does the display refresh rate match the 50fps of your stream? And at what resolution?
On Bookworm I’m running the standard Raspberry Pi OS desktop with Wayland.
I start VLC/mpv from a terminal inside the GUI and they render into normal fullscreen windows (Wayland + dmabuf / gpu output), not from a bare DRM console.
The display is a 1920×1080 panel connected via HDMI. It runs at 60 Hz (1920×1080@60).
For debugging purposes please add start_debug=1 to /boot/firmware/config.txt and reboot.
When it goes wrong, grab the output from sudo vclog -m and sudo vclog -a.
I have tried this on Trixie under labwc, and it's been fine on the few passes that I've given it.
In fullscreen mode it should be rendering direct to DRM with the YUV420 frame, so kmsprint should report the plane having a YU12 framebuffer on it. If not, then it'll be doing GPU composition of the scene to produce an XR24 frame.
I enabled start_debug=1 in /boot/firmware/config.txt, rebooted, and reproduced the issue on the CM4 (Bookworm). Right after the video froze / player was stopped, I collected:
cat vclog-a_2025-12-03_17-22-15.log 225480.317: assert( one == 1 ) failed; ../../../../../codecs/video/hw/dec3/h264/h264_parse.c::h264_parse_sei_ol line 2089
225882.792: assert( one == 1 ) failed; ../../../../../codecs/video/hw/dec3/h264/h264_parse.c::h264_parse_sei_ol line 2089
226283.702: assert( one == 1 ) failed; ../../../../../codecs/video/hw/dec3/h264/h264_parse.c::h264_parse_sei_ol line 2089
226684.517: assert( one == 1 ) failed; ../../../../../codecs/video/hw/dec3/h264/h264_parse.c::h264_parse_sei_ol line 2089
227085.457: assert( one == 1 ) failed; ../../../../../codecs/video/hw/dec3/h264/h264_parse.c::h264_parse_sei_ol line 2089
227486.338: assert( one == 1 ) failed; ../../../../../codecs/video/hw/dec3/h264/h264_parse.c::h264_parse_sei_ol line 2089
227887.348: assert( one == 1 ) failed; ../../../../../codecs/video/hw/dec3/h264/h264_parse.c::h264_parse_sei_ol line 2089
228288.617: assert( one == 1 ) failed; ../../../../../codecs/video/hw/dec3/h264/h264_parse.c::h264_parse_sei_ol line 2089
228689.428: assert( one == 1 ) failed; ../../../../../codecs/video/hw/dec3/h264/h264_parse.c::h264_parse_sei_ol line 2089
229090.439: assert( one == 1 ) failed; ../../../../../codecs/video/hw/dec3/h264/h264_parse.c::h264_parse_sei_ol line 2089
229491.329: assert( one == 1 ) failed; ../../../../../codecs/video/hw/dec3/h264/h264_parse.c::h264_parse_sei_ol line 2089
229892.262: assert( one == 1 ) failed; ../../../../../codecs/video/hw/dec3/h264/h264_parse.c::h264_parse_sei_ol line 2089
230293.072: assert( one == 1 ) failed; ../../../../../codecs/video/hw/dec3/h264/h264_parse.c::h264_parse_sei_ol line 2089
cat vclog-m_2025-12-03_17-22-12.log 003601.301: arasan: arasan_emmc_open 003601.472: arasan: arasan_emmc_set_clock C0: 0x00800000 C1: 0x000e0047 emmc: 200000000 actual: 390625 div: 0x00000100 target: 400000 min: 400000 max: 400000 delay: 5 003706.259: arasan: arasan_emmc_set_clock C0: 0x00800000 C1: 0x000e0047 emmc: 200000000 actual: 390625 div: 0x00000100 target: 400000 min: 400000 max: 400000 delay: 5 003706.345: arasan: arasan_emmc_set_clock C0: 0x00800f00 C1: 0x000e0047 emmc: 200000000 actual: 390625 div: 0x00000100 target: 400000 min: 390000 max: 400000 delay: 5 003724.741: boot-part: 0 fs-type: 0 003724.751: boot-part: 0 fs-type: 3 003724.888: arasan: arasan_emmc_set_clock C0: 0x00800f06 C1: 0x000e0207 emmc: 200000000 actual: 50000000 div: 0x00000002 target: 50000000 min: 0 max: 50000000 delay: 1 003810.361: brfs: File read: /mfs/sd/config.txt 003811.440: brfs: File read: 1679 bytes 003869.272: HDMI1:EDID error reading EDID block 0 attempt 0 003870.289: HDMI1:EDID giving up on reading EDID block 0 003875.366: brfs: File read: /mfs/sd/config.txt 003876.353: gpioman: gpioman_get_pin_num: pin DISPLAY_SDA not defined 003876.373: gpioman: gpioman_get_pin_num: pin LEDS_PWR_OK not defined 004367.384: gpioman: gpioman_get_pin_num: pin LEDS_PWR_OK not defined 004368.813: *** Restart logging 004368.831: brfs: File read: 1679 bytes 004411.827: hdmi: HDMI1:EDID error reading EDID block 0 attempt 0 004412.843: hdmi: HDMI1:EDID giving up on reading EDID block 0 004417.886: hdmi: HDMI1:EDID error reading EDID block 0 attempt 0 004418.903: hdmi: HDMI1:EDID giving up on reading EDID block 0 004418.920: hdmi: HDMI:hdmi_get_state is deprecated, use hdmi_get_display_state instead 004418.934: HDMI0: hdmi_pixel_encoding: 300000000 004418.948: HDMI1: hdmi_pixel_encoding: 300000000 004442.594: dtb_file 'bcm2711-rpi-cm4.dtb' 004451.299: brfs: File read: /mfs/sd/bcm2711-rpi-cm4.dtb 004451.317: Loaded 'bcm2711-rpi-cm4.dtb' to 0x100 size 0xddea 004465.131: brfs: File read: 56810 bytes 004482.196: brfs: File read: /mfs/sd/overlays/overlay_map.dtb 004507.155: brfs: File read: 5887 bytes 004508.519: brfs: File read: /mfs/sd/config.txt 004508.635: dtparam: spi=off 004518.055: brfs: File read: 1679 bytes 004544.508: brfs: File read: /mfs/sd/overlays/vc4-kms-v3d-pi4.dtbo 004608.190: Loaded overlay 'vc4-kms-v3d-pi4' 005001.012: brfs: File read: 3913 bytes 005008.489: brfs: File read: /mfs/sd/overlays/dwc2.dtbo 005024.082: Loaded overlay 'dwc2' 005024.104: dtparam: dr_mode=host 005053.737: brfs: File read: 801 bytes 005075.972: brfs: File read: /mfs/sd/overlays/pwm.dtbo 005092.931: Loaded overlay 'pwm' 005092.952: dtparam: pin=19 005093.361: dtparam: func=2 005094.106: dtparam: ant2=true 005214.014: brfs: File read: 948 bytes 005220.906: brfs: File read: /mfs/sd/overlays/disable-wifi.dtbo 005243.515: Loaded overlay 'disable-wifi' 005278.560: brfs: File read: 387 bytes 005292.110: brfs: File read: /mfs/sd/overlays/i2c1.dtbo 005313.963: Loaded overlay 'i2c1' 005313.987: dtparam: pins_44_45=1 005351.221: brfs: File read: 1004 bytes 005381.266: brfs: File read: /mfs/sd/overlays/uart3.dtbo 005404.132: Loaded overlay 'uart3' 005424.678: brfs: File read: 1016 bytes 005455.252: brfs: File read: /mfs/sd/overlays/uart5.dtbo 005478.372: Loaded overlay 'uart5' 005478.395: dtparam: ctsrts=true 005552.955: brfs: File read: 1016 bytes 005553.925: brfs: File read: /mfs/sd/cmdline.txt 005553.990: Read command line from file 'cmdline.txt': 005554.013: 'console=tty1 root=/dev/mmcblk0p2 rootfstype=ext4 fsck.repair=yes rootwait cfg80211.ieee80211_regdom=CH' 005870.674: brfs: File read: 103 bytes 008041.574: brfs: File read: /mfs/sd/kernel8.img 008041.614: Loaded 'kernel8.img' to 0x200000 size 0x981aa2 011448.789: Device tree loaded to 0x2eff1b00 (size 0xe449) 011456.169: gpioman: gpioman_get_pin_num: pin SDCARD_CONTROL_POWER not defined 011456.334: Watchdog stopped 011456.346: arm_loader: Starting ARM with 768MB 011561.751: sdram: sdram refresh 1562->3124 (2) 012582.502: sdram: sdram refresh 1562->6248 (1) 012867.868: vchiq_core: vchiq_init_state: slot_zero = 0xcf000000, is_master = 1 012874.306: TV service:host side not connected, dropping notification 0x00000002, 0x00000002, 0x00000052 014624.082: sdram: sdram refresh 1562->3124 (2) 016032.128: gpioman: gpioman_get_pin_num: pin FLASH_0_ENABLE not defined 016032.148: gpioman: gpioman_get_pin_num: pin FLASH_0_INDICATOR not defined 016032.179: gpioman: gpioman_get_pin_num: pin FLASH_0_ENABLE not defined 016032.194: gpioman: gpioman_get_pin_num: pin FLASH_0_INDICATOR not defined 017687.039: sdram: sdram refresh 1562->6248 (1) 026873.788: sdram: sdram refresh 1562->3124 (2) 191465.833: video_decode:9:RIL: resolution changing
kmsprint I will post tomorrow.
No smoking gun there. I was hoping for a VCOS_ABORT line or other error logging, but there isn't any.
If I've read it right, h264_parse_sei_ol line 2089 is only a validation that Rec. ITU-T H.264 D.1.1 General SEI message syntax is followed with padding at the end of the message being a 1 followed by 0's to align it to a byte boundary. Your stream would supposedly not comply with that bit of the spec. Overall that should be harmless.
I also ran kmsprint as you suggested.
-
kmsprint_idle.txt(no video playing) -
kmsprint_vlc_fullscreen.txt(VLC running fullscreen with the problematic stream and hw decode enabled)
cat kmsprint_idle.txt Connector 0 (33) HDMI-A-1 (connected) Encoder 0 (32) TMDS Crtc 3 (100) [email protected] 147.840 1920/48/32/200/+ 1080/3/6/31/- 60 (60.00) P|U|D Plane 3 (89) fb-id: 722 (crtcs: 3) 0,0 1920x1080 -> 0,0 1920x1080 (XR24 AR24 AB24 XB24 RG16 BG16 AR15 XR15 RG24 BG24 YU16 YV16 YU24 YV24 YU12 YV12 NV12 NV21 NV16 NV61 P030 XR30 AR30 AB30 XB30 RGB8 BGR8 XR12 AR12 XB12 AB12 BX12 BA12 RX12 RA12) FB 722 1920x1080 XR24 Connector 1 (42) HDMI-A-2 (disconnected) Encoder 1 (41) TMDS
cat kmsprint_vlc_fullscreen.txt Connector 0 (33) HDMI-A-1 (connected) Encoder 0 (32) TMDS Crtc 3 (100) [email protected] 147.840 1920/48/32/200/+ 1080/3/6/31/- 60 (60.00) P|U|D Plane 3 (89) fb-id: 722 (crtcs: 3) 0,0 1920x1080 -> 0,0 1920x1080 (XR24 AR24 AB24 XB24 RG16 BG16 AR15 XR15 RG24 BG24 YU16 YV16 YU24 YV24 YU12 YV12 NV12 NV21 NV16 NV61 P030 XR30 AR30 AB30 XB30 RGB8 BGR8 XR12 AR12 XB12 AB12 BX12 BA12 RX12 RA12) FB 722 1920x1080 XR24 Connector 1 (42) HDMI-A-2 (disconnected) Encoder 1 (41) TMDS
No smoking gun there. I was hoping for a VCOS_ABORT line or other error logging, but there isn't any.
If I've read it right, h264_parse_sei_ol line 2089 is only a validation that Rec. ITU-T H.264 D.1.1 General SEI message syntax is followed with padding at the end of the message being a 1 followed by 0's to align it to a byte boundary. Your stream would supposedly not comply with that bit of the spec. Overall that should be harmless.
Thanks for the analysis and the explanation about the SEI padding – I understand that this stream is not fully H.264-compliant.
However, this is our local DVB/IPTV stream from an official/state TV provider, so I unfortunately have to live with the way it is transmitted. Other devices and software decoders can cope with it (sometimes with visible artefacts), but they don’t end up with kernel WARNs and a frozen video pipeline.
Would it be possible to make the bcm2835 hardware decode path more robust in this situation?
Warnings are perfectly fine for me, but the hard stall (timeouts, "driver bug" and stuck buffers) is a real problem in practice.
Would it be possible to make the bcm2835 hardware decode path more robust in this situation? Warnings are perfectly fine for me, but the hard stall (timeouts, "driver bug" and stuck buffers) is a real problem in practice.
The decoder is generally pretty robust, and is only warning about these buffer issues rather than failing on them. There's obviously something else that is tripping it up, but currently I can see no information as to what that is.
You can run vcgencmd set_logging level=0x100c0 to enable more logging within the firmware, and therefore vclog -m should give far more information. Alternatively vcgencmd set_logging level=0x1000c might show something too (gives the lowest level codec logging rather than the interface level).
[ 184.293578] bcm2835_mmal_vchiq: timed out waiting for sync completion basically means the firmware has wedged totally, but if I can't reproduce it then it's hard to pinpoint what exactly has wedged and why.
And I'm surprised that kmsprint is giving FB 722 1920x1080 XR24. That would imply that it's doing GPU composition of the display, when it should be possible to pass the frame directly to the display as YU12 (YV420) and save a load of processing (hence power too). That may be a Bookworm vs Trixie thing though.
I have enabled the extra firmware logging as you suggested, please find attached the log from the two shots.