MediaMTX

Open-source live streaming infrastructure, honestly reviewed. Protocol conversion, recording, and proxy without a SaaS bill.

TL;DR

• What it is: MIT-licensed, zero-dependency media server and proxy that routes live video and audio streams between protocols — RTSP, RTMP, WebRTC, HLS, SRT, MPEG-TS, and RTP [README].
• Who it’s for: Developers, homelab operators, and surveillance builders who need to bridge streaming protocols, re-stream camera feeds, or replace expensive hosted streaming infrastructure. Not a tool for non-technical founders without help.
• Cost savings: Commercial video streaming platforms (Wowza, Dacast, AWS Kinesis Video Streams) start at $39–$195/month. MediaMTX self-hosted runs on a $5–10/month VPS with no per-stream or per-minute charges [README][website].
• Key strength: Single binary, zero dependencies, any-to-any protocol conversion. Publish via RTSP from an IP camera, read back via WebRTC in a browser — it just works [README].
• Key weakness: No built-in UI or dashboard. Pure infrastructure — there’s nothing to click. Setup requires comfort with terminals, networking, and port configuration. Non-technical users will need help [install docs].

---

What is MediaMTX

MediaMTX (formerly rtsp-simple-server) is a real-time media router. It sits in the middle of your streaming stack and routes video and audio between sources and consumers, translating between protocols as needed. The project’s own description is precise: “a ready-to-use and zero-dependency real-time media server and media proxy that allows to publish, read, proxy, record and playback video and audio streams” [README].

The “media router” framing is more accurate than “media server.” MediaMTX doesn’t host video files for on-demand playback — that’s Plex or Jellyfin’s job. It handles live streams: a camera publishing RTSP gets routed to a browser viewer consuming WebRTC; an OBS broadcast in RTMP gets forwarded to multiple downstream servers simultaneously; a Raspberry Pi camera feed gets recorded to disk in fMP4 while also being served as HLS to a dashboard.

The project sits at 18,219 GitHub stars under the MIT license, maintained by the bluenviron organization [merged profile]. Version 1.17.0 shipped March 17, 2026 [website]. It runs on Linux, Windows, and macOS as a single compiled Go binary with no runtime dependencies — no Java, no Python, no Node [README]. This is not a common quality in open-source infrastructure software, and it matters at deployment time.

The tool is mentioned in medevel.com’s roundup of open-source RTSP media servers as a solution for “real-time video streaming and RTSP cameras” that “enables the management and streaming of video from various sources” [1]. That framing is accurate but understates how broadly it’s used beyond surveillance — live event streaming, IoT camera networks, Raspberry Pi projects, and self-hosted video infrastructure all appear in its community.

---

Why people choose it

The case for MediaMTX comes down to three things: protocol coverage, operational simplicity, and cost.

Protocol coverage. No other single open-source tool handles the full range MediaMTX does. SRT (modern broadcast standard), WebRTC (browser-native), RTSP (IP cameras), RTMP (OBS, encoders), LL-HLS (low-latency browser delivery), MPEG-TS, and RTP — all supported, both for ingest and delivery [README]. Critically, streams are automatically converted between protocols, so you don’t need FFmpeg running as a permanent intermediary just to get an IP camera talking to a browser.

Operational simplicity. The “zero-dependency, single binary” claim is the real differentiator from alternatives like Nginx-RTMP (requires Nginx build with module), Wowza (Java runtime, commercial license), or Red5 Pro (Java stack, paid). You download one file and run it. Hot reloading of configuration means you never drop active streams to change settings [README]. For production infrastructure, this is meaningfully different from alternatives that require service restarts.

Cost. The streaming infrastructure market is expensive by default. AWS Kinesis Video Streams charges per GB ingested and consumed. Wowza Streaming Engine starts around $195/month. Dacast starts at $39/month with limits. MediaMTX is $0 in licensing cost, with the only expense being the VPS it runs on [README].

The surveillance/NVR community uses it heavily because most IP cameras speak RTSP but most browser-based dashboards want WebRTC or HLS — MediaMTX bridges that gap without transcoding overhead [1]. OBS streamers use it to relay a single stream to multiple destinations simultaneously (Twitch + YouTube + a self-hosted endpoint). Developers use it as the streaming backbone for applications that need to embed live video without paying per-stream fees.

---

Features

Based on the README and official documentation:

Stream publishing and reading:

• Publish live streams via SRT, WebRTC, RTSP, RTMP, HLS, MPEG-TS, RTP [README]
• Compatible sources: FFmpeg, GStreamer, OBS Studio, Python, Go, Unity, web browsers, Raspberry Pi Camera modules [README]
• Compatible viewers: FFmpeg, GStreamer, VLC, OBS, web browsers [README]
• Serve multiple simultaneous streams on separate paths [README]

Protocol conversion:

• Automatic cross-protocol translation — no manual FFmpeg pipeline required [README]
• Support for always-available stream paths (serves placeholder when publisher is offline) [README]

Recording and playback:

• Record streams to disk in fMP4 or MPEG-TS format [README]
• Playback recorded streams through the same server [README]

Routing and proxying:

• Forward streams to other RTMP/RTSP/SRT servers [README]
• Proxy requests to upstream media sources [README]

Authentication:

• Internal username/password, HTTP-based external auth, JWT token auth [README]

Operations:

• Control API for managing paths and connections programmatically [README]
• Prometheus-compatible metrics endpoint [README]
• CPU and RAM performance monitoring [README]
• Hooks (external commands) on connect, disconnect, read, publish events [README]
• Hot reload of config without dropping existing streams [README]

Deployment:

• Single binary for Linux, Windows, macOS — no runtime required [README]
• Docker image with four variants: base, ffmpeg-included, Raspberry Pi camera support, and combined [install docs]
• Arch Linux AUR package, FreeBSD ports, OpenWrt binary [install docs]

One important nuance: MediaMTX does not transcode by default. If you publish H.265 and a viewer can only consume H.264, that’s your problem to solve (typically by using the FFmpeg image variant and running an explicit FFmpeg pipeline). The server routes streams efficiently without decoding/re-encoding — which is good for performance and bad for codec compatibility [README].

---

Pricing: SaaS vs self-hosted math

MediaMTX has no paid tier. There is no cloud offering, no subscription, no usage limits — only the open-source software [README][website].

The relevant comparison is against what you’d pay for commercial streaming infrastructure:

Commercial alternatives (approximate 2026 pricing):

• Wowza Streaming Engine: Self-hosted license around $195/month or $1,995/year; cloud starting similarly
• Dacast: Entry plan ~$39/month for 1.2 TB bandwidth and 50 GB storage; overages apply
• AWS Kinesis Video Streams: ~$0.013 per GB ingested, ~$0.0085 per GB for HLS output — adds up fast at scale
• Cloudflare Stream: $5/1,000 minutes stored + $1/1,000 minutes delivered

Note: These are market reference points from publicly available pricing; verify current rates before budgeting.

MediaMTX self-hosted:

• Software: $0 (MIT) [README]
• VPS: $5–20/month depending on stream count and bitrates
• No per-stream, per-minute, or per-GB fees

Concrete example: A 24/7 surveillance setup with 8 IP cameras streaming at 2 Mbps each. On AWS Kinesis that’s roughly 2.1 TB/month ingested (~$27) plus viewer consumption. On a $10/month Hetzner VPS with MediaMTX, it’s $10/month with no overage risk.

For live event streaming re-broadcasting to multiple destinations, the math is similarly favorable. MediaMTX forwards your OBS output to Twitch, YouTube, and your own HLS endpoint simultaneously — no per-destination fee, no CDN cost for the ingest leg [README].

The honest caveat: MediaMTX doesn’t include CDN delivery to large audiences. If you’re delivering video to thousands of concurrent viewers, you still need a CDN layer in front. MediaMTX handles the ingest, routing, and recording — viewer-scale delivery is a separate problem.

---

Deployment reality check

The install path is genuinely straightforward for technical users. The Docker command from the official docs runs five lines [install docs]:

docker run --rm -it \
  -e MTX_RTSPTRANSPORTS=tcp \
  -e MTX_WEBRTCADDITIONALHOSTS=192.168.x.x \
  -p 8554:8554 -p 1935:1935 \
  -p 8888:8888 -p 8889:8889 \
  -p 8890:8890/udp -p 8189:8189/udp \
  bluenviron/mediamtx:1

What you actually need:

• A Linux server with enough bandwidth for your stream count
• Docker (or just the binary if you prefer)
• Open ports: 8554 (RTSP), 1935 (RTMP), 8888 (HLS), 8889 (WebRTC HTTP), 8890/8189 (WebRTC UDP)
• A reverse proxy (Caddy, nginx) for HTTPS if serving WebRTC — browsers require HTTPS for camera access
• The local IP address of the server filled into MTX_WEBRTCADDITIONALHOSTS so WebRTC works through Docker networking [install docs]

Where things get complicated:

The Docker networking caveat matters. The MTX_RTSPTRANSPORTS=tcp flag is required because Docker’s network stack can mangle UDP source addresses, breaking RTSP over UDP. If you skip this, RTSP sources may connect but not stream. The workaround (--network=host) bypasses Docker networking entirely but doesn’t work on macOS or Windows [install docs].

WebRTC in a browser requires the server’s real IP — not localhost, not a container IP. If MTX_WEBRTCADDITIONALHOSTS isn’t set to the right address, browsers will connect but video won’t flow. This trips up first-time users consistently.

There is no configuration GUI. All setup is through a YAML config file or environment variables. If you need to add authentication for a path, enable recording for a specific stream, or set up a forwarding rule, you edit text. This is fine for people comfortable with config files and disorienting for everyone else.

Realistic time estimates:

• Technical user (Linux-comfortable): 30–60 minutes to a working instance
• Developer who hasn’t done streaming before: 2–4 hours including understanding the port model
• Non-technical user: Not recommended without someone to set it up. The concepts (protocols, ports, ICE candidates) have no GUI equivalent to learn from.

---

Pros and cons

Pros

• Genuinely zero-dependency single binary. Download and run. No runtime, no package manager, no interpreter [README]. Unusual in open-source infrastructure software.
• Any-to-any protocol conversion. RTSP camera → WebRTC browser viewer in one hop, no FFmpeg intermediary required [README].
• Hot config reload. Change settings without dropping active streams [README]. Important for production use.
• MIT license. Commercial use, embedding in products, redistribution — all unrestricted [merged profile].
• Raspberry Pi camera support. The -rpi Docker image variant adds native Pi camera module integration, no additional tooling needed [install docs].
• Authentication built in. JWT, HTTP-callback, and internal auth — not bolted on later [README].
• Prometheus metrics. Standard observability integration for teams running monitoring stacks [README].
• 18K+ GitHub stars, active maintenance. v1.17.0 shipped March 2026, CI/CD green, not an abandoned project [merged profile][website].

Cons

• No dashboard or UI. Zero. If you want to see connected clients, active paths, or stream health, you query the API or scrape Prometheus metrics [README]. There’s no “open browser and check status” option.
• No transcoding by default. Protocol routing only. Codec mismatches between publisher and viewer are your problem [README]. The FFmpeg image variant helps but requires knowing which FFmpeg flags to set.
• Docker networking quirks require manual workarounds. The UDP/RTSP issue and WebRTC IP configuration are not obvious and documented obliquely [install docs].
• Not for non-technical users. No setup wizard, no guided configuration, no support tier. If the YAML config doesn’t work, you’re reading GitHub issues [README].
• No built-in recording management UI. Recording to disk works, but finding, playing back, and managing recordings requires external tooling or the API [README].
• Third-party review coverage is thin. Unlike workflow automation or database tools, MediaMTX has minimal in-depth third-party reviews. Most coverage is brief list-article mentions [1]. This makes community troubleshooting knowledge harder to find.

---

Who should use this / who shouldn’t

Use MediaMTX if:

• You’re running IP cameras (RTSP) and want to view them in a browser via WebRTC or HLS without a subscription to a camera cloud platform.
• You’re broadcasting live events via OBS and want to relay to multiple streaming destinations simultaneously.
• You’re building an application that needs live video infrastructure and don’t want per-stream fees.
• You’re comfortable with Docker and config files, or have someone technical on your team.
• You need to record streams to disk with precise format control (fMP4 or MPEG-TS) [README].

Skip it if:

• You’re a non-technical founder who wants to click “start streaming” — use Streamyard, Dacast, or a managed platform.
• You need a DVR/NVR interface with motion detection, camera management UI, and clip browsing — look at Frigate, Scrypted, or Shinobi instead.
• You need CDN-scale delivery to thousands of viewers — MediaMTX handles the ingest and routing; you still need a CDN.
• Your use case is video-on-demand (stored files, not live) — Jellyfin or Plex is the right tool.

---

Alternatives worth considering

• Frigate NVR — If surveillance is your use case, Frigate adds the recording management UI, motion detection, and object detection (with Coral TPU support) that MediaMTX deliberately omits. Often deployed alongside MediaMTX rather than instead of it.
• Nginx-RTMP module — Older, widely documented, RTMP/HLS only. More complex build process. Fine if you only need RTMP ingest and HLS output and want Nginx handling everything.
• Restreamer (Datarhei) — Has a UI. Handles RTMP/RTSP ingest and multi-destination output. Less protocol breadth than MediaMTX but more accessible to non-technical users.
• Wowza Streaming Engine — Commercial, Java-based, expensive. Choose this if you need enterprise support SLAs and don’t want to manage open-source infrastructure.
• OvenMediaEngine — Open-source, focused on WebRTC delivery at scale. More opinionated about the WebRTC use case than MediaMTX, less broad on other protocols.
• SRS (Simple Realtime Server) — Mature, feature-rich, Go-based alternative. More complex to configure, stronger community in Asian self-hosting circles.

MediaMTX and Frigate are frequently deployed together: MediaMTX handles the raw RTSP routing and protocol conversion, Frigate handles recording, motion detection, and the DVR interface on top.

---

Bottom line

MediaMTX does one thing — routing live media between protocols — and does it with unusual operational cleanliness: single binary, zero dependencies, hot reload, MIT license. For the specific problem of bridging IP camera RTSP feeds to browser viewers, forwarding OBS streams to multiple destinations, or building self-hosted live streaming infrastructure without per-stream fees, it’s the most straightforward open-source option available. The trade-off is everything else: no UI, no transcoding by default, networking quirks in Docker, and limited room for users who aren’t comfortable reading YAML and digging through GitHub issues when something breaks. This is infrastructure software for people who build infrastructure. If that’s you, the 18K stars and active maintenance cadence suggest you’re not alone.

If you need help deploying MediaMTX (or the Frigate + MediaMTX stack) on your own server, that’s a one-time setup upready.dev handles for clients.

---

Sources

1. Hazem Abbas, MEDevel.com — “14 Free Open-source RTSP Media Servers in 2025 (Updated)” — includes MediaMTX as a recommended open-source RTSP media server for surveillance and live streaming. https://medevel.com/tag/nvr/

Primary sources:

• GitHub repository and README — bluenviron/mediamtx (18,219 stars, MIT license): https://github.com/bluenviron/mediamtx
• Official website: https://mediamtx.org
• Install documentation: https://mediamtx.org/docs/kickoff/install