MediaMTX 低延迟直播实战SRT 推流 WebRTC 播放把端到端延迟压到 300ms【免费下载链接】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 的 3~10 秒、RTMP 的 1~3 秒缓冲都太慢了。MediaMTX 是一个零依赖的单文件流媒体服务器把 Media-over-QUIC、SRT、WebRTC、RTSP、RTMP、LL-HLS 等协议放在同一个进程里互相转换——它不重编码只做解封装再封装所以协议转换本身几乎不增加延迟。下面按起服务 → 跑通推流 → 选播放端 → 压延迟 → 放大规模的实际工作流把一套端到端 300ms 内的低延迟直播链路搭出来。先起一个 MediaMTX 实例生产环境推荐 Docker。下面这条命令把所有常用端口都映射出来并把 WebRTC 客户端要回连的地址通过环境变量传入docker run --rm -it \ -e MTX_WEBRTCADDITIONALHOSTS1.2.3.4 \ -p 8554:8554 \ -p 1935:1935 \ -p 8888:8888 \ -p 8889:8889 \ -p 8890:8890/udp \ -p 8189:8189/udp \ bluenviron/mediamtx:1改动说明8890/udp是 SRT 推流口8189/udp是 WebRTC 媒体口UDP 口漏映射是最常见的连不通原因MTX_WEBRTCADDITIONALHOSTS填客户端能访问到的服务器地址公网 IP 或域名浏览器靠它完成 ICE 握手。Windows/macOS 用户也可以直接下载 release 页的独立二进制运行./mediamtx即可。安装细节见 docs/1-kickoff/2-install.md。各协议默认端口速查RTSP8554、RTMP1935、HLS8888、WebRTC8889、SRT8890/udp、WebRTC 媒体8189/udp。SRT 推流地址怎么填主播端用 OBS 或 FFmpeg 走 SRT 推流。MediaMTX 的 SRT 推流 URL 格式是srt://地址:8890?streamidpublish:路径名srt://1.2.3.4:8890?streamidpublish:game这里把game换成你的流名推上来后服务端就出现了/game这条路径。注意两点publish:前缀不能省它告诉服务端这是推流请求而不是拉流。SRT 基于 UDP 并自带重传ARQ弱网下比裸 UDP 稳延迟通常在百毫秒级若网络把 UDP 挡死可改用 RTSP over TCP 推流rtsp://1.2.3.4:8554/game兜底。推流端编码用什么服务端就转什么——MediaMTX 不转码所以主播端开 H.264/HEVC 就行带宽由编码决定。SRT 各客户端用法见 docs/3-publish/03-srt-clients.md。观众端播放地址WebRTC 与 LL-HLS同一路/game流观众可以任选协议拉取这是 MediaMTX 媒体路由器模型的直接收益WebRTC推荐延迟约 100~300ms浏览器直接访问http://1.2.3.4:8889/game。WHEP嵌入式播放器用http://1.2.3.4:8889/game/whep适合把 WebRTC 流嵌进自己的页面。LL-HLS兼容性最好http://1.2.3.4:8888/game/index.m3u8苹果设备播放 LL-HLS 需要给 HLS 开 HTTPShlsEncryption: true。如果 WebRTC 在 NAT、容器或防火墙后连不通按代价从小到大依次处理先确认webrtcAdditionalHosts里填了客户端可达的地址再考虑 UDP 被墙时改用 TCP 传输webrtcLocalTCPAddress: :8189最后上 STUN 打洞或 TURN 中继webrtcICEServers2: - url: stun:stun.l.google.com:19302完整排障阶梯见 docs/2-features/25-webrtc-specific-features.md。延迟相关配置项清单仓库根目录的 mediamtx.yml 里所有项都有注释与延迟直接相关的只有这几处HLS 默认就是低延迟变体无需额外开关hlsVariant: lowLatency # mpegts / fmp4 / lowLatency 三选一默认 lowLatency hlsPartDuration: 200ms # LL-HLS 的 part 时长播放器通常缓冲 3 个 part约 600ms hlsSegmentDuration: 1s路径级配置控制录制和分发。以game这条流为例paths: game: record: true recordFormat: fmp4 recordPath: ./recordings/game/%Y-%m-%d_%H-%M-%S recordDeleteAfter: 1d forward: - srt://edge-1.example.org:8890?streamidpublish:gamerecord: true开启落盘录制fMP4 格式按 part 分段、断电最多丢一个 partforward把流复制推给外部 SRT/RTSP/RTMP 等服务器常用于把一路流灌进自己的 CDN。配置热加载不用重启服务改完文件即时生效文档见 docs/2-features/05-configuration.md。观众多了怎么办读副本与监控不转码的服务端瓶颈几乎都在服务器到观众的出口带宽所以横向扩展的标准做法是加读副本read replica# 读副本上的配置 webrtcLocalUDPAddress: webrtcICEServers2: - url: stun:stun.l.google.com:19302 paths: ~^(.)$: source: rtsp://origin.example.org:8554/$G1 sourceOnDemand: yes副本用正则路径从源站按需拉流sourceOnDemand: yes表示没人看就不拉省出口带宽。前面挂负载均衡时注意区分RTSP/RTMP/SRT 走 4 层 LBHLS/WebRTC 必须 7 层 LB 并开启 sticky session因为一个会话由多个 HTTP 请求组成。更完整的副本与 CDN 方案见 docs/2-features/19-scalability.md。配套可观测性两项都默认关闭、按需打开metrics: true # Prometheus 指标默认监听 :9998 api: true # Control API默认监听 :9997可查询路径状态、强制断开客户端日常盯 CPU、带宽、连接数即可想逐帧排查还有dumpPackets把网络包写到磁盘这类调试开关。总结一句SRT 进、WebRTC 出、LL-HLS 兜底是 MediaMTX 下 300ms 内端到端延迟的最短路径配置上真正要动的参数只有hlsPartDuration、webrtcICEServers2和路径级的record/forward。【免费下载链接】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），仅供参考
MediaMTX 低延迟直播实战SRT 推流 WebRTC 播放把端到端延迟压到 300ms【免费下载链接】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 的 3~10 秒、RTMP 的 1~3 秒缓冲都太慢了。MediaMTX 是一个零依赖的单文件流媒体服务器把 Media-over-QUIC、SRT、WebRTC、RTSP、RTMP、LL-HLS 等协议放在同一个进程里互相转换——它不重编码只做解封装再封装所以协议转换本身几乎不增加延迟。下面按起服务 → 跑通推流 → 选播放端 → 压延迟 → 放大规模的实际工作流把一套端到端 300ms 内的低延迟直播链路搭出来。先起一个 MediaMTX 实例生产环境推荐 Docker。下面这条命令把所有常用端口都映射出来并把 WebRTC 客户端要回连的地址通过环境变量传入docker run --rm -it \ -e MTX_WEBRTCADDITIONALHOSTS1.2.3.4 \ -p 8554:8554 \ -p 1935:1935 \ -p 8888:8888 \ -p 8889:8889 \ -p 8890:8890/udp \ -p 8189:8189/udp \ bluenviron/mediamtx:1改动说明8890/udp是 SRT 推流口8189/udp是 WebRTC 媒体口UDP 口漏映射是最常见的连不通原因MTX_WEBRTCADDITIONALHOSTS填客户端能访问到的服务器地址公网 IP 或域名浏览器靠它完成 ICE 握手。Windows/macOS 用户也可以直接下载 release 页的独立二进制运行./mediamtx即可。安装细节见 docs/1-kickoff/2-install.md。各协议默认端口速查RTSP8554、RTMP1935、HLS8888、WebRTC8889、SRT8890/udp、WebRTC 媒体8189/udp。SRT 推流地址怎么填主播端用 OBS 或 FFmpeg 走 SRT 推流。MediaMTX 的 SRT 推流 URL 格式是srt://地址:8890?streamidpublish:路径名srt://1.2.3.4:8890?streamidpublish:game这里把game换成你的流名推上来后服务端就出现了/game这条路径。注意两点publish:前缀不能省它告诉服务端这是推流请求而不是拉流。SRT 基于 UDP 并自带重传ARQ弱网下比裸 UDP 稳延迟通常在百毫秒级若网络把 UDP 挡死可改用 RTSP over TCP 推流rtsp://1.2.3.4:8554/game兜底。推流端编码用什么服务端就转什么——MediaMTX 不转码所以主播端开 H.264/HEVC 就行带宽由编码决定。SRT 各客户端用法见 docs/3-publish/03-srt-clients.md。观众端播放地址WebRTC 与 LL-HLS同一路/game流观众可以任选协议拉取这是 MediaMTX 媒体路由器模型的直接收益WebRTC推荐延迟约 100~300ms浏览器直接访问http://1.2.3.4:8889/game。WHEP嵌入式播放器用http://1.2.3.4:8889/game/whep适合把 WebRTC 流嵌进自己的页面。LL-HLS兼容性最好http://1.2.3.4:8888/game/index.m3u8苹果设备播放 LL-HLS 需要给 HLS 开 HTTPShlsEncryption: true。如果 WebRTC 在 NAT、容器或防火墙后连不通按代价从小到大依次处理先确认webrtcAdditionalHosts里填了客户端可达的地址再考虑 UDP 被墙时改用 TCP 传输webrtcLocalTCPAddress: :8189最后上 STUN 打洞或 TURN 中继webrtcICEServers2: - url: stun:stun.l.google.com:19302完整排障阶梯见 docs/2-features/25-webrtc-specific-features.md。延迟相关配置项清单仓库根目录的 mediamtx.yml 里所有项都有注释与延迟直接相关的只有这几处HLS 默认就是低延迟变体无需额外开关hlsVariant: lowLatency # mpegts / fmp4 / lowLatency 三选一默认 lowLatency hlsPartDuration: 200ms # LL-HLS 的 part 时长播放器通常缓冲 3 个 part约 600ms hlsSegmentDuration: 1s路径级配置控制录制和分发。以game这条流为例paths: game: record: true recordFormat: fmp4 recordPath: ./recordings/game/%Y-%m-%d_%H-%M-%S recordDeleteAfter: 1d forward: - srt://edge-1.example.org:8890?streamidpublish:gamerecord: true开启落盘录制fMP4 格式按 part 分段、断电最多丢一个 partforward把流复制推给外部 SRT/RTSP/RTMP 等服务器常用于把一路流灌进自己的 CDN。配置热加载不用重启服务改完文件即时生效文档见 docs/2-features/05-configuration.md。观众多了怎么办读副本与监控不转码的服务端瓶颈几乎都在服务器到观众的出口带宽所以横向扩展的标准做法是加读副本read replica# 读副本上的配置 webrtcLocalUDPAddress: webrtcICEServers2: - url: stun:stun.l.google.com:19302 paths: ~^(.)$: source: rtsp://origin.example.org:8554/$G1 sourceOnDemand: yes副本用正则路径从源站按需拉流sourceOnDemand: yes表示没人看就不拉省出口带宽。前面挂负载均衡时注意区分RTSP/RTMP/SRT 走 4 层 LBHLS/WebRTC 必须 7 层 LB 并开启 sticky session因为一个会话由多个 HTTP 请求组成。更完整的副本与 CDN 方案见 docs/2-features/19-scalability.md。配套可观测性两项都默认关闭、按需打开metrics: true # Prometheus 指标默认监听 :9998 api: true # Control API默认监听 :9997可查询路径状态、强制断开客户端日常盯 CPU、带宽、连接数即可想逐帧排查还有dumpPackets把网络包写到磁盘这类调试开关。总结一句SRT 进、WebRTC 出、LL-HLS 兜底是 MediaMTX 下 300ms 内端到端延迟的最短路径配置上真正要动的参数只有hlsPartDuration、webrtcICEServers2和路径级的record/forward。【免费下载链接】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），仅供参考
