3、实时视频流处理基础：理解视频流采集、解码、帧处理、编码输出的基本流程，以及实时性指标（延迟、吞吐量、抖动）

在将 NPU delegate 应用于实时视频流任务之前，必须首先建立对视频流处理管线的系统性认知。实时视频流并非简单的“读帧-处理-写帧”循环，而是一条由采集、解码、帧处理、编码、输出五个环节构成的流水线，每个环节都有其特定的时间约束与资源消耗特征。NPU 的引入并非替代整条链路，而是对“帧处理”这一计算密集环节进行硬件加速。因此，理解各阶段的数据形态、耗时分布与实时性指标，是后续进行 NPU 部署与性能调优的前提。本章将拆解视频流处理的基本流程，并深入解析延迟、吞吐量、抖动这三个核心实时性指标的定义、测量方法与工程权衡。

上图展示了实时视频流处理的标准管线。从工程视角看，NPU delegate 的部署位置在“帧处理”环节，但它的性能表现会受到前后环节的制约。例如，如果解码输出的 YUV 格式与 NPU 要求的输入格式不一致，就需要额外的格式转换，这会增加 t3 的耗时。同样，如果编码器无法跟上 NPU 的处理速度，就会造成帧堆积，导致延迟增加。因此，理解整条链路的时序关系，是进行 NPU 加速部署的第一步。

3.1 视频流处理的核心流程与数据形态

视频流处理本质上是一条数据变换流水线。原始视频信号经过采集、压缩、传输、解压、分析、再压缩、输出的过程，每一步都涉及数据形态的转换。理解这些形态转换，有助于定位性能瓶颈。

3.1.1 采集：从物理世界到数字帧

采集环节负责将物理世界的光信号转换为数字图像帧。常见采集源包括：USB 摄像头（通过 UVC 协议传输）、MIPI CSI 接口摄像头（常用于嵌入式平台）、RTSP 网络流（从 IP 摄像机拉流）、以及本地视频文件。采集环节的关键参数包括分辨率（如 1920x1080）、帧率（如 30fps）、像素格式（如 NV12、YUYV）。采集延迟（t1）通常由硬件驱动和缓冲区大小决定，一般较低（几毫秒），但在网络拉流场景下，t1 可能包含网络缓冲延迟，会显著增大。

3.1.2 解码：从压缩码流到原始像素

解码环节将 H.264/H.265 等压缩码流还原为 YUV 原始像素数据。解码是计算密集型任务，尤其在 4K 分辨率下，CPU 软解会占用大量资源。硬件解码器（VPU/GPU）通常能将解码延迟（t2）控制在 2-5ms 内。解码输出的数据格式通常是 NV12 或 I420，这是后续 NPU 处理的标准输入格式之一。需要注意的是，解码器的输出帧率必须与采集帧率匹配，否则会出现丢帧或重复帧。

3.1.3 帧处理：NPU 加速的核心战场

帧处理环节是 NPU delegate 发挥作用的地方。该环节通常包含以下子步骤：

• 预处理：将 YUV 帧转换为 NPU 所需的输入格式（如 RGB、FP16），并进行缩放（如从 1080p 缩放到 640x640）、归一化（除以 255）等操作。这些操作在 CPU 上执行时耗时明显，在 NPU 上则可部分硬件加速。
• 推理：运行神经网络模型（如目标检测 YOLO、语义分割 DeepLab）。这是计算量最大的部分，NPU 的 TOPS 算力直接决定推理耗时。
• 后处理：解析 NPU 输出的张量，执行 NMS（非极大值抑制）、阈值过滤、坐标映射等操作，生成最终的检测框或分割掩码。后处理通常在 CPU 上完成，其耗时与检测目标数量相关。

在未使用 NPU 时，帧处理耗时（t3）可能高达 50-100ms（CPU 推理）；使用 NPU 后，t3 可降至 5-15ms，但预处理和后处理的耗时占比会相对上升，成为新的瓶颈。

3.1.4 编码与输出：重新压缩与传输

编码环节将处理后的帧重新压缩为 H.264/H.265 码流，用于存储或网络传输。硬件编码器的延迟（t4）通常较低（3-8ms）。输出环节（t5）包括网络协议封装（如 RTMP、WebRTC）和发送缓冲，网络状况不佳时 t5 会显著增加。在实时交互场景（如视频会议）中，端到端延迟要求通常低于 200ms；在直播场景中，可容忍 1-3 秒延迟。

3.2 实时性指标：延迟、吞吐量与抖动

实时视频流系统的性能评估不能只看单一指标，需要从延迟、吞吐量、抖动三个维度综合衡量。这三个指标相互关联，且常常存在权衡关系。

3.2.1 延迟（Latency）：端到端的“时间账本”

延迟定义为从事件发生（如摄像头捕捉到一帧）到该帧内容显示在用户屏幕上所经过的总时间。在视频分析场景中，延迟则指从帧采集到算法输出结果的时间。延迟的构成可分解为：L_total = L_capture + L_decode + L_process + L_encode + L_transmit。对于 NPU 加速系统，L_process 是主要优化对象，但若其他环节存在瓶颈，整体延迟依然无法降低。

测量方法：使用 clock_gettime() 或 std::chrono::high_resolution_clock 在管线各环节打点，记录时间戳。注意，测量本身会引入微小开销，应使用低开销的计时函数。对于视频流，通常测量 PTS（Presentation Timestamp）与实际显示时间的差值。

3.2.2 吞吐量（Throughput）：系统的“最大承载力”

吞吐量指单位时间内系统能处理的帧数，单位是 FPS（Frames Per Second）。吞吐量受限于管线中最慢的环节（瓶颈）。例如，若 NPU 推理速度为 100FPS，但 CPU 后处理只能处理 30FPS，则系统整体吞吐量为 30FPS。提升吞吐量的方法包括：

• 并行化：将采集、解码、推理、编码分配到不同线程或硬件单元，形成流水线并行。
• 批处理：将多帧拼接为一个 batch 输入 NPU，提高 NPU 利用率（但会增加单帧延迟）。
• 降低分辨率：在满足精度要求的前提下，将输入分辨率从 1080p 降至 720p，可显著提升吞吐量。

3.2.3 抖动（Jitter）：稳定性的“试金石”

抖动指帧间延迟的波动程度，通常用标准差或百分位数（如 P95-P5）表示。高抖动会导致画面卡顿、音画不同步，即使平均延迟很低。抖动的来源包括：CPU 调度延迟、内存带宽竞争、NPU 任务排队、网络拥塞等。在 NPU 部署中，抖动可能来自模型推理耗时的不稳定（如动态 shape 导致的计算量变化），或预处理耗时波动（如不同帧的缩放比例不同）。

3.3 案例拆解：智能安防摄像头 NPU 加速的实时性调优

本案例展示一个典型的智能安防摄像头场景，目标是在嵌入式平台（如 RK3588）上实现 1080p@30fps 的实时行人检测，并部署 NPU delegate。

背景与约束：设备使用 Rockchip RK3588 平台，集成 6 TOPS NPU。原始方案使用 CPU 运行 YOLOv5s，实测性能为 8 FPS，端到端延迟约 120ms，无法满足实时性要求。目标是将吞吐量提升至 30 FPS，端到端延迟降至 80ms 以内，抖动控制在 ±10ms。

初始现象与数据：通过 profiling 工具（如 RKNN Toolkit 的 time profiler）分析，发现 CPU 推理耗时 85ms，预处理耗时 12ms，后处理耗时 15ms，解码耗时 4ms，编码耗时 5ms。瓶颈明显在 CPU 推理。

优化过程：

1. NPU 部署：将 YOLOv5s 模型转换为 RKNN 格式，并设置 NPU delegate。转换后，推理耗时降至 12ms，但预处理耗时上升至 20ms（因为需要将 NV12 转换为 RGB 并缩放至 640x640）。
2. 预处理优化：利用 RK3588 的 RGA（Raster Graphic Acceleration）硬件进行格式转换和缩放，将预处理耗时从 20ms 降至 3ms。
3. 后处理优化：将 NMS 算法从 CPU 单线程改为多线程，并针对检测目标数量进行动态调整，后处理耗时从 15ms 降至 6ms。
4. 流水线并行：将解码、NPU 推理、编码分配到三个独立线程，通过队列连接，实现三级流水线。整体吞吐量从 8 FPS 提升至 32 FPS。

结果对比：

风险与代价：NPU 部署后，模型精度略有下降（mAP 从 0.52 降至 0.50），因为 RKNN 量化使用了 INT8。此外，RGA 硬件在极端分辨率下可能存在兼容性问题，需要增加 fallback 逻辑。流水线并行增加了内存占用（约 200MB），在内存受限设备上需谨慎评估。

复盘经验：NPU 加速并非“一键式”解决方案。在本案例中，NPU 将推理耗时降低了 85%，但预处理和后处理成为了新瓶颈。真正的性能提升来自于全链路协同优化：NPU 负责重计算，RGA 负责数据搬运，CPU 负责逻辑控制。此外，抖动控制的关键在于为 NPU 推理预留独占资源，避免与其他任务争抢。

3.4 常见误区与总结复盘

在实时视频流处理与 NPU 部署中，以下误区值得警惕：

总结复盘：实时视频流处理是一个系统工程，NPU delegate 是其中的关键加速器，但不是全部。理解采集、解码、帧处理、编码、输出各环节的数据形态与耗时特征，是进行性能优化的基础。延迟、吞吐量、抖动三个指标相互制约，需要根据具体应用场景（如直播、会议、安防）确定优先级。在部署 NPU 时，务必进行全链路 profiling，识别真正的瓶颈，并采用硬件加速、流水线并行、资源隔离等手段，实现稳定、低延迟、高吞吐的视频流处理。