RTSPtoWebRTC connection timeout too short

[atx32]

The problem

I am using the RTSPtoWebRTC integration with the go2rtc server add-on. The RTSPtoWebRTC integration has a connection timeout of 10 sec defined in the code. When starting up multiple camera streams (multiple picture glance cards on a dashboard), it can take more than 10 sec for the server to start the last stream and so the integration times out (using a RPi4.) The default timeout needs to be larger (perhaps 20 sec or more) or be user configurable.

What version of Home Assistant Core has the issue?

core-2024.5.1

What was the last working version of Home Assistant Core?

No response

What type of installation are you running?

Home Assistant OS

Integration causing the issue

RTSPtoWebRTC

Link to integration documentation on our website

https://www.home-assistant.io/integrations/rtsp_to_webrtc

Diagnostics information

home-assistant_rtsp_to_webrtc_2024-05-05T15-13-20.199Z.log

Example YAML snippet

No response

Anything in the logs that might be useful for us?

No response

Additional information

My go2rtc server launches ffmpeg to transcode 3 of my 4 camera's audio to Opus. This causes extra delay in starting up the streams. Logs from go2rtc show the start time for the streams are after 7.2, 9.6, and 10.8 sec which causes the last stream to always time out in the RTSPtoWebRTC integration. I expect having even more transcoded streams would continue this trend and consistently time out.

[home-assistant[bot]]

Hey there @allenporter, mind taking a look at this issue as it has been labeled with an integration (rtsp_to_webrtc) you are listed as a code owner for? Thanks!

Code owner commands

Code owners of rtsp_to_webrtc can trigger bot actions by commenting:

• @home-assistant close Closes the issue.
• @home-assistant rename Awesome new title Renames the issue.
• @home-assistant reopen Reopen the issue.
• @home-assistant unassign rtsp_to_webrtc Removes the current integration label and assignees on the issue, add the integration domain after the command.
• @home-assistant add-label needs-more-information Add a label (needs-more-information, problem in dependency, problem in custom component) to the issue.
• @home-assistant remove-label needs-more-information Remove a label (needs-more-information, problem in dependency, problem in custom component) on the issue.

_{^{(message by CodeOwnersMention)}}

---

rtsp_to_webrtc documentation rtsp_to_webrtc source _{^{(message by IssueLinks)}}

[allenporter]

Seems accurate to me that it is failing for being too slow. You've proposed a solution of increasing the timeout, but i think its fine for things to timeout.

What is the actual end user behavior that you're seeing? For example if you go visit the camera in the frontend my impression is it would send a new offer. Perhaps the problem is more that the frontend never attempts to reload the camera ever if it fails on the first attempt?

[atx32]

What the user sees is a message at the top of the card that says "Failed to start WebRTC stream: Timeout talking to RTSPtoWebRTC server". The user must manually refresh the page and hope to get under 10 sec on the remaining cameras (logs show only the streams that timed out are reattempted on refresh.) I don't think that making the user refresh manually (or using some automatic process in the frontend) and wait even longer for the stream gives the best user experience. I see no harm in waiting longer on that initial attempt because otherwise something that would have been successful in 10-12 sec now takes 18 sec or more when you trigger a timeout and reattempt.

[allenporter]

Appreciate your suggestion for the solution. The problem exists whether the timeout is 10 or 20 or 30. It may be we need both solutions.

[atx32]

I agree that no matter what the timeout is set to, you could go to n+1 cameras and probably be in the same situation again. From my perspective the goal is to set a reasonable timeout to support a reasonable number of cameras. (At some point you'll need faster hardware to run a larger number of cameras anyway.) When I disable WebRTC it takes just over 30 sec to get all the camera streams running (no timeouts in this scenario), so a 15-20 sec WebRTC timeout is still going to represent a better user experience. If you are open to it, I'd suggest changing the timeout to something in that range which would give users a more successful experience when using WebRTC.

[allenporter]

I'm also thinking beyond rtsp to webrtc integration for webrtc use in other platforms as well.

Really the deadline of a single camera loading shouldn't matter how many cameras you have. Maybe something serial is happening. (Each camera should have its own deadline). Is the server doing something weird or the integration getting stuck with large number of cameras...

Will look into that also.

[allenporter]

Why do you think the server takes longer when you add more streams? Are you saying that it is expected this server has no parallelism? I want to question why we think that is acceptable

[atx32]

If I turn off server transcoding and use the streams from the cameras as is, they all load in the frontend in under 4 sec. It's my use of transcoding (just for audio to get a WebRTC-compliant codec) that adds the additional variable delay as an instance of ffmpeg is started for each transcoded stream. While it looks like each ffmpeg instance is started at the same time, each one takes progressively longer to launch. Maybe I'm interpreting the logs incorrectly, and I can certainly open an issue on that observation and see what the go2rtc author says.

[atx32]

I opened https://github.com/AlexxIT/go2rtc/issues/1162 and have been making progress, so there is no reason to keep this item open here.