3. 摄像头接口与多路视频采集
在 Intel 边缘视觉系统里，摄像头接口决定了“能接几路、每路能跑多快、CPU 要花多少力气搬运数据”。MIPI CSI、USB、GigE Vision 和 IP Camera 这四类接口，物理层、协议栈、带宽模型和 CPU 占用差异很大。选型时不能只看“能不能出图”，而要看三件事：单路带宽是否够、多路聚合后总线是否饱和、数据到达内存后由谁搬运。下面按接口特性、带宽估算和多路方案依次展开。
一、四类接口的物理与协议特性
MIPI CSI-2 是嵌入式平台最常用的传感器直连接口，走差分对，典型 2~4 lane，每 lane 速率常见 1.5~2.5 Gbps。它没有标准热插拔，通常直接焊在板或通过 FPC 连接，数据由 ISP 或 CSI 接收器写入内存，CPU 占用极低。Intel 平台本身不直接暴露 CSI，需要借助 IPU（图像处理单元）或通过 MIPI 转 PCIe/USB 桥接芯片接入，例如 Intel Atom/Core 平台搭配 IPU6 或第三方 CSI-to-PCIe 采集卡。
USB 摄像头 分 UVC 免驱和工业 USB3 Vision 两类。USB 2.0 实际有效带宽约 35~40 MB/s，USB 3.0/3.1 Gen1 约 350~400 MB/s，Gen2 约 900 MB/s。UVC 走等时传输，带宽预留但无重传，丢包表现为花屏；USB3 Vision 走批量传输，有重传但延迟略高。USB 的优点是即插即用、线缆长、成本低，缺点是所有设备共享控制器带宽，且中断和拷贝会消耗 CPU。
GigE Vision 基于千兆以太网，使用 GVCP 控制 + GVSP 流传输，单口理论 1 Gbps，实际有效约 110~118 MB/s。它支持 PoE 供电、线缆可达 100 米、多相机可挂同一交换机。缺点是千兆口容易成为瓶颈，且需要网卡支持巨帧（Jumbo Frame）和中断合并来降低 CPU 占用。万兆（10GbE）可把单口提升到约 1.1 GB/s，但交换机和网卡成本上升。
IP Camera 本质是“网络摄像机 + 编码”，输出 RTSP/H.264/H.265 流。它不直接给原始帧，而是给压缩码流，因此带宽需求远低于原始视频，但解码要消耗 CPU 或 GPU。1080p@25fps 的 H.264 码流通常 2~8 Mbps，H.265 可再降 30%~50%。IP Camera 适合远距离、多路、已有网络布线的场景，但端到端延迟通常比 CSI/USB 高 100~300 ms。
二、带宽需求怎么算
原始视频带宽公式为：带宽 = 宽 × 高 × 每像素字节 × 帧率。以 1920×1080、RGB 24bit（3 字节）、30fps 为例：1920×1080×3×30 ≈ 186.6 MB/s。若用 YUYV 16bit（2 字节），则约 124.4 MB/s；若用 MJPEG 压缩，通常可降到 10~30 MB/s。这个数字是判断接口能否承载多路的关键。
举例：一台 Intel NUC 用 USB3.0 接 4 路 1080p YUYV 相机，每路约 124 MB/s，4 路合计约 498 MB/s，已超过 USB3.0 实际可用 400 MB/s，必然丢帧。若改用 MJPEG 压缩，每路约 20 MB/s，4 路合计 80 MB/s，则余量充足。若用 GigE Vision 接 4 路 1080p 原始帧，每路 124 MB/s，单千兆口只有 115 MB/s，连一路都跑不满，必须改用万兆或让相机内部压缩。
三、Intel 平台上的多路采集方案
方案 A：CSI + IPU 直连。适合 1~4 路低延迟场景。Intel 第 11 代以后部分平台带 IPU6，可接多路 MIPI 传感器，数据直接进内存，CPU 几乎不参与搬运。缺点是路数受 IPU 通道数限制，且驱动和 ISP 调优复杂。若平台无 IPU，可用 MIPI 转 PCIe 采集卡，例如 4 路 CSI 转 PCIe x4，每路独立 DMA。
方案 B：USB3.0 多路。适合 2~4 路 1080p 压缩流。关键是把相机分散到不同 xHCI 控制器，避免单控制器带宽争抢。用 lsusb -t 查看拓扑，确保每路相机挂在独立 root hub 下。同时开启 UVC 的 MJPEG 或 H.264 输出，降低总线压力。
方案 C：GigE Vision 多路。适合 4~8 路，且需要长线缆和 PoE。用千兆交换机时，注意上行口带宽：8 路 1080p 压缩流每路约 20 MB/s，合计 160 MB/s，超过单千兆上行 115 MB/s，需用万兆上行或双千兆绑定。网卡侧开启巨帧（MTU 9000）和 RSS 多队列，把中断分散到多核。
方案 D：IP Camera 多路。适合 8~16 路，已有网络布线。带宽不是瓶颈，瓶颈在解码。1080p H.264 解码单路约占用 5%~10% 单核，16 路需 1~2 个物理核专门解码。可用 Intel Quick Sync Video（QSV）硬解，把 CPU 占用降到 1%~2% 每路。用 ffmpeg -hwaccel qsv -i rtsp://... -f rawvideo -pix_fmt nv12 - 可验证硬解通路。
四、多路采集的配置检查清单
| 检查项 | 判断依据 | 常见问题 |
|---|---|---|
| 单路带宽 | 宽×高×字节×帧率 | 用 RGB 原始流跑 4 路 USB3 |
| 总线余量 | 总带宽 ≤ 接口可用 × 0.7 | 千兆口接 4 路原始 GigE |
| 控制器分布 | lsusb -t / lspci | 4 路相机挂同一 xHCI |
| CPU 占用 | top / perf 观察软中断 | USB 中断集中单核 |
| 解码能力 | QSV / GPU 硬解 | 16 路 IP Camera 纯软解 |
| 时间戳同步 | PTP / 硬件触发 | 多路帧时间不对齐 |
实际部署时，建议先用一路相机跑通，记录 v4l2-ctl --stream-mmap --stream-count=300 或 ffmpeg -f v4l2 -i /dev/video0 -f null - 的帧率和丢帧数，再逐路增加，观察 dmesg 中的 uvcvideo: Failed to submit URB 或网卡的 rx_dropped 计数。一旦出现丢帧，优先降分辨率、降帧率或切压缩格式，而不是盲目加 CPU。
总结：MIPI CSI 适合低延迟少路数，USB 适合灵活中低路数，GigE Vision 适合中高路数长距离，IP Camera 适合高路数已有网络。选型时先算带宽，再看控制器和 CPU 占用，最后用逐路增加的方式验证稳定性。