DeepStream插件启动出错问题
NVIDIA DeepStream是基于GStreamer框架开发的，增加了一些适应视频识别推理跟踪方面的自己定制的扩展以及内置了提供了YOLO和Faster-RCNN的实现而已，需要简单看一下DeepStream的文档https://docs.nvidia.com/metropolis/deepstream/dev-guide/index.html (说实话那些文档写得真的很不咋样，超简单，很多都没说清楚的，没有GStreamer的基础估计理解也费劲，尤其API文档更是估计使用的doxygen机械式地从代码中抽取注释生成的，而那些注释基本上是说了等于没说，应付式的注释你懂的)再琢磨一下附带的samples示例代码，能懵懂上手，但如果之前做过GStreamer上的视频播放软件方面的开发或维护，对掌握DeepStream上的开发应该是驾轻就熟的。
本人前些年因当时公司的视频播放软件就是在GStreamer上开发的，在GStreamer上干过三四年，虽然出来后忘得差不多了，现在重新捡起来还是挺快，起码之前自己写的ppt和一些问题记录以及GStreamer的源码分析记录都还在，没想到现在又有了用处，要是没有前些年的经验积累，遇到问题恐怕会很懵，GStreamer的异常报错机制设计和某些代码写得实在是很烂，报错基本上都是一眼根本看不出哪里出了问题的, 加上GStreamer是使用的glib开发的，glib说白了就是在C上面用struct和宏定义为基础强行模拟出面向对象的编程，很怪异但有些人喜爱的搞法，我倒感觉这种搞法实在是得不偿失，还不如直接用C++写呢，C和C++代码以及编译器在嵌入式环境里基本上都是支持的，性能上也差别不大，占用资源嘛，现在的硬件一般都比较充裕了，早已不是那个内存只有几M的年代了。GStreamer的优点就是plugin机制，扩展自己的代码且不影响已有的框架代码比较容易，其他我觉得乏善可陈，但是Deepstream在GStreamer上开发的，又不得不用它了。那为什么要用DeepStream呢？在NVIDIA的板子上做AI视频识别应用层级开发时你得需要个框架啊，人力资源不够又没有现成的合适的框架代码积累时，DeepStream当然是最合适的选择了，另外呢，按照NVIDIA的说法，整合了TensorRT，好呆在CUDA上做了优化，还能支持DLA的使用，所以用NVIDIA的板子当然选择NVIDIA的软件框架是最佳选择了。
使用DeepStream以来遇到了不少问题，解决了但没有做记录，对于安装上的misguide导致板子不断重启和插件启动等问题做了记录，先记下来备查也供分享，后面遇到其他问题了再继续补充记录。
近日在一个docker发布环境里安装DeepStream后使用一个封装了C3D模型(自行训练出的模型，用于识别动作，采用C++自行封装调用接口)的plugin时（当然，C3D模型运行所需的支持包都基本安装了），发现插件老是创建不了，把GStreamer的debug打开也看不到任何有用的提示信息，发布时间节点又到了，真是抓狂，把GST_DEBUG设置到最大后慢慢看启动日志，看到插件创建启动时都先去访问了同一个文件 ~/.cache/gstreamer-1.0/registry.aarch64.bin，比如说你使用的root用户身份，那路径就是/root/.cache/gstreamer-1.0/registry.aarch64.bin，意识到GStreamer在系统启动时插件创建和注册后做了集中缓存，下次启动时为了加速估计是到这个缓存的register库里去找，找不到也没报错，直到后面应用程序代码使用这个插件的element时为nil才知道有错了，这个设计根本没考虑到插件创建报错后没有注册，下次启动时应该再试着再次注册到缓存库的问题，而是只要在缓存库存在插件信息就不试着创建插件了，上次启动没有创建成功的插件也不再去试着创建并注册，这点是很弱智的bug，于是试着把/root/.cache/gstreamer-1.0/registry.aarch64.bin删掉，然后启动系统，果然触发了封装c3d模型的插件(对应的so库文件是libnvdsgst_dsc3d.so)的创建和注册，于是在创建时出错的准确原因也就出来了:
0:00:01.948005316 968 0x5592173800 WARN GST_PLUGIN_LOADING gstplugin.c:792:_priv_gst_plugin_load_file_for_registry: module_open failed: libboost_python-py27.so.1.65.1: cannot open shared object file: No such file or directory
(gst-plugin-scanner:968): GStreamer-WARNING **: 08:42:13.448: Failed to load plugin '/usr/lib/aarch64-linux-gnu/gstreamer-1.0/deepstream/libnvdsgst_dsc3d.so': libboost_python-py27.so.1.65.1: cannot open shared object file: No such file or directory
从错误信息来看，原来是在docker发布环境里还少从docker外漏拷贝了一个c3d模型所需的boost库文件: libboost_python-py27.so.1.65.1，把这个文件从Linux主机拷贝到docker里，就可以了。
另外有时系统启动时某些插件会报类似这样的错误：
(gst-plugin-scanner:24087): GStreamer-WARNING **: 12:52:27.805: Failed to load plugin '/usr/lib/aarch64-linux-gnu/gstreamer-1.0/deepstream/libnvdsgst_dsc3d.so': /usr/lib/aarch64-linux-gnu/libgomp.so.1: cannot allocate memory in static TLS block
检查发现/usr/lib/aarch64-linux-gnu/libgomp.so.1是存在的而且之前没有这样的问题，尝试发现，如果先编译主程序(GStreamer main loop所在的程序)，然后再编译下插件并将插件的so库更新到/opt/nvidia/deepstream/deepstream/lib/gst-plugins/下，再运行就没问题了，插件可以正常起来。对于这个问题，还没发现其根本原因，为何存在这样的编译上的先后依赖关系，以前没见过这样的怪事，反正现在不影响使用就先赶进度，以后有时间再回头琢磨，先做下记录。