低延迟游戏直播完整指南MediaMTX 用 SRT 推流 WebRTC 播放打通全链路【免费下载链接】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游戏直播对延迟极其敏感传统 HLS、RTMP 链路里画面往往落后主播操作好几秒甚至十几秒。这篇指南以 MediaMTX 为中心讲清如何搭一套低延迟游戏直播服务主播端用 SRT 推流观众端用 WebRTC 或 LL-HLS 播放MediaMTX 在中间不做转码、只做协议转换把端到端延迟压到数百毫秒以内。无需流媒体背景照着步骤走即可得到一条能推、能播、能扩展的直播链路。延迟到底卡在哪一步一条直播链路的延迟由四段叠加而成优化前先定位问题段协议分片等待HLS 需要攒够一个分片才能下发分片越长延迟越高RTMP 客户端普遍带 1-3 秒播放缓冲。转码环节如果中间设备做重编码还要叠加编码器和 GOP 等待。MediaMTX 明确定位为媒体路由器只做协议间的解复用/复用remuxing不重编码这一段的转码延迟为零。网络传输UDP 协议族SRT、WebRTC可丢弃迟到的包而不拖慢后续帧整体延迟更低代价是弱网下可能有丢包。客户端缓冲播放器为了防卡顿自带的缓冲通常在百毫秒级无法完全消除。结论把分片等待和转码两段砍掉剩下的传输延迟就集中在几百毫秒量级这正是 SRT WebRTC 组合的思路。该选哪条传输路线四种路线的取舍对比如下按主播端推流 → 观众端播放分别选择路线延迟量级适合场景边界与注意SRT 推流低UDP 可靠传输主播 PC / 游戏机推流弱网、跨网段需开放 UDP 端口可用srtPublishPassphrase/srtReadPassphrase做加密和推流鉴权WebRTC 播放约百毫秒级浏览器端最低网页直播、互动场景需解决 NAT 穿越STUN/TURN浏览器不支持 H264 B-帧编码端建议 baseline profileLL-HLS 播放数百毫秒级分片/Part 粒度移动端、需经 CDN/防火墙 HTTP 分发延迟受hlsPartDuration制约低于约 1 秒体验骤降RTSP/RTMP中等受客户端缓冲影响对接存量摄像头、旧设备不是低延迟首选但 MediaMTX 可将其转换为 WebRTC/LL-HLS 输出实际部署中最常见的组合是SRT 收流 → MediaMTX 协议转换 → WebRTC 给浏览器、LL-HLS 给移动端一条源流同时服务多端且互不影响。最快把服务跑起来安装与启动MediaMTX 是零依赖的单可执行文件Docker 方式最快。以下是最小端口集SRT 推流 WebRTC 播放所需docker run --rm -it \ -p 8890:8890/udp \ # SRT 推流/拉流端口 -p 8889:8889 \ # WebRTC 信令HTTP 握手端口 -p 8189:8189/udp \ # WebRTC 媒体传输 UDP 端口 -e MTX_WEBRTCADDITIONALHOSTS192.168.x.x \ # 换成观众访问你的服务器 IP bluenviron/mediamtx:1端口与镜像变体的完整说明见 安装文档。低延迟关键参数配置编辑mediamtx.yml配置热加载修改后无需重启详见 配置文件参考# 低延迟参数每项对延迟的影响见行尾注释 srt: true # 启用 SRT 服务主播端走 UDP 推流避开 TCP 队头阻塞 webrtc: true # 启用 WebRTC 播放浏览器端延迟最低 hlsVariant: lowLatency # HLS 切到 Low-Latency 模式延迟从秒级压到数百毫秒 hlsPartDuration: 200ms # LL-HLS 最小 Part 时长越短延迟越低请求越频繁 webrtcICEServers2: # 观众与服务器无法直连 UDP 时用 STUN 辅助 NAT 穿越 - url: stun:stun.l.google.com:19302两个容易忽略的点webrtcLocalTCPAddress默认关闭是有原因的——TCP 传输在网络拥塞时会产生渐进式延迟除非观众侧无法走 UDP否则不要开启。弱网下 SRT/WebRTC 出现丢包时可调大udpReadBufferSize需同步调大系统net.core.rmem_max原理见 降低丢包专题。推流与播放配置生效后链路两端用 URL 即可对接不需要额外客户端改造主播端OBS、FFmpeg 等支持 SRT 的软件srt://服务器IP:8890?streamidmypathstream ID 的完整语法含认证信息写法见 SRT 专属特性OBS/FFmpeg 推流步骤见 SRT 推流文档。浏览器观众直接访问http://服务器IP:8889/mypath页面即 WebRTC 播放页移动端 / 经 CDN 分发http://服务器IP:8888/mypath/index.m3u8说明见 HLS 播放文档。并发上去了怎么扛单实例扛不住观众规模时按成本从低到高有三层手段转发到边缘节点在路径上配置forward把一路流同时推给多台下游 MediaMTX 实例就近分发原生支持 SRT、WebRTC、RTSP、RTMP、MoQ写法见 Forward 文档。读副本Read Replicas多台实例作为副本从源实例拉流、各自服务观众前端用负载均衡器按协议分发这是官方推荐的水平扩展主方案见 Scalability 文档。指标监控开启metrics: true默认监听:9998暴露 Prometheus 格式指标接入 Grafana 观察带宽与连接数判断扩容时机见 Metrics 文档。注意 MediaMTX 不重编码所以瓶颈几乎总是服务器到观众的带宽而非 CPU扩容前先用指标确认瓶颈位置。怎么验证链路还能顺手开哪些能力验证很简单主播推流后日志里出现该路径的 publisher 记录、浏览器播放页能出画面即链路打通。在此之上按需开启录制与回放路径级record: yes可将流按 fMP4 分段落盘并支持按时间回看适合赛后复盘见 Record 文档 与 Playback 文档。按需推流runOnDemand钩子可在首个观众进入时才启动推流进程无人观看时自动关闭见 Hooks 文档。性能排查内置 pprof 与 性能监控 用于定位 CPU/内存异常。WebRTC 连通性问题对称 NAT 等复杂网络的完整排查方法见 WebRTC 专属特性。小结低延迟游戏直播的关键不在堆砌协议而在于砍掉分片等待 转码这两段延迟MediaMTX 以 SRT 收流、WebRTC/LL-HLS 输出一次部署同时服务浏览器与移动端再配合转发与读副本向更大规模扩展。想继续深入可以看看 控制 API 用 HTTP 接口动态管理路径或 Always Available 让路径在主播掉线时播放离线片保持直播间不黑屏。你在部署中遇到哪一步的延迟卡住了欢迎带着你的mediamtx.yml片段来讨论。【免费下载链接】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），仅供参考