2、多路摄像头系统基础：摄像头类型、接口协议（RTSP、USB、GigE）、视频流格式与基本参数
多路摄像头调度系统的设计，首先取决于对“摄像头”这一物理与逻辑混合体的深刻理解。在工业视觉、智能安防、自动驾驶或机器人感知场景中，摄像头不仅是图像采集器件，更是携带特定接口协议、数据格式与时间特性的独立子系统。本章将系统梳理摄像头的主流类型、三大核心接口协议（RTSP、USB、GigE）的工程特性、视频流的基本封装格式与关键参数，为后续的采集调度、预处理流水线设计以及推理任务分配奠定物理与协议基础。
2.1 摄像头类型与选型逻辑
摄像头从物理形态与内部架构上可分为三大类：USB/UVC 摄像头、RTSP/IP 网络摄像头以及GigE Vision 工业摄像头。它们并非简单的“接口不同”，而是在数据通路、时序控制、同步机制和系统资源消耗上存在本质差异。
USB 摄像头（符合 UVC 标准）将图像传感器、ISP（图像信号处理器）和 USB 控制器集成于一体。主机通过 UVC 驱动直接获取 YUV、MJPEG 或 H.264 格式的数据流。其优势在于即插即用、成本低、驱动生态完善；但受限于 USB Host 控制器的带宽与中断处理能力，多路并发时容易产生 CPU 中断风暴或带宽争抢。例如，USB3.0 理论带宽 5Gbps，实际可用约 3.2Gbps，若 4 路 1080p@30fps H.264（每路约 8Mbps）尚可应对，但若切换为 YUV 裸流（每路约 1.5Gbps），则 2 路即达瓶颈。
RTSP 网络摄像头内置视频编码器与网络协议栈，通过以太网口输出 H.264/H.265 压缩流。其核心价值在于远距离传输（100m 以上）与大规模组网。但代价是引入了编码延迟（通常 100-300ms）、网络抖动与丢包风险。在多路调度场景中，RTSP 摄像头需要额外的 RTSP 会话管理、解码资源分配以及针对 I 帧间隔的同步策略。
GigE Vision 摄像头是工业机器视觉的黄金标准。它基于千兆以太网，使用 GenICam 标准描述相机参数，支持硬件触发、PTP 精确时间同步（IEEE 1588）以及多相机广播模式。GigE 相机通常输出 Bayer RAW 或未压缩 YUV 数据，将 ISP 处理留给主机端，从而获得最高的图像质量与算法灵活性。其代价是需要主机具备强大的 CPU/GPU 处理能力，且对网络交换机有特定要求（如巨型帧、流量整形）。
| 维度 | USB/UVC | RTSP/IP | GigE Vision |
|---|---|---|---|
| 传输距离 | ≤5m（USB3.0） | ≤100m（网线） | ≤100m（可中继） |
| 数据格式 | YUV/MJPEG/H.264 | H.264/H.265/MJPEG | Raw/Bayer/YUV |
| 同步机制 | 无硬件同步 | RTCP 时间戳 | 硬件触发/PTP |
| CPU 负载 | 中（驱动+拷贝） | 高（解码） | 高（ISP+处理） |
| 典型路数 | 2-4 路 | 8-64 路 | 4-16 路（聚合） |
2.2 接口协议深度解析
接口协议决定了数据如何从传感器到达主机内存，也决定了调度系统需要处理的“边界条件”。
RTSP（Real Time Streaming Protocol）是一个应用层控制协议，负责协商媒体会话（SETUP、PLAY、TEARDOWN）。实际媒体数据通过 RTP（Real-time Transport Protocol）承载，通常基于 UDP 传输，RTCP 负责统计丢包与抖动。在多路调度中，RTSP 的关键参数包括：rtsp_transport（TCP/UDP）、stimeout（超时）、max_delay（缓冲）、reorder_queue_size（乱序重排）。若使用 FFmpeg 拉流，典型命令为：
ffmpeg -rtsp_transport tcp -i rtsp://192.168.1.64:554/stream1 \
-f rawvideo -pix_fmt bgr24 -s 1920x1080 -USB UVC 协议采用批量传输（Bulk）或等时传输（Isochronous）。等时传输保证带宽但可能丢帧，批量传输可靠但延迟不确定。UVC 还定义了视频流接口的格式描述符，主机通过 V4L2（Linux）或 DirectShow（Windows）访问。多路 USB 摄像头调度时，必须注意 USB 控制器（xHCI）的带宽分配表，避免将多路高带宽摄像头挂载在同一控制器下。
GigE Vision 协议基于 UDP 的 GVSP（GigE Vision Streaming Protocol）传输图像数据，使用 GVCP（GigE Vision Control Protocol）进行寄存器读写。其核心优势是支持多播——同一相机数据可同时发送给多个接收端，这对多进程或多机协作非常有利。但 GVSP 依赖巨型帧（Jumbo Frame，通常 9000 字节 MTU）来降低包头开销，若交换机未开启巨型帧，有效带宽将下降约 20%。
2.3 视频流格式与基本参数
视频流格式决定了预处理管线的起点。在多路调度系统中，我们通常面对三种数据形态：
- 压缩流（H.264/H.265）：需硬件解码器或 CPU 软解，解码后得到 YUV 帧。优点是带宽占用低，缺点是引入编码延迟与解码开销。
- 半压缩流（MJPEG）：每帧独立 JPEG 压缩，便于随机访问，但压缩率低（约为 H.264 的 1/5-1/10），且解码 CPU 占用高。
- 裸流（YUV/Bayer/RGB）：无压缩，数据量最大，但无编解码延迟，适合对实时性要求极高的场景（如自动驾驶）。
关键基本参数包括：分辨率（决定像素吞吐量）、帧率（决定时间粒度）、像素格式（YUV420/YUV422/RGB24/Bayer RGGB）、位深（8bit/10bit/12bit）以及色彩空间（BT.601/BT.709）。以 4 路 1080p@30fps 为例，若采用 YUV420 裸流，总带宽需求为：
1920 × 1080 × 1.5（YUV420 字节/像素）× 30fps × 4路 ≈ 373 Mbps这一数值已超过千兆网单链路可用带宽，因此必须采用压缩流或万兆网/多网卡聚合方案。
2.4 多路摄像头调度实战场景：8 路安防与 4 路工业视觉对比
为更直观地理解上述概念，我们对比两个典型部署场景。
场景 A：园区安防（8 路 RTSP）。摄像头为海康威视 DS-2CD3T86FWDV2-I8，输出 H.264 1080p@25fps，码率约 4Mbps。接入交换机为千兆，汇聚至一台 GPU 服务器（NVIDIA T4）。初始现象：8 路视频在 VLC 中播放正常，但接入自研调度系统后出现花屏与延迟累积。分析过程：通过 ffprobe 检查发现部分摄像头 I 帧间隔不一致（有的 25 帧，有的 50 帧），且 RTP 时间戳存在漂移。进一步抓包发现交换机开启了 IGMP Snooping，但摄像头未启用组播，导致单播流量泛洪。解决方案：① 在调度系统中设置 reorder_queue_size=1024 并启用 buffer_size=2MB；② 将摄像头码率固定为 CBR 4Mbps，关闭动态码率；③ 在交换机上为视频 VLAN 配置 QoS 优先级。结果：延迟从 800ms 降至 200ms，花屏消失。复盘经验：RTSP 多路调度的首要风险是网络拓扑与码率波动，而非解码性能。
场景 B：工业质检（4 路 GigE）。相机为 Basler acA2440-75uc（500 万像素，Bayer RGGB 8bit，75fps）。初始目标：4 路同步采集并实时输出缺陷检测结果。关键约束：必须保证 4 路相机曝光时刻一致，否则运动物体测量误差超过 ±1mm。实施步骤：① 使用相机硬件触发线连接至 PLC，PLC 输出 50Hz 脉冲；② 开启 PTP 同步（IEEE 1588），交换机为思科 SG350 并启用边界时钟模式；③ 设置巨型帧 MTU=9000；④ 主机使用 Intel I210 网卡并开启 RSS（接收端缩放）。结果：4 路采集帧率稳定在 50fps，时间戳偏差小于 10μs。风险与代价：PTP 同步依赖交换机质量，低端交换机可能引入 100μs 级抖动；此外，巨型帧需统一配置，否则数据包被分片导致丢包。
2.5 总结与选型决策清单
多路摄像头系统的设计应遵循“先定数据形态，再选协议，最后定硬件”的路径。以下为本章核心决策清单：
- 明确路数与距离：≤4 路且距离近 → USB；≥8 路且分散 → RTSP；需要同步或高画质 → GigE。
- 确认数据格式：若算法需要 RAW 数据（如高精度测量），只能选 GigE；若仅需视觉检测，H.264 压缩流可大幅降低存储与带宽。
- 评估同步需求：多相机拼接或 3D 重建必须硬件触发 + PTP；普通监控仅需 RTCP 时间戳即可。
- 计算带宽预算：使用公式
分辨率 × 像素字节 × 帧率 × 路数估算裸流带宽，再考虑压缩比与协议开销（通常加 10%-20% 余量）。 - 验证驱动与 SDK 兼容性：GigE 相机需 GenICam 客户端，RTSP 需确认编码格式（H.264 Baseline/Main/High），USB 需确认 UVC 版本（1.1 支持 H.264）。