# MediaMTX: A Zero-Dependency Media Router for RTSP, WebRTC, SRT and MoQ > MediaMTX is a single-executable live media server and proxy that reads, publishes, converts, records and plays back real-time streams across RTSP, RTMP, WebRTC, SRT, HLS, MPEG-TS, RTP and Media-over-QUIC. It is aimed at engineers who need protocol bridging without wiring together a stack of separate daemons. **bluenviron/mediamtx** — Ready-to-use Media-over-QUIC / SRT / WebRTC / RTSP / RTMP / LL-HLS / MPEG-TS / RTP live media server and media proxy that allows to read, publish, proxy, record and playback real-time video and audio streams. - Repository: https://github.com/bluenviron/mediamtx - Website: https://mediamtx.org - Stars: 20,302 · Forks: 2,391 - Language: Go - License: MIT - Published: 2026-09-21 · Updated: 2026-09-21 · Language: en - Canonical page: https://hysenlabs.com/projects/bluenviron-mediamtx ## The gap MediaMTX fills between encoders and players A camera speaks RTSP. A browser speaks WebRTC or HLS. An OBS instance publishes RTMP. An SRT contribution feed arrives on UDP. Getting those four things to talk usually means running a relay, a packager, a signalling server and something to glue them together. MediaMTX collapses that into one executable that the README describes as a "media router" routing streams from one end to the other. The unit of organisation is the path: several streams can be served at once in separate paths, and each path can carry its own configuration. That maps cleanly onto the common case of one path per camera or per contribution feed. The project is written in Go, licensed MIT, and the README states it does not require any dependency or interpreter, which matters when the target is a Raspberry Pi or an edge box where you do not want a Python or Node runtime in the image. ## How the router moves a stream between protocols The mechanism is conversion at the path level rather than at the connection level. A publisher connects over any supported protocol, the stream lands on a named path, and any reader can then attach to that path over any other supported protocol. The README states plainly that streams are automatically converted from one protocol to another. The dependency list shows the shape of that work: gortsplib for RTSP, gortmplib for RTMP, gohlslib for HLS, pion/webrtc for WebRTC, datarhei/gosrt for SRT, and quic-go plus webtransport-go for Media-over-QUIC. mediacommon handles the shared media representation that lets a stream cross those boundaries. Around the media plane sit the operational pieces: a Control API, Prometheus-compatible metrics, hooks that run external commands when clients connect, disconnect, read or publish, and hot reloading of the configuration without disconnecting existing clients. A proxy mode forwards requests to another server, and a forward mode pushes streams onward to another server. ## Installing MediaMTX and publishing a first stream The README points to the install page at mediamtx.org/docs/kickoff/install and links a Docker Hub image at bluenviron/mediamtx. The repository ships a mediamtx.yml at the top level, which is the configuration file the server reads. Because the README gives no command-line publish example and no port numbers, the concrete first step it does document is the configuration file itself: start the server so that it reads mediamtx.yml, then publish to a path defined there. The Docker Hub image is the documented container route, and the install page covers Linux, Windows and macOS binaries. For a Raspberry Pi, the single-executable design is the reason it fits at all, and the install page is where the platform instructions live. What you should see after starting the server is a running process bound to the protocols enabled in mediamtx.yml, with each configured path accepting a publisher and any number of readers. ## Where MediaMTX is the wrong tool MediaMTX routes and repackages; it does not transcode. If your source is 4K H.265 and your audience needs 720p H.264, the router will carry the stream but will not change its codec or resolution for you, and you will need a transcoder in front of or behind it. The README's feature list does not claim transcoding, and the dependency list contains no encoder. The second boundary is the interface. There is a Control API and there are metrics, but the README documents no web UI, and the related search phrase "Mediamtx UI" reflects a demand the repository does not answer with a bundled dashboard. Third, the README says nothing about built-in TLS certificate management, so terminating TLS and managing certificates is your problem, not the server's. Finally, the README does not document rollback of a configuration change: hot reloading is listed as a feature, but reverting to a previous known-good configuration is not described, so treat mediamtx.yml as something you version in your own repository. ## MediaMTX compared with FFmpeg as a server FFmpeg is the obvious thing to reach for when you want to move media between formats, and people do use it as an ad hoc RTSP or SRT listener. The difference is architectural. FFmpeg is a command-line transcoder and muxer: you start a process with a specific input and a specific output, and when a second reader wants a different protocol you start a second process. MediaMTX is a long-running server holding named paths, where the set of readers and their protocols is not fixed at launch. That is why the router can serve one published stream to a WebRTC browser, an RTSP client and an HLS player simultaneously without three FFmpeg invocations. The trade-off runs the other way too: FFmpeg will filter, scale and re-encode, and MediaMTX will not. In practice the two are complements, with FFmpeg as the publisher or transcoder feeding a MediaMTX path. ## Maintenance, licence and the cost of upgrading The repository is not archived and the last push was on 2026-09-20, with v1.21.0 released on 2026-09-05 and v1.20.1 before it on 2026-08-18. Releases arrive on a roughly monthly cadence, which means upgrade cost is a recurring line item rather than a one-off. The Makefile exposes the project's own workflow: make test, make test-e2e, make lint, make binaries and make apidocs, and the Go version pinned in go.mod is 1.26.0, so building from source requires a toolchain at that level. The dependency list includes several pseudo-versioned modules (gohlslib, mediacommon, gosrt) pinned to specific commits, which is a signal that the protocol implementations move in step with the server and that cherry-picking a single dependency is not the intended upgrade path. The licence is MIT, which is permissive and imposes no copyleft obligation on your own code; that is a factual statement about the licence text, not legal advice about your deployment. ## Conclusion Adopt MediaMTX when you need one process to accept RTSP or RTMP from a camera or encoder and republish it as WebRTC, HLS or SRT without maintaining a pipeline of separate tools. Do not adopt it if you need adaptive bitrate transcoding or a browser dashboard: the repository documents neither, and the configuration is a YAML file plus a Control API. Before deploying, verify the paths block in mediamtx.yml, confirm your authentication mode (internal, HTTP or JWT), and check whether the always-available and record features are enabled for the streams you care about. ## FAQ ### What is MediaMTX used for? It is a live media server and media proxy that lets clients publish, read, proxy, record and play back real-time video and audio streams. The README describes it as a media router that moves streams between Media-over-QUIC, SRT, WebRTC, RTSP, RTMP, HLS, MPEG-TS and RTP. ### What are the key differences between MediaMTX and FFmpeg? FFmpeg is a transcoder and muxer driven by a command line, while MediaMTX is a server that holds named paths and converts streams between protocols automatically. MediaMTX does not transcode, so codec and resolution changes still belong to FFmpeg or another encoder. ### How do I download MediaMTX? The README links the install page at mediamtx.org/docs/kickoff/install and a Docker Hub image at bluenviron/mediamtx. Binaries are published on the GitHub releases page, and the project is compatible with Linux, Windows and macOS. ### How do I install MediaMTX on Windows? The README states the server is compatible with Windows and requires no dependency or interpreter, and it points to the install page for platform instructions. The related searches include a Windows download query, but the README itself does not list Windows-specific steps. ### Is MediaMTX safe? The repository includes a SECURITY.md file and the project is MIT licensed, and the README documents authentication through internal, HTTP or JWT modes. The README does not make any broader security guarantee, so exposure of the server ports should be decided by your own network design. ## Sources - [bluenviron/mediamtx on GitHub](https://github.com/bluenviron/mediamtx) - [License: MIT](https://github.com/bluenviron/mediamtx/blob/main/LICENSE) - [Project website](https://mediamtx.org) - [README](https://github.com/bluenviron/mediamtx/blob/main/README.md) - [Releases](https://github.com/bluenviron/mediamtx/releases) --- Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/bluenviron-mediamtx