[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依賴更小。

未完待續