企业官网建设流程全解析

MediaMTX 实战指南：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

MediaMTX 是一个开箱即用、零依赖的实时流媒体服务器：你把它当成一台"媒体路由器"，摄像头、推流软件从一边进来，网页、播放器从另一边读走，它负责中间的接入、分发、录制和回放。它用 Go 写成，编译后是一个独立可执行文件，支持 RTSP、RTMP、WebRTC、SRT、LL-HLS、MPEG-TS、RTP 乃至较新的 Media-over-QUIC 协议，而且不同协议之间可以自动互转，不需要你额外部署转码服务。

协议不匹配，才是直播链路里最常被低估的问题

先说一个很常见的卡点：手边的设备只会说"一种方言"。摄像头普遍吐 RTSP 或 SRT，OBS 之类的推流软件习惯用 RTMP，而现代网页端真正流畅的实时播放走的是 WebRTC。传统做法是中间垫几台服务器做协议转换，链路越长延迟越高，运维也越重。

MediaMTX 的思路是把这件事收敛到一个进程里。它内部由三块组成：负责路径管理和认证的 path manager、承载各路流媒体的 path（每个 path 对应一条独立流，由一个发布端提供、同时分发给多个读取端）、以及把流落盘的 recorder。所有协议适配都收敛在内部，对外你只需要面对"一个 URL + 一个路径名"。

各协议对应的默认端口可以先记下来，后面配防火墙、Docker 映射都会用到：

这些端口都写在mediamtx.yml里，可按需调整；具体取值以配置文件内注释和官方文档为准。

三步接入：装好、写一条路径、打开浏览器

第一步：把服务跑起来

两种主流方式，按你的环境选。Docker 方式适合生产：

docker run --rm -it \ -e MTX_RTSPTRANSPORTS=tcp \ -p 8554:8554 -p 1935:1935 -p 8888:8888 \ -p 8889:8889 -p 8890:8890/udp -p 8189:8189/udp \ bluenviron/mediamtx:1

注意那行MTX_RTSPTRANSPORTS=tcp：Docker 的网络栈有时会改写 UDP 包的源地址，把 RTSP 的 UDP 传输关掉最省事；如果你用--network=host模式则不需要。

二进制方式适合先试水：到项目 Releases 页面下载对应平台的压缩包，解压后直接执行./mediamtx（Windows 下为mediamtx.exe），它会读取同目录下的mediamtx.yml启动。

第二步：在配置里声明你的摄像头

你真正需要动的往往只是paths这一段。以一台 RTSP 摄像头为例：

paths: cam1: source: rtsp://admin:password@192.168.1.100:554/stream1

就这么一条：cam1是路径名，source是流的来源。来源还可以是 RTMP、SRT、HLS、RTP、UDP 的 MPEG-TS，甚至是另一台 MediaMTX——也就是说，级联部署时"从上游拉流"和"从摄像头拉流"用的是同一种写法。改完配置不用重启，MediaMTX 支持热加载，保存文件即生效，已连接的客户端不会断开。

第三步：用三种方式验证

推一个假流也行，用 VLC 拉个公开测试源推到rtsp://你的IP:8554/cam1也可以。然后分别验证：

• 浏览器直接访问http://你的IP:8889/cam1，这是内置的 WebRTC 播放页，延迟最低；
• 访问http://你的IP:8888/cam1/index.m3u8拿到 HLS 播放列表，也可以直接打开http://你的IP:8888/cam1/看内置播放页；
• 用 VLC 播放rtsp://你的IP:8554/cam1，验证 RTSP 读取。

同一条流，三种协议读出来，这就是它作为"媒体路由器"的全部意义：发布端只推一次，读取端想用哪个协议就用哪个。

不止看流：把录像、回放和权限一次配好

录像与自动清理

很多场景（安防、课堂记录）要求流存得下来。在pathDefaults下开启即可：

pathDefaults: record: yes recordFormat: fmp4 recordDeleteAfter: 1d

录像默认按小时切段、存到./recordings/下，recordDeleteAfter控制保留多久，设为0s则永不自动删除。recordPartDuration（默认 1s）决定了断电等异常下最多丢多久的数据，可以理解为你的 RPO 下限。

给历史录像一个播放入口

录完还要能给人看。开启回放服务后，它会监听 9996 端口，提供列出录像时间段的接口和按时间段下载录像的接口，返回的 fMP4 流可以直接塞进<video>标签：

playback: yes playbackAddress: :9996

具体接口参数（按路径、起始时间、时长查询）见仓库docs/2-features/10-playback.md，以官方文档为准。

权限：别忘了它默认对"任何人"敞开

这是新手最容易忽略的一条：默认配置里存在一个user: any的条目，允许任意匿名用户发布、读取、回放所有路径。内网试用无所谓，但暴露到公网前必须改掉。认证支持 internal（账号写在配置文件里）、外部 HTTP 校验、JWT 三种模式（authMethod字段切换），路径级还可以用maxReaders限制读取方数量。生产环境建议至少把 internal 用户收窄到具体 IP 段并设置密码。

上线前的几个容易踩的坑

• UDP 端口漏配：WebRTC 依赖 8189/UDP，SRT 依赖 8890/UDP，RTSP 的 UDP 传输还需要 8000-8005 一段。防火墙和 Docker 映射里漏掉 UDP，症状往往是"TCP 的 RTSP 正常、WebRTC 死活连不上"。
• Docker 下 WebRTC 连不通：容器对外暴露的 IP 和客户端实际要连的 IP 不一致时，需要设置webrtcAdditionalHosts或MTX_WEBRTCADDITIONALHOSTS环境变量，把客户端真正能到达的地址告诉它。
• HLS 延迟预期：HLS 天生是分段播放的协议，即便开启hlsVariant: lowLatency也只是"低延迟"而非"实时"。要毫秒级延迟走 WebRTC 或 SRT，HLS 更适合做广兼容和 CDN 分发。
• 排查手段先备好：出问题时把logLevel调到debug，再开dumpPackets把原始包落盘分析；需要量化监控就打开metrics: yes（9998 端口，Prometheus 兼容格式）。仓库里docs/2-features/23-performance.md有专门的性能排查文档，值得先翻一遍。

下一步可以做什么

1. 把一条真实摄像头流完整跑通：接入 → WebRTC 播放 → 录制 → 回放，走完这个闭环再谈扩展；
2. 试一下"发布用 A 协议、读取用 B 协议"的组合，比如 SRT 发布 + WebRTC 读取，感受弱网场景下 SRT 的作用；
3. 研究runOnDemand、runOnRead等 hooks：它们让你能在"有人来读流"时自动拉起 ffmpeg 推流，是搭建按需直播系统的利器；
4. 想深入实现细节的话，直接看仓库源码：路径管理在 internal/core/path_manager.go，各协议适配在 internal/protocols/ 下的子目录里，文档在 docs/。

如果你需要拿到源码研究或二次开发，仓库地址是https://gitcode.com/GitHub_Trending/me/mediamtx。最后提醒一句：MediaMTX 配置项非常多，本文只覆盖了最常用的一小块，动手前把mediamtx.yml里的注释通读一遍、拿不准的参数以官方文档为准，会比到处找零散教程省时间得多。

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