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 是一个开箱即用的 Go 语言实时流媒体服务器与媒体代理把 RTSP、RTMP、WebRTC、SRT、HLS含 LL-HLS、MPEG-TS、RTP 及 Media-over-QUIC 之间的发布、读取、转发、录制与回放收敛到同一个进程里完成。它按媒体路由器的思路工作把流从入口路由到出口它不做转码不提供编码、转封装以外的媒体加工能力边界在选型时就应划清。定位与能力边界一句话讲清 MediaMTX能力面多协议收发与互转、按路径多路复用、录制为 fMP4/MPEG-TS、基于磁盘的回放服务、Control API 与 Prometheus 指标、热加载配置。边界它是 remuxer重封装器而非 transcoder转码器码流进来什么样出去还是什么样。三个典型场景什么时候会需要它摄像头群的多端分发。场景一批 RTSP 摄像头办公网用 WebRTC 看App 用 SRT 拉还要出 HLS 给网页。没有它时每种出口协议都要维护一条 FFmpeg 转推链或者再架一台服务器做协议网关。有了它之后摄像头按路径推入各协议出口开箱即用互转在进程内完成。存量流的多目标转发。场景内部 RTSP 源要同时送到 RTMP 和 SRT 两个系统。没有它时每个下游一条独立拉流脚本源端连接数随下游线性增长。有了它之后源只被拉一次forward配置把同一份流推往多个目标见下文拉流再分发。按需拉流与留档。场景摄像头带宽有限不能 7×24 保持拉流但事件发生时又要求秒级可用且要留档备查。没有它时按需要靠外部调度器开关 FFmpeg留档要另写一套分段录制。有了它之后sourceOnDemand控制拉流生命周期record直接分段落盘回放服务再把它读出来。核心设计思路路由而非转码从设计角度看MediaMTX 的关键取舍有三个。路由模型而非转码模型。它把编解码完全留在源端服务器只做解封装、协议转换和再封装。收益是延迟接近裸推、CPU 开销极小代价是入口什么编码出口就是什么编码换格式的需求要外部解决。这个取舍决定了它适合做分发层不适合做加工层。单二进制、零依赖。一个可执行文件、一份 YAML 配置跨 Linux/Windows/macOS。各协议监听器可以独立启停配置热加载不打断现有连接。部署形态因此极简运维面也小。路径模型path。一条流对应一个路径单一来源URL 或推流客户端对任意多个读端录制、转发、鉴权都挂在路径维度上。核心组件是路径管理器见 docs/2-features/02-architecture.md负责路径的生命周期、认证和读端挂接。使用模式三种常见用法与关键配置纯转发协议互转不指定source路径等待客户端推入读端任意协议。路径名支持正则一条配置覆盖整批流。paths: all_others: # source 缺省为 publisher等待任意客户端推入拉流再分发source指向外部源。sourceOnDemand: yes表示有读端才拉、无人读即断开适合省带宽的摄像头源maxReaders给读端数量封顶。paths: cam01: source: rtsp://user:pass192.168.1.100:554/stream sourceOnDemand: yes maxReaders: 20 ~^cam\d$: source: rtsp://192.168.1.101/$(1)录制留档record: yes开启分段录制recordPartDuration控制小分片时长recordSegmentDuration控制一个完整段recordDeleteAfter控制保留期recordPath控制落盘位置。paths: cam01: record: yes recordPath: /var/mediamtx/recordings/%path recordPartDuration: 2s recordSegmentDuration: 1h recordDeleteAfter: 72h需要把同一份流再推往别家服务器时用forwardRTSP/RTMP/SRT/WebRTC/MoQ 目标不必让下游各自回拉源头。部署与集成要点端口与运行形态运行形态Docker 用--network host最省事媒体端口多NAT 映射容易漏裸二进制跑 systemd 适合长期驻留。关键监听RTSP 8554、RTMP 1935、HLS 8888、WebRTC 8889、SRT 8890UDP、MoQ 8892/8893管理面 Control API 9997、metrics 9998、pprof 9999、回放 9996。RTSP 走 UDP 时还要放行 RTP/RTCP 的 UDP 端口段默认 32768–60999 内分配。外部依赖无运行时依赖可选 STUN/TURNWebRTC 打洞、CDNHLS 分发、外部 HTTP/JWT 认证服务。docker run -d --name mediamtx --restart always \ --network host \ -v $PWD/mediamtx.yml:/mediamtx.yml \ bluenviron/mediamtx:latest选型参考适合与不适合的场景维度适合不适合替代方向协议工作多协议互转、按路径分发、轻量录制转码、换码率、换封装FFmpeg、MediaStreamProcessor规模形态单机中小并发、边缘节点大规模转码集群、需要媒体分析自建管道适合协议互转是主矛盾摄像头群的统一接入层需要推一次、处处可读的中间件角色录制留档与回放的轻量方案。不适合需要改编码参数或格式它不碰编码需要按内容做智能分发没有媒体理解能力只有配置驱动的forward与 hooks。边界与已知局限四条诚实的限制⚠️ 不做转码入口与出口编解码必须一致混编解码的端到端场景要在外部完成转换。单实例上限在出口带宽官方扩展方案是读副本多实例 负载均衡见 docs/2-features/19-scalability.md或 HLS 挂 CDN没有内置集群。WebRTC 穿复杂 NAT 必须配 STUN/TURNwebrtcICEServers2UDP 受限环境下只能走 TCP ICE 回落延迟会受影响。录制格式只有 fMP4 与 MPEG-TSHLS 走 CDN 分发时 LL-HLS 不可缓存通常要换fmp4变体并放弃最低延迟。延伸资源官方文档与源码入口官方功能与使用文档协议、录制、回放、鉴权的完整说明落地前必读。完整配置参考逐项解释默认配置与仓库根目录的 mediamtx.yml 一一对应。Control API 参考运行时查询路径、动态改配置的接口定义。源码入口internal/core/路径管理与服务器装配、internal/servers/各协议监听器实现。上游协议库go.mod 中的 gortsplib、gortsplib 生态与 gosrt理解行为边界时可对照协议实现。【免费下载链接】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），仅供参考
