2026年6月15日，mediamtx 发布了 v1.19.1 版本。
这次更新虽然整体仍然属于修复和改进为主，但涉及的范围非常广，覆盖了通用能力、抗暴力破解机制、调试日志、Media-over-QUIC、RTSP、RTMP、依赖升级以及安全验证等多个方面。对于正在使用 mediamtx 构建流媒体服务、进行协议转发、接入摄像头、部署在代理后面或者需要更强日志排查能力的用户来说，这一版本值得重点关注。
一、General 通用改进
1. 支持在 source URL 的任意部分使用 regexp groups
本次更新中，一个非常实用的增强是：
支持在 source URL 的每一部分使用正则分组。
这意味着，在源地址配置中，正则表达式的分组能力不再局限于某个固定位置，而是可以应用在 URL 的各个组成部分中。对于需要根据不同路径、参数或地址特征进行动态匹配和路由的场景，这个改动会让配置更加灵活。
原先在处理某些复杂 source URL 时，配置能力可能存在限制；现在通过支持 regexp groups，能够更细粒度地解析和匹配来源地址，提升了规则配置的表达力。
对于需要按不同来源进行统一管理的直播转发、设备接入和媒体源识别，这项能力会带来更强的适配性。
2. 改进防暴力破解机制
v1.19.1 对防暴力破解机制进行了进一步增强，主要有两个变化：
- 在认证失败后，增加随机延迟
- 对所有用户使用相同的防暴力破解机制
这项改动的目标非常明确，就是提升认证阶段的安全性。
认证失败延迟随机化
当认证失败时，系统不再以固定时间返回，而是增加一个随机时长的延迟。这样做可以降低攻击者通过高频测试、统计响应时间来判断系统行为的可行性，从而增强对暴力破解的抵抗能力。
所有用户使用统一机制
这次更新还强调，对所有用户应用相同的防暴力破解策略。
这意味着不同用户在认证失败时不会出现机制差异，整体行为更加一致，减少某些账户因策略不一致而暴露更多可推断信息的可能性。
对于部署在公网环境、需要账号认证、或者对访问控制要求较高的系统来说，这项改进是非常重要的安全优化。
3. 限制 debug 日志中显示的 HTTP 请求大小
调试日志是排查问题的重要手段，但如果请求内容过大，日志本身可能变得臃肿，甚至影响可读性和排障效率。
v1.19.1 增加了一个限制：
在 debug 日志中显示的 HTTP 请求大小被限制。
这意味着当请求体过大时，不会在调试日志里无限制地完整展开，从而避免日志过长、占用过多存储空间，也有助于减少调试输出中的噪音。
对于流媒体服务这种可能接收到较大请求或复杂协议交互的场景，这类控制非常有必要。
4. 在 debug 级别下打印选定 HTTP 响应的 body
除了限制请求日志大小之外，这次更新还增强了调试日志的可观测性：
在 debug 日志级别下，会打印选定 HTTP 响应的 body。
这项改动的意义在于，当你排查某些 HTTP 交互问题时，可以更直接地看到响应体内容，从而更容易判断接口返回、认证失败、重定向、错误信息等具体情况。
与前一个“限制请求大小”的改动搭配起来看，v1.19.1 在日志可读性和日志控制之间做了更合理的平衡。
二、Media-over-QUIC
Media-over-QUIC 相关部分也有重要修复。
1. 修复关闭服务器时的竞态条件
本次修复了一个关闭服务器时可能出现的竞态条件。
问题表现为：如果某些 session 正在被远端 peer 同时关闭，那么在服务器关闭过程中，这些 session 可能会卡住。
v1.19.1 修复了这一竞态问题，避免了在关闭服务或断开会话时出现挂起现象。
对于运行在高并发、会话频繁建立与关闭的场景，这种修复可以提升整体稳定性，减少异常挂起带来的资源残留和运维困扰。
2. 重命名 moqHTTPS2Address 和 moqHTTPS3Address
本次版本还进行了字段或配置名称的调整：
- moqHTTPS2Address 重命名为 moqHTTP2Address
- moqHTTPS3Address 重命名为 moqHTTP3Address
这一改动主要是名称统一和语义更清晰。
从命名上看，新名称更直接对应 HTTP2 和 HTTP3 的地址概念，减少歧义。
如果你在使用相关配置或代码对接，需要注意新的命名变化，避免因为旧名称继续使用而导致配置不生效。
三、RTSP 相关更新
RTSP 是本次更新中非常值得关注的一块，因为它涉及兼容性、安全传输以及摄像头接入场景。
1. 支持 PROXY protocol
v1.19.1 为 RTSP 和 RTSPS 的 TCP 监听器增加了 PROXY protocol 支持。
具体来说，支持：
- PROXY protocol v1
- PROXY protocol v2
并且适用于以下协议监听器：
- RTMP
- RTMPS
- RTSP
- RTSPS
这个能力的核心价值在于：当 mediamtx 运行在 L4 代理后面时，可以获取真实客户端 IP。
为什么这很重要
在很多生产环境中，mediamtx 并不直接暴露在公网，而是部署在 nginx stream、HAProxy、AWS NLB 等四层代理之后。
如果没有 PROXY protocol，后端服务看到的往往只是代理的 IP，而不是真实客户端来源地址。
启用 PROXY protocol 后，mediamtx 可以识别真实客户端 IP，这对于：
- 访问审计
- 安全策略
- 日志排查
- 黑白名单控制
- 连接来源追踪
都非常有帮助。
这次更新把这一能力同时扩展到了 RTMP、RTMPS、RTSP、RTSPS 的 TCP 监听场景，覆盖面很广。
2. 恢复对 H264 packetization-mode 0 的支持
这是 RTSP 部分非常关键的兼容性修复。
v1.19.0 之后，packetization-mode=0 的 H264 流曾经被服务器阻止，因为这类流无法通过 UDP 路由，原因是数据包太大。
但是实际使用中，这样的限制给某些摄像头带来了兼容性问题。
在 v1.19.1 中，这个问题得到修复：
- 服务器现在可以通过 TCP 接收 packetization-mode=0 的流
- 接收后会自动 remux 成 packetization-mode=1
- 转换后的流可以自由路由
这项修复的意义
很多摄像头或推流设备在实际部署中并不完全遵循统一的打包模式，若服务器过于严格，就可能导致接入失败。
本次更新恢复兼容性，意味着：
- 某些原本无法接入的摄像头现在可以继续工作
- TCP 接入场景下的 H264 流处理更稳妥
- 服务端会自动完成重封装，减轻上游设备适配压力
对于 RTSP 摄像头接入用户来说，这是一项非常实用的修复。
四、RTMP 相关更新
RTMP 部分与 RTSP 类似，也新增了 PROXY protocol 支持。
支持 PROXY protocol
RTMP 和 RTMPS 的 TCP 监听器现在同样支持：
- PROXY protocol v1
- PROXY protocol v2
这表示当 RTMP 服务部署在 L4 代理后面时，也能获取真实客户端 IP 地址，而不是只看到代理的来源。
这对运行 RTMP 推流服务、转推服务、直播接入服务的用户尤其重要。
在真实生产环境中，很多服务前面都会有负载均衡或代理层，如果无法获得真实来源 IP，日志审计与访问控制都会受到限制。
这次更新让 RTMP 相关场景在代理架构下的可用性进一步增强。
五、Dependencies 依赖升级
v1.19.1 还包含一批依赖库升级。这类更新虽然看起来不如功能特性显眼，但往往和稳定性、安全性、兼容性密切相关。
本次升级如下：
- code.cloudfoundry.org/bytefmt 从 v0.74.0 升级到 v0.76.0
- github.com/bluenviron/gortsplib/v5 从 v5.5.4 升级到 v5.6.0
- github.com/pion/ice/v4 从 v4.2.7 升级到 v4.2.8-0.20260604162030-72f5001c4596
- github.com/pion/webrtc/v4 从 v4.2.14 升级到 v4.2.15
- github.com/quic-go/quic-go 从 v0.59.0 升级到 v0.60.0
- golang.org/x/crypto 从 v0.52.0 升级到 v0.53.0
- golang.org/x/net 从 v0.55.0 升级到 v0.56.0
- golang.org/x/sync 从 v0.20.0 升级到 v0.21.0
- golang.org/x/sys 从 v0.45.0 升级到 v0.46.0
- golang.org/x/term 从 v0.43.0 升级到 v0.44.0
- github.com/pion/dtls/v3 从 v3.1.3 升级到 v3.1.4
- github.com/pion/stun/v3 从 v3.1.4 升级到 v3.1.5
- github.com/pion/turn/v5 从 v5.0.7 升级到 v5.0.9
- golang.org/x/text 从 v0.37.0 升级到 v0.38.0
- github.com/pires/go-proxyproto v0.12.0 被新增
从更新内容来看，这次依赖升级覆盖了网络、加密、同步控制、终端处理、WebRTC、QUIC、DTLS、STUN、TURN 以及代理协议支持等多个模块。
尤其是 github.com/pires/go-proxyproto 的新增，也与前面提到的 PROXY protocol 支持直接对应，说明这一版本在代理兼容性方面做了完整补齐。
六、安全说明
这次更新还特别强调了安全相关说明，内容非常明确。
1. 二进制文件由 Release 工作流从源代码编译生成
官方说明中指出：
二进制文件是由 Release 工作流从源代码编译出来的。
整个过程是完全可见的，这可以防止对产物进行任何更改或外部干预。
这意味着发布流程具有透明性，用户可以更放心地理解构建来源和产物生成过程。
2. 二进制的校验和会通过 GitHub Attestations 发布到公共区块链
官方还说明：
二进制文件的 checksums 也会通过 GitHub Attestations 发布到公共区块链，并且可以进行验证。
验证命令如下：
ls mediamtx_* | xargs -L1 gh attestation verify --repo bluenviron/mediamtx
这条命令的作用是对下载的发布产物进行 attestation 验证，确认其来源和完整性。
3. 通过 checksums.sha256 验证二进制校验和
如果你想进一步校验二进制文件，可以下载 checksums.sha256，然后执行如下命令：
cat checksums.sha256 | grep “$(ls mediamtx_*)” | sha256sum --check
这个过程的目的，是通过官方发布的校验和来验证下载的二进制文件是否完整、是否与发布内容一致。
对于重视供应链安全、发布可信度以及生产环境部署安全的用户来说，这部分说明非常重要。
七、本次版本的整体看点总结
综合来看，mediamtx v1.19.1 主要围绕以下几个方向进行了优化：
1. 配置能力增强
支持在 source URL 的任意部分使用 regexp groups，提升了源地址匹配和路由的灵活性。
2. 安全性提升
增强了防暴力破解机制，通过随机延迟和统一策略提高认证安全性。
3. 调试体验优化
限制 debug 日志中 HTTP 请求体大小，同时在 debug 级别打印选定 HTTP 响应 body，增强排障能力。
4. Media-over-QUIC 稳定性修复
修复关闭服务器时的竞态条件，避免 session 挂起。
5. RTSP / RTMP 代理兼容性增强
支持 PROXY protocol v1/v2，可在 L4 代理后获取真实客户端 IP。
6. H264 兼容性修复
恢复对 packetization-mode=0 的支持，并自动 remux 为 packetization-mode=1，提升摄像头兼容性。
7. 依赖升级
多个核心依赖同步更新，覆盖网络、安全、传输和 WebRTC 相关库。
8. 发布安全可验证
提供公开可验证的二进制构建与校验机制，增强发布可信度。
八、结语
代码地址：github.com/bluenviron/mediamtx
mediamtx v1.19.1 虽然不是一次大规模功能扩展版本，但它在安全性、兼容性、稳定性和可观测性上的改进都非常实用。
尤其是 PROXY protocol 支持、H264 packetization-mode 0 修复、抗暴力破解增强以及调试日志改进，都属于直接影响生产环境体验的变化。
