MediaMTX零依赖多协议流媒体服务器5 分钟跑通 RTSP 推流到 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/mediamtxMediaMTX 是一个用 Go 编写的零依赖实时媒体服务器与媒体代理发布、读取、录制、回放音视频流一个进程全部完成。它编译后是一个独立可执行文件不依赖 FFmpeg 或任何运行时。对开发者最直接的好处是用一份配置替代一整套协议转换组件RTSP、RTMP、WebRTC、SRT、LL-HLS 在同一个实例上同时工作5 分钟即可搭建。它解决了什么问题典型需求MediaMTX 的解法RTSP 摄像头需要在浏览器里看摄像头用 RTSP 推流浏览器用 WebRTC 读取协议转换由服务器自动完成无需转码OBS 推 RTMP移动端要低延迟观看一条路径接收推流后WebRTC、SRT、HLS 读者可同时拉取各取所需流要落盘保存还要支持回放一个参数开启录制fMP4 或 MPEG-TS 分段写盘回放服务器直接提供回放同一台机器管理几十路流每路流对应一条 path互不干扰可单独配置认证、录制、转发 首次运行前置条件已安装 Docker二进制与其他方式见安装文档。第 1 步启动服务器映射常用端口docker run --rm -it \ -p 8554:8554 -p 1935:1935 -p 8888:8888 \ -p 8889:8889 -p 8189:8189/udp \ -e MTX_RTSPTRANSPORTStcp \ bluenviron/mediamtx:1验证终端持续输出各服务器启动日志且ss -tln | grep 8554能看到端口在监听。第 2 步用 FFmpeg 模拟一个推流端ffmpeg -re -stream_loop -1 -i test.mp4 -c copy -f rtsp rtsp://localhost:8554/mystream验证MediaMTX 日志出现针对mystream的 RTSP 发布会话记录。第 3 步读取这条流ffmpeg -i rtsp://localhost:8554/mystream -c copy -t 5 out.mp4验证out.mp4生成且可正常播放日志中多出一条读取会话。到这一步推流 → 中转 → 拉流的完整链路已经跑通。️ 能力地图速览维度支持内容发布协议MoQ、SRT、WebRTC、RTSP、RTMP、HLS、MPEG-TSUDP/Unix 套接字、RTP、树莓派摄像头读取协议MoQ、SRT、WebRTC、RTSP、RTMP、低延迟 HLSLL-HLS协议转换自动完成。一端发布另一端可用不同协议读取不做转码录制与回放fMP4/MPEG-TS 分段录制按 part 写入降低故障丢失回放服务器提供下载与回放运维配置热重载不踢断客户端Control API9997、Prometheus 指标9998、pprof9999安全内置用户、外部 HTTP、JWT 三种认证支持按路径与 IP 段授权部署单可执行文件或 Docker 镜像覆盖 Linux、Windows、macOS无外部依赖所谓全协议在 MediaMTX 里不是多个服务拼在一起而是同一条流挂上多个入口一份mediamtx.yml同时决定谁能发布、谁能读取、录不录制。⚙️ 内部机制MediaMTX 把每路流称为一条path。服务器启动时路径管理器读取paths配置为每条路径建立对象并做认证。发布端无论使用哪种协议进入服务器后都由协议层把包解复用为轨道视频轨、音频轨交给路径持有。读者连接时再按该读者需要的协议重新封装发出。录制、转发、代理这些功能本质上都是路径的消费者所以扩展一条路径的成本很低。三个核心组件路径管理器internal/core/path_manager.go 负责路径生命周期、认证与客户端挂载热重载时在此完成配置对齐协议层internal/protocols/ 下每个协议目录都有 to_stream/from_stream 一对实现分别处理协议包 → 内部轨道和反向封装录制器internal/recorder/ 按 part 周期把数据刷盘进程异常时最多丢失一个 part单场景实战RTSP 摄像头接入浏览器顺带录像场景一台 RTSP 摄像头目标是浏览器低延迟观看同时保留录像。在mediamtx.yml里只改paths段的两处paths: cam1: source: rtsp://user:pass192.168.1.50:554/stream1 record: yes recordFormat: fmp4source指向摄像头地址有读者连接时服务器才会去拉流record开启落盘文件默认写在./recordings/一天后自动清理格式可选 fMP4 或 MPEG-TS。验证方式有三条浏览器打开http://服务器IP:8889/cam1这是 WebRTC 内置播放页几秒内出画面查看recordings/cam1/目录fMP4 分段文件在按小时滚动生成用http://服务器IP:8888/cam1/hls.m3u8在 HLS 播放器里验证同一路流的低延迟 HLS 输出整个过程没有重启服务器、没有引入额外进程录像与实时播放来自同一条流。 避坑指南现象原因解决容器内 WebRTC 一直握手失败握手走 8889/TCP媒体实际走 8189/UDPUDP 口没映射映射8189/udp并用MTX_WEBRTCADDITIONALHOSTS填上客户端能访问到的 IPRTSP over UDP 拉不动流Docker 会改写 UDP 包的源地址和端口摄像头无法回包设MTX_RTSPTRANSPORTStcp或以--networkhost方式运行苹果设备不播 LL-HLS低延迟 HLS 在苹果设备上强制要求 HTTPS开启hlsEncryption并配置证书或将hlsVariant改为mpegts弱网下卡顿、丢包系统默认 UDP 缓冲区偏小或载荷过大被分片调大udpReadBufferSize如 4MB调小udpMaxPayloadSize如 1400内存占用高于预期每条连接的出站包队列默认 512降低writeQueueSize吞吐与内存之间取平衡录像把磁盘占满recordDeleteAfter被设为 0s关闭了自动删除恢复保留期如7d并用recordSegmentDuration控制单文件时长 深入方向全部配置项逐项说明docs/5-references/1-configuration-file.md录制与回放的完整行为docs/2-features/09-record.md、docs/2-features/10-playback.md架构设计图与组件职责docs/2-features/02-architecture.md下一步建议把仓库自带的mediamtx.yml完整读一遍每个字段都有注释然后试着把hlsVariant在lowLatency与mpegts之间切换用同一播放器观察 2~3 秒与 5 秒以上延迟的差别生产部署前再看一眼热重载章节确认改配置不会踢掉在线读者。把可执行文件下载下来两条命令就能推上你的第一条流本文的示例改个摄像头地址即可复用。真正动手时你才会发现这个服务器能接住的协议组合比配置文件的长度还要多。【免费下载链接】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），仅供参考 
长河君 · 2026/9/8 15:52:19 · 阅读 1.2k MediaMTX：零依赖多协议流媒体服务器，5 分钟跑通 RTSP 推流到 WebRTC 播放
MediaMTX零依赖多协议流媒体服务器5 分钟跑通 RTSP 推流到 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/mediamtxMediaMTX 是一个用 Go 编写的零依赖实时媒体服务器与媒体代理发布、读取、录制、回放音视频流一个进程全部完成。它编译后是一个独立可执行文件不依赖 FFmpeg 或任何运行时。对开发者最直接的好处是用一份配置替代一整套协议转换组件RTSP、RTMP、WebRTC、SRT、LL-HLS 在同一个实例上同时工作5 分钟即可搭建。它解决了什么问题典型需求MediaMTX 的解法RTSP 摄像头需要在浏览器里看摄像头用 RTSP 推流浏览器用 WebRTC 读取协议转换由服务器自动完成无需转码OBS 推 RTMP移动端要低延迟观看一条路径接收推流后WebRTC、SRT、HLS 读者可同时拉取各取所需流要落盘保存还要支持回放一个参数开启录制fMP4 或 MPEG-TS 分段写盘回放服务器直接提供回放同一台机器管理几十路流每路流对应一条 path互不干扰可单独配置认证、录制、转发 首次运行前置条件已安装 Docker二进制与其他方式见安装文档。第 1 步启动服务器映射常用端口docker run --rm -it \ -p 8554:8554 -p 1935:1935 -p 8888:8888 \ -p 8889:8889 -p 8189:8189/udp \ -e MTX_RTSPTRANSPORTStcp \ bluenviron/mediamtx:1验证终端持续输出各服务器启动日志且ss -tln | grep 8554能看到端口在监听。第 2 步用 FFmpeg 模拟一个推流端ffmpeg -re -stream_loop -1 -i test.mp4 -c copy -f rtsp rtsp://localhost:8554/mystream验证MediaMTX 日志出现针对mystream的 RTSP 发布会话记录。第 3 步读取这条流ffmpeg -i rtsp://localhost:8554/mystream -c copy -t 5 out.mp4验证out.mp4生成且可正常播放日志中多出一条读取会话。到这一步推流 → 中转 → 拉流的完整链路已经跑通。️ 能力地图速览维度支持内容发布协议MoQ、SRT、WebRTC、RTSP、RTMP、HLS、MPEG-TSUDP/Unix 套接字、RTP、树莓派摄像头读取协议MoQ、SRT、WebRTC、RTSP、RTMP、低延迟 HLSLL-HLS协议转换自动完成。一端发布另一端可用不同协议读取不做转码录制与回放fMP4/MPEG-TS 分段录制按 part 写入降低故障丢失回放服务器提供下载与回放运维配置热重载不踢断客户端Control API9997、Prometheus 指标9998、pprof9999安全内置用户、外部 HTTP、JWT 三种认证支持按路径与 IP 段授权部署单可执行文件或 Docker 镜像覆盖 Linux、Windows、macOS无外部依赖所谓全协议在 MediaMTX 里不是多个服务拼在一起而是同一条流挂上多个入口一份mediamtx.yml同时决定谁能发布、谁能读取、录不录制。⚙️ 内部机制MediaMTX 把每路流称为一条path。服务器启动时路径管理器读取paths配置为每条路径建立对象并做认证。发布端无论使用哪种协议进入服务器后都由协议层把包解复用为轨道视频轨、音频轨交给路径持有。读者连接时再按该读者需要的协议重新封装发出。录制、转发、代理这些功能本质上都是路径的消费者所以扩展一条路径的成本很低。三个核心组件路径管理器internal/core/path_manager.go 负责路径生命周期、认证与客户端挂载热重载时在此完成配置对齐协议层internal/protocols/ 下每个协议目录都有 to_stream/from_stream 一对实现分别处理协议包 → 内部轨道和反向封装录制器internal/recorder/ 按 part 周期把数据刷盘进程异常时最多丢失一个 part单场景实战RTSP 摄像头接入浏览器顺带录像场景一台 RTSP 摄像头目标是浏览器低延迟观看同时保留录像。在mediamtx.yml里只改paths段的两处paths: cam1: source: rtsp://user:pass192.168.1.50:554/stream1 record: yes recordFormat: fmp4source指向摄像头地址有读者连接时服务器才会去拉流record开启落盘文件默认写在./recordings/一天后自动清理格式可选 fMP4 或 MPEG-TS。验证方式有三条浏览器打开http://服务器IP:8889/cam1这是 WebRTC 内置播放页几秒内出画面查看recordings/cam1/目录fMP4 分段文件在按小时滚动生成用http://服务器IP:8888/cam1/hls.m3u8在 HLS 播放器里验证同一路流的低延迟 HLS 输出整个过程没有重启服务器、没有引入额外进程录像与实时播放来自同一条流。 避坑指南现象原因解决容器内 WebRTC 一直握手失败握手走 8889/TCP媒体实际走 8189/UDPUDP 口没映射映射8189/udp并用MTX_WEBRTCADDITIONALHOSTS填上客户端能访问到的 IPRTSP over UDP 拉不动流Docker 会改写 UDP 包的源地址和端口摄像头无法回包设MTX_RTSPTRANSPORTStcp或以--networkhost方式运行苹果设备不播 LL-HLS低延迟 HLS 在苹果设备上强制要求 HTTPS开启hlsEncryption并配置证书或将hlsVariant改为mpegts弱网下卡顿、丢包系统默认 UDP 缓冲区偏小或载荷过大被分片调大udpReadBufferSize如 4MB调小udpMaxPayloadSize如 1400内存占用高于预期每条连接的出站包队列默认 512降低writeQueueSize吞吐与内存之间取平衡录像把磁盘占满recordDeleteAfter被设为 0s关闭了自动删除恢复保留期如7d并用recordSegmentDuration控制单文件时长 深入方向全部配置项逐项说明docs/5-references/1-configuration-file.md录制与回放的完整行为docs/2-features/09-record.md、docs/2-features/10-playback.md架构设计图与组件职责docs/2-features/02-architecture.md下一步建议把仓库自带的mediamtx.yml完整读一遍每个字段都有注释然后试着把hlsVariant在lowLatency与mpegts之间切换用同一播放器观察 2~3 秒与 5 秒以上延迟的差别生产部署前再看一眼热重载章节确认改配置不会踢掉在线读者。把可执行文件下载下来两条命令就能推上你的第一条流本文的示例改个摄像头地址即可复用。真正动手时你才会发现这个服务器能接住的协议组合比配置文件的长度还要多。【免费下载链接】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），仅供参考