DepthAI v2 has been superseded by DepthAI v3. You are viewing legacy documentation.
概览硬件软件云平台
此页面由 AI 自动翻译。查看英文原版
DepthAI 组件
DepthAI 教程
DepthAI 感知
ROS
神经网络
DepthAI API 参考

本页目录

  • 编码帧
  • PoE 延迟
  • 带宽
  • 测量操作时间
  • 运行 NN 时降低延迟
  • 增加 NN 资源
  • 将摄像头 FPS 降低到与 NN FPS 匹配
  • NN 输入队列大小和阻塞行为

优化 FPS 和延迟

这些表格显示了使用 OAK 相机通过 USB 3.2 Gen 1 (5 Gbps) 连接时可以预期的性能。测试中禁用了 XLink 分块 (pipeline.setXLinkChunkSize(0))。有关代码示例，请参阅 延迟测量。
WhatResolutionFPSFPS setLatency [ms]BandwidthHistogram
Color (isp)1080P6060331.5 Gbpslink
Color (isp)4K28.5301502.8 Gbpslink
Color (isp)4K262683 (Std: 3.6)2.6 Gbps/
Mono720P/800P12012024.5442/482 Mbpslink
Mono400P1201207.5246 Mbpslink
以下是相同的测试，但还包括使用千兆以太网连接的 OAK PoE 相机。相机直接连接到计算机，中间没有任何交换机或路由器。电源通过 M8 连接器提供。
WhatResolutionFPSFPS setPoE Latency [ms]USB Latency [ms]Bandwidth
Color (isp)1080P25255133 Std: 0.8622 Mbps
Color (isp)4K8814880 Std: 1.2530 Mbps
Color (isp)4K8.51053080 Std: 1.3663 Mbps
Mono400P909012 Std: 5.08 Std: 0.47184 Mbps
Mono400P11011016 Std: 9.48 Std: 0.45225 Mbps
由于带宽限制，我们为 PoE 测量设置了较低的 FPS。例如，4K 8 FPS 的延迟为 150ms，而 4K 10FPS 的延迟为 530ms，因为链路已饱和。
  • 延迟测量的是帧时间戳 (imgFrame.getTimestamp()) 和帧在主机上接收时的时间戳 (dai.Clock.now()) 之间的时间。
  • Histogram 显示了从帧到主机的时间每帧的变化情况。Y 轴表示在该时间发生的帧数，X 轴表示微秒。
  • Bandwidth 是以指定 FPS 流式传输指定帧所需的计算带宽。

编码帧

WhatResolutionFPSFPS setTime-to-Host [ms]Histogram
Color video H.2654K28.530210link
Color video MJPEG4K303071link
Color video H.2651080P606042link
Color video MJPEG1080P606031link
Mono H.265800P606023.5link
Mono MJPEG800P606022.5link
Mono H.265400P1201207.5link
Mono MJPEG400P1201207.5link
您还可以通过使用 DepthAI 的 Zero-Copy 分支来减少帧延迟。这将传递指向 cv2.Mat 的指针（在 XLink 级别），而不是进行内存复制（目前是这样做的），因此性能提升将取决于您使用的图像大小。 （注意：API 不同，并且 message_zero_copy 分支上的所有功能并非都可用）

PoE 延迟

在 PoE 上，延迟可能会因多种因素而有很大差异：
  • 网络本身。例如，如果您在一个拥有许多节点的庞大网络中，与使用直接连接相比，延迟会更高。
  • 存在带宽瓶颈：
    • 也许某个网络链路是 10mbps/100mbps 而不是完整的 1gbps（由于交换机/网卡...）。您可以使用 PoE 测试脚本 进行测试（speed 应为 1000）。
    • 网络/计算机被其他流量饱和。您可以使用 OAK 带宽测试 脚本测试实际带宽。使用直接连接，我获得了约 800mbps 的下行链路和约 210mbps 的上行链路。
  • 计算机的网卡设置，文档在此
  • 100% OAK Leon CSS（CPU）使用率。Leon CSS 核心负责 POE 通信（参见此处文档），如果 CPU 使用率达到 100%，它将无法像应有的那样快速处理通信。解决方法： 请参阅 CPU 使用率 文档。
  • 提高 PoE 延迟的另一种潜在方法是微调网络设置，例如 MTU、TCP 窗口大小等（此处 获取更多信息）

带宽

使用大型、未编码的帧，即使在 30FPS 下，也很快会使带宽饱和，尤其是在 PoE 设备（1gbps 链路）上：
Command Line
14K NV12/YUV420 帧：3840 * 2160 * 1.5 * 30fps * 8bits = 3 gbps
21080P NV12/YUV420 帧：1920 * 1080 * 1.5 * 30fps * 8bits = 747 mbps
3720P NV12/YUV420 帧：1280 * 720 * 1.5 * 30fps * 8bits = 331 mbps
4
51080P RGB 帧：1920 * 1080 * 3 * 30fps * 8bits = 1.5 gbps
6
7800P 深度帧：1280 * 800 * 2 * 30fps * 8bits = 492 mbps
8400P 深度帧：640 * 400 * 2 * 30fps * 8bits = 123 mbps
9
10800P 单声道帧：1280 * 800 * 1 * 30fps * 8bits = 246 mbps
11400P 单声道帧：640 * 400 * 1 * 30fps * 8bits = 62 mbps
公式中的第三个值是字节/像素，对于 NV12/YUV420 是 1.5，对于 RGB 是 3，对于深度帧是 2，对于单声道（灰度）帧是 1。对于视差帧，它是 1（正常）或 2（亚像素模式）。减少带宽的几种选择：
  • 使用设备上的 VideoEncoder 对帧（H.264、H.265、MJPEG）进行编码
  • 降低 FPS/分辨率/流的数量

测量操作时间

如果用户将 depthai 级别设置为 trace（参见 DepthAI 调试级别），depthai 将记录每个节点/进程的操作时间，如下所示。
Command Line
1[SpatialDetectionNetwork(1)] [trace] SpatialDetectionNetwork 同步耗时 '70.39142' ms。
2[StereoDepth(4)] [trace] Warp 节点耗时 '2.2945' ms。
3[system] [trace] EV:0,S:0,IDS:27,IDD:10,TSS:2,TSN:601935518
4[system] [trace] EV:0,S:1,IDS:27,IDD:10,TSS:2,TSN:602001382
5[StereoDepth(4)] [trace] Stereo 耗时 '12.27392' ms。
6[StereoDepth(4)] [trace] 'Median+Disparity to depth' 流水线耗时 '0.86295' ms。
7[StereoDepth(4)] [trace] Stereo 后处理（总计）耗时 '0.931422' ms。
8[SpatialDetectionNetwork(1)] [trace] NeuralNetwork 推理耗时 '62.274784' ms。
9[StereoDepth(4)] [trace] Stereo 校正耗时 '2.686294' ms。
10[MonoCamera(3)] [trace] Mono ISP 耗时 '1.726888' ms。
11[system] [trace] EV:0,S:0,IDS:20,IDD:25,TSS:2,TSN:616446812
12[system] [trace] EV:0,S:1,IDS:20,IDD:25,TSS:2,TSN:616489715
13[SpatialDetectionNetwork(1)] [trace] DetectionParser 耗时 '3.464118' ms。

运行 NN 时降低延迟

在上面的示例中，我们只传输帧，而没有在 OAK 相机上执行其他任何操作。本节将重点介绍在 OAK 上运行 NN 模型时如何降低延迟。

增加 NN 资源

降低延迟的一个选项是增加 NN 资源。这可以通过更改分配的 NCE 和 SHAVE 的数量来完成（参见 HW 加速器 文档在此）。编译工具 可以为更多的 SHAVE 核心编译模型。要分配更多的 NCE，您可以使用下面的 API：
Python
1import depthai as dai
2
3pipeline = dai.Pipeline()
4# nn = pipeline.createNeuralNetwork()
5# nn = pipeline.create(dai.node.MobileNetDetectionNetwork)
6nn = pipeline.create(dai.node.YoloDetectionNetwork)
7nn.setNumInferenceThreads(1) # 默认使用 2 个线程
8nn.setNumNCEPerInferenceThread(2) # 默认，每个线程使用 1 个 NCE
模型通常在最高 FPS 下运行，使用 2 个线程（1 个 NCE/线程），并且模型编译为 AVAILABLE_SHAVES / 2。YoloV7-tiny 的 FPS 和延迟比较示例：
NN 资源Camera FPS延迟NN FPS
6 个 SHAVE，2 个线程（1 个 NCE/线程）15155 毫秒15
6 个 SHAVE，2 个线程（1 个 NCE/线程）14149 毫秒14
6 个 SHAVE，2 个线程（1 个 NCE/线程）13146 毫秒13
6 个 SHAVE，2 个线程（1 个 NCE/线程）10141 毫秒10
13 个 SHAVE，1 个线程（2 个 NCE/线程）30145 毫秒11.6
13 个 SHAVE，1 个线程（2 个 NCE/线程）12128 毫秒12
13 个 SHAVE，1 个线程（2 个 NCE/线程）10118 毫秒10

将摄像头 FPS 降低到与 NN FPS 匹配

降低 FPS 以不超过 NN 功能通常能提供最佳的延迟性能，因为 NN 能够在新帧可用时立即开始推理。例如，使用 15 FPS，总延迟约为 70 毫秒，从捕获时间（曝光结束和 MIPI 读取开始）开始测量。此时间包括以下内容：
  • MIPI 读取
  • ISP 处理
  • 预览后处理
  • NN 处理
  • 流式传输到主机
  • 最后，最终到达应用程序的额外延迟
注意：如果 FPS 略微提高到 19..21 FPS，会出现大约 10 毫秒的额外延迟，我们认为这与固件有关。我们正在积极寻求改进以降低延迟。

NN 输入队列大小和阻塞行为

如果应用程序具有 detNetwork.input.setBlocking(False)，但队列大小未更改，则以下调整可能有助于提高延迟性能：通过添加 detNetwork.input.setQueueSize(1)，同时将摄像头 FPS 设置回 40，我们获得约 80..105 毫秒的延迟。 非确定性行为的原因之一是摄像头以不同的速率（25 毫秒帧时间）生成，而 NN 已完成并可以接受新帧进行处理。