Webrtc in frigate live view from external go2rtc source instead of restream from bundled go2rtc

[dasb00ter]

I have some cameras that run bundled go2rtc to stream out rtsp. The go2rtc webui from the camera definitely will stream in RTC in chrome but when used as input rtsp for frigate I just have the jsmpeg option for the live view? Seems silly to restream from one go2rtc to another? I do have webrtc working for another camera without a bundled go2rtc using restream in the go2rtc bundled in frigate.

camera config

somecamera:
#    objects:
#      track:
#        - person
#        - car    
    rtmp:
      enabled: False # <-- RTMP should be disabled if your stream is not H264
    ffmpeg:

      inputs:

        - path: rtsp://10.0.0.115:8554/1080p # <----- The stream you want to use for detection
          roles:
            - detect
            - record
    detect:
      width: 1920 # <---- update for your camera's resolution
      height: 1080 # <---- update for your camera's resolution
      fps: 5
      enabled: false
    motion:
      threshold: 15
      contour_area: 20

relevant go2rtc config from camera

streams:
  1080p:

  - exec:ffmpeg -fflags +genpts+flush_packets+nobuffer+bitexact -flags +low_delay -thread_queue_size 100 -analyzeduration 50 -probesize 50 -pix_fmt yuv420p -r 30 -i /dev/video6  -flags +global_header -movflags +empty_moov+default_base_moof+frag_keyframe -framerate 30 -video_size 1920x1080 -pix_fmt yuv420p -c:v copy -copyts -rtsp_transport tcp -f rtsp {output}
  - exec:ffmpeg -hide_banner -f alsa -ac 1 -i dsnooper0 -c:a copy -muxdelay 0 -muxpreload 0 -f rtsp {output}
  - exec:ffmpeg -hide_banner -f alsa -ac 1 -i dsnooper0 -c:a libfdk_aac -afterburner 1 -channels 1 -b:a 128k -profile:a aac_he -ar 16000 -strict experimental -muxdelay 0 -muxpreload 0 -ac:a 1 -f rtsp {output}
# libopus has higher cpu requirements, audio may studder.
#  - exec:ffmpeg -hide_banner -f alsa -ac 1 -i dsnooper0 -c:a libopus -muxdelay 0 -muxpreload 0 -ac:a 1 -af adelay=0|0 -f rtsp {output}

not sure but maybe an audio problem looks like aac is there and so I wont get webrtc but should get MSE?
Looking for some direction. Thanks

[NickM-27]

The mse and webrtc live views only show when the name of the stream matches the name of the camera OR live -> stream_name is set

[dasb00ter]

Thanks for your reply. So in this case I'm trying to not use the bundled go2rtc in frigate and make use of the go2rtc server in the camera. So how would the configuration look below?

live:
      stream_name:  "what do I put here if I'm not using the bundled go2rtc"

Sorry if I'm missing a fundamental principle of operation here

[dasb00ter]

Fair if I understand you. I contemplated that. Why have the cameras do the work that perhaps the CPU in the system that is running frigate, is better suited for.

I thought it might be useful as I add cameras to have the load distributed amongst the cameras instead of the CPU in the machine running frigate. The system running frigate is doing some others jobs too like running home assistant.

There is perhaps a way to reduce the processing power of the frigate machine/go2rtc/ffmpeg since the stream is already being streamed out by go2rtc from the camera but I'm not sure how, but I guess this is the way forward. If I understand

[pyrodex]

Is this going to change down the road in future versions? I love go2rtc and frigate together but also love being able to decouple them if possible for other reasons. Today if I have to make a change to Frigate and restart it any thing consuming go2rtc from Frigate burps until it comes back. Since go2rtc doesn't change nearly as us tuning our frigate with filters, masks, etc. it causes unforeseen downtime. I mean we could run two copies, one in Frigate and one outside of frigate but losing MSE/WEBRTC in live because of this is meh. If frigate supported live reloading without losing the go2rtc running processes that would solve this issue.

[NickM-27]

in the next version of frigate more things will be live reloaded

I don't see the go2rtc being decoupled in the future

[lezruk]

Option for decoupling go2rtc and maintain working liveview should be good for several reasons:

1. Distributing cpu/ram load amoung cluster/containers, very usefull for small VMs
2. Less memory/cpu use in frigate container/pod
3. If you already have running standalone instance of go2rtc, just plug sources
4. Different release/mainteance/fixes pace between both projects
5. Possible difference in drivers/software versions (intel qsv, ffmpeg)

[blakeblackshear]

You can already use a bind mount to overwrite the upstream for go2rtc in nginx in the dev builds easily. This is unlikely to ever make our priority list, but we would be open to reviewing a PR that makes it easier to use external go2rtc as long as it maintains 100% feature parity for current users.