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-QUICMedia-over-QUIC 相关部分也有重要修复。1. 修复关闭服务器时的竞态条件本次修复了一个关闭服务器时可能出现的竞态条件。问题表现为如果某些 session 正在被远端 peer 同时关闭那么在服务器关闭过程中这些 session 可能会卡住。v1.19.1 修复了这一竞态问题避免了在关闭服务或断开会话时出现挂起现象。对于运行在高并发、会话频繁建立与关闭的场景这种修复可以提升整体稳定性减少异常挂起带来的资源残留和运维困扰。2. 重命名 moqHTTPS2Address 和 moqHTTPS3Address本次版本还进行了字段或配置名称的调整moqHTTPS2Address 重命名为 moqHTTP2AddressmoqHTTPS3Address 重命名为 moqHTTP3Address这一改动主要是名称统一和语义更清晰。从命名上看新名称更直接对应 HTTP2 和 HTTP3 的地址概念减少歧义。如果你在使用相关配置或代码对接需要注意新的命名变化避免因为旧名称继续使用而导致配置不生效。三、RTSP 相关更新RTSP 是本次更新中非常值得关注的一块因为它涉及兼容性、安全传输以及摄像头接入场景。1. 支持 PROXY protocolv1.19.1 为 RTSP 和 RTSPS 的 TCP 监听器增加了 PROXY protocol 支持。具体来说支持PROXY protocol v1PROXY protocol v2并且适用于以下协议监听器RTMPRTMPSRTSPRTSPS这个能力的核心价值在于当 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-mode0 的 H264 流曾经被服务器阻止因为这类流无法通过 UDP 路由原因是数据包太大。但是实际使用中这样的限制给某些摄像头带来了兼容性问题。在 v1.19.1 中这个问题得到修复服务器现在可以通过 TCP 接收 packetization-mode0 的流接收后会自动 remux 成 packetization-mode1转换后的流可以自由路由这项修复的意义很多摄像头或推流设备在实际部署中并不完全遵循统一的打包模式若服务器过于严格就可能导致接入失败。本次更新恢复兼容性意味着某些原本无法接入的摄像头现在可以继续工作TCP 接入场景下的 H264 流处理更稳妥服务端会自动完成重封装减轻上游设备适配压力对于 RTSP 摄像头接入用户来说这是一项非常实用的修复。四、RTMP 相关更新RTMP 部分与 RTSP 类似也新增了 PROXY protocol 支持。支持 PROXY protocolRTMP 和 RTMPS 的 TCP 监听器现在同样支持PROXY protocol v1PROXY protocol v2这表示当 RTMP 服务部署在 L4 代理后面时也能获取真实客户端 IP 地址而不是只看到代理的来源。这对运行 RTMP 推流服务、转推服务、直播接入服务的用户尤其重要。在真实生产环境中很多服务前面都会有负载均衡或代理层如果无法获得真实来源 IP日志审计与访问控制都会受到限制。这次更新让 RTMP 相关场景在代理架构下的可用性进一步增强。五、Dependencies 依赖升级v1.19.1 还包含一批依赖库升级。这类更新虽然看起来不如功能特性显眼但往往和稳定性、安全性、兼容性密切相关。本次升级如下code.cloudfoundry.org/bytefmt 从 v0.74.0 升级到 v0.76.0github.com/bluenviron/gortsplib/v5 从 v5.5.4 升级到 v5.6.0github.com/pion/ice/v4 从 v4.2.7 升级到 v4.2.8-0.20260604162030-72f5001c4596github.com/pion/webrtc/v4 从 v4.2.14 升级到 v4.2.15github.com/quic-go/quic-go 从 v0.59.0 升级到 v0.60.0golang.org/x/crypto 从 v0.52.0 升级到 v0.53.0golang.org/x/net 从 v0.55.0 升级到 v0.56.0golang.org/x/sync 从 v0.20.0 升级到 v0.21.0golang.org/x/sys 从 v0.45.0 升级到 v0.46.0golang.org/x/term 从 v0.43.0 升级到 v0.44.0github.com/pion/dtls/v3 从 v3.1.3 升级到 v3.1.4github.com/pion/stun/v3 从 v3.1.4 升级到 v3.1.5github.com/pion/turn/v5 从 v5.0.7 升级到 v5.0.9golang.org/x/text 从 v0.37.0 升级到 v0.38.0github.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-mode0 的支持并自动 remux 为 packetization-mode1提升摄像头兼容性。7. 依赖升级多个核心依赖同步更新覆盖网络、安全、传输和 WebRTC 相关库。8. 发布安全可验证提供公开可验证的二进制构建与校验机制增强发布可信度。八、结语代码地址github.com/bluenviron/mediamtxmediamtx v1.19.1 虽然不是一次大规模功能扩展版本但它在安全性、兼容性、稳定性和可观测性上的改进都非常实用。尤其是 PROXY protocol 支持、H264 packetization-mode 0 修复、抗暴力破解增强以及调试日志改进都属于直接影响生产环境体验的变化。
mediamtx v1.19.1 最新更新发布：安全增强、RTSP/RTMP协议支持升级、媒体处理修复与依赖全面更新
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-QUICMedia-over-QUIC 相关部分也有重要修复。1. 修复关闭服务器时的竞态条件本次修复了一个关闭服务器时可能出现的竞态条件。问题表现为如果某些 session 正在被远端 peer 同时关闭那么在服务器关闭过程中这些 session 可能会卡住。v1.19.1 修复了这一竞态问题避免了在关闭服务或断开会话时出现挂起现象。对于运行在高并发、会话频繁建立与关闭的场景这种修复可以提升整体稳定性减少异常挂起带来的资源残留和运维困扰。2. 重命名 moqHTTPS2Address 和 moqHTTPS3Address本次版本还进行了字段或配置名称的调整moqHTTPS2Address 重命名为 moqHTTP2AddressmoqHTTPS3Address 重命名为 moqHTTP3Address这一改动主要是名称统一和语义更清晰。从命名上看新名称更直接对应 HTTP2 和 HTTP3 的地址概念减少歧义。如果你在使用相关配置或代码对接需要注意新的命名变化避免因为旧名称继续使用而导致配置不生效。三、RTSP 相关更新RTSP 是本次更新中非常值得关注的一块因为它涉及兼容性、安全传输以及摄像头接入场景。1. 支持 PROXY protocolv1.19.1 为 RTSP 和 RTSPS 的 TCP 监听器增加了 PROXY protocol 支持。具体来说支持PROXY protocol v1PROXY protocol v2并且适用于以下协议监听器RTMPRTMPSRTSPRTSPS这个能力的核心价值在于当 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-mode0 的 H264 流曾经被服务器阻止因为这类流无法通过 UDP 路由原因是数据包太大。但是实际使用中这样的限制给某些摄像头带来了兼容性问题。在 v1.19.1 中这个问题得到修复服务器现在可以通过 TCP 接收 packetization-mode0 的流接收后会自动 remux 成 packetization-mode1转换后的流可以自由路由这项修复的意义很多摄像头或推流设备在实际部署中并不完全遵循统一的打包模式若服务器过于严格就可能导致接入失败。本次更新恢复兼容性意味着某些原本无法接入的摄像头现在可以继续工作TCP 接入场景下的 H264 流处理更稳妥服务端会自动完成重封装减轻上游设备适配压力对于 RTSP 摄像头接入用户来说这是一项非常实用的修复。四、RTMP 相关更新RTMP 部分与 RTSP 类似也新增了 PROXY protocol 支持。支持 PROXY protocolRTMP 和 RTMPS 的 TCP 监听器现在同样支持PROXY protocol v1PROXY protocol v2这表示当 RTMP 服务部署在 L4 代理后面时也能获取真实客户端 IP 地址而不是只看到代理的来源。这对运行 RTMP 推流服务、转推服务、直播接入服务的用户尤其重要。在真实生产环境中很多服务前面都会有负载均衡或代理层如果无法获得真实来源 IP日志审计与访问控制都会受到限制。这次更新让 RTMP 相关场景在代理架构下的可用性进一步增强。五、Dependencies 依赖升级v1.19.1 还包含一批依赖库升级。这类更新虽然看起来不如功能特性显眼但往往和稳定性、安全性、兼容性密切相关。本次升级如下code.cloudfoundry.org/bytefmt 从 v0.74.0 升级到 v0.76.0github.com/bluenviron/gortsplib/v5 从 v5.5.4 升级到 v5.6.0github.com/pion/ice/v4 从 v4.2.7 升级到 v4.2.8-0.20260604162030-72f5001c4596github.com/pion/webrtc/v4 从 v4.2.14 升级到 v4.2.15github.com/quic-go/quic-go 从 v0.59.0 升级到 v0.60.0golang.org/x/crypto 从 v0.52.0 升级到 v0.53.0golang.org/x/net 从 v0.55.0 升级到 v0.56.0golang.org/x/sync 从 v0.20.0 升级到 v0.21.0golang.org/x/sys 从 v0.45.0 升级到 v0.46.0golang.org/x/term 从 v0.43.0 升级到 v0.44.0github.com/pion/dtls/v3 从 v3.1.3 升级到 v3.1.4github.com/pion/stun/v3 从 v3.1.4 升级到 v3.1.5github.com/pion/turn/v5 从 v5.0.7 升级到 v5.0.9golang.org/x/text 从 v0.37.0 升级到 v0.38.0github.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-mode0 的支持并自动 remux 为 packetization-mode1提升摄像头兼容性。7. 依赖升级多个核心依赖同步更新覆盖网络、安全、传输和 WebRTC 相关库。8. 发布安全可验证提供公开可验证的二进制构建与校验机制增强发布可信度。八、结语代码地址github.com/bluenviron/mediamtxmediamtx v1.19.1 虽然不是一次大规模功能扩展版本但它在安全性、兼容性、稳定性和可观测性上的改进都非常实用。尤其是 PROXY protocol 支持、H264 packetization-mode 0 修复、抗暴力破解增强以及调试日志改进都属于直接影响生产环境体验的变化。
