Open ardera opened 7 months ago
What version of GStreamer are you using?
Whilst userspace shouldn't be able to produce kernel warns, this is a condition that is handed by the V4L2 frameworks and cleaned up anyway https://github.com/raspberrypi/linux/blob/rpi-6.1.y/drivers/media/common/videobuf2/videobuf2-core.c#L2029-L2035
gstreamer1.0-plugins-good
shows version 1.22.0-5+rpt1+deb12u1
; I'm on Raspberry Pi OS bookworm (64-bit), all packages are up-to-date.
So the actual hang might also be gstreamer related?
EDIT: Okay, my bad, apparently multifilesrc can not be used for video files. Doesn't work on other machines either. (In my defense, still bad UX if the playback just freezes at the end of the video without any indication/logging as to why and that it was left as an easter egg to the user that multifilesrc doesn't work with videos, but oh well)
Should I still leave this open for the kernel warnings? Otherwise, if I reproduce the actual hangs I seemingly had some time ago, I'll create a new issue.
Describe the bug
When using a certain gstreamer pipeline and the v4l2 hardware decoder to do gapless looping of a video file, the playback will hang at the first EOS. Terminating the playback using Ctrl+C prints multiple kernel bugs/warnings/stack traces (?) and
driver bug:
messagesSteps to reproduce the behaviour
Device (s)
Raspberry Pi 4 Mod. B
System
Logs
dmesg
output of the last few frames and subsequent Ctrl+C, with bcm2835-codecdebug=5
and /dev/video10debug=0x1f
:Additional context
This is a kernel bug, right? i.e. gstreamer should not be able to cause kernel stack dumps?
I think the issue exists in this form since quite some time, I remember trying to do gapless looping in flutter-pi in 2020/2021 or something and having to do normal looping instead because of this hang. Now, I'm having some trouble with normal looping (though not sure it's gstreamer or kernel yet), and while trying to find some steps to reproduce it, I tried this again, saw all the warning / error messages in dmesg and decided to report this.