MediaMTX 搭建指南：10 分钟跑通零依赖流媒体服务器-育师

MediaMTX 搭建指南：10 分钟跑通零依赖流媒体服务器

【免费下载链接】mediamtxReady-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.项目地址: https://gitcode.com/GitHub_Trending/me/mediamtx

凌晨两点，刚装好的摄像头要立刻出现在网页预览里，还要同时给 NVR 留一路录像。你不想再拼一套转码加多协议网关的部署。MediaMTX 是一个零依赖的流媒体服务器和媒体代理：它把 RTSP、RTMP、WebRTC、HLS、SRT 等协议的读、写、转发、录制、回放收进同一个进程。下面带你把它跑起来。

跑起来：编译、启动、确认监听

MediaMTX 用 Go 编写、不开 CGO，所以拿到的是一个单文件二进制。我们走源码编译这条最稳的路径。

克隆仓库并编译出可执行文件：

git clone https://gitcode.com/GitHub_Trending/me/mediamtx cd mediamtx CGO_ENABLED=0 go build -o mediamtx

仓库里已经带了一份带完整注释的mediamtx.yml，保持原样即可启动：

./mediamtx

预期输出里会出现各协议的监听日志（节选）：

[RTSP] listener opened on :8554 (TCP/RTSP), :8000 (UDP/RTP), :8001 (UDP/RTCP) [RTMP] listener opened on :1935 [HLS] listener opened on :8888 [WebRTC] listener opened on :8889 (TCP/HTTP), :8189 (UDP/ICE) [SRT] listener opened on :8890 (UDP)

看到这几行listener opened，说明服务器已经就绪。

8554、1935、8888、8889、8890 端口空闲
./mediamtx进程持续运行
日志出现listener opened
curl 127.0.0.1:9997/v3/config/global返回 JSON

MediaMTX 架构图，展示一个进程内的多协议监听与转发关系

它能做什么

一张表说清这台流媒体服务器的能力边界：

能力	说明
多协议接入	RTSP、RTMP、WebRTC、HLS、SRT、MPEG-TS、RTP、MOQ
协议转换	一路输入多路输出，原生完成，不依赖 FFmpeg
录制	FMP4 或 MPEG-TS 分段写入，按小时归档
按需拉流	有观看者才去拉源，无人观看自动断开
回放与转发	已录内容通过 HTTP 回放，可推送到下游媒体代理

最容易被误解的一点：所谓"协议转换"不是转码。MediaMTX 做的是原生封装转换，输入 H.264 输出还是 H.264，只换容器和传输方式。它不改变分辨率、码率或编码。需要重编码时，要在上游完成。

一份能直接用的配置

把下面这份mediamtx.yml放到二进制旁边，替换仓库自带的那份。它覆盖了三路摄像头，每路都是"按需拉流 + 录制"的组合，这是实际使用中最常见的搭配。

logLevel: info logDestinations: [stdout] paths: all_others: source: publisher gate_camera: source: rtsp://192.168.1.101:554/stream1 sourceOnDemand: true sourceOnDemandStartTimeout: 10s sourceOnDemandCloseAfter: 30s record: true recordFormat: fmp4 recordPath: ./recordings/gate/%Y-%m-%d_%H-%M-%S recordSegmentDuration: 1h recordDeleteAfter: 72h shop_camera: source: rtsp://192.168.1.102:554/ch1 sourceOnDemand: true sourceOnDemandCloseAfter: 30s record: true recordPath: ./recordings/shop/%Y-%m-%d_%H-%M-%S warehouse_camera: source: rtsp://192.168.1.103:554/main sourceOnDemand: true sourceOnDemandCloseAfter: 30s

source 指向一路 RTSP 摄像头

source写摄像头的 RTSP 地址，MediaMTX 会主动去拉这一路流。all_others是兜底规则：没有单独写路径名的流走这里，source: publisher表示该路径只接受外部推流。

按需拉流让摄像头按需上线

sourceOnDemand: true表示有观看者时才去连摄像头，sourceOnDemandCloseAfter规定最后一个观看者离开后多久断开。摄像头不是一直被占用，夜间没人看的时段它也休眠。

录制按小时切片、自动清理

recordFormat: fmp4生成可被多数播放器直接打开的分片文件，recordSegmentDuration: 1h按小时切段，recordPath里的%Y-%m-%d等占位符用于归档到日期目录，recordDeleteAfter: 72h让旧录像自动删除。

搭一个完整的东西

把上面配置里的三路路径当成一个小型安防中枢：三路 RTSP 摄像头接入，任何一路随时可以通过 WebRTC 在浏览器里打开，同时自动落盘。把配置替换进mediamtx.yml，重启./mediamtx。

配置完成后，各协议的访问地址如下（把10.0.0.5换成你的服务器 IP）：

流	RTSP	WebRTC（浏览器）	录像位置
gate_camera	`rtsp://10.0.0.5:8554/gate_camera`	`http://10.0.0.5:8889/gate_camera`	`./recordings/gate/`
shop_camera	`rtsp://10.0.0.5:8554/shop_camera`	`http://10.0.0.5:8889/shop_camera`	`./recordings/shop/`
warehouse_camera	`rtsp://10.0.0.5:8554/warehouse_camera`	`http://10.0.0.5:8889/warehouse_camera`	未开启

管理面走 9997 端口的 API，GET /v3/paths能列出当前所有路径状态。HLS 观看地址在 8888 端口，格式为http://10.0.0.5:8888/gate_camera/index.m3u8。

验证顺序建议：先curl 127.0.0.1:9997/v3/paths确认路径已注册；再用 VLC 或任意 RTSP 客户端拉一路确认能出画面；最后在浏览器打开 WebRTC 地址确认低延迟预览。

踩坑与调优

UDP 丢包导致花屏

症状：室外 Wi-Fi 或跨网段拉流时画面周期性花屏。

udpReadBufferSize: 4194304

MediaMTX 的 UDP 读缓冲区默认交给操作系统，往往只有 64KB 上下，突发流量直接丢弃。把它调大给内核留出缓冲余量。

WebRTC 在浏览器里连不上

症状：浏览器控制台显示 ICE 失败，VLC 拉同一路 RTSP 却正常。

webrtcICEServers2: - url: stun:stun.l.google.com:19302

跨网络时 UDP 打洞需要 STUN 协助。防火墙挡 UDP 8189 时，WebRTC 会退化到 TCP，延迟上去，先检查防火墙规则。

HLS 预览延迟高

症状：浏览器 HLS 预览比 WebRTC 慢好几秒。

hlsVariant: lowLatency hlsSegmentDuration: 1s hlsPartDuration: 200ms

这是仓库配置的默认值，确认没被改回m3u8普通变体即可。LL-HLS 把 1 秒段切成 200ms 的分片，客户端边下边播。

内存占用持续偏高

症状：观看者多时进程内存上涨。

writeQueueSize: 256

writeQueueSize是每个连接的待发包队列，默认 512，调小直接省内存，代价是弱网下更容易丢帧。先用默认值跑，确认基线后再动它。

先拿一路摄像头把上面这条链路验证完：RTSP 能拉、网页能播、录像在目录里增长。确认没问题再扩路数。所有参数名和默认值，仓库里那份mediamtx.yml的注释就是最权威的手册，直接对照改。

创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考

MediaMTX 搭建指南：10 分钟跑通零依赖流媒体服务器