尧图网页设计 
用 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 是 3 到 10 秒走 RTMP 也要 1 到 3 秒。对娱乐直播来说尚可忍受但对游戏直播观众看到技能释放时操作已经完成体验直接崩掉。延迟问题的根源不在网络带宽而在协议本身的分段缓冲机制——而破局的办法是用支持WebRTC的流媒体服务器把播放端延迟压到亚秒级。MediaMTX是一个开箱即用的零依赖实时流媒体服务器同时内置 WebRTC、SRT、RTSP、RTMP、LL-HLS 等协议栈可以把一路推流转成任意协议播放并支持录制与回放。一条流如何同时喂饱四种播放器MediaMTX 的核心心智模型很朴素所有流都挂在一个叫path路径的对象上path 由一个path manager统一管理。一个 path 只有一个推流者publisher可以是 RTSP/RTMP/WebRTC/SRT 客户端也可以是被配置拉流的外部源任意多个观众可以用任意受支持的协议读同一条流服务器内部只做remux协议转换、不重编码所以 CPU 开销极低单进程即可撑起多路并发也就是说推流者用 SRT 进来浏览器观众用 WebRTC 看移动端用 LL-HLS 看VLC 用 RTSP 看——它们读的是同一条流。数据流向就是推流客户端 → path → 各协议 server → 观众完整说明见架构文档。关键技术决策为什么用 SRT 推流SRTSecure Reliable Transport是基于 UDP 的可靠传输协议用应用层重传对抗丢包典型端到端延迟在 100ms 量级远低于 TCP 系的 RTSP/RTMP。对游戏场景更重要的是它天然适配 OBS 这类推流端。MediaMTX 的 SRT server 默认开启监听 UDP:8890streamid 同时支持mpublish,rlive这种标准语法部分硬件只认它细节见SRT 特性文档srt: true srtAddress: :8890为什么用 WebRTC 播放WebRTC 在浏览器里无需插件媒体走 SRTP 直连观众端延迟通常在几十毫秒到 100ms 出头。MediaMTX 的 WebRTC 握手走 HTTP:8889媒体走独立的 UDP/ICE 监听默认:8189四层连通方案按优先级排列静态 UDP 端口 → 静态 TCP 端口 → STUN 打洞 → TURN 中继。局域网或端口放通的内网机器默认配置就够了公网部署时把公网 IP 写进webrtcAdditionalHosts即可webrtc: true webrtcAddress: :8889 webrtcLocalUDPAddress: :8189 webrtcAdditionalHosts: [1.2.3.4]为什么留一个 LL-HLS 兜底部分移动端场景尤其是 iOS 系统播放器只能走 HLS。MediaMTX 的 HLS 默认就是lowLatency变体hlsPartDuration: 200ms把 LL-HLS 的 part 粒度压到 200 毫秒配合 CDN 分发时延迟能到 2 秒左右——不是最优但足够覆盖 WebRTC 触达不了的终端。从安装到出画面的最小配置MediaMTX 是单个可执行文件Docker 启动最快。注意 WebRTC 的 UDP 端口8189和 SRT 的8890都要用/udp映射漏掉 8189 是新手最常见的失败点docker run --rm -it \ -p 8554:8554 -p 8888:8888 -p 8889:8889 \ -p 8189:8189/udp -p 8890:8890/udp \ bluenviron/mediamtx:1启动后日志会逐行列出各 server 的监听状态。默认配置仓库根目录的mediamtx.yml共 800 余行注释里authMethod: internal且user: any放行匿名读写局域网实验直接可用上生产前至少要改成按 path 限制权限完整参数以配置文件参考为准。推流端用 FFmpeg 生成测试源走 SRT 标准 streamid 语法推入live路径ffmpeg -re -f lavfi -i testsrcduration30 -f lavfi -i sineduration30 \ -c:v libx264 -preset ultrafast -c:a aac \ -f srt srt://127.0.0.1:8890?streamid#!::mpublish,rlive验证闭环只需要两条命令。第一条确认流真的进了服务器跨协议读取成功ffprobe -v error -show_entries streamcodec_name rtsp://127.0.0.1:8554/live # 预期输出h264 与 aac 两行 codec_name第二条确认 LL-HLS 播放列表已生成curl -s http://127.0.0.1:8888/live/index.m3u8 | head # 预期输出#EXTM3U 开头的播放列表浏览器打开http://服务器IP:8889MediaMTX 自带 WebRTC 查看页填入流地址即可出画面——从推流到出画面这条链路通常不到 1 秒。两个文档不会重点提醒的坑⚠️ 第一个坑在编码器上浏览器用 WebRTC 播 H265 基本全军覆没仅 Windows 版 Chrome 在特定 GPU 下支持而含B 帧的 H264 同样不被 WebRTC 规范接纳——服务端转不动浏览器的编码限制唯一解法是推流端改用 H264 baseline profile Opus 重新编码WebRTC 特性文档 里给了现成的 FFmpeg 转码参数。如果你的推流设备固定输出 B 帧 H264观众端大概率是黑屏而非报错这点非常隐蔽。第二个坑在网络层Docker 部署时如果只映射了8889忘了8189/udp握手 HTTP 200、页面正常加载、但画面永远转圈——因为 ICE 媒体通道根本建立不起来。排查顺序建议照文档的四层方案走先确认 UDP 8189 放通再开webrtcLocalTCPAddress: :8189走 TCP 兜底代价是拥塞时延迟递增最后才上 STUN/TURN。另外录制是默认关闭的record: false开启后recordPath默认按%path与时间戳落盘 fMP4 分段单段 1 小时适合比赛回放详见录制文档。延伸方向大规模并发时把主服务器的 path 通过forward推到边缘 MediaMTX 节点或反向用source拉流做读副本见转发文档用:9998的 Prometheus metrics 端点接 Grafana盯每路的 reader 数与 CPU 占用探索 MoQMedia over QUIC协议栈它基于 HTTP3/WebTransport是比 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创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 用 MediaMTX 搭建低延迟直播：从 SRT 推流到 WebRTC 播放的完整指南
用 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 是 3 到 10 秒走 RTMP 也要 1 到 3 秒。对娱乐直播来说尚可忍受但对游戏直播观众看到技能释放时操作已经完成体验直接崩掉。延迟问题的根源不在网络带宽而在协议本身的分段缓冲机制——而破局的办法是用支持WebRTC的流媒体服务器把播放端延迟压到亚秒级。MediaMTX是一个开箱即用的零依赖实时流媒体服务器同时内置 WebRTC、SRT、RTSP、RTMP、LL-HLS 等协议栈可以把一路推流转成任意协议播放并支持录制与回放。一条流如何同时喂饱四种播放器MediaMTX 的核心心智模型很朴素所有流都挂在一个叫path路径的对象上path 由一个path manager统一管理。一个 path 只有一个推流者publisher可以是 RTSP/RTMP/WebRTC/SRT 客户端也可以是被配置拉流的外部源任意多个观众可以用任意受支持的协议读同一条流服务器内部只做remux协议转换、不重编码所以 CPU 开销极低单进程即可撑起多路并发也就是说推流者用 SRT 进来浏览器观众用 WebRTC 看移动端用 LL-HLS 看VLC 用 RTSP 看——它们读的是同一条流。数据流向就是推流客户端 → path → 各协议 server → 观众完整说明见架构文档。关键技术决策为什么用 SRT 推流SRTSecure Reliable Transport是基于 UDP 的可靠传输协议用应用层重传对抗丢包典型端到端延迟在 100ms 量级远低于 TCP 系的 RTSP/RTMP。对游戏场景更重要的是它天然适配 OBS 这类推流端。MediaMTX 的 SRT server 默认开启监听 UDP:8890streamid 同时支持mpublish,rlive这种标准语法部分硬件只认它细节见SRT 特性文档srt: true srtAddress: :8890为什么用 WebRTC 播放WebRTC 在浏览器里无需插件媒体走 SRTP 直连观众端延迟通常在几十毫秒到 100ms 出头。MediaMTX 的 WebRTC 握手走 HTTP:8889媒体走独立的 UDP/ICE 监听默认:8189四层连通方案按优先级排列静态 UDP 端口 → 静态 TCP 端口 → STUN 打洞 → TURN 中继。局域网或端口放通的内网机器默认配置就够了公网部署时把公网 IP 写进webrtcAdditionalHosts即可webrtc: true webrtcAddress: :8889 webrtcLocalUDPAddress: :8189 webrtcAdditionalHosts: [1.2.3.4]为什么留一个 LL-HLS 兜底部分移动端场景尤其是 iOS 系统播放器只能走 HLS。MediaMTX 的 HLS 默认就是lowLatency变体hlsPartDuration: 200ms把 LL-HLS 的 part 粒度压到 200 毫秒配合 CDN 分发时延迟能到 2 秒左右——不是最优但足够覆盖 WebRTC 触达不了的终端。从安装到出画面的最小配置MediaMTX 是单个可执行文件Docker 启动最快。注意 WebRTC 的 UDP 端口8189和 SRT 的8890都要用/udp映射漏掉 8189 是新手最常见的失败点docker run --rm -it \ -p 8554:8554 -p 8888:8888 -p 8889:8889 \ -p 8189:8189/udp -p 8890:8890/udp \ bluenviron/mediamtx:1启动后日志会逐行列出各 server 的监听状态。默认配置仓库根目录的mediamtx.yml共 800 余行注释里authMethod: internal且user: any放行匿名读写局域网实验直接可用上生产前至少要改成按 path 限制权限完整参数以配置文件参考为准。推流端用 FFmpeg 生成测试源走 SRT 标准 streamid 语法推入live路径ffmpeg -re -f lavfi -i testsrcduration30 -f lavfi -i sineduration30 \ -c:v libx264 -preset ultrafast -c:a aac \ -f srt srt://127.0.0.1:8890?streamid#!::mpublish,rlive验证闭环只需要两条命令。第一条确认流真的进了服务器跨协议读取成功ffprobe -v error -show_entries streamcodec_name rtsp://127.0.0.1:8554/live # 预期输出h264 与 aac 两行 codec_name第二条确认 LL-HLS 播放列表已生成curl -s http://127.0.0.1:8888/live/index.m3u8 | head # 预期输出#EXTM3U 开头的播放列表浏览器打开http://服务器IP:8889MediaMTX 自带 WebRTC 查看页填入流地址即可出画面——从推流到出画面这条链路通常不到 1 秒。两个文档不会重点提醒的坑⚠️ 第一个坑在编码器上浏览器用 WebRTC 播 H265 基本全军覆没仅 Windows 版 Chrome 在特定 GPU 下支持而含B 帧的 H264 同样不被 WebRTC 规范接纳——服务端转不动浏览器的编码限制唯一解法是推流端改用 H264 baseline profile Opus 重新编码WebRTC 特性文档 里给了现成的 FFmpeg 转码参数。如果你的推流设备固定输出 B 帧 H264观众端大概率是黑屏而非报错这点非常隐蔽。第二个坑在网络层Docker 部署时如果只映射了8889忘了8189/udp握手 HTTP 200、页面正常加载、但画面永远转圈——因为 ICE 媒体通道根本建立不起来。排查顺序建议照文档的四层方案走先确认 UDP 8189 放通再开webrtcLocalTCPAddress: :8189走 TCP 兜底代价是拥塞时延迟递增最后才上 STUN/TURN。另外录制是默认关闭的record: false开启后recordPath默认按%path与时间戳落盘 fMP4 分段单段 1 小时适合比赛回放详见录制文档。延伸方向大规模并发时把主服务器的 path 通过forward推到边缘 MediaMTX 节点或反向用source拉流做读副本见转发文档用:9998的 Prometheus metrics 端点接 Grafana盯每路的 reader 数与 CPU 占用探索 MoQMedia over QUIC协议栈它基于 HTTP3/WebTransport是比 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创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考