MediaMTX v1.21.0 accepts 8 publishing protocols in one process
MediaMTX v1.21.0 is a media router for Media-over-QUIC, SRT, WebRTC, RTSP, RTMP, HLS, MPEG-TS, and RTP publishers. Readers can connect through Media-over-QUIC, SRT, WebRTC, RTSP, RTMP, or HLS. The server links one publisher or external source to a named path, then broadcasts that stream to its readers. For a camera fleet or live-production toolchain, this can replace several small protocol gateways and their separate configuration files.
The same process can pull remote sources, forward streams, record fMP4 or MPEG-TS to disk, and serve playback. Optional endpoints expose a control API, Prometheus metrics, and pprof data. Hooks can launch external commands when clients connect, publish, read, or disconnect. Configuration reloads do not disconnect existing clients. That is a lot of operational surface in one binary, and each enabled listener still needs an explicit access and exposure decision.
What happened when we ran it
Our sandbox installed commit 3a9fdaf in 35 seconds and pulled 153 Go packages. Compilation succeeded in 4 seconds. The full test step ran for 97 seconds, then exited with code 1: 122 tests passed and 5 failed out of 127. This is a mixed result. Source builds are quick, but the checkout did not clear its complete suite in our fresh 3-CPU, 8 GB Debian container.
The supplied log tail listed successful packages for static sources, HLS, Media-over-QUIC, MPEG-TS, Raspberry Pi camera downloading, RTMP, RTP, RTSP, SRT, WebRTC, and stream handling. It ended with a bare FAIL and did not name the 5 failed tests or show their diagnostics. We cannot attribute the result to networking, privileges, timing, or missing system software from that excerpt. Reproducing the full output is a release gate for anyone building this commit.
Protocol conversion does not include codec conversion
MediaMTX can accept a stream through one protocol and make it readable through another when the media itself is compatible. That is routing and remuxing, not a promise to turn any input codec into one every browser can decode. The re-encoding guide tells users to run FFmpeg or GStreamer through hooks when they need a different format, codec, or compression level. The base Docker image intentionally omits utilities, while separate image variants add FFmpeg or Raspberry Pi camera support.
Browser playback makes this boundary visible. The WebRTC guide warns that browser codec support varies, especially for H.265 and H.264 streams containing B-frames. Its compatibility example uses H.264 baseline and Opus via an external FFmpeg process. A deployment that accepts arbitrary cameras needs a codec inventory and a decision about where transcoding runs. The 153 packages in our source build do not turn the MediaMTX process into a general transcoder.
The shipped v1.21.0 configuration allows anonymous stream access
The default internal user is any, with publish, read, and playback permissions on every path and no IP restriction. Administrative API, metrics, and pprof permissions are limited to localhost by default, and those services start disabled. This makes a local demo easy. It is an unsafe starting point for an internet-facing host unless the operator replaces the stream permissions, restricts the network, and enables encryption or a VPN as the authentication guide advises.
Authentication can remain in the YAML file with Argon2 or SHA-256 hashes, call an HTTP endpoint for each decision, or validate JWTs against a JWKS provider. Permissions cover actions and paths. Protocols carry credentials differently, and token length limits matter for RTSP, RTMP, and SRT clients. Release v1.21.0 also changed default allowed origins for administrative endpoints and added credential redaction in RTSP logs, evidence that browser and log exposure need version-aware review.
The Docker quick start publishes 9 TCP or UDP mappings
The official container command maps 9 TCP or UDP entries, including RTSP, RTMP, HLS, WebRTC, SRT, and Media-over-QUIC listeners. WebRTC needs webrtcAdditionalHosts set to an address clients can reach. A container or NAT must route UDP port 8189, or the operator can enable TCP, configure STUN for hole punching, or provide a TURN relay and its credentials. RTSP UDP may require host networking, which the install guide says is incompatible with Windows, macOS, and Kubernetes.
Horizontal scale is similarly hands-on. The documented design puts publishers on an origin and readers on replicas, with a Layer 4 load balancer for RTSP, RTMP, and SRT or a sticky Layer 7 balancer for HLS and WebRTC. A CDN can offload HLS, but the guide says low-latency playlists remain uncacheable and normal MediaMTX authentication no longer applies. MediaMTX supplies the routing pieces; autoscaling, load balancing, shared secrets, and failure recovery remain infrastructure work.
A September 8 push outweighs the 190 open threads
GitHub showed 20,067 stars, 164 open issues, and 26 open pull requests. The last push was September 8, 2026, three days after v1.21.0. The ten most recent releases listed by GitHub span April 26 through September 5, a rapid cadence for a network server. Recent changes covered dependency updates, H.265 recording, allowed-origin checks, Media-over-QUIC forwarding, API fields, and protocol fixes. The queue is large, but activity is current and specific.
SRS is the broader broadcast-server alternative when built-in workflows matter more than a compact router. LiveKit is a better match for WebRTC rooms, participant state, and application SDKs. OvenMediaEngine focuses on large low-latency broadcast delivery. MediaMTX is the cleaner choice when your problem is moving existing streams among protocols and you can keep codecs unchanged. Its 4-second build is appealing; the 5 failed tests and substantial network configuration keep this from being a blind install.