MediaMTX 接入 SRT 摄像头与远程服务器的完整指南【免费下载链接】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原 mediamtx中将 SRT 协议摄像头、编码器或远程 SRT 服务器作为静态推流源接入通过路径source参数配置即可完成拉流、转发布与录制。读完本文你将掌握 SRT 支持的编解码器范围、srt://源 URL 的完整语法含streamid、pkt_size、modelistener、自定义与标准两种 stream ID 规范以及基于源码层面的底层实现原理与排障思路。一、SRT 协议与静态源接入场景SRTSecure Reliable Transport是一种面向实时媒体传输的协议在 UDP 之上提供加密、数据完整性校验与丢包重传机制通常用于承载以 MPEG-TS 封装的媒体流。在 MediaMTX 中SRT 既可以作为推流/拉流协议对应服务端能力也可以作为静态源static source协议——即 MediaMTX 主动去连接一台 SRT 摄像头、SRT 服务器或处于 listening 模式的 SRT 客户端。“SRT cameras and servers”文档所讲的核心场景正是后者当远端设备作为 SRT listener 等待接入时在路径配置的source参数中填入对应的srt://URLMediaMTX 就会作为 caller调用方主动发起连接并持续拉取该路流。该场景的典型应用包括接入仅支持 SRT 输出的网络摄像头或编码器如部分广电级设备对接另一台 SRT 服务器发布的频道实现跨节点拉流中转接入以modelistener方式运行的 SRT 客户端如 FFmpeg、GStreamer由 MediaMTX 反向连接取流。二、支持的编解码器无论是以 SRT 作为静态源拉流还是客户端通过 SRT 向 MediaMTX 推流编解码器支持范围是一致的见下表分类支持的编码格式视频H265、H264、MPEG-4 VideoH263、Xvid、MPEG-1/2 Video音频Opus、MPEG-4 AudioAAC、MPEG-1/2 AudioMP3、AC-3其他KLV这意味着接入 SRT 源后媒体流经由 MediaMTX 内置的 MPEG-TS 解复用链路完成解码与轨道识别再按需转封装为 RTSP、RTMP、WebRTC、HLS 等任意输出协议无需重新编码。三、配置一个 SRT 静态源将 SRT 流接入 MediaMTX 只需在配置文件mediamtx.yml的paths段中为一个路径指定srt://形式的sourcepaths: proxied: source: srt://host:port?streamidstreamid各组成部分的含义host远端 SRT 服务器/摄像头/客户端的 IP 或主机名port远端 SRT 监听端口streamid告诉远端“你准备做什么”的流标识见下文 stream ID 语法一节。保存并重启或热加载后MediaMTX 会立即作为 caller 连接该地址。连接成功后该路径即变为可用其他协议的客户端即可通过/proxied路径读取这路流。从源码结构看该功能由 internal/staticsources/srt/source.go 中的Source实现它以srt.DialWithContext主动拨号见 source.go 第 126 行随后用mpegts.EnhancedReader读取并解析 MPEG-TS 流最终调用SetReady将媒体轨道注册到路径管理器使路径对外可见。3.1 URL 校验规则在配置加载阶段internal/conf/path.go 会针对srt://前缀的source调用validateURL做合法性检查见 path.go 第 570-574 行。其中值得注意的约束有URL 必须同时具备 scheme 与 host否则报 “is not a valid URL”若在 URL 中同时携带了用户名与密码则二者必须同时提供如果你的路径名使用正则表达式~前缀且指定了静态源则必须同时设置sourceOnDemand: true否则配置校验会直接报错见 path.go 第 796-805 行——这是正则路径与静态源组合时的硬性要求。四、深入理解sourceURL 的完整语法4.1 自定义 stream ID 语法MediaMTX 默认SRT 协议的streamid是一个字符串用于向远端宣告“调用方将要执行的动作推流 publish 或拉流 read、目标路径以及凭据”。MediaMTX 默认支持自定义语法格式为action:pathname[:query]或携带凭据的扩展形式action:pathname:user:pass[:query]其中action只能是publish或readpathname为目标路径名user/pass为认证凭据末尾可选的query是携带附加信息的令牌。该解析逻辑实现在 internal/servers/srt/streamid.go 的unmarshal方法中见 streamid.go 第 62-96 行且会兼容性地剥离客户端可能附加的#feedbackplay后缀。因此当远端 SRT 服务器或支持自定义语法的客户端监听在 8890 端口时可以在路径中这样配置paths: proxied: source: srt://192.168.1.100:8890?streamidpublish:mystreampkt_size1316上面的streamidpublish:mystream告诉远端“MediaMTX 将读取你发布的名为mystream的频道”pkt_size1316则是推荐的 UDP 包尺寸——1316 恰好是 7 个 MPEG-TS 包188 字节的大小是 SRT 传输 MPEG-TS 时的常用取值。4.2 标准 stream ID 语法Haivision Access Control部分 SRT 硬件设备强制使用 SRT 协议作者提出的标准语法其格式以#!::开头键值对以逗号分隔srt://localhost:8890?streamid#!::mpublish,rmypath,umyuser,smypasspkt_size1316各键的含义详见 docs/2-features/24-srt-specific-features.md键含义m动作publish或requestrequest 对应读取r目标路径名u用户名s密码从源码看streamid.go 第 26-61 行 会对以#!::开头的 stream ID 走标准语法解析分支把mrequest映射为读取模式、mpublish映射为推流模式对h主机名、t类型等键则读取后忽略。也就是说MediaMTX 的静态源同样可以直接使用标准语法去对接只认标准格式的硬件设备。五、modelistener模式让远端充当 listener文档中特别强调上述静态源接入方式适用于远端处于 listening 模式即在 URL 中追加modelistener的服务器、摄像头或客户端。SRT 连接与 TCP 不同其“谁主动拨号”与“谁是被接入方”可以通过mode参数灵活互换caller默认主动发起连接的一方listener等待对方接入的一方。因此将modelistener追加到 URL 的是远端设备例如用 FFmpeg 起一个 listener 等待 MediaMTX 来连。此时 URL 语义为远端告诉 MediaMTX——“我会在指定地址以 listener 方式等待你作为 caller 来取流”。一个完整的分工示例远端 FFmpeg 以 listener 模式等待发布 MPEG-TS 到 SRTffmpeg -re -stream_loop -1 -i file.mp4 -c copy -f mpegts srt://0.0.0.0:8890?modelistenerstreamidpublish:mystreampkt_size1316MediaMTX 侧配置静态源路径作为 caller 主动拉取paths: proxied: source: srt://192.168.1.100:8890?streamidpublish:mystreampkt_size1316连接建立后MediaMTX 的/proxied路径立即对外可用任意协议客户端均可读取。这种“MediaMTX 作为 caller、远端作为 listener”的组合尤其适合远端设备无法被直接访问如位于内网、NAT 之后的场景——由 MediaMTX 主动连出即可穿透访问。六、SRT 加密与认证配置如果远端 SRT 流启用了加密 passphrase或你需要对读取/推流做凭据认证可以在路径配置中叠加以下参数均可在 mediamtx.yml 中查看完整注释参数作用位置srtReadPassphrase从本路径读取流时要求客户端提供的 SRT 加密口令路径级srtPublishPassphrase客户端向本路径推流时必须提供的 SRT 加密口令路径级关于 passphrase 的约束配置校验要求其长度介于 10 到 79 个字符之间见 path.go 第 57-65 行 的checkSRTPassphrase这是 SRT 协议本身的限制。同时 path.go 第 464-466 行 规定srtPublishPassphrase只能在source: publisher即允许客户端直接推流的路径上使用用于静态源的路径则不能配置该参数。在连接建立阶段internal/servers/srt/conn.go 的srtCheckPassphrase见 conn.go 第 27-42 行会检查若路径要求 passphrase 而客户端连接未加密则直接拒绝若已加密但口令错误同样拒绝并断开。认证失败时连接会以REJ_PEER拒绝码被 SRT 层关闭。如果接入的是标准语法设备认证信息也可以直接编码进streamid的u、s字段由 conn.go 第 137-162 行 传入路径管理器的访问请求进行鉴权。七、底层实现原理源码解读为了帮助排查问题与理解行为这里从源码层面梳理 SRT 静态源的完整生命周期1. 连接建立。internal/staticsources/srt/source.go 的Run方法先用srt.DefaultConfig()创建配置通过conf.UnmarshalURL解析带查询参数的srt://URL因此pkt_size、streamid等查询参数都会在此时生效校验后调用srt.DialWithContext拨号。2. 读取与解封装。连接建立后使用mpegts.EnhancedReader读取字节流见 source.go 第 162-168 行随后mpegts.ToStream将 MPEG-TS 解复用为媒体轨道列表解码错误会经由errordumper以日志形式上报而不是中断整条流。这也解释了为何 SRT 静态源仅支持以 MPEG-TS 承载的编码格式。3. 就绪与对外发布。轨道解析完成后调用SetReady向路径管理器注册见 source.go 第 194-201 行此时路径对外可见读取者可以接入。4. 读取超时保护。每次读取前都会设置SetReadDeadline默认readTimeout若远端长时间无数据连接会被判定为超时并重连避免路径长期挂在死连接上。5. 服务端侧连接。若远端是 SRT 服务器、MediaMTX 以streamidpublish:...接入则 MediaMTX 是读取者见 conn.go 第 264-351 行 的runRead若远端是 listener 客户端MediaMTX 则是读取者或发布者取决于 stream ID 中的动作。动作与路径由 internal/servers/srt/streamid.go 解析鉴权通过后连接才会被Accept。6. 统计与可观测性。SRT 连接会持续采集大量协议统计RTT、丢包率、重传数、收发速率、拥塞窗口等可通过 MediaMTX 的 API 与指标接口查询用于判断弱网环境下拉流质量。八、端到端验证FFmpeg MediaMTX 实战以下用 FFmpeg 作为远端 listener完整演示一次 SRT 静态源接入FFmpeg 相关命令可参考 docs/3-publish/17-ffmpeg.md 中的 SRT 客户端章节。第 1 步启动远端 FFmpeg listener模拟摄像头/编码器ffmpeg -re -stream_loop -1 -i file.mp4 -c copy -f mpegts srt://0.0.0.0:8890?modelistenerstreamidpublish:streampkt_size1316第 2 步配置 MediaMTX 静态源paths: proxied: source: srt://127.0.0.1:8890?streamidpublish:streampkt_size1316第 3 步用任意 SRT 客户端读取验证ffmpeg -i srt://localhost:8890?streamidread:proxied -f null -读取语法详见 docs/4-read/02-srt.md若使用标准语法可参考上文 4.2 节。九、常见问题与排查要点配置校验报 “is not a valid URL”检查srt://源 URL 是否同时具备协议前缀与主机端口且不要遗漏?streamid。正则路径 静态源报错为使用了~正则表达式路径名的静态源补充sourceOnDemand: true。连接建立后立即断开确认远端确实以modelistener运行并核对 stream ID 中动作publish/request与远端预期是否一致若启用了加密检查 passphrase 是否满足 10~79 字符且与远端一致。能连接但看不到流SRT 源必须是 MPEG-TS 封装且编码格式需落在本文第二节的编解码器支持表内不支持的编码会在解复用阶段报解码错误日志中可见decode error。需要先决条件的路径参数若在sourceURL 中携带了用户名密码二者必须成对出现path.go 的validateURL。更完整的 SRT 特性如推流/拉流共享的标准语法细节可继续阅读 docs/2-features/24-srt-specific-features.mdSRT 服务器全局开关与监听地址默认:8890参数srt与srtAddress可在 mediamtx.yml 的 “Global settings - SRT server” 段落查看与调整。【免费下载链接】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 接入 SRT 摄像头与远程服务器的完整指南
MediaMTX 接入 SRT 摄像头与远程服务器的完整指南【免费下载链接】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原 mediamtx中将 SRT 协议摄像头、编码器或远程 SRT 服务器作为静态推流源接入通过路径source参数配置即可完成拉流、转发布与录制。读完本文你将掌握 SRT 支持的编解码器范围、srt://源 URL 的完整语法含streamid、pkt_size、modelistener、自定义与标准两种 stream ID 规范以及基于源码层面的底层实现原理与排障思路。一、SRT 协议与静态源接入场景SRTSecure Reliable Transport是一种面向实时媒体传输的协议在 UDP 之上提供加密、数据完整性校验与丢包重传机制通常用于承载以 MPEG-TS 封装的媒体流。在 MediaMTX 中SRT 既可以作为推流/拉流协议对应服务端能力也可以作为静态源static source协议——即 MediaMTX 主动去连接一台 SRT 摄像头、SRT 服务器或处于 listening 模式的 SRT 客户端。“SRT cameras and servers”文档所讲的核心场景正是后者当远端设备作为 SRT listener 等待接入时在路径配置的source参数中填入对应的srt://URLMediaMTX 就会作为 caller调用方主动发起连接并持续拉取该路流。该场景的典型应用包括接入仅支持 SRT 输出的网络摄像头或编码器如部分广电级设备对接另一台 SRT 服务器发布的频道实现跨节点拉流中转接入以modelistener方式运行的 SRT 客户端如 FFmpeg、GStreamer由 MediaMTX 反向连接取流。二、支持的编解码器无论是以 SRT 作为静态源拉流还是客户端通过 SRT 向 MediaMTX 推流编解码器支持范围是一致的见下表分类支持的编码格式视频H265、H264、MPEG-4 VideoH263、Xvid、MPEG-1/2 Video音频Opus、MPEG-4 AudioAAC、MPEG-1/2 AudioMP3、AC-3其他KLV这意味着接入 SRT 源后媒体流经由 MediaMTX 内置的 MPEG-TS 解复用链路完成解码与轨道识别再按需转封装为 RTSP、RTMP、WebRTC、HLS 等任意输出协议无需重新编码。三、配置一个 SRT 静态源将 SRT 流接入 MediaMTX 只需在配置文件mediamtx.yml的paths段中为一个路径指定srt://形式的sourcepaths: proxied: source: srt://host:port?streamidstreamid各组成部分的含义host远端 SRT 服务器/摄像头/客户端的 IP 或主机名port远端 SRT 监听端口streamid告诉远端“你准备做什么”的流标识见下文 stream ID 语法一节。保存并重启或热加载后MediaMTX 会立即作为 caller 连接该地址。连接成功后该路径即变为可用其他协议的客户端即可通过/proxied路径读取这路流。从源码结构看该功能由 internal/staticsources/srt/source.go 中的Source实现它以srt.DialWithContext主动拨号见 source.go 第 126 行随后用mpegts.EnhancedReader读取并解析 MPEG-TS 流最终调用SetReady将媒体轨道注册到路径管理器使路径对外可见。3.1 URL 校验规则在配置加载阶段internal/conf/path.go 会针对srt://前缀的source调用validateURL做合法性检查见 path.go 第 570-574 行。其中值得注意的约束有URL 必须同时具备 scheme 与 host否则报 “is not a valid URL”若在 URL 中同时携带了用户名与密码则二者必须同时提供如果你的路径名使用正则表达式~前缀且指定了静态源则必须同时设置sourceOnDemand: true否则配置校验会直接报错见 path.go 第 796-805 行——这是正则路径与静态源组合时的硬性要求。四、深入理解sourceURL 的完整语法4.1 自定义 stream ID 语法MediaMTX 默认SRT 协议的streamid是一个字符串用于向远端宣告“调用方将要执行的动作推流 publish 或拉流 read、目标路径以及凭据”。MediaMTX 默认支持自定义语法格式为action:pathname[:query]或携带凭据的扩展形式action:pathname:user:pass[:query]其中action只能是publish或readpathname为目标路径名user/pass为认证凭据末尾可选的query是携带附加信息的令牌。该解析逻辑实现在 internal/servers/srt/streamid.go 的unmarshal方法中见 streamid.go 第 62-96 行且会兼容性地剥离客户端可能附加的#feedbackplay后缀。因此当远端 SRT 服务器或支持自定义语法的客户端监听在 8890 端口时可以在路径中这样配置paths: proxied: source: srt://192.168.1.100:8890?streamidpublish:mystreampkt_size1316上面的streamidpublish:mystream告诉远端“MediaMTX 将读取你发布的名为mystream的频道”pkt_size1316则是推荐的 UDP 包尺寸——1316 恰好是 7 个 MPEG-TS 包188 字节的大小是 SRT 传输 MPEG-TS 时的常用取值。4.2 标准 stream ID 语法Haivision Access Control部分 SRT 硬件设备强制使用 SRT 协议作者提出的标准语法其格式以#!::开头键值对以逗号分隔srt://localhost:8890?streamid#!::mpublish,rmypath,umyuser,smypasspkt_size1316各键的含义详见 docs/2-features/24-srt-specific-features.md键含义m动作publish或requestrequest 对应读取r目标路径名u用户名s密码从源码看streamid.go 第 26-61 行 会对以#!::开头的 stream ID 走标准语法解析分支把mrequest映射为读取模式、mpublish映射为推流模式对h主机名、t类型等键则读取后忽略。也就是说MediaMTX 的静态源同样可以直接使用标准语法去对接只认标准格式的硬件设备。五、modelistener模式让远端充当 listener文档中特别强调上述静态源接入方式适用于远端处于 listening 模式即在 URL 中追加modelistener的服务器、摄像头或客户端。SRT 连接与 TCP 不同其“谁主动拨号”与“谁是被接入方”可以通过mode参数灵活互换caller默认主动发起连接的一方listener等待对方接入的一方。因此将modelistener追加到 URL 的是远端设备例如用 FFmpeg 起一个 listener 等待 MediaMTX 来连。此时 URL 语义为远端告诉 MediaMTX——“我会在指定地址以 listener 方式等待你作为 caller 来取流”。一个完整的分工示例远端 FFmpeg 以 listener 模式等待发布 MPEG-TS 到 SRTffmpeg -re -stream_loop -1 -i file.mp4 -c copy -f mpegts srt://0.0.0.0:8890?modelistenerstreamidpublish:mystreampkt_size1316MediaMTX 侧配置静态源路径作为 caller 主动拉取paths: proxied: source: srt://192.168.1.100:8890?streamidpublish:mystreampkt_size1316连接建立后MediaMTX 的/proxied路径立即对外可用任意协议客户端均可读取。这种“MediaMTX 作为 caller、远端作为 listener”的组合尤其适合远端设备无法被直接访问如位于内网、NAT 之后的场景——由 MediaMTX 主动连出即可穿透访问。六、SRT 加密与认证配置如果远端 SRT 流启用了加密 passphrase或你需要对读取/推流做凭据认证可以在路径配置中叠加以下参数均可在 mediamtx.yml 中查看完整注释参数作用位置srtReadPassphrase从本路径读取流时要求客户端提供的 SRT 加密口令路径级srtPublishPassphrase客户端向本路径推流时必须提供的 SRT 加密口令路径级关于 passphrase 的约束配置校验要求其长度介于 10 到 79 个字符之间见 path.go 第 57-65 行 的checkSRTPassphrase这是 SRT 协议本身的限制。同时 path.go 第 464-466 行 规定srtPublishPassphrase只能在source: publisher即允许客户端直接推流的路径上使用用于静态源的路径则不能配置该参数。在连接建立阶段internal/servers/srt/conn.go 的srtCheckPassphrase见 conn.go 第 27-42 行会检查若路径要求 passphrase 而客户端连接未加密则直接拒绝若已加密但口令错误同样拒绝并断开。认证失败时连接会以REJ_PEER拒绝码被 SRT 层关闭。如果接入的是标准语法设备认证信息也可以直接编码进streamid的u、s字段由 conn.go 第 137-162 行 传入路径管理器的访问请求进行鉴权。七、底层实现原理源码解读为了帮助排查问题与理解行为这里从源码层面梳理 SRT 静态源的完整生命周期1. 连接建立。internal/staticsources/srt/source.go 的Run方法先用srt.DefaultConfig()创建配置通过conf.UnmarshalURL解析带查询参数的srt://URL因此pkt_size、streamid等查询参数都会在此时生效校验后调用srt.DialWithContext拨号。2. 读取与解封装。连接建立后使用mpegts.EnhancedReader读取字节流见 source.go 第 162-168 行随后mpegts.ToStream将 MPEG-TS 解复用为媒体轨道列表解码错误会经由errordumper以日志形式上报而不是中断整条流。这也解释了为何 SRT 静态源仅支持以 MPEG-TS 承载的编码格式。3. 就绪与对外发布。轨道解析完成后调用SetReady向路径管理器注册见 source.go 第 194-201 行此时路径对外可见读取者可以接入。4. 读取超时保护。每次读取前都会设置SetReadDeadline默认readTimeout若远端长时间无数据连接会被判定为超时并重连避免路径长期挂在死连接上。5. 服务端侧连接。若远端是 SRT 服务器、MediaMTX 以streamidpublish:...接入则 MediaMTX 是读取者见 conn.go 第 264-351 行 的runRead若远端是 listener 客户端MediaMTX 则是读取者或发布者取决于 stream ID 中的动作。动作与路径由 internal/servers/srt/streamid.go 解析鉴权通过后连接才会被Accept。6. 统计与可观测性。SRT 连接会持续采集大量协议统计RTT、丢包率、重传数、收发速率、拥塞窗口等可通过 MediaMTX 的 API 与指标接口查询用于判断弱网环境下拉流质量。八、端到端验证FFmpeg MediaMTX 实战以下用 FFmpeg 作为远端 listener完整演示一次 SRT 静态源接入FFmpeg 相关命令可参考 docs/3-publish/17-ffmpeg.md 中的 SRT 客户端章节。第 1 步启动远端 FFmpeg listener模拟摄像头/编码器ffmpeg -re -stream_loop -1 -i file.mp4 -c copy -f mpegts srt://0.0.0.0:8890?modelistenerstreamidpublish:streampkt_size1316第 2 步配置 MediaMTX 静态源paths: proxied: source: srt://127.0.0.1:8890?streamidpublish:streampkt_size1316第 3 步用任意 SRT 客户端读取验证ffmpeg -i srt://localhost:8890?streamidread:proxied -f null -读取语法详见 docs/4-read/02-srt.md若使用标准语法可参考上文 4.2 节。九、常见问题与排查要点配置校验报 “is not a valid URL”检查srt://源 URL 是否同时具备协议前缀与主机端口且不要遗漏?streamid。正则路径 静态源报错为使用了~正则表达式路径名的静态源补充sourceOnDemand: true。连接建立后立即断开确认远端确实以modelistener运行并核对 stream ID 中动作publish/request与远端预期是否一致若启用了加密检查 passphrase 是否满足 10~79 字符且与远端一致。能连接但看不到流SRT 源必须是 MPEG-TS 封装且编码格式需落在本文第二节的编解码器支持表内不支持的编码会在解复用阶段报解码错误日志中可见decode error。需要先决条件的路径参数若在sourceURL 中携带了用户名密码二者必须成对出现path.go 的validateURL。更完整的 SRT 特性如推流/拉流共享的标准语法细节可继续阅读 docs/2-features/24-srt-specific-features.mdSRT 服务器全局开关与监听地址默认:8890参数srt与srtAddress可在 mediamtx.yml 的 “Global settings - SRT server” 段落查看与调整。【免费下载链接】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），仅供参考