本文转载自：https://www.cnblogs.com/xiaozhi_5638/p/10949404.html
下面是在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越来越小。
未完待续