企业官网建设流程全解析

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（开源实时媒体服务器）的RTSP 读取（Read）能力：从协议层的能力边界、编码格式支持，到 UDP / TCP / UDP-multicast 传输协商、RTSPS 加密与 HTTP/WebSocket 隧道等进阶特性，再到 FFmpeg、GStreamer、VLC 三大客户端的完整读取命令与参数调优。读完本文，你将能够根据网络环境选择正确的 RTSP 传输方式，并直接用命令行或图形播放器拉取任意路径上的直播流。

RTSP 读取：一句话理解

RTSP（Real Time Streaming Protocol）是一个既可**推流（publish）也可拉流（read）**的协议，它是 MediaMTX 生态中兼容性最好、被官方推荐优先使用的读取协议。要读取服务器上的一个流，只需要构造如下形式的 URL：

rtsp://localhost:8554/mystream

其中8554是 MediaMTX 默认的 RTSP 监听端口，mystream是流路径（path）。该路径与推流端发布时使用的路径一致，也对应 mediamtx.yml 中paths配置里定义的路径名。

支持的编码格式（Codec 一览）

MediaMTX 的 RTSP 服务端对读取端的编码兼容性很强，官方在 docs/4-read/04-rtsp.md 中给出了完整的支持矩阵：

从源码看，这一能力由internal/protocols/rtsp与internal/stream中的 RTP 封装/解封装逻辑承载（如 internal/stream/rtp_decoder.go），RTSP 会话建立与媒体协商则基于 gortsplib 库完成（见 internal/servers/rtsp/server.go）。

注意：即使推流端用不支持的编码推入，MediaMTX 也会以“RTP 兼容编码”的方式尽力透传，因此 RTSP 读取的兼容面实际上非常广。

RTSP 会话的底层组成：握手与数据传输

MediaMTX 官方在 docs/2-features/26-rtsp-specific-features.md 中明确指出：一次 RTSP 会话被拆分为两个部分——

1. 握手（handshake）：始终通过 TCP 完成（OPTIONS / DESCRIBE / SETUP / PLAY 等信令）；
2. 数据流传输（streaming）：可由客户端在握手期间自由选择底层传输协议。

这个设计意味着“传输协议”不是服务器单方面决定的，而是由客户端在 SETUP 阶段协商，因此切换传输方式需要调整的是客户端的配置，而非服务器配置。服务器侧只负责按rtspTransports配置开放相应的监听能力。

三种底层传输协议与选型

在 mediamtx.yml 的默认配置中，三种传输全部开启：

rtspTransports: [udp, multicast, tcp]

很多客户端默认使用 UDP，一旦拉流失败，第一步就应当显式切换到 TCP。下面给出三大客户端的切换方式。

FFmpeg：-rtsp_transport

FFmpeg 通过-rtsp_transport参数指定传输协议：

ffmpeg -rtsp_transport tcp -i rtsp://localhost:8554/mystream -c copy output.mp4

可选值：

• -rtsp_transport tcp—— TCP 传输
• -rtsp_transport udp—— UDP 传输
• -rtsp_transport udp_multicast—— UDP-multicast 传输

GStreamer：rtspsrc的protocols属性

GStreamer 在rtspsrc（读取）与rtspclientsink（推送）上通过protocols属性控制：

gst-launch-1.0 rtspsrc location=rtsp://127.0.0.1:8554/mystream protocols=tcp latency=0 ! decodebin ! autovideosink

可选值（注意组播写法与 FFmpeg 不同）：

• protocols=tcp
• protocols=udp
• protocols=udp-mcast

VLC：--rtsp-tcp与 URL 参数

VLC 使用命令行参数或 URL 后缀：

# TCP 传输 vlc --network-caching=50 --rtsp-tcp rtsp://localhost:8554/mystream # UDP-multicast 传输（在 URL 后追加 ?vlcmulticast） vlc --network-caching=50 rtsp://localhost:8554/mystream?vlcmulticast

提示：--network-caching=50用于将网络缓存降到 50ms，可显著降低观看延迟，是 VLC 拉流时的推荐做法。

加密读取：RTSPS / SRTP / SRTCP

当流经过公网传输，或涉及敏感画面时，应当启用加密。MediaMTX 将 RTSP 体系中的各个子协议整体替换为安全变体：

• RTSP →RTSPS（TCP 信令走 TLS）
• RTP →SRTP
• RTCP →SRTCP

启用加密需要 TLS 证书，可用 OpenSSL 生成：

openssl genrsa -out server.key 2048 openssl req -new -x509 -sha256 -key server.key -out server.crt -days 3650

然后在 mediamtx.yml 中配置（以当前仓库默认配置文件为准）：

rtspEncryption: "no" # no / optional / strict 三选一 rtspServerKey: server.key rtspServerCert: server.crt

说明：rtspEncryption取值含义——no完全禁用加密；optional同时开放明文与加密端口（RTSP 与 RTSPS 均可访问）；strict只接受加密连接。注意旧版文档中的encryption: optional、serverKey、serverCert等写法在当前版本中已分别被 internal/conf/conf.go 中的rtspEncryption、rtspServerKey、rtspServerCert取代（启动时会打印 deprecated 警告）。

配置完成后，加密流使用rtspsscheme 与8322端口：

rtsps://localhost:8322/mystream

服务端启动日志中会通过printAddresses打印各监听器的实际形态（TCP/RTSPS、UDP/SRTP、UDP/SRTCP），见 internal/servers/rtsp/server.go。

客户端加密注意事项

不同客户端对证书校验的处理不同，读取 RTSPS 流时可能需要额外参数：

GStreamer 读取时关闭 TLS 校验（自签证书场景）：

gst-launch-1.0 rtspsrc tls-validation-flags=0 location=rtsps://ip:8322/...

VLC 的限制：当前版本的 VLC不支持直接读取 RTSPS 加密流。官方给出的替代方案是借助 stunnel、nginx 等代理，或再起一个本地 MediaMTX 实例做解密中转（详见 docs/4-read/10-vlc.md）。

HTTP / WebSocket 隧道：穿越"仅 HTTP"网络

在存在强制 API 网关或严格防火墙、只放行 HTTP 的环境中，RTSP 可以被隧道封装进 HTTP 体系。MediaMTX 支持两种标准隧道变体：

• RTSP over WebSocket：效率更高，要求网关/防火墙支持 WebSocket；
• RTSP over HTTP：更古老的变体，在极端环境下也能工作。

关键结论：MediaMTX自动处理进入服务器的 HTTP 隧道 RTSP 连接，无需任何配置（这体现为服务端对rtsp+http、rtsp+ws等 URL scheme 的透明接受）。

而当 MediaMTX 作为客户端去拉取外部 RTSP 服务器的流时，只需在paths的source中指定带隧道 scheme 的 URL：

paths: mypath: source: rtsp+http://standard-rtsp-url

可用的 scheme 组合包括：

• rtsp+http—— RTSP over HTTP 隧道
• rtsps+http—— RTSPS over HTTPS 隧道
• rtsp+ws—— RTSP over WebSocket
• rtsps+ws—— 加密 RTSP over 安全 WebSocket

这些 scheme 同样出现在 mediamtx.yml 的 source 注释中，可作为静态源（static source）直接配置。

客户端读取实战

用 FFmpeg 读取

FFmpeg 是官方推荐的首选读取客户端，它同时支持 RTSP、RTMP、HLS、SRT，而其中RTSP 是推荐协议。最简单的转存命令：

ffmpeg -i rtsp://localhost:8554/mystream -c copy output.mp4

-c copy表示流复制、不做转码，速度最快。若想实时预览画面，可以去掉输出文件改为播放器输出（如-f sdl/-f vlc等），具体见 docs/4-read/08-ffmpeg.md。

用 GStreamer 读取

gst-launch-1.0 rtspsrc location=rtsp://127.0.0.1:8554/mystream latency=0 ! decodebin ! autovideosink

latency=0用于消除缓冲以降低延迟。其余细节与protocols组合方式参考上文及 docs/4-read/09-gstreamer.md。

用 VLC 读取

直接在 VLC 中打开 URL（或命令行执行）：

rtsp://localhost:8554/mystream

为了最小化延迟，建议将 VLC 的Network caching参数从默认值调低至50ms：菜单 _工具 → 偏好设置 → 左下角"显示设置"切到全部→ 页签输入/编解码器→ 找到网络缓存（毫秒）设为50。

Ubuntu 用户注意：Ubuntu 21.10 自带的 VLC 因许可证问题无法播放 RTSP。解决办法是卸载自带版本并改用 snap 版：

sudo apt purge -y vlc sudo snap install vlc

详见 docs/4-read/10-vlc.md。

进阶：MPEG-TS inside RTSP 的解复用

某些 RTSP 客户端（例如部分 IPC 摄像头）会先把媒体封装成MPEG-TS再经 RTSP 发送，导致服务器看到的只是一个独立的 "MPEG-TS" 轨道，无法跨协议转换（如无法转给 WebRTC / HLS 使用）。

MediaMTX 提供了自动解复用能力，通过路径级配置rtspDemuxMpegts开启（默认false，见 mediamtx.yml）：

pathDefaults: # 将 RTSP 内的 MPEG-TS 解复用为基本流。 # 启用后，发送 MP2T/90000 的 RTSP 推流方会被解复用， # 其基本流（H.264、H.265、AAC 等）将以原生轨道形式暴露， # 从而使 HLS、WebRTC 等输出对 MPEG-TS 源透明可用。 rtspDemuxMpegts: true

该逻辑在 RTSP 会话的onRecord（推流握手）阶段触发，通过mpegtsDemuxer将单个 MPEG-TS 媒体描述拆解为多个基本流（见 internal/servers/rtsp/session.go 与 internal/servers/rtsp/mpegts_demuxer.go）。这一特性对"读取"场景的间接价值在于：上游 MPEG-TS 源被解复用后，下游 RTSP 读取端能获得更清晰的轨道信息与更佳的兼容性。

小结

从协议机制（docs/2-features/26-rtsp-specific-features.md）到服务端实现（internal/servers/rtsp/server.go、internal/servers/rtsp/session.go），再到默认配置（mediamtx.yml），RTSP 读取链路在 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/mediamtx