MediaMTX is a ready-to-use, zero-dependency live media server and media proxy written in Go, aimed at anyone who needs to publish, read, proxy, record and play back real-time video and audio streams across many protocols without standing up a heavy media platform.
What it is
MediaMTX is a live media server and media proxy that routes real-time video and audio streams from one endpoint to another. Its authors describe it as a "media router": publishers send a stream in, and the server delivers it to any client that asks, converting between protocols on the way. It is a single executable written in Go, distributed under the MIT licence, and it does not require any dependency or interpreter. It runs on Linux, Windows and macOS. The project lives in the open-source live-streaming ecosystem and is published by the bluenviron organisation at mediamtx.org.
The concrete problem it replaces is the collection of separate, protocol-specific servers that a streaming setup usually accumulates. Instead of running one server for RTSP, another for RTMP, another for HLS and a separate WebRTC gateway, a single MediaMTX instance accepts Media-over-QUIC, SRT, WebRTC, RTSP, RTMP, HLS, MPEG-TS and RTP, and converts automatically between those protocols. Streams can be served on several paths at once, forwarded to other servers, proxied, recorded, and replayed later, all from one process with one configuration.
Key capabilities
- Publish streams to the server with Media-over-QUIC, SRT, WebRTC, RTSP, RTMP, HLS, MPEG-TS and RTP, using FFmpeg, GStreamer, OBS Studio, Python, Golang, Unity, web browsers or Raspberry Pi cameras.
- Read streams back with Media-over-QUIC, SRT, WebRTC, RTSP, RTMP and HLS, from FFmpeg, GStreamer, VLC, OBS Studio, Python, Golang, Unity or web browsers.
- Automatic protocol conversion, so a publisher on one protocol and a reader on another still connect.
- Record streams to disk in fMP4 or MPEG-TS format, and play the recorded streams back from disk.
- Serve always-available streams even when the original publisher is offline.
- Authenticate users through internal, HTTP or JWT authentication.
- Operate the server through the Control API, extract Prometheus-compatible metrics, and run hooks in the form of external commands when clients connect, disconnect, read or publish.
- Reload configuration without disconnecting existing clients (hot reloading), and serve several streams at once in separate paths.
Who uses it and how
- Broadcasters and developers publishing from OBS Studio or FFmpeg and letting MediaMTX repackage the same feed for RTSP, HLS and WebRTC viewers.
- Operators running Raspberry Pi cameras that publish to the server and forward streams to a second MediaMTX instance in another location.
- Teams building browser players, Unity applications or Python and Golang clients that read streams over WebRTC or HLS from the same instance.
- Users recording streams to disk in fMP4 or MPEG-TS for later playback, with authentication enforced through internal, HTTP or JWT credentials.
- Single-machine deployments on Linux, Windows or macOS where a media server is needed without installing a dependency or interpreter, since MediaMTX ships as one executable.
Getting started
Install from the instructions at mediamtx.org/docs/kickoff/install, or run the official Docker image bluenviron/mediamtx published on Docker Hub.
How it compares
No comparable paid products or similar tools are named in the facts provided, so MediaMTX stands alone in this registry rather than being contrasted against alternatives.
When to use it — and when not to
A self-hoster takes on operating the server itself, opening the ports for the protocols in use, managing the configuration file and giving the recording feature somewhere to write. Teams that want a hosted service with a vendor behind it, or that cannot accept the responsibilities of running their own media path, should look elsewhere. The project carries 188 open issues, so a deployment should plan for active version tracking rather than set-and-forget stability.
