优化 FPS 和延迟

这些表格显示了使用 OAK 相机通过 USB 3.2 Gen 1 (5 Gbps) 连接时可以预期的性能。在这些测试中，XLink 分块被禁用 (pipeline.setXLinkChunkSize(0))。有关代码示例，请参阅延迟测量。

要启用 10Gbps USB3 模式（当使用符合 USB 3.2 Gen 2 标准的线缆时），您必须在 Device 构造函数中显式设置它：

Python

1with dai.Device(maxUsbSpeed=dai.UsbSpeed.SUPER_PLUS) as device:

类型	分辨率	FPS	设置的 FPS	延迟 [ms]	带宽	直方图
彩色 (isp)	1080P	60	60	33	1.5 Gbps	link
彩色 (isp)	4K	28.5	30	150	2.8 Gbps	link
彩色 (isp)	4K	26	26	83 (标准差: 3.6)	2.6 Gbps	/
单色	720P/800P	120	120	24.5	442/482 Mbps	link
单色	400P	120	120	7.5	246 Mbps	link

以下是相同的测试，但还包括 OAK PoE 相机，它使用千兆以太网连接。相机直接连接到计算机，中间没有任何交换机或路由器。电源通过 M8 连接器提供。

oak_bandwidth_test.py 结果：下行 797 mbps，上行 264 mbps。
oak_latency_test.py 结果：平均值：5.2 ms，标准差：6.2。

类型	分辨率	FPS	设置的 FPS	PoE 延迟 [ms]	USB 延迟 [ms]	带宽
彩色 (isp)	1080P	25	25	51	33 标准差: 0.8	622 Mbps
彩色 (isp)	4K	8	8	148	80 标准差: 1.2	530 Mbps
彩色 (isp)	4K	8.5	10	530	80 标准差: 1.3	663 Mbps
单色	400P	90	90	12 标准差: 5.0	8 标准差: 0.47	184 Mbps
单色	400P	110	110	16 标准差: 9.4	8 标准差: 0.45	225 Mbps

由于带宽限制，我们为 PoE 测量设置了较低的 FPS。例如，4K 8 FPS 的延迟为 150ms，而 4K 10FPS 的延迟为 530ms，因为链路已饱和。

延迟测量的是帧时间戳 (imgFrame.getTimestamp()) 与帧在主机上接收时的时间戳 (dai.Clock.now()) 之间的时间。
直方图显示了从帧到主机的延迟随帧变化的程度。Y 轴表示在该时间发生的帧数，X 轴表示微秒。
带宽是根据指定的 FPS 流式传输指定帧所需的计算带宽。

编码帧

类型	分辨率	FPS	设置的 FPS	主机时间 [ms]	直方图
彩色视频 H.265	4K	28.5	30	210	link
彩色视频 MJPEG	4K	30	30	71	link
彩色视频 H.265	1080P	60	60	42	link
彩色视频 MJPEG	1080P	60	60	31	link
单色 H.265	800P	60	60	23.5	link
单色 MJPEG	800P	60	60	22.5	link
单色 H.265	400P	120	120	7.5	link
单色 MJPEG	400P	120	120	7.5	link

您还可以通过使用 DepthAI 的 Zero-Copy 分支来减少帧延迟。这将传递指针（在 XLink 级别）到 cv2.Mat 而不是进行内存复制（目前是这样做的），因此性能提升将取决于您使用的图像大小。（注意：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.create(dai.node.NeuralNetwork)
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/线程）	15	155 毫秒	15
6 个 SHAVE，2 个线程（1 个 NCE/线程）	14	149 毫秒	14
6 个 SHAVE，2 个线程（1 个 NCE/线程）	13	146 毫秒	13
6 个 SHAVE，2 个线程（1 个 NCE/线程）	10	141 毫秒	10
13 个 SHAVE，1 个线程（2 个 NCE/线程）	30	145 毫秒	11.6
13 个 SHAVE，1 个线程（2 个 NCE/线程）	12	128 毫秒	12
13 个 SHAVE，1 个线程（2 个 NCE/线程）	10	118 毫秒	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 完成并可以接受新帧进行处理。

本页目录

优化 FPS 和延迟View as Markdown

编码帧