在NVIDIA Jetson 平台上运行Deepstream速度慢的常见解决办法

NVIDIA发布了最新的Deepstream 4.0.

关于Deepstream 4.0的一些新特新和应用,我们之前已经整理了笔记:

NVIDIA Deepstream 4.0笔记(一):加速基于实时AI的视频和图像分析

NVIDIA Deepstream 4.0笔记(二):智能零售场景应用

NVIDIA Deepstream 4.0笔记(三):智能交通场景应用

NVIDIA Deepstream 4.0笔记(四):工业检测场景应用

NVIDIA Deepstream 4.0笔记(五):仓储物流场景应用

NVIDIA Deepstream 4.0笔记(完结篇):如何开始使用Deepstream以及容器

光说不练假把式,光练不说傻把式,不少用户发现在Jetson嵌入式平台上运行Deepstream会遭遇到速度变慢,今天汇总几个常见解决方案:

1

确保Jetson时钟设置高。运行这些命令将Jetson时钟调高。

$ sudo nvpmodel -m --for MAX perf and power mode is 0
$ sudo jetson_clocks

2

pipeline中的某个插件可能运行缓慢。您可以测量pipeline中的每个插件的延迟,以确定是哪个插件很慢。

启用帧延迟测量

$ export NVDS_ENABLE_LATENCY_MEASUREMENT=1

启用对所有插件的处理延迟测量

$ export NVDS_ENABLE_COMPONENT_LATENCY_MEASUREMENT=1

3

在配置文件里的[streammux]选项组里,将batched-push-timeout设定成1/max_fps。例如max_fps是60fps,那么倒数是16.7ms.

4

在配置文件中[streammux] 选项组种,设定成视频流的实际高度和宽度,

( 可能就能减少一步缩放的过程吧,甚至还能降低功耗)

5

对于RTSP流输入,在配置文件的[streammux]组中,设置live-source=1。还要确保所有[sink#]组的sync属性都设置为0。

6

如果启用了二次推理,请尝试在配置文件的[secondary-gie#]组中增加批大小,以防要推理的对象数量大于批大小设置。

(二次推理的意思是:第一次基于全图像进行目标检测,第二次只针对第一次识别出的区域进行二次推理,比如第一次识别出车的区域,然后第二次针对识别出的车的区域进行推理,识别车类别/颜色)

7

在Jetson上,使用Gst-nvoverlaysink而不是Gst-nveglglessink,因为overlay的不需要使用GPU绘制(输出单元合并即可),GL的需要GPU上(跑shader之类的)

8

如果GPU是性能瓶颈,我们可以增加主检测器的推理时间间隔,通过修改应用程序配置中的[primary-gie]组的interval属性或Gst-nvinfer配置文件的interval属性来实现。(也就是说,GPU用满了,那么可以让主检测网络,原本是10ms推理检测一次,现在改成30ms…)

9

如果pipeline中的元素(估计是各个处理插件),卡死在等待可用的缓冲区上—这点可以通过观察是否CPU/GPU使用率都很低来确定,那么你就可以增加decoder所分配出来的缓冲区数量。请尝试通过设置[source#]组的num-extra-surfaces属性来增加解码器分配的缓冲区数量,这是 在应用程序或Gst nvv4l2decoder元素的num-extra-surfaces属性中。

10

如果你正在docker里,或者在控制台上运行应用程序,同时FPS性能很低 ,请在配置文件的[sink0]组中设置qos = 0.问题是由初始加载引起的。I/O操作使CPU陷入困境,而qos=1作为[sink0]组的默认属性,decodebin开始丢弃帧。为了避免这种情况,在配置文件中的[sink0]组中设置qos=0。

11

在NVIDIA®Jetson Nano™上,启动deepstream-segmentation-test测试后,几分钟后崩溃。系统重新启动,解决办法:NVIDIA建议您在运行此应用程序时通过DC电源连接器为Jetson模块供电。