MediaMTX SRT 推流客户端实战publish URL、Stream ID 语法与 FFmpeg/GStreamer 接入【免费下载链接】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/mediamtxSRTSecure Reliable Transport是基于 UDP 的实时音视频传输协议内置 AES 加密、数据完整性与丢包重传机制常用于跨网络尤其是弱网环境下以 MPEG-TS 封装传输直播流。本文以 MediaMTX 仓库文档 docs/3-publish/03-srt-clients.md 为主线完整讲解如何使用 SRT 客户端向 MediaMTX 推流从 URL 构造、自定义/标准两种 Stream ID 语法到 FFmpeg 与 GStreamer 的可运行命令行示例并深入 SRT 服务端源码internal/servers/srt/说明推流链路、passphrase 校验与配置项的底层原理。读完本文你可以直接向 MediaMTX 推送一路 H264/H265 AAC/Opus 的直播流并把它读取到/mystream路径下供其他协议消费。SRT 推流与 MediaMTX协议定位与适用场景在 MediaMTX 中SRT 是一个双向协议既能用于推流publish也能用于拉流read。本文聚焦推流侧拉流侧的使用方式见 SRT 拉流客户端指南。SRT 相比 RTSP/RTMP 的核心差异在于加密可选 AES 加密通过 passphrase 协商传输内容不裸露完整性数据包带校验损坏的包会被丢弃或触发重传重传机制基于 ACK/NAK 的丢包重传与乱序重排适合高延迟、高丢包的公网链路承载格式SRT 通常用来传输用 MPEG-TS 编码后的流。在 MediaMTX 中SRT 推流的载荷正是 MPEG-TS。支持的编解码格式MediaMTX 的 SRT 服务端对推流内容有明确的编解码支持范围官方文档给出的支持矩阵如下supported codecsvideoH265, H264, MPEG-4 Video (H263, Xvid), MPEG-1/2 VideoaudioOpus, MPEG-4 Audio (AAC), MPEG-1/2 Audio (MP3), AC-3otherKLV也就是说推流时视频建议选择 H265 或 H264编码效率与兼容性最好音频选择 Opus 或 AACMP3、AC-3、MPEG-1/2 Video 等老式格式也在支持之列KLV 元数据可作为附带轨。推流 URL 与自定义 Stream ID 语法要向 MediaMTX 用 SRT 推流URL 形式为srt://localhost:8890?streamidpublish:mystreampkt_size1316拆解各段含义URL 片段含义srt://协议前缀SRT 默认走 UDPlocalhost:8890MediaMTX 的 SRT 监听地址默认端口 8890由全局配置srtAddress决定streamidpublish:mystream自定义 Stream IDpublish表示推流动作mystream是要发布的路径名pkt_size1316UDP 数据包大小1316 188 × 7即 7 个 MPEG-TS 包该值需与对端协商一致其中mystream可以替换成任意合法路径名。推流成功建立后流会出现在路径/mystream上其他协议RTSP、RTMP、HLS、WebRTC 等的读者即可按该路径名拉取。自定义 Stream ID 的完整格式上述publish:mystream是自定义语法的最简形式。从服务端源码 internal/servers/srt/streamid.go 可以看到它支持两种结构action:pathname[:query] action:pathname:user:pass[:query]即actionpublish推流或read拉流pathname路径名user/pass可选的认证凭据与 MediaMTX 的认证系统对接对应源码中的Credentials{User, Pass}字段query可选的附加信息会透传给认证、hooks 等下游模块。因此带认证的推流 URL 可以写作srt://localhost:8890?streamidpublish:mystream:myuser:mypasspkt_size1316解析逻辑对原始串还有一处细节末尾的#feedbackplay后缀会被自动剥离strings.TrimSuffix这是为了兼容某些 SRT 客户端附加的标记。标准 Stream ID 语法除了上述自定义语法MediaMTX 还支持 SRT 协议作者Haivision提出的标准 Stream ID 语法Access Control 规范该语法被部分硬件设备强制要求使用。标准语法以#!::开头srt://localhost:8890?streamid#!::mpublish,rmypath,umyuser,smypasspkt_size1316各键的含义键含义m动作publish推流或request拉流r路径名u用户名可选s密码可选从源码看服务端正是通过判断 Stream ID 是否以#!::前缀开头来分流解析逻辑streamid.go标准语法按逗号分隔键值对识别u、r、s、t、m等键其中mrequest映射为拉流模式、mpublish映射为推流模式其余键值会被忽略而h、t等键当前不做处理。这与文档 SRT 特有功能 中的说明一致推流与拉流两侧共用同一套解析。SRT 服务端监听、解析与推流接入链路为了让你理解 URL 中的每个参数最终走向哪里这里结合源码说明推流的完整链路。服务端初始化与监听全局配置中SRT 服务由两个参数控制mediamtx.yml 的Global settings - SRT server一节对应结构体定义在 internal/conf/conf.go# Enable the SRT server, which allows to publish and read streams with the SRT protocol. srt: true # Address of the UDP/SRT listener. srtAddress: :8890srt: true启用 SRT 服务默认为truesrtAddress: :8890UDP/SRT 监听地址默认监听本机 8890 端口。服务端启动时internal/servers/srt/server.go 的Initialize会基于srtAddress调用srt.Listen创建监听器并把PayloadSize设为srtMaxPayloadSize(UDPMaxPayloadSize)。这个函数揭示了pkt_size1316的来源func srtMaxPayloadSize(u int) int { return ((u - 16) / 188) * 188 // 16 SRT header, 188 MPEG-TS packet }即SRT 头占 16 字节剩余载荷按 188 字节的 MPEG-TS 包对齐取整。客户端与服务器约定pkt_size1316正是为了与服务端的 UDP 载荷上限UDPMaxPayloadSize默认 1316保持一致避免分片。从 Stream ID 到路径的推流流程每个新连接由 internal/servers/srt/conn.go 处理核心流程为读取连接请求中的StreamId调用streamID.unmarshal()解析出动作、路径、凭据与查询参数若动作是publish则调用FindPathConf做路径访问控制鉴权、权限校验校验失败会以REJ_PEER拒绝连接校验srtPublishPassphrase若配置了 SRT 加密口令见下文接受连接后把 SRT 流接入mpegts.EnhancedReader通过mpegts.ToStream解析出媒体轨并注册为路径的发布者AddPublisher之后循环读取 MPEG-TS 包持续供给流媒体管道。从源码结构可以推断SRT 推流在服务端被当作MPEG-TS over UDP/SRT来消费因此客户端侧必须用mpegtsmuxGStreamer或-f mpegtsFFmpeg完成 MPEG-TS 封装后再塞进 SRT。推流侧 SRT 加密口令srtPublishPassphrase如果你希望推流内容被 AES 加密可在路径配置中设置srtPublishPassphrase对应 internal/conf/path.go 中的SRTPublishPassphrase字段paths: mystream: source: publisher srtPublishPassphrase: your-secret-10chars-min配置校验要求口令长度在1079 个字符之间checkSRTPassphrase实现于 internal/conf/path.go。握手时服务端会检查连接是否已加密若客户端未提供口令或口令错误则拒绝连接见 conn.go 的srtCheckPassphrase。对应的读取侧口令是srtReadPassphrase。注意passphrase 与 Stream ID 中的user:pass是两回事——前者用于 SRT 链路本身的加密后者用于 MediaMTX 的应用层认证。使用 FFmpeg 推流FFmpeg 是最常用的 SRT 推流工具。使用 FFmpeg 向 MediaMTX 推流时把它当作 SRT 客户端即可完整示例见 FFmpeg 推流文档ffmpeg -re -stream_loop -1 -i file.mp4 -c copy -f mpegts srt://localhost:8890?streamidpublish:streampkt_size1316要点说明-re按原速读取输入避免突发推流打爆带宽-stream_loop -1循环播放输入文件-c copy直接复制编码不转码。注意前提是输入文件的编解码格式在本文开头的支持矩阵内-f mpegts必须把输出封装为 MPEG-TS因为 MediaMTX 的 SRT 服务端接收的就是 MPEG-TS 流URL 用单引号包裹避免被 shell 解释为后台执行符streamidpublish:stream中的stream是推流路径名可自行更换。推流启动后即可通过srt://localhost:8890?streamidread:stream或其他协议如 RTSP、HLS读取该流。使用 GStreamer 推流GStreamer 同样可以作为 SRT 客户端推流示例见 GStreamer 推流文档核心是用mpegtsmux做 MPEG-TS 复用、用srtsink作为 SRT 发送端gst-launch-1.0 -v mpegtsmux namemux ! srtsink urisrt://localhost:8890?streamidpublish:mystreampkt_size1316 \ videotestsrc ! video/x-raw,width1280,height720,formatI420 ! x264enc speed-presetultrafast bitrate3000 key-int-max60 ! video/x-h264,profilehigh ! mux. \ audiotestsrc ! audioconvert ! avenc_aac ! mux.命令解读视频源用videotestsrc测试图案经x264enc编码为 H264speed-presetultrafast与bitrate3000控制编码速度与码率key-int-max60设置关键帧间隔音频源用audiotestsrc经avenc_aac编码为 AAC两路轨汇入mpegtsmux复用成 MPEG-TSsrtsink以uri参数指定目标地址与 Stream ID把 TS 流通过 SRT 发送给 MediaMTX。若想用摄像头/文件等真实源替换videotestsrc只需把输入管道换成对应的filesrc、v4l2src等元素编码与复用部分保持不变。其他可用的推流客户端仓库文档将 OBS Studio 也列为可用的 SRT 推流客户端之一。需要说明的是OBS Studio 的专用推流文档当前主要覆盖 RTMP含 RTMPS 加密与 WebRTC/WHIP 两种方式如果你打算用 OBS 走 SRT 推流可通过其自定义输出/FFmpeg 输出能力配合上述 URL 规则自行配置但具体的 OBS 界面操作路径不属于本文档覆盖范围请以 OBS 官方文档为准。此外任意支持 SRT 协议的推流软件如 ffmpeg 系工具、硬件编码器等都可使用同一套 URL 规则接入关键是满足两点载荷必须是 MPEG-TS且Stream ID 语法正确自定义或标准语法二选一。进阶监听模式推流与拉流对照客户端以监听模式推流modelistener默认情况下SRT 推流客户端以呼叫方caller身份主动连接 MediaMTX 的 8890 端口。如果你的客户端需要以监听模式工作——即由 MediaMTX 反向发起连接——可以在 URL 中附加modelistener参数srt://localhost:8890?streamidpublish:mystreammodelistenerpkt_size1316这种模式适用于无法主动外联如位于 NAT 后、防火墙限制出方向的推流端客户端先在本机监听MediaMTX 侧将其作为srt://host:port?streamid...形式的静态源source拉取。其配置入口在路径的source字段见 mediamtx.yml 中的说明# * srt://host:port?streamidstreamid - the stream is pulled from another SRT server / camera与拉流 URL 的对照推流与拉流共用同一个 Stream ID 解析器区别只在动作关键字推流用publish拉流用read。作为对照从 MediaMTX 用 SRT 读取一路流的 URL 为详见 SRT 拉流客户端指南srt://localhost:8890?streamidread:mystream两条 URL 只有publish/read一处不同这正体现了 Stream ID 把动作 路径 凭据压缩进单一字符串的设计意图。常见问题排查推流被拒连接被拒绝/立即断开优先检查 Stream ID 语法publish:路径名中动作关键字拼写、路径名合法性不能包含非法字符是高频原因服务端解析失败会以REJ_PEER拒绝conn.go 中的unmarshal错误路径画面花屏/无法解析确认推流内容确实封装为 MPEG-TSFFmpeg 加-f mpegtsGStreamer 加mpegtsmux且编解码格式在支持矩阵内口令错误被拒若配置了srtPublishPassphrase客户端必须启用 SRT 加密并提供相同口令且口令长度须在 1079 字符之间包大小不匹配pkt_size建议保持 1316与服务器UDPMaxPayloadSize默认值对齐推流成功但拉不到确认推流动作完成后路径名与后续读取方使用的路径名完全一致/mystream。参考资源SRT 推流客户端文档本文依据SRT 特有功能标准 Stream ID 语法SRT 拉流客户端指南SRT 服务端实现、连接与推流处理、Stream ID 解析SRT 全局配置与路径配置项srt、srtAddress、srtPublishPassphrase、srtReadPassphraseFFmpeg 推流文档、GStreamer 推流文档、OBS Studio 推流文档【免费下载链接】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 推流客户端实战：publish URL、Stream ID 语法与 FFmpeg/GStreamer 接入
MediaMTX SRT 推流客户端实战publish URL、Stream ID 语法与 FFmpeg/GStreamer 接入【免费下载链接】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/mediamtxSRTSecure Reliable Transport是基于 UDP 的实时音视频传输协议内置 AES 加密、数据完整性与丢包重传机制常用于跨网络尤其是弱网环境下以 MPEG-TS 封装传输直播流。本文以 MediaMTX 仓库文档 docs/3-publish/03-srt-clients.md 为主线完整讲解如何使用 SRT 客户端向 MediaMTX 推流从 URL 构造、自定义/标准两种 Stream ID 语法到 FFmpeg 与 GStreamer 的可运行命令行示例并深入 SRT 服务端源码internal/servers/srt/说明推流链路、passphrase 校验与配置项的底层原理。读完本文你可以直接向 MediaMTX 推送一路 H264/H265 AAC/Opus 的直播流并把它读取到/mystream路径下供其他协议消费。SRT 推流与 MediaMTX协议定位与适用场景在 MediaMTX 中SRT 是一个双向协议既能用于推流publish也能用于拉流read。本文聚焦推流侧拉流侧的使用方式见 SRT 拉流客户端指南。SRT 相比 RTSP/RTMP 的核心差异在于加密可选 AES 加密通过 passphrase 协商传输内容不裸露完整性数据包带校验损坏的包会被丢弃或触发重传重传机制基于 ACK/NAK 的丢包重传与乱序重排适合高延迟、高丢包的公网链路承载格式SRT 通常用来传输用 MPEG-TS 编码后的流。在 MediaMTX 中SRT 推流的载荷正是 MPEG-TS。支持的编解码格式MediaMTX 的 SRT 服务端对推流内容有明确的编解码支持范围官方文档给出的支持矩阵如下supported codecsvideoH265, H264, MPEG-4 Video (H263, Xvid), MPEG-1/2 VideoaudioOpus, MPEG-4 Audio (AAC), MPEG-1/2 Audio (MP3), AC-3otherKLV也就是说推流时视频建议选择 H265 或 H264编码效率与兼容性最好音频选择 Opus 或 AACMP3、AC-3、MPEG-1/2 Video 等老式格式也在支持之列KLV 元数据可作为附带轨。推流 URL 与自定义 Stream ID 语法要向 MediaMTX 用 SRT 推流URL 形式为srt://localhost:8890?streamidpublish:mystreampkt_size1316拆解各段含义URL 片段含义srt://协议前缀SRT 默认走 UDPlocalhost:8890MediaMTX 的 SRT 监听地址默认端口 8890由全局配置srtAddress决定streamidpublish:mystream自定义 Stream IDpublish表示推流动作mystream是要发布的路径名pkt_size1316UDP 数据包大小1316 188 × 7即 7 个 MPEG-TS 包该值需与对端协商一致其中mystream可以替换成任意合法路径名。推流成功建立后流会出现在路径/mystream上其他协议RTSP、RTMP、HLS、WebRTC 等的读者即可按该路径名拉取。自定义 Stream ID 的完整格式上述publish:mystream是自定义语法的最简形式。从服务端源码 internal/servers/srt/streamid.go 可以看到它支持两种结构action:pathname[:query] action:pathname:user:pass[:query]即actionpublish推流或read拉流pathname路径名user/pass可选的认证凭据与 MediaMTX 的认证系统对接对应源码中的Credentials{User, Pass}字段query可选的附加信息会透传给认证、hooks 等下游模块。因此带认证的推流 URL 可以写作srt://localhost:8890?streamidpublish:mystream:myuser:mypasspkt_size1316解析逻辑对原始串还有一处细节末尾的#feedbackplay后缀会被自动剥离strings.TrimSuffix这是为了兼容某些 SRT 客户端附加的标记。标准 Stream ID 语法除了上述自定义语法MediaMTX 还支持 SRT 协议作者Haivision提出的标准 Stream ID 语法Access Control 规范该语法被部分硬件设备强制要求使用。标准语法以#!::开头srt://localhost:8890?streamid#!::mpublish,rmypath,umyuser,smypasspkt_size1316各键的含义键含义m动作publish推流或request拉流r路径名u用户名可选s密码可选从源码看服务端正是通过判断 Stream ID 是否以#!::前缀开头来分流解析逻辑streamid.go标准语法按逗号分隔键值对识别u、r、s、t、m等键其中mrequest映射为拉流模式、mpublish映射为推流模式其余键值会被忽略而h、t等键当前不做处理。这与文档 SRT 特有功能 中的说明一致推流与拉流两侧共用同一套解析。SRT 服务端监听、解析与推流接入链路为了让你理解 URL 中的每个参数最终走向哪里这里结合源码说明推流的完整链路。服务端初始化与监听全局配置中SRT 服务由两个参数控制mediamtx.yml 的Global settings - SRT server一节对应结构体定义在 internal/conf/conf.go# Enable the SRT server, which allows to publish and read streams with the SRT protocol. srt: true # Address of the UDP/SRT listener. srtAddress: :8890srt: true启用 SRT 服务默认为truesrtAddress: :8890UDP/SRT 监听地址默认监听本机 8890 端口。服务端启动时internal/servers/srt/server.go 的Initialize会基于srtAddress调用srt.Listen创建监听器并把PayloadSize设为srtMaxPayloadSize(UDPMaxPayloadSize)。这个函数揭示了pkt_size1316的来源func srtMaxPayloadSize(u int) int { return ((u - 16) / 188) * 188 // 16 SRT header, 188 MPEG-TS packet }即SRT 头占 16 字节剩余载荷按 188 字节的 MPEG-TS 包对齐取整。客户端与服务器约定pkt_size1316正是为了与服务端的 UDP 载荷上限UDPMaxPayloadSize默认 1316保持一致避免分片。从 Stream ID 到路径的推流流程每个新连接由 internal/servers/srt/conn.go 处理核心流程为读取连接请求中的StreamId调用streamID.unmarshal()解析出动作、路径、凭据与查询参数若动作是publish则调用FindPathConf做路径访问控制鉴权、权限校验校验失败会以REJ_PEER拒绝连接校验srtPublishPassphrase若配置了 SRT 加密口令见下文接受连接后把 SRT 流接入mpegts.EnhancedReader通过mpegts.ToStream解析出媒体轨并注册为路径的发布者AddPublisher之后循环读取 MPEG-TS 包持续供给流媒体管道。从源码结构可以推断SRT 推流在服务端被当作MPEG-TS over UDP/SRT来消费因此客户端侧必须用mpegtsmuxGStreamer或-f mpegtsFFmpeg完成 MPEG-TS 封装后再塞进 SRT。推流侧 SRT 加密口令srtPublishPassphrase如果你希望推流内容被 AES 加密可在路径配置中设置srtPublishPassphrase对应 internal/conf/path.go 中的SRTPublishPassphrase字段paths: mystream: source: publisher srtPublishPassphrase: your-secret-10chars-min配置校验要求口令长度在1079 个字符之间checkSRTPassphrase实现于 internal/conf/path.go。握手时服务端会检查连接是否已加密若客户端未提供口令或口令错误则拒绝连接见 conn.go 的srtCheckPassphrase。对应的读取侧口令是srtReadPassphrase。注意passphrase 与 Stream ID 中的user:pass是两回事——前者用于 SRT 链路本身的加密后者用于 MediaMTX 的应用层认证。使用 FFmpeg 推流FFmpeg 是最常用的 SRT 推流工具。使用 FFmpeg 向 MediaMTX 推流时把它当作 SRT 客户端即可完整示例见 FFmpeg 推流文档ffmpeg -re -stream_loop -1 -i file.mp4 -c copy -f mpegts srt://localhost:8890?streamidpublish:streampkt_size1316要点说明-re按原速读取输入避免突发推流打爆带宽-stream_loop -1循环播放输入文件-c copy直接复制编码不转码。注意前提是输入文件的编解码格式在本文开头的支持矩阵内-f mpegts必须把输出封装为 MPEG-TS因为 MediaMTX 的 SRT 服务端接收的就是 MPEG-TS 流URL 用单引号包裹避免被 shell 解释为后台执行符streamidpublish:stream中的stream是推流路径名可自行更换。推流启动后即可通过srt://localhost:8890?streamidread:stream或其他协议如 RTSP、HLS读取该流。使用 GStreamer 推流GStreamer 同样可以作为 SRT 客户端推流示例见 GStreamer 推流文档核心是用mpegtsmux做 MPEG-TS 复用、用srtsink作为 SRT 发送端gst-launch-1.0 -v mpegtsmux namemux ! srtsink urisrt://localhost:8890?streamidpublish:mystreampkt_size1316 \ videotestsrc ! video/x-raw,width1280,height720,formatI420 ! x264enc speed-presetultrafast bitrate3000 key-int-max60 ! video/x-h264,profilehigh ! mux. \ audiotestsrc ! audioconvert ! avenc_aac ! mux.命令解读视频源用videotestsrc测试图案经x264enc编码为 H264speed-presetultrafast与bitrate3000控制编码速度与码率key-int-max60设置关键帧间隔音频源用audiotestsrc经avenc_aac编码为 AAC两路轨汇入mpegtsmux复用成 MPEG-TSsrtsink以uri参数指定目标地址与 Stream ID把 TS 流通过 SRT 发送给 MediaMTX。若想用摄像头/文件等真实源替换videotestsrc只需把输入管道换成对应的filesrc、v4l2src等元素编码与复用部分保持不变。其他可用的推流客户端仓库文档将 OBS Studio 也列为可用的 SRT 推流客户端之一。需要说明的是OBS Studio 的专用推流文档当前主要覆盖 RTMP含 RTMPS 加密与 WebRTC/WHIP 两种方式如果你打算用 OBS 走 SRT 推流可通过其自定义输出/FFmpeg 输出能力配合上述 URL 规则自行配置但具体的 OBS 界面操作路径不属于本文档覆盖范围请以 OBS 官方文档为准。此外任意支持 SRT 协议的推流软件如 ffmpeg 系工具、硬件编码器等都可使用同一套 URL 规则接入关键是满足两点载荷必须是 MPEG-TS且Stream ID 语法正确自定义或标准语法二选一。进阶监听模式推流与拉流对照客户端以监听模式推流modelistener默认情况下SRT 推流客户端以呼叫方caller身份主动连接 MediaMTX 的 8890 端口。如果你的客户端需要以监听模式工作——即由 MediaMTX 反向发起连接——可以在 URL 中附加modelistener参数srt://localhost:8890?streamidpublish:mystreammodelistenerpkt_size1316这种模式适用于无法主动外联如位于 NAT 后、防火墙限制出方向的推流端客户端先在本机监听MediaMTX 侧将其作为srt://host:port?streamid...形式的静态源source拉取。其配置入口在路径的source字段见 mediamtx.yml 中的说明# * srt://host:port?streamidstreamid - the stream is pulled from another SRT server / camera与拉流 URL 的对照推流与拉流共用同一个 Stream ID 解析器区别只在动作关键字推流用publish拉流用read。作为对照从 MediaMTX 用 SRT 读取一路流的 URL 为详见 SRT 拉流客户端指南srt://localhost:8890?streamidread:mystream两条 URL 只有publish/read一处不同这正体现了 Stream ID 把动作 路径 凭据压缩进单一字符串的设计意图。常见问题排查推流被拒连接被拒绝/立即断开优先检查 Stream ID 语法publish:路径名中动作关键字拼写、路径名合法性不能包含非法字符是高频原因服务端解析失败会以REJ_PEER拒绝conn.go 中的unmarshal错误路径画面花屏/无法解析确认推流内容确实封装为 MPEG-TSFFmpeg 加-f mpegtsGStreamer 加mpegtsmux且编解码格式在支持矩阵内口令错误被拒若配置了srtPublishPassphrase客户端必须启用 SRT 加密并提供相同口令且口令长度须在 1079 字符之间包大小不匹配pkt_size建议保持 1316与服务器UDPMaxPayloadSize默认值对齐推流成功但拉不到确认推流动作完成后路径名与后续读取方使用的路径名完全一致/mystream。参考资源SRT 推流客户端文档本文依据SRT 特有功能标准 Stream ID 语法SRT 拉流客户端指南SRT 服务端实现、连接与推流处理、Stream ID 解析SRT 全局配置与路径配置项srt、srtAddress、srtPublishPassphrase、srtReadPassphraseFFmpeg 推流文档、GStreamer 推流文档、OBS Studio 推流文档【免费下载链接】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），仅供参考
