企业官网建设流程全解析

MediaMTX 流媒体服务器完整教程：5 分钟把 RTSP 摄像头送上网页低延迟播放

【免费下载链接】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

安保室的监控摄像头只会说 RTSP，而网页管理端却想要秒级延迟的画面，两者之间的缺口需要一台流媒体服务器来补。MediaMTX 就是这样一台即开即用的流媒体服务器：它由 Go 编译成单个可执行文件、没有任何运行时依赖，覆盖 RTSP、RTMP、HLS、WebRTC、SRT、MoQ 等多种协议的实时转发，用 Docker 一条命令部署后，就能把摄像头推来的 RTSP 流转成浏览器直接可播的 HLS 或 WebRTC。

📊 特性速览：动手前先看这张表

🚀 三命令跑通最短链路：FFmpeg 推流，浏览器验证

第一步，拉起容器并映射核心端口：

docker run --rm -it \ -p 8554:8554 -p 1935:1935 -p 8888:8888 -p 8889:8889 \ bluenviron/mediamtx:1

第二步，用 FFmpeg 把任意本地视频循环推入 RTSP 端口：

ffmpeg -re -stream_loop -1 -i file.mp4 -c copy -f rtsp rtsp://localhost:8554/mystream

第三步，验证结果。浏览器打开http://localhost:8888/mystream，出现画面即说明 RTSP 输入已经转成 HLS 输出；VLC 里播放rtsp://localhost:8554/mystream，则证明同一路流被两种协议同时读取。至此，一条典型的 RTSP 转 HLS 链路已经在你机器上跑通。

🧭 顺着一条流的旅程走一遍：从推入到上屏

比起先背架构图，跟着一个视频帧的行程更直观：

1. 推入。发布端经 RTSP、RTMP、SRT、WebRTC 或 MoQ 任一协议建立连接，接入层（internal/servers/下各协议子目录）完成握手并接收首帧。
2. 翻译。协议数据包在internal/protocols/里被解复用为统一的内部媒体流：视频轨（H.264、H.265、AV1 等）、音频轨和一条统一时间线。全程只拆包重封，不做转码，所以延迟和画质都取决于源流本身。
3. 分发。中枢 internal/core/path_manager.go 维护着“一条路径、一个源、多个读取端”的关系表。每来一个读取端就动态长出对应输出：HLS 复用器切分 TS/fMP4 分片、WebRTC 建立 PeerConnection 发送 RTP、RTMP 重新封装。各读取端互相独立，互不干扰。
4. 落盘与外发。同一条流还可以被录制器写进磁盘、被 forward 机制推到外部服务器、被回放服务索引，全部由配置开关决定。

🎥 场景一：监控摄像头接进网页管理端

需求：摄像头只输出 RTSP，前端要求低延迟、跨端可播。

怎么配：在mediamtx.yml的paths下登记这条流，服务器会自动去拉：

paths: cam1: source: rtsp://user:pass@192.168.1.64:554/stream1

读者得到什么：无需再写任何采集端代码，http://主机:8889/cam1是 WebRTC 播放地址（延迟最低），http://主机:8888/cam1是 LL-HLS 地址，默认即为 lowLatency 变体，通常在秒级延迟内出画面。

🎬 场景二：直播留存 + 按时间段回放

需求：直播过程要可追溯，事后能按时间点回看。

怎么配：给路径打开录制，再全局启用回放服务：

paths: cam1: record: yes recordFormat: fmp4 recordDeleteAfter: 7d playback: yes playbackAddress: :9996

分片按recordPath模板（默认./recordings/%path/%Y-%m-%d_%H-%M-%S-%f_%z）自动切段写盘，recordDeleteAfter负责到期清理。回放服务的实现位于internal/playback/，它提供两个端点：http://主机:9996/list?path=cam1列出可回放的时段，/get?path=cam1&start=...&duration=...按时段取流。

读者得到什么：输出是 fMP4 格式，可直接塞进网页<video>标签播放，实现“直播 + 录像 + 回放”三合一。

🌐 场景三：按需拉流与多节点就近分发

需求：流源不稳定或不想空耗带宽，且多地用户都来看。

怎么配：

• sourceOnDemand: yes：有人读才建立拉流连接，读端清零一段时间后自动断开，省掉空窗期的带宽；
• runOnDemand：更进一步，用自定义命令（比如一条 FFmpeg 指令）在首次有人读时临时拉起推流源；
• forward列表：把本路径的流同时推到别的 RTSP / RTMP / SRT / WebRTC WHIP 目标，一配多用。

读者得到什么：带宽按需付费，跨机房部署时用 Control API 动态把远端流 URL 注册成本地路径，让各节点承接就近流量，拓扑规划见 docs/2-features/19-scalability.md。

✅ 上线前必查清单：认证、监控、扩展

认证

• authInternalUsers别保留默认的user: any，改为按用户分配凭据
• 权限按动作拆分：publish（推流）、read（读流）、playback（回放）分别授权
• 敏感路径叠加path限制（支持~前缀的正则）与ips白名单
• 已有企业身份体系时，切换authJWTJWKS（JWT + JWKS 公钥）或authHTTPAddress（HTTP 回调）

监控

• api: true打开9997Control API，可随时查看路径状态、在线增删路径
• metrics: true打开9998Prometheus 接口，接入现有告警

扩展

• 确认单机出口带宽覆盖多路流的并发读流量
• 多站点部署前读一遍 scalability 文档，规划边缘节点与动态路径注册

🔧 故障排查速查表：症状—原因—动作

📖 延伸阅读与下一步

• 官方起步路径：安装、升级、首次使用，见 docs/1-kickoff/
• 全部配置项的完整字典：docs/5-references/1-configuration-file.md
• 想理解回放如何拼回时间轴，直接翻internal/playback/的源码

先按“三命令跑通最短链路”在本地跑通一条 RTSP 转 HLS，看到画面后再按需开启录制、认证与监控——这就是掌握单文件流媒体转发部署的最短路线。

【免费下载链接】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