[AI开发]DeepStream开发填坑记录

下面是在deepstream使用过程中碰到的一些坑:

(1)Pipeline中的Sink如果需要编码存文件或者推rtmp的流,注意控制编码的参数,编码质量不要太高。否则可能Sink带不动,整个Pipeline有数据积累,延时越来越高,程序占用的内存越来越大,最终crash。开发中碰到一个问题:刚开始延时2秒,后来延时慢慢增大,观察发现内存一点点增高。排除了推理性能不够的因素,最后定位编码推rtmp流的时候,分辨率太大(deepstream3.0没有硬编码的插件),导致编码性能不够,后来调整编码分辨率,延时没有积累。这个就像高速出口拥堵,拥堵长度慢慢增加,从匝道一直堵到了主干路。

(2)分析Pipeline的Src有很多种,file、rtsp、rtp等等。个人经验判断,使用rtp的方式最好(udpsrc插件)。如果需要分析N路视频,需要创建N个udpsrc,N个decoder,每路一个decoder,各自连接在一起,最终通过nvstreammux插件将这N条分支合并起来,再与推理插件连接。使用rtp的好处是:即插即用,与其他模块的耦合性低。一个系统中用于视频分析pipeline不可能独立存在,前面还需要给他推流的模块,而使用udp的方式接收rtp报文无疑是最方便的,哪路有数据哪路就开始工作,没数据的分支不影响有数据的分支。注意,如果有N路视频流,在用nvstreammux合并的时候,nvstreammux的 batched-push-timeout属性一定不能设置为-1,-1表示无限等待,必须等到每个分支都收到数据,如果这时候有一路没有视频流了(只有N-1路有数据),那么会无限等待,其他分支不能正常工作。可以设置一个合理的值,比如40000(40ms),过了这个时间如果某个分支没有数据,等待40ms之后就不会再等了。

(3)动态删除/添加/替换Pipeline中的插件非常麻烦,实际应用中,比如需要给某路视频录像,由于录像是有时间限制的,因此不可能一直使用filesink,当时间到了,我们需要将录像用到的filesink替换成fakesink,这个替换过程很复杂:先需要在filesink的上一个插件的src-pad上添加一个block 的probe,然后在这个probe中编写代码将filesink remove掉,创建新的fakesink,然后将fakesink连在原来filesink的位置,最后返回GST_PAD_PROBE_REMOVE,表示将block probe移除,整个流程结束。反过来,当需要录像时,一样需要添加一个block probe,然后在这个probe中将filesink加上去,开始录像。

(4)目标跟踪优先使用KLT算法,但是这个算法特别吃CPU,所以如果影响到整个pipeline的性能了,比如FPS变小了,可以切换到IOU,IOU的跟踪效果不如KLT,但是还凑合,关键还是检测模型要准,这样可以弥补一下IOU的缺陷。IOU相对而言对CPU依赖更小。

(5)在使用udpsrc接收其他模块发来的rtp数据时,由于其他模块可能出现故障会重启,重启后接着发送rtp数据,这时候pipeline中的rtph264depay可能会抛出NAL unit type 26 not supported的异常,这是因为之前piepline中可能有残留数据,导致depay失败。对于这个error,我们在bus_callback中捕获之后,不需要做任何处理,千万不要delete整个pipeline再recreate,这样会导致内存泄漏(至今没找到什么原因),最后越来越卡,FPS越来越小。

未完待续

 

posted @ 2019-05-30 14:38  周见智  阅读(3010)  评论(1编辑  收藏