Hardware encoder with splitmuxsink in tee stops recording from live RTSP source after some time

Hello, and thank you for your attention.

I’m currently trying to create a gstreamer pipeline that records a live RTSP source in segments using splitmuxsink, while also storing a sequence of images from the source. Here’s the pipeline (as a bash script):

#!/bin/bash
video_dir="~/Videos/recordings"
image_dir="~/Videos/frames"
segment_seconds=60
ns_per_second=1000000000
stream_url="rtsp://wowzaec2demo.streamlock.net/vod/mp4:BigBuckBunny_115k.mov"

mkdir -p "$video_dir"
mkdir -p "$image_dir"

gst-launch-1.0 -e \
   rtspsrc location="$stream_url" protocols=tcp latency=2000 buffer-mode=0 ! \
   queue ! \
   decodebin ! \
   tee name=t ! \
     queue ! \
     nvvidconv ! \
     "video/x-raw(memory:NVMM),format=I420" ! \
     nvv4l2h265enc bitrate=1000000 ! \
     h265parse ! \
     queue ! \
     splitmuxsink \
       muxer-factory=qtmux \
       location="$video_dir/recording_%08d.mp4" \
       max-size-time=$((segment_seconds * ns_per_second)) \
       async-handling=true \
       async=false \
   t. ! \
     queue ! \
     nvvidconv ! \
     videorate ! \
     videoscale ! \
     clockoverlay time-format="%F %H:%M:%S" ! \
     nvvidconv ! \
     "video/x-raw,width=1280,height=720,framerate=1/10" ! \
     nvjpegenc ! \
     multifilesink location="$image_dir/frame_%08d.jpg" async=false

The current pipeline performs perfectly well on the provided stream_url, however when using an RTSP camera on the local network, it begins to behave oddly in the sense that, after some time (sometimes within a few minutes, sometimes half an hour), new videos will cease to be created while images continue to be stored.

To me, this suggests that there is no deadlock in the pipeline, but that something is not right with the splitmuxsink branch of the tee.

I’ve tried a number of different strategies to no avail, including setting and unsetting the “async” property of both sinks, playing with the bitrate, tuning the latency of the source, and others.

Any idea what might be happening here and how to resolve the issue? Could it be a problem with the encoder?

I’m happy to provide more information as necessary.

Thanks,
Harris