expose the go2rtc instance to avoid multiple go2rtc instances and high loads

[regevbr]

While this library uses go2rtc to convert WebRTC to RTSP, it also recommends (in the FAQ) using go2rtc to convert the RTSP stream back to WebRTC using go2rtc for better performance. This has 2 outcomes:

1. My HA setup actually runs 2 go2rtc instances (the addon is used to convert other rtsp streams as well as the ring ones)
2. The WebRTC stream from ring is being converted twice WebRTC -> RTSP -> WebRTC for no reason, creating CPU load

Since your go2rtc configuration requires running local scripts, I can't see a way to utilize an external addon. So what I suggest is a way to expose the go2rtc instance completely (including UI) using the host network (might need to release a different addon version for that). This way we can use the go2rtc of this addon for other streams, and use directly the webrtc of ring, instead of double converting it (using the amazing WebRTC component, without creating a generic camera integration (that indeed must use an RTSP stream).
To achieve this change, there is also a need to mount the go2rtc config from the local disk (so users can edit it) and make the code read the config and edit it inline (instead of overwriting it).

Thoughts?

[tsightler]

When I first switched to go2rtc I had originally planned to expose it, and, in the first few beta releases of 5.1.0, it was possible to use the go2rtc instance in the ring-mqtt addon directly, without the additional go2rtc addon, but after testing with various scenarios, I decided it just wasn't worth it for a multitude of reasons:

1. Lots of people have more than just Ring cameras, I don't want the ring-mqtt project to become the perceived support path for those, but that is what will happen.
2. As you note, ring-mqtt runs on the docker internal network, with zero ports exposed externally by default, and only a single port that can even be configured for exposure (the RTSP port) while go2rtc addon runs on host network. Running ring-mqtt on host network opens multiple security issues that would have to be dealt with. Of course, it's possible to run go2rtc on docker internal network, but then you have to expose another TCP/UDP port and provide for configuring STUN, etc., items that are already handled in the go2rtc addon.
3. The go2rtc project is currently developing very fast, I don't want ring-mqtt to become the bottleneck for go2rtc fixes and features, there have already been two releases of go2rtc with many fixes for various cameras and scenarios since the last ring-mqtt release just a few weeks ago.
4. In ring-mqtt go2rtc is used only as an RTSP proxy, a part of the code I understand fairly well, and it is very light on CPU and memory since it is basically just forwarding decrypted RTP streams unmodified. I've tested 5 concurrent live streams on a RPi4b, and the go2rtc instance in ring-mqtt was using 20MB of RAM and 15% of a single core, while the required ffmpeg processes used 80MB of RAM and ~75-80% of a core, and werift (the WebRTC receiver) used 225% of CPU, so 2.25 cores. Basically, having a second go2rtc instance running as an RTSP proxy is not even 5% of the CPU load. The vast majority of the load is in werift.
5. The WebRTC->RTSP ->WebRTC path stays unchanged, other than the fact that the final path would stay "internal" to addon as go2rtc doesn't have any method to consume the stream directly from WebRTC. If people don't like this then someone should probably fix the native Ring integration to use the Ring WebRTC interface directly, which is totally possible and would eliminate the need ring-mqtt for streaming in the HA frontend.
6. The go2rtc project is adding features like automatic hardware transcoding and other features that will likely become more useful going forward, especially with Ring causing all kinds of havoc and incompatibility rolling out HEVC/H.265 support, but I don't want to have to deal with all of those things in ring-mqtt.
7. The use of the go2rtc addon is HA specific, while 20-25% of ring-mqtt users are not Home Assistant users.

Basically, I see little reason to take on the headache of maintaining all of that in ring-mqtt when I only need the rtsp-proxy portion of go2rtc, all for the benefit of maybe 20MB of RAM and <5% of a single core of CPU per stream.

[regevbr]

I see. Thanks for the detailed response!