3. 视频分析基础
边缘AI视频分析系统的输入，本质上是一路或多路数字视频流。无论是从IP摄像头拉取实时画面，还是读取本地录像文件，系统工程师都必须理解视频流是如何封装、传输和编码的。如果只把摄像头当作“能出画面的黑盒”，那么在遇到延迟过高、花屏、掉帧、CPU占用率飙升等问题时，将无从下手。本章将深入剖析RTSP、RTMP、HLS三种主流流媒体协议的适用场景与差异，厘清帧率、分辨率、码率三者对AI推理性能的直接影响，并讲解H.264/H.265编码的核心概念，为后续多路摄像头推理系统的架构设计打下坚实基础。
上图展示了从视频源到AI推理引擎的完整链路。在实际边缘系统中，视频流格式的选择往往受限于摄像头硬件能力和网络环境，而编码格式则直接决定了边缘设备的解码负载。下面我们逐一展开。
3.1 视频流格式：RTSP、RTMP与HLS的选型逻辑
核心原理
视频流格式本质上是封装协议，它定义了视频数据如何被分割、添加时间戳、建立会话以及进行网络传输。三种主流协议各有其设计目标：
- RTSP（Real Time Streaming Protocol）：由IETF标准化，用于控制流媒体服务器（发起、暂停、停止）。它通常配合RTP（Real-time Transport Protocol）传输实际数据，默认端口为554。RTSP是IP摄像头最广泛支持的协议，延迟可控制在200-500ms以内，非常适合实时监控和AI推理。
- RTMP（Real-Time Messaging Protocol）：最初由Macromedia（现Adobe）开发，基于TCP，默认端口1935。RTMP将流媒体数据封装为FLV标签，设计初衷是低延迟直播（1-3秒）。由于基于TCP，RTMP在弱网环境下比RTSP更稳定，但协议开销较大，且现代浏览器已不再原生支持。
- HLS（HTTP Live Streaming）：由Apple提出，基于HTTP协议，默认端口80/443。HLS将视频切片为多个TS（MPEG-TS）或fMP4文件，通过m3u8索引文件管理播放列表。延迟通常在5-30秒，但优势在于可以穿透绝大多数防火墙，且天然支持CDN分发。
判断方法：如何选择适合AI推理的协议
对于边缘AI视频分析系统，选择协议的核心标准是端到端延迟和解码效率。以下是决策清单：
- 优先选择RTSP：如果摄像头支持RTSP，且网络环境为局域网或专网，应优先使用RTSP。它提供最低的延迟和最小的封装开销，便于直接送入解码器。
- 谨慎使用RTMP：当摄像头输出RTMP流（常见于部分网络直播摄像头），或需要推流到云端流媒体服务器时，才考虑RTMP。注意RTMP的TCP重传机制在丢包时会导致延迟增加。
- 避免直接使用HLS做实时推理：HLS的切片机制导致延迟过高，且频繁的HTTP请求会消耗边缘设备资源。HLS更适合录像回放或对实时性要求不高的场景。
案例拆解：多路RTSP拉流的工程实践
在某工厂安全生产监测项目中，需要接入32路1080P摄像头。初始方案中，部分摄像头通过RTMP推流至NVR，再从NVR拉取RTSP流。实际测试发现，RTMP链路在持续运行4小时后出现累积延迟，导致AI检测结果滞后于实际行为约3秒。分析后确认，RTMP的TCP拥塞控制机制在带宽波动时触发了缓冲。最终方案改为：所有摄像头直接输出RTSP流，边缘服务器通过VLC或FFmpeg库直接拉取，并设置tcp传输模式以避免UDP丢包。调整后延迟稳定在300ms以内。
| 协议 | 传输层 | 典型延迟 | AI推理适用性 | 备注 |
|---|---|---|---|---|
| RTSP | TCP/UDP | 200-500ms | ★ ★ ★ ★ ★ | 首选，需处理UDP丢包 |
| RTMP | TCP | 1-3s | ★ ★ ★ | 适合推流，不适合拉流推理 |
| HLS | HTTP/TCP | 5-30s | ★ | 仅用于回放或低实时性场景 |
常见误区与复盘
- 误区一：认为RTSP延迟高。实际上，RTSP本身不产生高延迟，延迟主要来自传输层（UDP丢包重传）或解码缓冲。
- 误区二：忽略摄像头子码流。多数摄像头提供主码流（高分辨率）和子码流（低分辨率）。AI推理可同时拉取两路：子码流用于快速检测，主码流用于细节分析。
- 复盘经验：在项目初期，应使用
ffprobe工具检查摄像头输出的实际编码参数，确认是否为H.264/H.265，以及是否有B帧（B帧会增加解码延迟）。
3.2 帧率与分辨率：AI推理的输入权衡
核心原理
帧率（FPS）和分辨率决定了AI推理引擎每秒需要处理的像素总量。假设分辨率为1920x1080，帧率为25fps，则每秒需要处理约5184万像素。对于边缘设备（如Jetson Orin、RK3588），这直接占用了内存带宽和算力。
帧率影响时间分辨率，即检测目标运动的流畅度。对于人员跌倒检测，15fps可能足够；对于高速运转的机械臂，则需要30fps以上。分辨率影响空间分辨率，即小目标（如远处的车辆、人脸）能否被检测模型识别。但分辨率过高会导致GPU/CPU解码压力增大，且模型推理时间变长。
判断方法：如何设定推理帧率与分辨率
- 确定业务需求：列出需要检测的事件类型。例如，入侵检测需要高帧率（≥20fps），而统计人流量只需5fps。
- 评估解码能力：使用
ffmpeg测试边缘设备对特定分辨率/编码格式的硬解码路数。例如，Jetson Orin NX支持16路1080P H.264硬解码。 - 设置跳帧策略：如果解码能力不足，可在解码后、推理前进行跳帧。例如，每3帧取1帧送入模型，但需注意跳帧可能导致快速移动目标漏检。
- 缩放输入尺寸：将解码后的图像缩放至模型输入尺寸（如640x640）。缩放会丢失细节，但能显著提升推理速度。
案例拆解：帧率与分辨率的平衡调优
在智慧园区车辆违停检测项目中，初始配置为每路摄像头25fps、1080P全帧率推理。边缘服务器（配置为8核CPU+GPU）接入8路后，GPU利用率达到95%，且出现周期性丢帧。通过分析nvidia-smi和top命令，发现解码器占用过高。优化措施：
- 将摄像头主码流分辨率降至720P，帧率降至15fps。
- 在解码后增加ROI（感兴趣区域）裁剪，仅对停车位区域进行推理。
- 设置推理间隔为100ms（即10fps推理），其余帧仅做解码丢弃。
调整后，GPU利用率降至60%，8路视频全部稳定运行，且检测准确率未明显下降，因为违停车辆是静止目标，低帧率不影响检测。
常见误区与总结
- 误区：盲目追求高分辨率。对于大多数目标检测模型（如YOLOv5），输入尺寸通常为640x640，1080P图像需要先缩放，缩放过程本身消耗CPU资源。
- 误区：忽略帧率对延迟的影响。高帧率意味着更短的曝光时间，在低照度环境下画面会变暗，影响检测效果。
- 总结：帧率和分辨率的选择应基于“最小满足业务需求”原则，而非“最大能力”原则。
3.3 视频编解码基础：H.264与H.265的工程影响
核心原理
视频编码通过去除空间冗余（帧内预测）和时间冗余（帧间预测）来压缩数据。H.264（AVC）是目前最广泛使用的编码标准，而H.265（HEVC）在相同画质下可节省约50%码率，但编码/解码复杂度更高。
在边缘AI系统中，编码格式直接影响解码器硬件支持和CPU负载。大多数边缘SoC（如瑞芯微RK3588、英伟达Jetson）内置了H.264/H.265硬解码模块，但H.265的硬解码路数通常少于H.264。例如，RK3588支持8K H.265解码，但仅支持4K H.264解码。
判断方法：选择编码格式的考量
- 存储与带宽：如果摄像头输出H.265，且边缘设备支持硬解，应优先使用H.265以降低带宽占用。
- 兼容性：如果系统需要与旧版NVR或第三方平台对接，H.264兼容性更好。
- 关键帧间隔（GOP）：编码器通常设置GOP为2秒（如50帧@25fps）。AI推理需要依赖I帧（关键帧）进行随机访问，如果GOP过大，拉流启动延迟会增加。
案例拆解：H.265解码导致的CPU瓶颈
在某智慧门店项目中，边缘盒子（RK3399）接入4路H.265摄像头。系统运行后CPU占用率持续100%，且视频画面卡顿。排查发现，RK3399的H.265硬解能力有限，实际调用的是软解（FFmpeg）。通过ffmpeg -hwaccel命令检查，确认硬件解码未生效。解决方案：
- 在摄像头端将编码格式改为H.264，码率控制为CBR（恒定码率）4Mbps。
- 在边缘设备上启用RKMPP硬件解码接口（Rockchip Media Process Platform）。
调整后，CPU占用率降至30%，4路视频流畅运行。此案例说明，编码格式的选择必须与边缘设备的硬件解码能力匹配。
常见误区与复盘
- 误区：认为H.265一定优于H.264。在算力受限的边缘设备上，H.265的解码开销可能抵消码率节省的优势。
- 误区：忽略B帧的影响。B帧需要参考前后帧，会增加解码延迟和内存占用。在实时推理场景，建议在摄像头端关闭B帧或设置较小的B帧数。
- 复盘经验：在项目验收前，务必使用
ffprobe检查实际拉取的视频流参数，确认编码格式、分辨率、帧率与预期一致。部分摄像头配置页面显示与实际输出不符。