I’m using GStreamer-sharp for this with GStreamer 1.24.2. In my app, I have the following pipeline:
rtspsrc location=rtsp://my_rtsp_server !
queue max-size-bytes=20971520 max-size-time=0 !
parsebin !
identity sync=true !
fallbackswitch name=fbs immediate-fallback=true !
video/x-h264 !
tee name=t !
queue max-size-bytes=20971520 max-size-time=0 !
fakesink
videotestsrc pattern=black !
video/x-raw,width=1280,height=720 !
textoverlay text="Waiting for video stream..." font-desc="Sans, 30" halignment=center valignment=center !
x264enc !
video/x-h264, stream-format=avc !
fbs.
The functionality works perfectly fine. However, it uses up a lot of CPU. So, I tested without the fallbackswitch with this:
rtspsrc location=rtsp://my_rtsp_server !
queue max-size-bytes=20971520 max-size-time=0 !
parsebin !
identity sync=true !
tee name=t !
queue max-size-bytes=20971520 max-size-time=0 !
fakesink
This is much better.
CPU wise, I think the most suspect thing is the h264 encoding of the videotestsrc, but I can’t understand why it would keep doing this after it has switched over to the real stream.
If that is what’s happening, is there any solution to pause the fallbackswitch?
Alternatively, I’m wondering if I should just pre-record a few seconds of the videotestsrc with h264 encoding and use that for playback on a loop? I suspect that’s possible, but it does mean any changes to the fallback stream require re-recording the file.