RTSPtoWebRTC is a Go bridge the author asks you to replace with his own project

The bridge is pure Go, with no ffmpeg in the path

RTSPtoWebRTC takes an RTSP stream and delivers it to a web browser over WebRTC. The headline claim in the README is that it is based on Pion and full native, not using ffmpeg or gstreamer.

That matters operationally. There is no external transcoding binary in the container, so the service is a single Go process that speaks RTSP itself and negotiates WebRTC itself. The go.mod file makes the stack concrete: it requires Go 1.18, github.com/deepch/vdk v0.0.20 for the RTSP side and github.com/gin-gonic/gin v1.9.0 for the HTTP layer, with the Pion family underneath.

The Pion modules are all indirect dependencies pulled in by the WebRTC side, and there are many of them: datachannel, dtls, ice, interceptor, mdns, randutil, rtcp, rtp, sctp, sdp, srtp, stun, transport, turn and udp in both v1 and v2 forms. Nothing here is a wrapper around a browser or an external media server. The repository is small and flat at that, with config.go, http.go, main.go and stream.go at the root plus a web/ directory for the front end.

One oddity in the metadata: the repository's primary language is listed as JavaScript while the source is Go, because the bundled web directory is what the language detector weighed most heavily.

Running it is clone, go run, open a browser

The test-run sequence in the README is four steps.

$ git clone https://github.com/deepch/RTSPtoWebRTC

$ cd RTSPtoWebRTC/

$ GO111MODULE=on go run *.go

open web browser http://127.0.0.1:8083 work chrome, safari, firefox

There is no configuration file passed on the command line and no flag for the address. The port comes from config.json, so the 8083 in the browser URL is the value in the sample configuration, and changing it means editing that file before the first run.

The browser line carries a warning embedded in it: the author states that the current test work is on chrome, safari and firefox, and adds no MAC OS. So the README's own test matrix has a hole where macOS would be, and that is stated by the maintainer rather than inferred.

The Dockerfile gives you the production shape of the same thing: it starts from golang:1.18, copies the source, runs go get and go install, exposes 8083, sets GO111MODULE=on and GIN_MODE=release, and runs the same go run *.go command. Note that the container image contains the toolchain rather than a small static binary, and that the entrypoint runs a compiler at start rather than a built binary.

config.json defines the streams and their start behaviour

Configuration is a single JSON file with a server block and a streams map, and the sample ships three demo streams.

{
  "server": {
    "http_port": ":8083"
  },
  "streams": {
    "demo1": {
      "on_demand" : false,
      "url": "rtsp://170.93.143.139/rtplive/470011e600ef003a004ee33696235daa"
    },
    "demo2": {
      "on_demand" : true,
      "url": "rtsp://admin:[email protected]/mpeg4"
    }
  }
}

The demo1 and demo3 entries point at the same public RTSP URL and differ in nothing except the key name, which tells you the file is a demonstration rather than a curated list. demo2 shows the credential form with a username and password inside the URL, which is how RTSP authentication is carried here.

Each stream takes a name used as the key and an on_demand flag. The README spends a separate section on that flag, and the advice is blunt: use "on_demand": false, otherwise you will get choppy jerky streams and performance issues when multiple clients connect. That is a statement about how the sessions are created rather than about camera bandwidth, and it means the flag should be set deliberately per stream, not left on.

There is no documented option for bitrate, resolution, frame rate or TCP versus UDP transport, so whatever the camera sends is what the browser receives.

The codec list is short and it is the real constraint

The limitations section names exactly what is supported.

Video codecs supported: H264. Audio codecs supported: pcm alaw and pcm mulaw.

That is the whole media support statement, and it rules out more deployments than the rest of the project does. An H265 camera, an MJPEG stream or any AAC audio will not work here, and nothing in the repository offers transcoding as a fallback because there is no ffmpeg in the design. G.711 in its two 8 kHz variants is what IP cameras with audio most often emit, which is why the pairing works as often as it does.

The performance note connects to the same area. Because there is no transcode, the browser receives the camera's own H264 stream, and the on_demand setting determines whether the RTSP session exists before a viewer arrives. When several clients connect to an on-demand stream, the README says you will see choppy streams and performance problems, which is the behaviour that pushes people to set on_demand to false and keep the session alive.

The README points at a different repository twice

The most consequential line in the document is at the top, and it is not a description of this project.

The README states that deepch/RTSPtoWeb is an improved service providing the same functionality, an improved API, and support for even more protocols, and that RTSPtoWeb is recommended over using this service. It repeats the point in the Other Example section, which lists six sibling repositories: RTSPtoWeb, RTSPtoWebRTC, RTSPtoWSMP4f, RTSPtoImage, RTSPtoHLS and RTSPtoHLSLL.

There is also a targeted redirect. If you need RTSP to WebSocket MPEG-4, the answer is RTSPtoWSMP4f, a separate repository for that combination.

Read together, that is the maintainer telling you the family has a preferred member, and that this one exists for the specific case where you want WebRTC rather than WebSocket, HLS or an image pull. If you are starting a new deployment and do not have a reason to pick WebRTC over the sibling services, the README itself argues for picking a different repository.

What a deployable version of this looks like

Beyond the codec limits, the packaging is the part a deployment team will notice. The Dockerfile builds and runs with a full Go toolchain in the image, which is a development shape rather than a minimal production one. There is no non-root user configured, no health check, and no reverse proxy or TLS termination described anywhere in the repository.

The HTTP surface is whatever gin serves plus the signalling the browser needs for WebRTC, and the README says nothing about authentication of the browser endpoints. Anyone who can reach the port can request a stream. For a camera feed that is a serious consideration and the documentation gives you nothing to build on.

The project is not archived and the last push was on 2026-10-15, so work is landing. It has no GitHub releases at all, which means there is no tag to pin, no changelog to read and no version string to put in a deployment manifest. The CHANGELOG and renovate configuration sit in the repository, and renovate suggests dependency updates are automated, but neither gives you a release to install.

Licensing is MIT in the LICENSE file, with no complications. The vdk dependency is by the same author, deepch, which means the RTSP half and the WebRTC half of the stack come from one person.

Editorial conclusion

Adopt RTSPtoWebRTC only for a lab or a single camera where you need WebRTC in a browser today and can accept H264 with pcm alaw or pcm mulaw audio, because that is the entire codec surface it documents. Do not start new work here: the README recommends deepch/RTSPtoWeb instead, calls that service an improved one with a better API and more protocols, and points at RTSPtoWSMP4f if you need MPEG-4 over WebSocket instead. Verify first that your cameras speak H264 and G.711, that you can set on_demand to false in config.json, because on-demand starts produce the choppy streams the README warns about, and that your network allows the WebRTC path you need. There are no GitHub releases, so build from master with the Go 1.18 Dockerfile rather than pinning a version.

Frequently asked questions

Official sources

1. deepch/RTSPtoWebRTC on GitHub
2. Issues
3. License: MIT
4. README