Gstreamer与OPENCV交互中的APPSINK问题

项目中使用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摄像头