Josh HawkinsandGitHub
e73a14db5d
* update homekit docs * update dictionary * preserve function names in production builds adds only 162kb gzipped/450k unzipped to the bundle * margin tweak * fix maximum update depth exceeded when dragging the timeline handlebar Dragging the handlebar, especially quickly or with fast direction changes, could exceed React's nested update limit and unmount the whole app, leaving a blank screen. Motion search was worst affected. The drag loop committed a new time into React state on every animation frame. Edge auto-scrolling mutates scrollTop each iteration, so the value always differed and React's same-value bail-out never engaged, letting the update chain run to the limit of 50. Pace those commits to one per 100ms and flush the pending value on release, so the drop position is still exact. The handlebar position and label are written to the DOM directly and remain at frame rate. useUserInteraction dispatched state on every scroll and touchmove event; only commit on the leading edge. Motion search also passed fresh array literals for the timeline's events, motion events and unavailable ranges, giving the segment memo and the drag effect new dependencies on every render. Both views also passed an inline arrow for onHandlebarDraggingChange, which is an effect dependency that calls setState. * Verify motion search jobs belong to the requested camera * Apply persisted profile and runtime overrides before workers start Worker processes are handed a copy of the config when they start and only learn about later changes from the config_updater broadcast, which is plain ZMQ PUB/SUB with no queue, ack, or retained value, so a message published before a subscriber has connected is dropped and never re-sent. The persisted profile and the runtime camera toggles were restored only by that broadcast, at the very end of startup, so a worker that lost the race kept its yaml values for the rest of the session: audio detection kept running on a camera whose audio had been toggled off, even though /api/config, the UI, and the runtime state file all showed it disabled. Split both restores into a config half and a publish half. ProfileManager.restore_persisted_profile_to_config() and Dispatcher.reapply_runtime_state_to_config() now run right after init_profile_manager(), before the first worker starts, so every worker is handed a config that already carries both layers. ProfileManager.restore_persisted_profile() and Dispatcher.restore_runtime_state() still run at the end of startup: the recording, review, and embeddings processes start before the dispatcher exists, so the broadcast remains their only channel, and MQTT needs the retained switch states. Both config passes have to stay after init_profile_manager(), which snapshots the config as the no-profile base that deactivation resets to. * End timeline drags on touchcancel
4.7 KiB
id, title
| id | title |
|---|---|
| go2rtc | go2rtc |
import ConfigTabs from "@site/src/components/ConfigTabs"; import TabItem from "@theme/TabItem"; import NavPath from "@site/src/components/NavPath";
Frigate uses the bundled go2rtc to power a number of key features:
- WebRTC or MSE for live viewing with audio, higher resolutions and frame rates than the jsmpeg stream which is limited to the detect stream and does not support audio
- Live stream support for cameras in Home Assistant Integration
- RTSP relay for use with other consumers to reduce the number of connections to your camera streams
:::tip[Most users no longer need to configure go2rtc by hand]
The camera setup wizard is the recommended way to add cameras. Click Add Camera in , and the wizard probes your camera and writes its configuration for you, including the go2rtc restream and the live stream mapping, so go2rtc is set up automatically.
This guide is mainly useful if you are upgrading from an older version and have existing cameras that don't yet use go2rtc, or if you want to fine-tune a stream by hand (for example, to transcode a codec your browser can't play). The go2rtc troubleshooting guide applies regardless of how your cameras were added.
:::
Adding a go2rtc stream manually
If you added your cameras with the wizard, go2rtc is already configured. You can skip straight to troubleshooting. The steps below are for upgrading users with existing cameras that aren't using go2rtc yet, or for anyone who prefers to configure a stream by hand.
Configure go2rtc to connect to your camera by adding the stream you want to use for live view. Avoid changing any other parts of your config at this step. Note that go2rtc supports many different stream types, not just rtsp.
:::tip
For the best experience, set the stream name under go2rtc to match the name of your camera so that Frigate will automatically map it and be able to use better live view options for the camera.
See the live view docs for more information.
:::
Navigate to and click Add stream. Give the stream a name (use the camera's name so Frigate can auto-map it - for example, if your camera's name is back, use back as the go2rtc stream name), then paste the camera's stream URL into the Source field. Save the section.
go2rtc:
streams:
back:
- rtsp://user:password@10.0.10.10:554/cam/realmonitor?channel=1&subtype=2
After adding this to the config, restart Frigate and try to watch the live stream for a single camera by clicking on it from the dashboard. It should look much clearer and more fluent than the original jsmpeg stream.
Next steps
- If the stream you added to go2rtc is also used by Frigate for the
recordordetectrole, you can migrate your config to pull from the RTSP restream to reduce the number of connections to your camera as shown here. - You can set up WebRTC if your camera supports two-way talk. Note that WebRTC only supports specific audio formats and may require opening ports on your router.
- If your camera supports two-way talk, you must configure your stream with
#backchannel=0to prevent go2rtc from blocking other applications from accessing the camera's audio output. See preventing go2rtc from blocking two-way audio in the restream documentation.
Troubleshooting
If your stream won't play, has no audio, uses excessive CPU, or otherwise misbehaves, see the dedicated go2rtc troubleshooting guide. It walks through how to isolate where the problem is and covers the most common issues: unsupported codecs, H.265/HEVC, audio, WebRTC and two-way talk, hardware-accelerated transcoding with FFmpeg 8, and camera-specific quirks.
Homekit Configuration
To export camera streams to HomeKit, Frigate must be configured in docker to use host networking mode. HomeKit settings are stored in /config/go2rtc_homekit.yml rather than in your Frigate config, and are edited through the go2rtc config editor at http://<frigate_host>:1984/editor.html. Pairings are saved back to that file automatically.
See the HomeKit integration docs for the full setup, including the video and audio requirements HomeKit places on the stream.