企业官网建设流程全解析

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、RTMP、WebRTC、SRT、HLS、MoQ 等协议间自动转换与路由。本文以官方《Basic usage》文档为骨架，完整讲解"发布一条流 → 再读取这条流"的端到端实操流程：你将学会用 FFmpeg / GStreamer 推送本地视频到 MediaMTX，再用 VLC / GStreamer / FFmpeg 拉流观看或转存，并能根据仓库源码与配置文件理解其中的端口、路径与参数原理，后续自行迁移到任何支持的协议组合。

前置条件

开始之前，请确保：

• 已安装并运行 MediaMTX（安装方式见 安装指南，可直接运行独立二进制或使用 Docker 镜像bluenviron/mediamtx:1）。
• 本机具备 FFmpeg、GStreamer、VLC 三者之一或以上（用于下文演示的推流/拉流命令）。
• 准备一个本地视频文件（下文以file.mp4为例），可以是任何 FFmpeg/GStreamer 可解码的媒体文件。

端口与路径：理解命令背后的地址

官方 架构说明 指出，MediaMTX 会同时暴露多套服务器，让客户端用不同协议发布和读取流。默认配置（mediamtx.yml）中各协议监听地址如下：

以rtsp://localhost:8554/mystream为例，URL 中的8554即rtspAddress的默认值，/mystream则是流的路径（path）名称。路径是 MediaMTX 路由媒体的核心概念：一条路径在同一时刻只允许一个发布者（或一个外部源）提供流，但可被任意数量的读者同时读取；发布到/mystream后，读者即可用任意支持的协议（RTSP、RTMP、HLS、WebRTC、SRT 等）从同一路径读取，协议转换由服务器自动完成。相关源码实现位于 internal/servers/rtsp/server.go（RTSP 服务器启动与地址打印逻辑），路径管理的核心位于 internal/core/path_manager.go 与 internal/core/path.go。

从源码结构看，rtspAddress、rtspTransports等参数在 internal/conf/conf.go 中定义并解析，再注入 RTSP 服务器；进程入口见 main.go（调用core.New启动整套组件）。

第一步：发布流

用 FFmpeg 通过 RTSP 发布

官方 发布文档 支持 Media-over-QUIC、SRT、WebRTC、RTSP、RTMP、HLS、MPEG-TS、RTP 等多种发布协议。这里以 RTSP 为例，将本地 MP4 文件循环推流：

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

各参数含义：

• -re：以原始帧率读取输入，模拟实时推流，避免瞬间推完整个文件。
• -stream_loop -1：无限循环播放输入文件，保证流持续在线。
• -c copy：流拷贝，不做转码，保持原始编码（效率最高）。
• -f rtsp：强制输出格式为 RTSP。
• rtsp://localhost:8554/mystream：目标服务器地址与路径，即发布到路径/mystream。

推流成功后，在 MediaMTX 日志中会看到类似[RTSP] [conn ...] opened的连接记录（详细日志级别配置见 mediamtx.yml 的logLevel）。

用 GStreamer 通过 RTSP 发布

使用 GStreamer 的rtspclientsink完成同样的操作：

gst-launch-1.0 rtspclientsink name=s location=rtsp://localhost:8554/mystream filesrc location=file.mp4 \ ! qtdemux name=d d.video_0 ! queue ! s.sink_0 d.audio_0 ! queue ! s.sink_1

这条管线的思路是：filesrc读取file.mp4→qtdemux解封装出视频轨（d.video_0）与音频轨（d.audio_0）→ 各自经过queue缓冲后分别接到rtspclientsink的sink_0（视频）与sink_1（音频），最终推送到rtsp://localhost:8554/mystream。

RTSP 协议发布时支持的编码范围见 RTSP 客户端文档：视频支持 AV1、VP9、VP8、H265、H264、MPEG-4 Video、MPEG-1/2 Video、M-JPEG；音频支持 Opus、AAC、MP3、AC-3、G726、G722、G711、LPCM；此外还支持 KLV、MPEG-TS 等其它负载。

提示：若发布端先将媒体打包成 MPEG-TS 再发送（表现为服务器只看到一个 "MPEG-TS" 轨），可开启pathDefaults下的rtspDemuxMpegts: true让服务器自动解封装出 H.264、H.265、AAC 等原始轨，从而保证 HLS、WebRTC 等输出正常工作，详见 RTSP 客户端文档。

其他发布方式

除了 RTSP，官方 发布文档 还提供了以下发布路径，本文不再展开，但原理一致——发布者写入某路径，读者即可从该路径读取：

• 用 WebRTC（浏览器页面/publish）、SRT、RTMP、HLS、MPEG-TS、RTP 发布；
• 使用 Raspberry Pi Cameras、通用摄像头 等设备；
• 使用 Web 浏览器、OBS Studio、Python/OpenCV、Golang、Unity 等软件。

第二步：读取流

流发布到/mystream后，即可用任意支持协议读取。官方 读取文档 支持 Media-over-QUIC、SRT、WebRTC、RTSP、RTMP、HLS 等读取协议。这里演示三种 RTSP 读取方式。

用 VLC 读取

vlc --network-caching=50 rtsp://localhost:8554/mystream

--network-caching=50将网络缓存设为 50 ms，可显著降低播放延迟，适合实时监控类场景。RTSP 读取 URL 规则见 RTSP 读取文档，读取方支持的编解码范围与发布方一致。

用 GStreamer 读取

gst-play-1.0 rtsp://localhost:8554/mystream

gst-play-1.0是 GStreamer 自带的简易播放器，会自动选择解码器播放 RTSP 流。

用 FFmpeg 读取并保存

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

该命令将 RTSP 流以流拷贝方式（-c copy，不转码）写入output.mp4文件，适合旁路录制或验证流内容。更多 FFmpeg 读取方式（含 RTMP、SRT、HLS 及增强编码参数-rtmp_enhanced_codecs）见 FFmpeg 读取文档。

验证与排错

完成上述两步后，可以通过以下方式确认链路是否正常：

1. 同时开启两个终端：一个运行推流命令，另一个运行拉流命令；播放画面正常即表示发布/读取链路打通。
2. 观察服务器日志：默认日志级别为info，推送与读取连接、路径创建等事件都会输出到 stdout（见 mediamtx.yml 中logLevel/logDestinations）。
3. 网络无法连通时：
   • 确认 8554 端口未被占用，且防火墙放行 TCP 8554（RTSP 握手与控制）以及 UDP 8000/8001（RTP/RTCP 媒体传输，若使用 UDP transport）；
   • 在 Docker 中运行时需显式映射端口-p 8554:8554，并注意 RTSP 的 UDP transport 在 Docker 网络下可能不工作，官方 安装指南 推荐设置MTX_RTSPTRANSPORTS=tcp或使用--network=host；
   • 修改默认端口后，所有 URL 中的端口需同步调整。

深入：这套链路在服务器内部如何工作

从源码层面看，一次"发布→读取"会经历以下关键环节：

• 监听与握手：RTSP 服务器（internal/servers/rtsp/server.go）在rtspAddress上监听，握手始终基于 TCP；媒体传输可选择 UDP、multicast 或 TCP（对应配置rtspTransports: [udp, multicast, tcp]，见 mediamtx.yml）。
• 路径注册：发布者建立连接后，由路径管理器（internal/core/path_manager.go）将/mystream注册为一条路径；路径内由 internal/core/path.go 维护"单发布者、多读者"的流分发。
• 读者接入：读者通过rtsp://localhost:8554/mystream请求同一路径时，路径直接把正在广播的流分发给读者。若读者使用 HLS、WebRTC 等其它协议访问同一路径，服务器会自动完成协议转封装（remuxing），这正是 架构文档 所述"媒体路由器"的核心能力。
• 配置驱动：上述所有地址、传输方式、认证等参数均来自配置（mediamtx.yml），可通过环境变量（MTX_前缀）、配置文件热加载或 Control API 修改，详见 配置文档。

总结

本文完成了 MediaMTX 最基础也最核心的一次实践闭环：发布（FFmpeg/GStreamer → RTSP）→ 读取（VLC/GStreamer/FFmpeg ← RTSP）。掌握这一流程后，你可以把其中的协议任意替换——比如用 OBS 通过 RTMP 推流，再用浏览器通过 HLS/WebRTC 观看；同一路径可被多种协议同时访问，服务器自动完成转换。官方 发布 与 读取 文档列出了全部支持的协议与客户端软件，可作为下一步深入实践的索引。

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