一条命令跑通多协议直播MediaMTX 流媒体服务器快速上手指南【免费下载链接】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/mediamtxMediaMTX 是一款零依赖的流媒体服务器与媒体代理一个服务同时接住 RTSP、RTMP、SRT、WebRTC、HLS 的流也支持较新的 Media-over-QUIC 协议并能在它们之间自动完成流媒体协议转换。它是单文件可执行程序不需要任何运行环境定位很明确拿来即用推流、看流、录流都靠一份 YAML 配置。围绕直播的配套能力也齐了分段录制与回放、按需拉流、鉴权、向外部服务器转发、配置热重载全部内置。下面从一个真实场景说起。 什么时候会需要它监控室里有一批 IP 摄像头只会说 RTSP运营大屏在浏览器里需要 WebRTC 或低延迟的 LL-HLSCDN 那边又要求 RTMP 推流接入。没有中间层的话就得给每一路流挂一个 FFmpeg 进程做协议缝合流一多进程就失控。另一个常见场景同一路摄像头画面既要进内部低延迟直播大屏又要录 30 天备查回放。MediaMTX 就是那个中间层所有流挂在一个个路径path下不同协议的客户端连同一路径拿到的就是同一路流。 MediaMTX 核心能力速览每条路径对应一路流。来源可以是客户端推上来RTSP、RTMP、SRT 推流、WebRTC、MoQ也可以是服务器主动拉取的 URLRTSP 摄像头、HLS、SRT、RTP、MPEG-TS甚至树莓派摄像头。读者侧则对 RTSP、RTMP、HLS含低延迟 LL-HLS、WebRTC、SRT、MoQ 六种协议全开协议之间不做转码只做封装转换。外围能力同样实用一行配置开启 fMP4/MPEG-TS 分段录制并自动清理旧文件内置回放服务把录像当直播一样播forward原生转发到别的服务器热重载配置不踢掉在线客户端连接、读取、录制分段完成等事件都能挂外部命令。内部结构见 架构文档。 MediaMTX 快速部署最省心的方式是 Docker一条命令即可启动docker run --rm -it --networkhost bluenviron/mediamtx:1要自定义流路径就挂一份自己的 mediamtx.yml核心配置只有几行api: true # 打开控制接口便于验证 paths: cam1: # 摄像头流有人看才拉 source: rtsp://admin:pass192.168.1.100:554/stream1 sourceOnDemand: true all_others: # 其余路径默认等客户端推流 source: publisher启动后跑一条命令验证服务是否正常curl http://127.0.0.1:9997/v3/paths/list能返回 JSON初期为空列表也正常就说明服务已就绪。其他方式见 安装文档。 典型应用实战摄像头录制与 30 天回放安防场景的要点就三个参数开启录制、定分段时长、定保留期细节在 录制功能文档。pathDefaults: record: true # 开启录制 recordSegmentDuration: 1h # 每小时一个文件好检索 recordDeleteAfter: 30d # 30 天后自动清理 playback: true # 开启 9996 端口的回放服务之后录像可直接在浏览器里在线回放也可以用runOnRecordSegmentComplete钩子在分段完成时同步到对象存储。一路流多协议输出RTSP 转 WebRTC摄像头以 RTSP 进入某条路径后大屏用 WebRTC8889 端口自带网页播放器读同一路径移动端走低延迟 LL-HLS不需要写任何转发代码。若还要给 CDN 一份加一条forward即可paths: cam1: forward: - dest: rtmp://cdn.example.com/app/streamkey # 转发到 RTMP CDN按需推流有人看才开播流源成本高时比如解码点播文件、摄像头只支持单连接用runOnDemand让服务器在第一个观众到来时自动执行外部命令推流观众全部离开后自动终止paths: vod_demo: runOnDemand: ffmpeg -re -stream_loop -1 -i demo.mp4 -c copy -f rtsp rtsp://127.0.0.1:8554/vod_demo 调优与监控要点调优基本围绕带宽与丢包如果日志里 UDP 类协议SRT、WebRTC、RTSP-UDP丢包多那么调大udpReadBufferSize注意系统参数net.core.rmem_max要先放宽到同量级如果日志出现 reader is too slow说明读端慢、发送队列积压那么调大writeQueueSize代价是内存如果摄像头链路抖动、宁可慢不可丢那么设置rtspTransport: tcp改用 TCP 传输如果担心单路流被大量并发拉爆那么在该路径上设置maxReaders如果摄像头源很多但并非都要实时拉那么把sourceOnDemand: true放到pathDefaults全局生效。监控只需两个入口启用控制 API9997 端口通过/v3/paths/list查各路径状态启用 metrics9998 端口让 Prometheus 抓取连接数与流量计数。更多参数解释见 降低丢包文档 和 控制 API 文档。⚠️ 容易踩的坑浏览器里 WebRTC 连不上ICE 握手需要能到达服务器的地址内网或 NAT 后收不到候选。配置webrtcICEServers2加 STUN/TURN或用webrtcAdditionalHosts显式指定下发给客户端的地址。Docker 里 UDP 端口半瘫容器走 NAT 后 UDP 包源 IP 被替换RTSP 的 UDP 传输会紊乱。设置环境变量MTX_RTSPTRANSPORTStcp或干脆用--networkhost。录像结尾几秒总是缺失录制按小分段写盘进程异常退出时未刷盘的尾部会丢损失上限就是recordPartDuration。调小它可减少丢失代价是写盘更频繁。iOS 上 LL-HLS 播不了低延迟 HLS 在苹果设备要求 HTTPS。开启hlsEncryption并配好证书即可。⚖️ 选型参考SRS、Nginx-RTMP、ZLMediaKit 也都是常见的开源流媒体服务器在 RTMP 生态和集群化方面各有积累。MediaMTX 的定位是单二进制、零依赖、协议覆盖面全SRT、MoQ 这类较新协议原生集成且把录制、回放、控制 API 直接内置开箱成本更低。高并发分发时可用读副本横向扩展主实例负责发布与拉流多个副本实例只承接读取请求。回到开头监控室的场景一台 MediaMTX摄像头的 RTSP 直接进浏览器、CDN 拿到 RTMP、录像随时可回放中间的 FFmpeg 进程链一行都不用写。如果你正在找一台能搞定 RTSP 转 WebRTC、SRT 推流和低延迟直播的流媒体服务器不妨先用单二进制的 MediaMTX 把链路跑通再谈扩展。【免费下载链接】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创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考