下面是在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加上去，开始录像。

 

未完待续