Option to preload RTSP streams

[felipecrs]

I have two use cases for this feature:

1. I have a chinese Wi-Fi camera which, unless I keep always keep loading its stream, breaks the stream and go2rtc does not recover automatically.
   • I don't think this is an issue with go2rtc
   • Preloading the camera in Home Assistant fixes the issue
2. As a temporary fix for: https://github.com/AlexxIT/go2rtc/issues/530

If there was an option to preload (or maintain some stream always open in go2rtc itself), it would be great. I feel like preloading the camera from Home Assistant side takes too many CPU cycles as it spawns a ffmpeg process.

Example of how it could look like:

streams:
  camera_01:
    - rtsp://192.168.1.21:554/user=admin_password=pass_channel=0_stream=1&onvif=0.sdp?real_stream#preload

I don't think this support needs to be implemented to any other source (only RTSP), because one could easily create a fake consumer to the source just to preload it, if it's not already RTSP:

streams:
  camera_01:
    - ffmpeg:rtsp://192.168.1.21:554/user=admin_password=pass_channel=0_stream=1&onvif=0.sdp?real_stream#video=copy#audio=copy
  camera_01_for_preload:
    - rtsp://127.0.0.1:8554/camera_01#preload

[AlexxIT]

This require some core refactoring...

[felipecrs]

This option is not a game chancer as well, don't worry. Thanks as always.

[gtxaspec]

Maybe this could decrease stream loading times in general? Keeping the stream open all the time would be useful 😀 in some situations

[felipecrs]

Certainly, depending on how long the stream takes to initiate for each camera.

That's another good use case.

[marcelmah]

Notice the same behaviour (since 1.2 I think?) One Chinese (backend) camera and 2 Foscam (also Chinese offcourse..., when not? :) )

Using custom:webrtc-camera, so no preload option(?). Reloading the page fixes it for x time.

[felipecrs]

Using custom:webrtc-camera, so no preload option(?). Reloading the page fixes it for x time.

I am using too, you just need to add as Generic Camera in Home Assistant and tick the preload option in its settings.

• https://github.com/AlexxIT/go2rtc/pull/611

[felipecrs]

But, @marcelmah, if you are sure that you did not have this problem before go2rtc 1.2, I think you should fill an issue with the details.

[gtxaspec]

@AlexxIT, do you have more ideas about this? I suggest that if go2rtc maintains a constant connection with the original stream, it will reduce the time it takes to connect from the client to go2rtc.

Now, the process is:

1. Client links to go2rtc.
2. go2rtc links to the source.
3. go2rtc begins to re-transmit to client from the source.

With a constant connection, it could be:

1. Client links to go2rtc.
2. go2rtc begins to re-transmit to client from the source

I'm not sure what the best way to design it is, or how it could be specified in the configuration file. But I believe it is a worthwhile idea to investigate.

[swex]

I just set up sending video to telegram after motion detected, and this feature will be extremely useful if we could give option to get some time BEFORE detection, like back_duration or something: http://localhost:1984/api/stream.mp4?src=gates&mp4=flac&back_duration=10&duration=32&filename=record.mp4 I'll have 10 seconds before event happened and 32 seconds after!

[bagobones]

+1 from me..

It is quite noticeable how slow initial stream load time is when I call a already running stream like my frigate recording / detect streams vs calling a substream on a camera that isn't in active use. The load time can be several seconds for a cold stream.

I would really like to be able to persistently load my doorbell stream for example, however I think some careful through will be needed in terms of how this might impact features like two way audio.

Edit: Dumb idea, but what if you just add a devnull type client to the current architecture? It just keeps reloading the feed if it is lost like a client would but essentially does nothing with the feed.