gst-launch-1.0 pipeline freezes after recording of rapidly changing images
Describe your issue
UDP pipeline gets frozen after a fast-changing image (ie. while waving a hand in front of camera or shaking). The internal clock is working, but pipeline clock stops without state changing. Only pipeline restart helps.
Expected Behavior
The pipeline should still transmit video
Observed Behavior
The pipeline does not send any video data and is still in a playing state with a stopped pipeline clock.
Setup
- Operating System: Debian 11 aarch64
- Device: Raspberry Pi3B+ 1 GB, EM7455 LTE Modem (1Mbit/s real speed), PS3 Eye webcam
- GStreamer Version: 1.0
Steps to reproduce the bug
host pipeline:
gst-launch-1.0 -ve v4l2src device=/dev/video0 ! video/x-raw,width=640,height=480,framerate=\(fraction\)30/1 ! clockoverlay ! v4l2h264enc extra-controls=s,video_bitrate=250000 capture-io-mode=4 output-io-mode=4 ! "video/x-h264,level=(string)4" ! rtph264pay config-interval=1 ! multiudpsink clients="127.0.0.1:5006,10.123.0.2:5006" sync=false
client pipeline:
udpsrc port=5006 do-timestamp=true ! application/x-rtp, media=(string)video, clock-rate=(int)90000, encoding-name=(string)H264, payload=(int)96 ! rtpjitterbuffer latency=100 drop-on-latency=true drop-messages-interval=100000000 ! queue max-size-buffers=20000 ! rtph264depay ! h264parse ! avdec_h264 ! videoconvert ! glupload ! qmlglsink name=qmlglsink sync=false
Solutions you have tried
Modifying pipeline in many ways. Modifying rtpjitter buffer, queue, camera bitrate and resolution. Tried to change h264 encoder, but pipeline starts only with hardware v4l2h264enc. Connecting via ethernet also doesn't resolve the problem. For testing, I lunch a simple ffmpeg pipeline and it worked without any problems so that excludes hardware problems.
Additional Information
For more information, I enclose a log file. Pay attention to what happens after the last sent video frame. It falls into the loop while sending a query and in v4l2src0 gets a timeout. zipped log file