The 540-file checkout routes streams across protocols
Our 540-file go2rtc checkout is a camera transport layer with inputs for RTSP, ONVIF, WebRTC, HomeKit, Ring, Nest, Tapo, Wyze, Xiaomi, local devices, files, and external commands. It can expose a source through RTSP, WebRTC, HLS, MP4, MJPEG, or other documented outputs. Home Assistant and Frigate can consume those republished feeds, while developers can use HTTP and WebSocket APIs. Two-way audio and track mixing cover cases that a simple RTSP relay would miss.
The source occupied 2.6 MB and contained about 59,959 lines, which is compact for the number of protocol adapters present. A single named stream can combine an original camera feed with an FFmpeg-generated audio track, then let go2rtc choose tracks that a browser accepts. That is the practical appeal: operators define a camera once and stop teaching every viewer how to reach its private vendor protocol. It remains a streaming component, so recording, events, and object detection belong in surrounding software.
Three default ports make first use easy and LAN exposure real
The 2.6 MB repository starts with predictable endpoints: the web API uses port 1984, RTSP uses 8554, and WebRTC uses TCP and UDP 8555. A minimal YAML file can contain one stream name and one camera URL. Release binaries cover Windows, macOS, Linux, FreeBSD, several CPU architectures, and older Raspberry Pi hardware. The project also publishes containers and a Home Assistant add-on, with FFmpeg and Python included in the documented container image.
Those defaults are unsafe on a network you do not fully trust. The README says all three ports are accessible from the local network and anyone there can watch cameras without authorization. It warns that an attacker reaching the API may invoke insecure sources such as echo and exec, gaining full server access. Bind the API and RTSP listeners to localhost, limit modules and API paths, restrict executable paths, and put standalone web access behind an authenticated reverse proxy.
What happened when we ran it
Our Node-focused sandbox installed 220 npm packages in 44 seconds and consumed 115 MB on disk. npm audit reported 0 known vulnerabilities: 0 critical, 0 high, 0 moderate, and 0 low. The checkout was commit c245815 in an unprivileged Debian container with 3 CPUs, 8 GB of RAM, and no secrets. Our scan also recorded 3 CI workflow files and no tests directory.
The lab found no npm build script or target, so it skipped the build. It also found no npm test script or target and skipped tests. Those are absences, not successes. This measurement path checked the repository's npm dependency surface and did not compile, start, or send video through the Go application. The 44-second install and clean npm audit therefore say nothing about camera latency, stream stability, Go compilation, or protocol correctness. Each of those claims would require a different run.
Nine documented codecs still require endpoint matching
The roughly 59,959 source lines recognize nine listed audio and video codecs, including H.264, H.265, AAC, Opus, MJPEG, and several PCM forms. Compatibility still depends on the output and viewer. The README's matrix shows different results for Chrome, Firefox, Safari, Home Assistant, WebRTC, MSE, HTTP streaming, and HLS. Codec filters select from tracks that already exist. They do not create a codec that the camera never supplied.
go2rtc performs a few narrow conversions, such as repacking some PCM audio for modern browser containers and resampling audio for WebRTC. Complex transcoding stays in FFmpeg, and the README says there are no plans to embed those algorithms. That separation keeps the core smaller, but it moves CPU sizing, hardware acceleration, and FFmpeg syntax into the operator's job. Test the exact chain from camera to viewer, including audio and talkback. A picture in one browser proves only that one negotiated path.
v1.9.14 issues show why every camera needs a trial
Version v1.9.14 was published January 19, 2026, with major Xiaomi work, a native Wyze source that requested testing, WebRTC listener changes, ONVIF changes, and a new web configuration editor. Open issue 2465 reports that the same release panics when a DJI RTMP publisher sends an empty video payload. The reporter says every stream drops during repeated restarts. That is one specific publisher case, yet it matters wherever go2rtc is a shared hub for unrelated cameras.
The 3 CI workflow files do not settle vendor behavior. Issue 2233 reports a Xiaomi cloud token expiring after about 3 days, after which the user deletes the saved token and signs in again. Other current reports cover dual-lens Tapo selection, unusual H.265X firmware, and reconnect behavior for long-running consumers. Camera makers change firmware and often implement standards unevenly. Treat the protocol list as a set of adapters to test, not a promise that every model revision works.
July code and September issue activity show uneven cadence
GitHub recorded the last source push on July 13, 2026, and listed 14,116 stars plus 900 combined issues and pull requests. The latest release remained v1.9.14 from January, while open issues were still being updated on September 5. That combination is more informative than the release date alone: the project has a large audience and current user activity, although the published release and source push are separated from the newest reports.
Our run installed 220 npm packages and found 0 known vulnerabilities, yet the missing npm build and test targets leave the Go product unverified by this lab pass. go2rtc is still an unusually capable bridge for Home Assistant, Frigate, and mixed camera fleets. Its compact binary path makes a trial cheap. Adoption should follow only after authentication, listener binding, codec negotiation, vendor login renewal, restart behavior, and the exact camera firmware have survived a realistic soak on the network where it will run.