如何解决DeepStream拉流时延时越来越长的问题

     DeepStream是基于GStreamer框架开发的，像GStreamer这种pipeline架构它有个毛病就是pipeline里任何一个element里的基于pipeline这个context下的同步计算耗时过长导致超过源端视频帧的发送间隔的话会导致整个pipeline里的视频数据流动速度下降从而产生帧积累，如果没有主动丢弃的话，视频播放离实时视频时间上自然相差越来越来多，也就是延时越来越长。加上一个边缘板子上拉几个IPC摄像头的流的话，边缘板子的CPU和GPU处理能力有限，还有长时间运行发热等因素影响导致计算速度变慢，下游插件的计算耗时也会慢慢变长，这样也会导致来不及处理的帧积累越来越多，视频延时越来越长。

     但是我们有时在某些element里的同步计算是不可避免的，例如对帧调用模型进行推理，将推理结果发送给下游插件使用去进行结果分析产生分析数据上传云端，还有对视频中的敏感目标进行准实时打码等等这样的需求不可避免，而像调用模型进行推理，精度高的模型都大一点的，大一点的网络模型的推理时间稍长一点，加上数据预处理和推理结果的后处理时间，可能很难低于100ms，假如源端发送视频数据的FPS大于10，那么帧间隔就少于100ms了，这样就会慢慢产生帧积累而延时越来越长，那怎么解决这种问题呢？很显然需要进行主动丢帧才能跟得上实时视频的进度，怎么主动丢帧就是个坑。

     像使用rtspsrc来拉取网络摄像头的RTSP流时，rtspsrc element有latency和drop-on-latency组合使用实现解码前丢帧，这样确实可以主动丢帧超过latency设置的值范围的帧数据，但是这样做有个很差的后果就是视频会出现花屏和抖动不清晰，这对后面模型推理非常不利，所以这种做对于有对视频进行推理分析需求的项目显然是不合适的！另外对于nvv4l2decoder，它有drop-frame-interval这样的属性可以设置间隔丢帧，这样做对于interval较大时可能影响不大，较小时丢帧频繁可能还是有花屏出现。

     查了国外网上有人推荐在decode后面增加使用queue或者queu