Inside go2rtc: port 1984, per-target binaries, and a codec negotiation layer

Installation is three steps and one port number

The whole getting started procedure fits in three lines. Grab the software, either a binary, a Docker image, or one of the two Home Assistant routes. Open the web interface at `http://localhost:1984/`. Then add your streams to the configuration. That last step is where the real work sits, because the config file is where cameras are declared, and the interface at port 1984 is how you inspect what is running rather than how you define it. The application describes itself as a zero-dependency small app for all operating systems, meaning Windows, macOS, Linux, and FreeBSD, with nothing else to install first. That claim is about the running system rather than the source tree, which is a different matter and comes back later.

Prebuilt binaries cover everything from a Pi Zero to Apple Silicon

The release table is the widest part of the project and the reason most people never compile anything. Windows is covered by `go2rtc_win64.zip` for Windows 10+ 64-bit, `go2rtc_win32.zip`, and `go2rtc_win_arm64.zip`. Linux has `go2rtc_linux_amd64` and `go2rtc_linux_i386` for ordinary 64-bit and 32-bit hosts, plus `go2rtc_linux_arm64` and `go2rtc_linux_arm` for Raspberry OS in both widths, `go2rtc_linux_armv6` aimed at the old Raspberry 1 and Zero, and `go2rtc_linux_mipsel`, which the table ties to devices such as the Xiaomi Gateway 3 and Wyze cameras. macOS entries are `go2rtc_mac_amd64.zip` for macOS 11+ on Intel and `go2rtc_mac_arm64.zip` for Apple Silicon. Building from source instead needs Go 1.24.0, the version declared in go.mod.

The Home Assistant add-on and the integration are different hooks

Home Assistant appears twice in the installation options, as an add-on and as an integration, and the two are not interchangeable in practice. An add-on is installed and lifecycle-managed by Home Assistant itself, which suits a single-box install where the camera bridge and the automation platform share a host. An integration leaves go2rtc running somewhere and connects to it from Home Assistant, which suits a deployment where go2rtc lives on a different machine, or in Docker, or serves clients beyond Home Assistant. There is also a Master version listed alongside the binary and Docker routes, for people who want current code rather than a tagged build. For developers there is a third path stated separately: an HTTP API under `internal/api/README.md`, meant to be integrated into a smart home platform. The `examples/go2rtc_hass` directory is where that integration work is shown.

Format matching is negotiated client side, not hardcoded per app

The headline claim is support for dozens of formats and protocols on input, all popular formats on output, and ingest in a number of popular formats, but the mechanism underneath is the interesting part. Instead of a fixed table of what each client can play, go2rtc auto-matches the formats and codecs the client already supports, and that logic lives in a JavaScript API documented in `www/README.md`. Alongside it the table of contents names four distinct codec areas: codecs filters, codecs madness, built-in transcoding, and codecs negotiation, which tells you the negotiation path is where the complexity lives. Transcoding is deliberately not the default: it happens on the fly via FFmpeg only if necessary, with that path documented separately under `internal/ffmpeg`. You can also mix tracks from different sources into a single stream. The cost of this design is that no single page explains it.

Two-way audio turns a viewer into a control path

Most of the feature list is about getting a picture from A to B, and three items are not. Two-way audio is supported for many formats, and streaming audio back to a camera is claimed for all of them, which is talkback rather than playback. Publishing pushes any source out to popular streaming services, with YouTube and Telegram named. Preloading keeps a stream warm instead of starting it per viewer, and streaming stats report every active connection. The security consequence is direct. Once audio travels inbound on a protocol you opened, the application is no longer a read-only viewer sitting next to your recordings: it is a path to a speaker and a microphone in your home, on a port that the installation steps tell you to open on localhost without mentioning any access control. The table of contents does include a Security section, which is where that belongs, and the port mapping question belongs with whoever exposes this beyond your own machine.

The examples directory is the real integration documentation

The `examples` directory lists the surfaces people actually build against: `go2rtc_hass` for Home Assistant, `go2rtc_rtsp` and `rtsp_client` for RTSP, `onvif_client` for ONVIF, `go2rtc_mjpeg` for motion JPEG, `homekit_info`, `mdns` for discovery, `mod_pinggy`, and `tutk_decoder`. Reading that list tells you more about the project's shape than the feature bullets do, since it shows go2rtc approached as a library by other Go programs as much as a standalone app. Documentation is scattered to match: `internal/api/README.md` for the HTTP API, `www/README.md` for the JavaScript API, `internal/ffmpeg/README.md` for transcoding, and a separate `website` directory built with VitePress, wired through scripts named `docs:dev`, `docs:build`, and `docs:preview` in package.json. Expect to cross three or four files for any question that spans layers.

The newest tag is from January while commits continue

The release history is short and regular: v1.9.12 on 2025-11-16, v1.9.13 on 2025-12-14, and v1.9.14 on 2026-01-19, with the last push to master dated 2026-09-06. So commits have continued for several months past the newest listed tag, which is the normal shape of an actively used project but does mean the tagged builds and the head of the branch are different things. The Master version install route exists precisely for people who want that head. The project is MIT licensed, which is permissive enough to embed in other software, and the README notes it can be integrated into any project or used standalone. Its inspirations are named too, including the pion WebRTC library, the rtsp-simple-server idea, a GStreamer pipeline idea, a MediaSoup routing idea, and the HomeKit Accessory Protocol from the hap project.

Editorial conclusion

go2rtc is worth the trouble for anyone whose camera speaks a protocol their viewer does not, or who wants browser and app clients without rebuilding a camera stack, and the per-target binaries make a first install cheap. It is a poor fit if you need a documented service hardening story, a configuration reference in one place, or a maintained release cadence to plan upgrades against, because the answer to each of those lives in a different file or is missing. Before you commit, pick the install path that matches who manages the device, pin a version tag rather than master, and read the Security and Codecs sections in full before you expose port 1984 anywhere.

Frequently asked questions

Official sources

1. Official documentation
2. Official README
3. Project repository
4. Release notes