項目中使用appsink獲取實時視頻流，並將獲取到的數據轉入OPENCV進行處理（在此使用imshow顯示）。
appsink使用new-sample信號獲取幀數據，使用中發現問題：
在獲取到995或者996幀的時候，遇到map.data==NULL的情況，但是顯示線程還是正常顯示，只是圖像有拖影，就像是CPU佔用過高時圖像處理不及時一樣，暫時未找出原因。
2020-02-25更新
由於一直是在獲取到995左右出問題，判斷大概是因爲1000的幀限制，因爲appsink中有個參數：max-size-time,默認值爲：1000.曾經信嘗試將此參數設置爲2000，還是出現一樣的問題。有懷疑過是內存限制問題，但是通過top實時查看內存佔用情況，整個過程中並沒有超過80%的佔用率。
查看gstreamer的源碼，看到gst_buffer_map方法中有調試信息GST_DEBUG_OBJECT輸出，因此通過使用--gst-debug=appsink:5,fdmemory:5參數查看調試信息（在此使用appsink和fdmemory是使用--gst-debug-level=5對所有日誌信息進行查看，估計是這兩個組件出的問題，用這兩個參數是把其他不必要的信息排除，方便查看），發現出問題的時候，是gstfdmemory.c中先出：fd:-1 maped(nil)信息。在 此確定應該是內存不足的問題，但是前面使用top查看實時內存佔用情況時，又沒有發現內存不足問題（好糾結啊……）。重新整理思路後發現，程序中使用的是rkisp這個源，顯示也是使用rkximagesink，正常顯示時CPU佔用很少，因爲整個過程中使用的是硬件資源進行處理，或許在此過程中，內存佔用不是我們看到的常規內存空間，而是像fdm（應該是這個，或者是dma）這樣的內存空間。然後就出現1000frame的空間將此內存空間耗盡，所以每次都在固定的995左右出問題。
解決方法：appsink的參數max-size-time設置爲500，程序正常運行，跑了2個小時，幀數到1W6以上，視頻正常，程序正常。
總結：問題出現的時候，就初步判斷應該是內存問題（因爲都是在995左右出問題，條件太明顯），但是顯示線程又一直工作，而且使用top查看內存佔用又正常，這影響了決斷。最初雖然定位到了max-size-time這個參數，但是並沒有往小的方面想，而是想着擴大這個參數。
學到的內容：
1、學會使用--gst-debug-level和--gst-deubg=name:level將組件中的debug信息輸出。
2、在Linux中使用script -a *.txt加exit將terminal中顯示的內容保存到*.txt中。
3、硬件資源組件使用的資源空間不是常規資源空間，使用常規命令並不能查看到資源使用情況。
附上我使用的平臺：
硬件：rk3399 NEO 4, 1G, 16G
系統：friendly ElEC(Linux NanoPi - NEO4 4.4.167)
攝像頭：130W MIPI CSI攝像頭