Cameras

go2rtc: low-latency camera live view

Fix laggy in-browser camera viewing — why RTSP/HLS is seconds behind, and how go2rtc's MSE and WebRTC give near-real-time live view (ports 1984/8554/8555).

Problem summary

Watching a camera in a browser feels seconds behind because the page is using HLS or a transcoded RTSP path. go2rtc fixes this with MSE (low latency) and WebRTC (sub-second), restreaming the camera once. The gotchas are codec compatibility (WebRTC wants H.264/PCMU audio), and WebRTC needing a reachable host:port (8555) for its candidates.

Operator snapshotEvidence first

First proof

Identify the transport the browser is actually using.

Screen to open

http://<host>:1984

Expected signal

You know whether live view is HLS, MSE, or WebRTC.

Stop boundary

Don't expose 8555 to the public internet — reach it over the tunnel.

Layer path

1In-browser camera viewing feels seconds behind because the page is using HLS (multi-second segment buffering) or a transcoded RTSP path — that latency is the protocol, not the camera.

2go2rtc fixes it by restreaming the camera once and serving low-latency players: MSE (~half a second, very compatible) and WebRTC (sub-second).

3Defaults: go2rtc web UI/API on 1984, RTSP on 8554, WebRTC on 8555 (TCP+UDP). Embedded in Frigate, MSE is fronted by Frigate's own port while WebRTC still uses 8555.

4The two gotchas: codec compatibility (MSE/WebRTC prefer H.264 video and a browser-friendly audio codec), and WebRTC needing a reachable host:port so it can advertise a candidate the client can connect to.

Runbook

Step-by-step runbook

Start here. Do each check in order, compare it to the expected result, and stop when the evidence explains the failure or the safe stop point applies.

Restream the camera through go2rtc

Check: Define the camera once in go2rtc and confirm it plays in the 1984 UI.

Expected result: go2rtc shows the stream connected with a known codec.

If not: If go2rtc can't pull it, fix the source/URL/codec first.

Use a browser-friendly codec for live view

Check: Serve an H.264 stream for the live view (substream is fine), or let go2rtc transcode.

Expected result: MSE/WebRTC play in all your browsers.

If not: H.265-only can fail MSE in some browsers.

Embed the MSE/WebRTC player

Check: Point your dashboard/app at go2rtc's MSE or WebRTC stream instead of an HLS embed.

Expected result: Live view is near-real-time.

If not: MSE is the compatible default; WebRTC is lowest latency.

Make WebRTC reachable if you want sub-second

Check: Ensure 8555 (TCP+UDP) is reachable from the client, on LAN and over the VPN.

Expected result: WebRTC establishes and live view is sub-second.

If not: If you can't make 8555 reachable, use MSE — don't expose 8555 publicly.

Match standalone vs embedded ports

Check: Use standalone go2rtc ports (1984/8554/8555) or, in Frigate, its fronted MSE plus 8555 for WebRTC.

Expected result: The player connects on the correct port for your deployment.

If not: Mismatched ports are a common 'works in UI, not in app' cause.

Decision tree

If: Live view is seconds behind.

Then: Player is using HLS/transcoded RTSP.

Action: Switch to go2rtc MSE (or WebRTC) for the live view.

If: MSE works on LAN but fails in some browsers.

Then: H.265-only stream MSE can't decode.

Action: Provide an H.264 stream for live view (substream) or transcode.

If: WebRTC won't connect (esp. remotely).

Then: 8555 / candidate not reachable from the client.

Action: Make 8555 reachable over the VPN, or fall back to MSE.

Safe stop: Don't expose 8555 to the public internet — reach it over the tunnel.

If: go2rtc itself can't play the stream.

Then: Source/codec/URL problem upstream.

Action: Fix the source in go2rtc (URL, codec, transport) before blaming the player.

Evidence

Evidence table

Symptom	Evidence to collect	Likely layer	Next action
Multi-second live-view lag.	Whether the player is HLS vs MSE/WebRTC.	Transport / protocol	Use go2rtc MSE/WebRTC.
Live view blank in one browser.	Stream codec (H.265 vs H.264) for MSE.	Codec compatibility	Serve H.264 for live view or transcode.
WebRTC fails, MSE works.	Reachability of 8555 / advertised candidate.	WebRTC port / candidate	Route 8555 to the client (over VPN); else use MSE.
Nothing plays even in go2rtc UI.	go2rtc source connection/codec.	Upstream source	Fix the RTSP source/codec first.

Reference

Commands and settings paths

Open the go2rtc web UI

http://<host>:1984

Where: In a browser on the LAN.

Expected: The stream lists and plays via MSE/WebRTC with low latency.

Failure means: If it won't play here, it's the source/codec, not the embedding page.

Safe next step: Resolve the source in go2rtc; then embed the low-latency player.

Test the WebRTC port

nc -vz <host> 8555 (TCP) and verify UDP 8555 routing

Where: From the viewing client (LAN or across the VPN).

Expected: 8555 is reachable from the client.

Failure means: If blocked, WebRTC can't establish and live view fails or falls back.

Safe next step: Route 8555 over the tunnel to the client, or use MSE.

Compare MSE vs WebRTC latency

go2rtc UI player: switch stream mode (mse / webrtc) and watch a clock in-frame

Where: On the live camera in the go2rtc UI.

Expected: WebRTC shows sub-second, MSE ~half a second; both far below HLS.

Failure means: If only HLS is low-latency-free, you're not on the go2rtc player.

Safe next step: Use the go2rtc MSE/WebRTC player for live monitoring.

Hardware boundary

Hardware and platform boundary

Change only when

Adopt go2rtc for live view as soon as in-browser lag bothers you or you embed cameras in a dashboard — it's the standard low-latency path.

Evidence that matters

An H.264 substream for live view, go2rtc restreaming, and a reachable WebRTC port (8555) if you want sub-second remotely.

Evidence that does not matter

Chasing HLS tuning for 'real-time' — HLS buffers in segments; it's the wrong tool for live monitoring.

Avoid

Exposing go2rtc's WebRTC port to the public internet (reach it over the VPN) or serving only H.265 to browsers that can't decode it via MSE.

Related tool/calculator

Use the linked calculator or tool to turn this runbook into numbers for your exact setup.

Camera bandwidth calculator

Last reviewed

2026-06-03 · Reviewed by HomeTechOps. Built from June-2026 research verified against the go2rtc README and WebRTC notes (default ports 1984/8554/8555, MSE vs WebRTC latency) and Frigate's embedded-go2rtc behavior; leads with HLS-is-why-it-lags, the MSE-vs-WebRTC tradeoff, the H.264 codec requirement, and the reachable-8555 WebRTC gotcha, cross-linking the remote-access page for the over-VPN case.

Sources/assumptions

Assumes go2rtc (standalone or embedded in Frigate) restreaming an RTSP camera for browser live view.
go2rtc defaults: web UI/API on 1984, RTSP on 8554, WebRTC on 8555 (TCP+UDP); inside Frigate, MSE is fronted by Frigate's own port.
Latency depends on codec and transport — WebRTC needs reachable candidates, so remote WebRTC may need the host:port exposed over your VPN.

Source-backed checks

HomeTechOps turns official docs and conservative safety rules into a shorter runbook. These links are the source trail for the page direction.

Frigate docs: Recommended hardwareUsed for detector inference times, the cameras ≈ (1000 ÷ inference_ms) ÷ detect_fps capacity model, and the current 'Coral no longer recommended for new installs' guidance.Frigate docs: Camera setup (detect vs record streams)Used for the detect-on-substream / record-on-main pattern that drives bandwidth and detector load.FS.com: Understanding PoE standards and wattageUsed for the 802.3af/at/bt source-vs-delivered power figures and the switch total-PoE-budget constraint.go2rtc (AlexxIT) — READMEUsed for go2rtc restreaming, the default ports (web 1984 / RTSP 8554 / WebRTC 8555), and MSE vs WebRTC low-latency live view.go2rtc (AlexxIT) — WebRTC notesUsed for the WebRTC candidate/port behavior (8555 TCP+UDP) and why WebRTC needs a reachable host:port for true sub-second live view.Frigate documentationUsed as the first-party reference for Frigate camera setup, detectors, recording, and configuration.

Diagnostic rule

1. Check the simplest signal first.
2. Change one thing at a time.
3. Prove the stream/reachability before deep config.
4. Stop when the evidence says the risk moved.

FAQ

Why is my browser camera view several seconds behind real time?

Because it's almost certainly using HLS (which buffers in multi-second segments) or a transcoded RTSP-over-something path. For live monitoring you want MSE (low latency, ~half a second) or WebRTC (sub-second). go2rtc serves both: restream the camera once and view it via go2rtc's MSE/WebRTC player instead of an HLS embed.

MSE or WebRTC in go2rtc — which should I use?

MSE is the lowest-friction low-latency option and works well on a LAN; WebRTC is the lowest latency (sub-second) but needs a reachable host:port (8555 TCP+UDP) to exchange candidates, so it can need extra config across networks or over a VPN. go2rtc auto-negotiates, but if WebRTC won't connect remotely, confirm 8555 is reachable; otherwise MSE is the reliable fallback.

WebRTC works locally but not when I'm away — why?

WebRTC has to advertise an IP:port the client can reach for the media path. On the LAN that's automatic; remotely, the candidate may be a private IP the client can't reach. Reach the NVR over a mesh VPN (so the private candidate is routable) or ensure go2rtc's WebRTC port (8555) is reachable through the tunnel. See view cameras remotely without the cloud.