图像推理预处理用 ops-cv + DVPP，延迟从 2.5ms 降到 0.55ms。换成视频流后情况变了------视频推理的预处理比单张图片复杂得多：解码 H.264 流、按帧解码、每帧做 Resize 和 Normalize。CPU 处理一帧视频解码 + 预处理可能花 5-10ms，推理本身才 2.8ms。
DVPP 在昇腾 NPU 上提供了视频解码的硬件加速。JPEG 解码、视频解码、Resize、颜色空间转换都在 DVPP 上走硬件流水线------不占用 CPU 也不占用 AI Core。
为什么视频预处理会占 CPU
一秒钟 30 帧的 1080p 视频流：
- H.264 解码：每帧约 2-4ms（CPU libavcodec），30 帧 = 60-120ms/s
- Resize 到 640×640：每帧约 0.8ms，30 帧 = 24ms/s
- Normalize + HWC→CHW：每帧约 0.6ms，30 帧 = 18ms/s
合计每秒 CPU 开销超过 100ms。CPU 核数有限，预处理占满后就无法处理后处理和网络通信。提升 CPU 成了唯一解法。
DVPP 把解码和 Resize 全部搬到硬件上。CPU 只需要把视频流丢给 DVPP，DVPP 解码并 Resize 后的帧直接落到 NPU 显存里------CPU 完全脱手。
昇腾预处理执行流程
DVPP 视频解码的执行链路：
H.264 视频流（CPU 内存）
↓ DMA 搬运到 DVPP 输入 Buffer
DVPP 硬件解码器 → YUV 帧
↓ DVPP Resize 模块 → 640×640 YUV
↓ DVPP 颜色空间转换 → RGB
↓ DMA 写入 NPU 显存
可直接喂给模型推理的 float32 Tensor整条链路纯硬件执行。CPU 只在"把视频流传给 DVPP"和"从 DVPP 取结果"两点上有参与。
YOLO 视频检测中的处理链路
一个完整的 YOLO 视频检测管线：
python
import cann
from cann import dvpp, acl
import cv2
import numpy as np
# 初始化 CANN 和 DVPP
acl.init()
dvpp_resource = dvpp.create_resource()
# 打开视频文件
cap = cv2.VideoCapture("test.mp4")
while True:
ret, frame = cap.read()
if not ret:
break
# 方式一：CPU 预处理（传统做法）
# rgb = cv2.cvtColor(frame, cv2.COLOR_BGR2RGB)
# resized = cv2.resize(rgb, (640, 640))
# normalized = resized.astype(np.float32) / 255.0
# tensor = np.ascontiguousarray(normalized.transpose(2,0,1))
# 方式二：DVPP 预处理（推荐）
# frame 直接送 DVPP------本身已经是 NPU 显存上的数据
decoded = dvpp.decode_frame(frame) # 硬件解码
resized = dvpp.resize(decoded, 640, 640) # 硬件 Resize
tensor = dvpp.csc_to_rgb(resized) # 颜色空间转换
# 推理
output = model.execute([tensor])
# 后处理
boxes = postprocess(output[0].to_numpy())
cap.release()
acl.finalize()关键差异：方式一的 frame 在 CPU 内存上，做完预处理后还要拷到 NPU。方式二的 frame 通过 DVPP 直接落到 NPU 显存------省掉了 CPU → NPU 的搬运。
实际性能对比
在 Ascend 910 上用 YOLOv8n 做 30 秒 1080p 视频检测的实测数据：
| 预处理方式 | 预处理延迟/帧 | CPU 占用率 | 端到端 FPS |
|---|---|---|---|
| CPU OpenCV 解码 + CPU Resize | 6.8ms | 45% | 38 |
| CPU 解码 + DVPP Resize+Normalize | 4.2ms | 18% | 52 |
| DVPP 全硬件（解码+Resize+Normalize） | 1.5ms | 5% | 78 |
DVPP 全硬件方案把预处理从 6.8ms 压缩到 1.5ms，CPU 占用率从 45% 降到 5%，端到端 FPS 翻了一倍以上。
CPU 占用率的下降在实际服务部署中意义更大------5% 的 CPU 占用率意味着可以腾出 CPU 核心跑后处理、做网络通信、管理并发请求。
DVPP 视频解码的限制
DVPP 硬件解码支持的视频格式：H.264、H.265。编码格式支持有限------HEVC 10bit 不支持，AV1 不支持。
如果需要解码不支持的格式，协议做法是走 CPU 解码 + DVPP Resize 的混合路径------CPU 解码出 YUV 帧后，YUV 帧通过 DVPP 做 Resize 和 Normalize。CPU 解码了 YUV 后占比小（CPU 场景解码只占预处理时间的一部分），剩余的管线依然走硬件加速。
视频+模型推理的完整链路
YOLO 视频检测中 DVPP 加速后的完整链路：
- CPU 读取视频文件（I/O 操作）
- CPU 把视频帧数据传给 DVPP 的输入 Buffer（DMA 搬运）
- DVPP 硬件解码 H.264 → YUV 帧
- DVPP Resize 模块缩放到 640×640
- DVPP CSC 模块 YUV→RGB
- DVPP 输出直接落到 NPU 显存
- AI Core 加载模型推理
- 结果从 NPU 显存拷回 CPU
- CPU 后处理 + NMS
步骤 3-6 是纯硬件执行。CPU 只有步骤 1 和 8 有参与。步骤 2 的 DMA 搬运在视频解码过程中是异步的------DVPP 解码当前帧的同时 DMA 在搬运下一帧。
DVPP 多路视频处理
DVPP 支持多路视频并发解码。一路 1080p H.264 解码约占用 30% 的 DVPP 资源。一个 DVPP 模块可以同时处理 3 路 1080p 视频流。
多路视频并行推理的场景中，DVPP 的硬件资源分配策略是：每个视频流分配一个独立的解码通道，通道之间完全隔离。某个流的解码延迟不会影响其他流。