Support external go2rtc

[Roarrk]

Support external go2rtc

[marq24]

thanks Nick - so I have now picked up that Frigate is using go2rtc as service but it's essential that Frigate keeps control over the go2rtc.yml configuration file in order that the restreaming birdseye feature and support for additional cam viewers in the frigate frontend will work correctly. Furthermore there is the risk, that any upcoming change in the 'docker/main/rootfs/usr/local/go2rtc/create_config.py' can cause issues for environments where users try to use an none-embedded (aka 'external') go2rtc.

If I don't use birdseye restreaming and if I don't use the Frigate GUI (to consume camera footage - since I am using Frigate in a combination with home assistant) - and If I am able to diff changes in the create_config.py with every Frigate release, then it should be possible for me to use an external go2rtc with Frigate in the following way (I am leaving this here as reference for other users with the same restrictions as I am):

docker-compose.yml

in my docker-compose file - together with home assistant I have added the go2rtc - please note, that I have made the go2rtc GUI stuff available via the port 8984 (and not 1984) - as alternative you might like to simply use the network_mode: host to expose all ports of the container to the host (that's what I did for the start).

Also note, that I prefer to have all config files on the host in the home assistant config folder (typically files have to be exist before the container start)

  go2rtc:
    container_name: go2rtc
    image: alexxit/go2rtc
    #network_mode: host		# important for WebRTC, HomeKit, UDP cameras or use ports section - but I prefer to expose only required ports
    privileged: true		# only for FFmpeg hardware transcoding
    restart: unless-stopped	# autorestart on fail or config change from WebUI
    volumes:
      - /home/[your-local-path]/homeassist/config/go2rtc.yml:/config/go2rtc.yaml
      - /etc/localtime:/etc/localtime:ro
    ports:
      - "8554:8554"		# RTSP feeds
      - "8555:8555/tcp"		# WebRTC over tcp
      - "8555:8555/udp"		# WebRTC over udp
      - "8984:1984"		# go2rtc stuff

the 'go2rtc.yml' used by the the service

this configuration 'should' contain all additional settings that Frigate requires - please note that my frigate configuration does not contain any go2rtc section.

# see also: https://github.com/AlexxIT/go2rtc
api:
  origin: '*'
  listen: ':1984' # that is the port of the webgui inside the container!

ffmpeg:
    h264/rk: -c:v h264_rkmpp_encoder -g 50 -bf 0
    h265/rk: -c:v hevc_rkmpp_encoder -g 50 -bf 0

# I have not figured out yet for what this hass section is used by go2rtc - so I am not using it
#hass:
#  config: /config

# I prefer an alternative log configuration then the frigate's default
#log:
#  format: text

# of course you can alter your log levels to your local requirements
log:
    level: debug  # default level
    api: debug
    exec: debug
    ngrok: debug
    rtsp: debug
    streams: debug
    webrtc: debug

rtsp:
    default_query: mp4

# here you have to configure your source cam streams! (that you previously did in frigate go2rtc section) - and YES I have read multiple times, that reolink rtsp should be instable and http(s) source should be used - for me it's the other way around
streams: 
    reolink_811a_main:
        - "ffmpeg:rtsp://[user]:[pwd]@[CAM-1-IP]:554/h265Preview_01_main#video=h264#hardware=vaapi#audio=aac"
    reolink_811a_sub:
        - "ffmpeg:rtsp://[user]:[pwd]@[CAM-1-IP]:554/h264Preview_01_sub#video=h264#hardware=vaapi#audio=aac"
    reolink_510a_main:
        - "ffmpeg:rtsp://[user]:[pwd]@[CAM-2-IP]:554/h264Preview_01_main#video=h264#hardware=vaapi#audio=aac"
    reolink_510a_sub:
        - "ffmpeg:rtsp://[user]:[pwd]@[CAM-2-IP]:554/h264Preview_01_sub#video=h264#hardware=vaapi#audio=aac"

webrtc:
    candidates:
        - stun:8555

cam definition in the my frigate configuration yml

cameras:
  fri_front: # <------ Name the camera
    ffmpeg:
      inputs:
      - path: rtsp://[ip-of-mashine-running-go2rtc]:[go2rtc-rtsp-feed-port-probably-8554]/reolink_510a_main
        input_args: preset-rtsp-restream
        roles:
        - record

[NickM-27]

frigate sets a number of internal configurations that it expects and needs to work correctly with go2rtc, a user may ignore these and whenever frigate changes the values required it would become a breaking change where was now we can change these and they are applied automatically for every user.

Frigate also adds features like birdseye restream which again would be much more complicated when Frigate doesn't have direct control.

With that said I don't think this makes sense. You can always have frigate connect to go2rtc externally and the connections to the camera will still be reduced. If you want frigate internal features like live view then the internal go2rtc must be used.

If other maintainers disagree then this can be discussed further and potentially reopened

[Roarrk]

All of those features you are referring to are supported in a pure RTSP stream. I don't see how birdseye etc has to have anything to do with it, but fair enough if no maintainers agree this is a priority. I saw several other previous issues where people brought up issues with this and I thought I would put this in as a request rather than an issue. I will try to work around it.

[NickM-27]

I think you are misunderstanding what I am referring to. Frigate controls specific things in go2rtc.

For example the default arm builds in frigate use ffmpeg version 4 optimized for the RPi meanwhile go2rtc assumes ffmpeg version 5. Frigate specifically changes the default args when this is the case so go2rtc works. If external go2rtc was used frigate would not be able to control this directly, ans also wouldn't be able to automatically change args in the future if this changed.

There are many other examples like this as well.

[Roarrk]

Frigate would not necessarily need to set magic things in go2rtc if the user was offered more control. Frigate already supports custom detectors, and injecting custom ffmpeg and go2rtc builds is even documented.

Ultimately it is in my opinion a software design choice, modularity etc. If a prebuilt go2rtc is provided as default, I don't (personally) see the harm in providing a semi-supported way of supporting an external one.

However, like I said, I will work around it and I fully respect that it is not a priority for you.

[blakeblackshear]

If you can describe how any of the features we currently use go2rtc for could be accomplished with an external instance please do. I don't see how it would be possible to support the vast majority of functionality that way.

[marq24]

I might make an idiot of myself - but I would like to leave a comment on this topic.

I am using Frigate since last summer (in a home assistant setup running on a quite powerful hardware) - cause of stability issues I was forced to move the frigate container to another hardware (an older notebook with just 4 CPU cores) - till today everything was working fine...

Today I have configured a second camera - unfortunately this hardware only provides a h265 rtsp stream - and so I have the need to convert the source camera stream to h264 format. It took me a short while but I have found a stream configuration for go2rtc to make the magic happen.

But the CPU power of the notebook running the frigate docker container is not able to run both (the detection and the stream conversion).

T solve this I have setup here (on the main hardware) an separate go2rtc docker container. Configured the inbound (rtsp) streams from the cameras and applied the conversion and used then these (h264 converted) streams in the frigate instance running on the second computer (hardware) [in the cameras:[MY-CAM-NAME]:ffmpeg:inputs:path: rtsp://[IP-RUNNING-GO2RTC-CONATINER]:8554/STEAM_NAME].

Everything works more of less flawless now for some hours - but I dislike the fact, that on the frigate container there is still a instance of go2rtc running (yes not configured with any streams - but it's up and running - and I do not see what possible tasks will/should be processed by this local instance).

So the core question is, why it should not be possible with frigate to specify on which IP & PORTS the the go2rtc services can be found - by default frigate can start/use it's internal go2rtc instance. But from an software architectural point of view this is "just" an service frigate use - so it should not matter where this service is running.

It's cool for the average user, that frigate comes with a build-in service instance - for for users who have 'reasons' to sperate these services it would be cool, if frigate would allow us to do so.

[NickM-27]

So the core question is, why it should not be possible with frigate to specify on which IP & PORTS the the go2rtc services can be found - by default frigate can start/use it's internal go2rtc instance. But from an software architectural point of view this is "just" an service frigate use - so it should not matter where this service is running.

this question was answered in detail above, and your statement is objectively wrong. Frigate is not just connecting to go2rtc, frigate is explicitly configuring go2rtc to behave in a way that it requires and expects. So just pointing to an external go2rtc ip/port would not work.

[NickM-27]

also let's be clear that in your example, everything does not work. If you go to the live view inside frigate and try to use mse or webrtc live view it will not be available

[marq24]

First of all thanks for your fast reply...

this question was answered in detail above...

might be related to my initial statement concerning my state of mind - might be that English is not my primary language - but I haven't picked up the details from your previous reply (to the initial request)...

I have understood so far that build-in go2rtc is used for:

• birdseye
• additional/alternative Live View modes [In my setup this becomes only available in the case that I configure the additional live:stream_name attribute for a camera) (so that the 'select' show the additional options mse & webrtc) - but this might be related to the fact that I did not gave up yet to use my old reolink cameras]
• ???

I have spend the past hours tried to find more references to go2rtc in the source-code, trying to understand what's documented via the md files - and sorry - I am still struggling to understand the reason why the bundled 'go2rtc' must be started with frigate (specially when I read in the docs that the configuration of go2rtc is optional).

and your statement (this is "just" an service frigate use) is objectively wrong

I might haven't just not found the part in the code yet, where "frigate is explicitly configuring go2rtc to behave in a way that it requires and expects"... I searched for some sort of commands to the go2rtc executable but was not successful - only found some traces in the services.py...

or do you mean that the go2rtc.yaml that will be generated by frigate (docker/main/rootfs/usr/local/go2rtc/create_config.py) is the specialty - and if I want to use an external instance, then I must ensure, that my local config will match the one created by frigate... and if in future release the frigate internal go2rtc.yaml file will be adjusted, this need to be adjusted then also by all other external instanced (which is of course beyond of your control) ?

But please - I don't have to understand it - the software the team is providing is really fantastic!

[NickM-27]

or do you mean that the go2rtc.yaml that will be generated by frigate (docker/main/rootfs/usr/local/go2rtc/create_config.py) is the specialty - and if I want to use an external instance, then I must ensure, that my local config will match the one created by frigate... and if in future release the frigate internal go2rtc.yaml file will be adjusted, this need to be adjusted then also by all other external instanced (which is of course beyond of your control) ?

yes, this is exactly where frigate is explicitly configuring go2rtc to behave in a way that it requires and expects.