大规模 RTSP 流媒体传输：架构和性能考量

尽管流媒体行业常聚焦于最新协议或 Flash 等已淘汰的旧标准，实时流媒体协议（RTSP）却正迎来巨大复兴。这并非因 RTSP 是突破性新技术，而是它始终是交通运输部门、执法机构及其他政府部门等受监管领域中 IP 摄像头集群无可争议的骨干技术。

如今企业不再满足于单纯查看原始视频流，而是通过添加物体识别、自动车辆计数等智能功能来升级现有基础设施。这使用户能够从使用数十年的视频流中挖掘出重大新价值，同时避免了彻底更换硬件的高昂成本。阅读本文，了解如何大规模优化 RTSP 视频流以适应现代工作流程，无论是优先保障监控的实时传输，还是提升远程监控的韧性。

为什么RTSP流媒体在工业环境中无处不在

在高安全级别或工业环境中，硬件设备已投入使用多年，往往经历了数次软件更新迭代。RTSP 仍然是 IP 摄像机的通用标准。

确保IP摄像机的互操作性

虽然现代网络流媒体通常需要专有或复杂的握手协议，但RTSP协议却被大量IP摄像机原生支持。大多数IP摄像机本身就是独立的RTSP服务器。然而，不同厂商和固件之间并没有统一的标准。换句话说，要找到并集成各种不同年代、功能和连接协议的RTSP摄像机可能会很困难。

初始集成工作需要获取设备的 IP 地址，并研究正确的 Web 管理面板访问权限，包括用户名/密码的查找。连接成功后，接下来的工作就是探索旧版编解码器、帧速率和带宽设置，这需要更深入的思考和测试。对于业余爱好者或小型办公室/家庭办公室 (SOHO) 用户来说，这种磕磕绊绊的过程尚可接受，但如果一个团队的任务是集成数千台设备，又该如何应对呢？

这就是ONVIF发挥作用的地方。ONVIF 配置文件和附加组件对接口进行标准化，以确保不同设备的功能一致。此外，运营商无需预先知道 IP 地址即可在给定网络上发现摄像机。RTSP 是实现合规性和标准化 IP 设备互操作性的核心。ONVIF 合规性几乎完全依赖 RTSP 来协调媒体传输。这使其成为将来自某一制造商的视频集成到第三方网络视频录像机 (NVR) 或视频管理软件 (VMS) 的主要方法。

保持精细化网络控制

与基于 HTTP 的协议（例如 HLS）本质上是下载视频片段不同，RTSP 本身是有状态的。这意味着它可以保持持续的会话。这种架构支持类似录像机的控制功能，可以直接发出 DESCRIBE、SETUP、PLAY、PAUSE 和 TEARDOWN 等命令来控制视频流。

对于需要低延迟远程控制云台（PTZ）摄像机的安防人员来说，需要注意的是，RTSP 实际上并不处理这些云台控制命令。这些命令通常通过单独的通道发送。RTSP 在以低延迟传输视频流方面发挥着至关重要的作用，为云台控制人员提供所需的视觉反馈回路。这是高延迟或基于分段的 Web 协议可能难以满足的关键要求。

First-Mile 贡献

在现代架构中，RTSP 很少用于“最后一公里”（即向最终用户的手机或笔记本电脑传输内容），因为它缺乏原生浏览器播放支持。相反，它作为内容传输协议表现出色。RTSP 通过建立一次会话并利用 RTP 持续传输数据，避免了重复 HTTP 请求带来的持续开销和通信量。在受控的局域网 (LAN) 中，RTSP 的延迟可以远低于一秒，使其成为关键任务监控的可靠选择。

可靠性与实时性（弹性权衡）

RTSP 提供了独特的灵活性，允许在TCP 和 UDP传输协议之间进行选择。每种协议都有其自身的优势和理想的应用场景：

• TCP交错传输：对于位于防火墙后或网络不稳定的摄像机，RTSP 可以通过单个 TCP 连接交错传输控制数据和媒体数据，从而确保可靠性和弹性。
• UDP 性能：对于高带宽和稳定骨干网的环境，UDP 可以实现绝对最小的延迟，丢帧比引入缓冲延迟更可取。

RTSP 流媒体传输中 TCP 和 UDP 传输的选择

传输 RTSP 流是一项根本性的架构决策，需要在可靠性和速度之间做出权衡。这一战略选择应基于具体应用场景，例如是任务关键型监控中心还是带宽有限的远程监控站。

TCP（交错式）优先考虑可靠性和弹性。对于资源受限的网络，TCP 是确保弹性的标准选择。由于 TCP 是一种面向连接的协议，它可以保证每个数据包按正确的顺序到达。它是穿透防火墙和 NAT（网络地址转换）的首选方法，因为它将媒体数据交错到现有的控制连接中。其主要缺点是队头阻塞。如果丢失一个数据包，整个数据流将暂停，直到该数据包被重新发送。这在不稳定的环境中会导致明显的延迟。

UDP（RTP）优先考虑速度和实时性。对于超低延迟应用，UDP 无疑是最佳选择。在实时监控场景中，丢帧几乎总是比五秒的延迟要好。UDP 是一种“即发即弃”协议，这意味着它不会等待确认或重传丢失的数据包。UDP 经常被企业或政府防火墙屏蔽。在这种情况下，确保数据流能够到达目的地需要更复杂的网络配置。

RTSP 流媒体架构模式的扩展

RTSP 的扩展很少仅仅是将单个流推送给单个用户。它可能涉及将RTSP 内容分发到视频墙、应急响应人员或 CDN 进行全球公共分发。此外，它还涉及高效地支持不断增长的输入源。为了实现高效的 RTSP 流媒体传输，可以实施转复用架构。将有状态的 RTSP 流接收并重新打包成无状态的、CDN 友好的格式，例如 HLS 或 DASH。转复用还支持 WebRTC 工作流，使交通运营中心能够从传统的 RTSP 源获得超低延迟的性能，并在 Web 浏览器中播放。

数据采集规模化：集中式与区域式

数据采集​​架构很大程度上取决于摄像头的数量和位置。现代架构采用容器化策略来加速开发、降低风险，并能轻松扩展数据采集点，以适应任意数量的摄像头。这种架构可以集中式采集，也可以区域分布式采集。

集中式采集（单源模式）将所有摄像头连接保存在单个服务器上，从而简化了管理和监控。它通常足以满足最多约 50 个摄像头的本地部署需求。区域式采集（分布式模式）通常用于覆盖整个州的交通运输部或政府大规模部署。在这种模式下，区域式采集节点部署在视频源附近。这些节点处理本地摄像头连接，并将视频流转发到中央源服务器，通常通过可靠的专用网络进行传输，从而减少网络跳转次数并隔离区域故障。

扩展交付：源-边缘模式

摄取流之后，源-边模式可确保大规模可靠交付。源服务器专注于可靠摄取、流管理和RTSP流的转码。边缘服务器（或多CDN策略）专注于观众连接。由于 HLS 和 DASH 基于HTTP，因此它们可以被缓存并分发到数千个边缘节点，而不会给摄取层增加额外的负载。

大规模 RTSP 分发的一个常见痛点是摄像头到服务器的带宽，这既是成本问题，也是基础设施问题。利用源服务器上的API功能，应用程序逻辑可以指示源服务器通过RTSP连接到摄像头。这样就创建了一种按需传输的场景，仅在需要查看RTSP时才提供流量，从而最大限度地降低带宽成本。

数据密度因子

扩展需要深入了解视频数据包的原始重量。每个额外的字节元数据或高于必要值的比特率都会在整个边缘网络中成倍增加，直接影响带宽成本和基础设施需求。

性能基准测试：流、核心和内存

大规模处理 RTSP 请求需要平衡 CPU、内存和网络套接字资源。操作的 CPU 使用率不应超过85%，以便为网络中断或突发的数据摄入高峰预留足够的开销。

CPU和GPU效率

将视频源转码为自适应比特率 (ABR) 阶梯，无论涉及多少个版本，都会消耗大量的计算资源。许多 IP 摄像机会对多个视频流进行编码，从而减轻源端的转码负担。但是，在某些情况下，仍然需要进行高级转码。

• CPU 转码
  适用于简单的工作流程或较低的流数量。一个拥有 24 个 vCPU 的实例在转码为标准 ABR 阶梯（720p、360p、140p）时，可以处理多个 1080p 源流。
• GPU 加速
  适用于高密度环境，可显著提高流密度。将任务卸载到GPU（例如NVIDIA或AMD Xilinx），单个高端媒体加速器即可以100%的利用率处理多达8个1080p60fps流。

内存和连接限制

CPU负责转码运算，内存负责数据流传输。内存效率决定了服务器在出现瓶颈之前可以同时维持多少个RTSP会话。扩展性通常也受限于操作系统能够管理的并发TCP/UDP套接字数量。分辨率、帧速率和比特率越高，源服务器所需的内存就越多。

高可用性（HA）

在政府或应急响应等关键任务领域，单点故障是不可接受的。扩展 RTSP 需要周全的方案来实现可靠且经济高效的视频传输。如前所述，容器化策略可以确保即使单个接收服务器发生故障，整个安全运营中心 (SOC) 控制面板也不会瘫痪。

为传统 RTSP 视频集群添加智能

RTSP 复兴的真正威力在于团队在接收到视频流后可以进行哪些操作。例如，通过使用Wowza Streaming Engine中的自定义模块，团队无需更换任何硬件即可将传统摄像头改造为先进的边缘传感器。这些工作流程的现代化为安全录像提供了严格的监管链，同时仍然允许通过 WebRTC 或 HLS 将视频分发到基于浏览器的现代化控制面板。

利用目标检测和人工智能基础设施，对原本仅供人工观察的视频流执行车辆计数或运动分析等自动化任务。使用自定义模块将 ID3 元数据直接注入视频流。这些元数据可以标记特定事件，例如车辆越过指定线，从而允许玩家触发警报或实时记录数据。

优化互联医疗的未来

在媒体基础设施领域，价值并非总是体现在最新的硬件上。无论您是为政府机构管理庞大的传统摄像头群，还是为远程医疗构建低延迟监控解决方案，目标始终如一：从每个视频流中挖掘最大价值。

通过将RTSP的普及性、现代AI工作流的智能性以及分布式架构的规模优势相结合，企业可以将传统基础设施转变为面向未来的资产。创新并不需要最新的协议，只需要合适的架构就能为现有系统增添智能。

作者：Brian Ellis
译自：https://www.wowza.com/blog/rtsp-streaming-at-scale-architecture-and-performance-considerations