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 读取一句话理解RTSPReal Time Streaming Protocol是一个既可**推流publish也可拉流read**的协议它是 MediaMTX 生态中兼容性最好、被官方推荐优先使用的读取协议。要读取服务器上的一个流只需要构造如下形式的 URLrtsp://localhost:8554/mystream其中8554是 MediaMTX 默认的 RTSP 监听端口mystream是流路径path。该路径与推流端发布时使用的路径一致也对应 mediamtx.yml 中paths配置里定义的路径名。支持的编码格式Codec 一览MediaMTX 的 RTSP 服务端对读取端的编码兼容性很强官方在 docs/4-read/04-rtsp.md 中给出了完整的支持矩阵类别支持的编码video视频AV1, VP9, VP8, H265, H264, MPEG-4 VideoH263、Xvid, MPEG-1/2 Video, M-JPEGaudio音频Opus, MPEG-4 AudioAAC, MPEG-1/2 AudioMP3, AC-3, G726, G722, G711PCMA、PCMU, LPCMother其他KLV, MPEG-TS, 任意兼容 RTP 的编码从源码看这一能力由internal/protocols/rtsp与internal/stream中的 RTP 封装/解封装逻辑承载如 internal/stream/rtp_decoder.goRTSP 会话建立与媒体协商则基于 gortsplib 库完成见 internal/servers/rtsp/server.go。注意即使推流端用不支持的编码推入MediaMTX 也会以“RTP 兼容编码”的方式尽力透传因此 RTSP 读取的兼容面实际上非常广。RTSP 会话的底层组成握手与数据传输MediaMTX 官方在 docs/2-features/26-rtsp-specific-features.md 中明确指出一次 RTSP 会话被拆分为两个部分——握手handshake始终通过 TCP 完成OPTIONS / DESCRIBE / SETUP / PLAY 等信令数据流传输streaming可由客户端在握手期间自由选择底层传输协议。这个设计意味着“传输协议”不是服务器单方面决定的而是由客户端在 SETUP 阶段协商因此切换传输方式需要调整的是客户端的配置而非服务器配置。服务器侧只负责按rtspTransports配置开放相应的监听能力。三种底层传输协议与选型在 mediamtx.yml 的默认配置中三种传输全部开启rtspTransports: [udp, multicast, tcp]传输协议特点适用场景UDP性能最好但客户端需要额外访问服务器上的两个 UDP 端口RTP/RTCP在 NAT / 防火墙环境下常因端口被阻断或重映射而失败同网段、可控网络UDP-multicast数据包只发送一次到固定组播 IP组内所有客户端共享同一份带宽能大幅节省带宽客户端同处一个局域网TCP兼容性最好信令与数据都走 TCP可穿透绝大多数防火墙跨网络、不可控环境最常被推荐很多客户端默认使用 UDP一旦拉流失败第一步就应当显式切换到 TCP。下面给出三大客户端的切换方式。FFmpeg-rtsp_transportFFmpeg 通过-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 传输GStreamerrtspsrc的protocols属性GStreamer 在rtspsrc读取与rtspclientsink推送上通过protocols属性控制gst-launch-1.0 rtspsrc locationrtsp://127.0.0.1:8554/mystream protocolstcp latency0 ! decodebin ! autovideosink可选值注意组播写法与 FFmpeg 不同protocolstcpprotocolsudpprotocolsudp-mcastVLC--rtsp-tcp与 URL 参数VLC 使用命令行参数或 URL 后缀# TCP 传输 vlc --network-caching50 --rtsp-tcp rtsp://localhost:8554/mystream # UDP-multicast 传输在 URL 后追加 ?vlcmulticast vlc --network-caching50 rtsp://localhost:8554/mystream?vlcmulticast提示--network-caching50用于将网络缓存降到 50ms可显著降低观看延迟是 VLC 拉流时的推荐做法。加密读取RTSPS / SRTP / SRTCP当流经过公网传输或涉及敏感画面时应当启用加密。MediaMTX 将 RTSP 体系中的各个子协议整体替换为安全变体RTSP →RTSPSTCP 信令走 TLSRTP →SRTPRTCP →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-flags0 locationrtsps://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效率更高要求网关/防火墙支持 WebSocketRTSP over HTTP更古老的变体在极端环境下也能工作。关键结论MediaMTX自动处理进入服务器的 HTTP 隧道 RTSP 连接无需任何配置这体现为服务端对rtsphttp、rtspws等 URL scheme 的透明接受。而当 MediaMTX 作为客户端去拉取外部 RTSP 服务器的流时只需在paths的source中指定带隧道 scheme 的 URLpaths: mypath: source: rtsphttp://standard-rtsp-url可用的 scheme 组合包括rtsphttp—— RTSP over HTTP 隧道rtspshttp—— RTSPS over HTTPS 隧道rtspws—— RTSP over WebSocketrtspsws—— 加密 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 locationrtsp://127.0.0.1:8554/mystream latency0 ! decodebin ! autovideosinklatency0用于消除缓冲以降低延迟。其余细节与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.ymlpathDefaults: # 将 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 读取端能获得更清晰的轨道信息与更佳的兼容性。小结能力关键要点读取 URLrtsp://localhost:8554/path传输协商握手走 TCP数据流由客户端选择 UDP / multicast / TCP加密RTSPS/SRTP/SRTCP端口 8322需配置rtspEncryption、rtspServerKey、rtspServerCert隧道rtsphttp、rtspshttp、rtspws、rtspsws服务端零配置自动处理推荐客户端FFmpeg、GStreamer、VLC均以 RTSP 为推荐协议编解码范围视频覆盖 AV1~M-JPEG音频覆盖 Opus~LPCM另支持 KLV、MPEG-TS 与任意 RTP 编码从协议机制docs/2-features/26-rtsp-specific-features.md到服务端实现internal/servers/rtsp/server.go、internal/servers/rtsp/session.go再到默认配置mediamtx.ymlRTSP 读取链路在 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创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 MediaMTX 中通过 RTSP 读取直播流：协议、传输、加密与三大客户端实战
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 读取一句话理解RTSPReal Time Streaming Protocol是一个既可**推流publish也可拉流read**的协议它是 MediaMTX 生态中兼容性最好、被官方推荐优先使用的读取协议。要读取服务器上的一个流只需要构造如下形式的 URLrtsp://localhost:8554/mystream其中8554是 MediaMTX 默认的 RTSP 监听端口mystream是流路径path。该路径与推流端发布时使用的路径一致也对应 mediamtx.yml 中paths配置里定义的路径名。支持的编码格式Codec 一览MediaMTX 的 RTSP 服务端对读取端的编码兼容性很强官方在 docs/4-read/04-rtsp.md 中给出了完整的支持矩阵类别支持的编码video视频AV1, VP9, VP8, H265, H264, MPEG-4 VideoH263、Xvid, MPEG-1/2 Video, M-JPEGaudio音频Opus, MPEG-4 AudioAAC, MPEG-1/2 AudioMP3, AC-3, G726, G722, G711PCMA、PCMU, LPCMother其他KLV, MPEG-TS, 任意兼容 RTP 的编码从源码看这一能力由internal/protocols/rtsp与internal/stream中的 RTP 封装/解封装逻辑承载如 internal/stream/rtp_decoder.goRTSP 会话建立与媒体协商则基于 gortsplib 库完成见 internal/servers/rtsp/server.go。注意即使推流端用不支持的编码推入MediaMTX 也会以“RTP 兼容编码”的方式尽力透传因此 RTSP 读取的兼容面实际上非常广。RTSP 会话的底层组成握手与数据传输MediaMTX 官方在 docs/2-features/26-rtsp-specific-features.md 中明确指出一次 RTSP 会话被拆分为两个部分——握手handshake始终通过 TCP 完成OPTIONS / DESCRIBE / SETUP / PLAY 等信令数据流传输streaming可由客户端在握手期间自由选择底层传输协议。这个设计意味着“传输协议”不是服务器单方面决定的而是由客户端在 SETUP 阶段协商因此切换传输方式需要调整的是客户端的配置而非服务器配置。服务器侧只负责按rtspTransports配置开放相应的监听能力。三种底层传输协议与选型在 mediamtx.yml 的默认配置中三种传输全部开启rtspTransports: [udp, multicast, tcp]传输协议特点适用场景UDP性能最好但客户端需要额外访问服务器上的两个 UDP 端口RTP/RTCP在 NAT / 防火墙环境下常因端口被阻断或重映射而失败同网段、可控网络UDP-multicast数据包只发送一次到固定组播 IP组内所有客户端共享同一份带宽能大幅节省带宽客户端同处一个局域网TCP兼容性最好信令与数据都走 TCP可穿透绝大多数防火墙跨网络、不可控环境最常被推荐很多客户端默认使用 UDP一旦拉流失败第一步就应当显式切换到 TCP。下面给出三大客户端的切换方式。FFmpeg-rtsp_transportFFmpeg 通过-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 传输GStreamerrtspsrc的protocols属性GStreamer 在rtspsrc读取与rtspclientsink推送上通过protocols属性控制gst-launch-1.0 rtspsrc locationrtsp://127.0.0.1:8554/mystream protocolstcp latency0 ! decodebin ! autovideosink可选值注意组播写法与 FFmpeg 不同protocolstcpprotocolsudpprotocolsudp-mcastVLC--rtsp-tcp与 URL 参数VLC 使用命令行参数或 URL 后缀# TCP 传输 vlc --network-caching50 --rtsp-tcp rtsp://localhost:8554/mystream # UDP-multicast 传输在 URL 后追加 ?vlcmulticast vlc --network-caching50 rtsp://localhost:8554/mystream?vlcmulticast提示--network-caching50用于将网络缓存降到 50ms可显著降低观看延迟是 VLC 拉流时的推荐做法。加密读取RTSPS / SRTP / SRTCP当流经过公网传输或涉及敏感画面时应当启用加密。MediaMTX 将 RTSP 体系中的各个子协议整体替换为安全变体RTSP →RTSPSTCP 信令走 TLSRTP →SRTPRTCP →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-flags0 locationrtsps://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效率更高要求网关/防火墙支持 WebSocketRTSP over HTTP更古老的变体在极端环境下也能工作。关键结论MediaMTX自动处理进入服务器的 HTTP 隧道 RTSP 连接无需任何配置这体现为服务端对rtsphttp、rtspws等 URL scheme 的透明接受。而当 MediaMTX 作为客户端去拉取外部 RTSP 服务器的流时只需在paths的source中指定带隧道 scheme 的 URLpaths: mypath: source: rtsphttp://standard-rtsp-url可用的 scheme 组合包括rtsphttp—— RTSP over HTTP 隧道rtspshttp—— RTSPS over HTTPS 隧道rtspws—— RTSP over WebSocketrtspsws—— 加密 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 locationrtsp://127.0.0.1:8554/mystream latency0 ! decodebin ! autovideosinklatency0用于消除缓冲以降低延迟。其余细节与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.ymlpathDefaults: # 将 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 读取端能获得更清晰的轨道信息与更佳的兼容性。小结能力关键要点读取 URLrtsp://localhost:8554/path传输协商握手走 TCP数据流由客户端选择 UDP / multicast / TCP加密RTSPS/SRTP/SRTCP端口 8322需配置rtspEncryption、rtspServerKey、rtspServerCert隧道rtsphttp、rtspshttp、rtspws、rtspsws服务端零配置自动处理推荐客户端FFmpeg、GStreamer、VLC均以 RTSP 为推荐协议编解码范围视频覆盖 AV1~M-JPEG音频覆盖 Opus~LPCM另支持 KLV、MPEG-TS 与任意 RTP 编码从协议机制docs/2-features/26-rtsp-specific-features.md到服务端实现internal/servers/rtsp/server.go、internal/servers/rtsp/session.go再到默认配置mediamtx.ymlRTSP 读取链路在 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创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考