图像采集节点发布图像数据速度较快，而推理节点处理速度较慢的情况。
1. 图像数据会不会出现堆积。
2.如果图像出现堆积，那么会导致t时刻采集到的图像，延迟相当长的时间才能推理并发布。有没有途径能降低这种延迟。换句话说，能不能只订阅最新图像进行推理。
问题1：会出现数据堆积，当订阅到图片后处理耗时大于图片发布时间间隔就会出现堆积。
问题2：解决方法
使用create_subscription/create_subscription_hbmem接口创建图片数据的订阅者时会通过qos参数指定缓存数据量，一般是10，可以将参数指定为1（需要修改源码后重新编译），即只缓存一帧数据，能够保证订阅到的数据时最新的图像。
mipi_cam图像发布节点的发布者队列长度需要设置为1吗？发布者和订阅者两个队列长度之间有什么关系？
不需要，发布和订阅是完全解耦的，所以两者的队列长度之间没有关系。
改了订阅的队列长度之后，拿到的图像数据延迟有多少？
把订阅者队列长度设置为1后，采用同步模式推理，task_num=1，图片订阅延迟为40+ms，还是偏高。
这里图片订阅延迟是这样算的：
在订阅回调函数起点clock_gettime时间戳 - img_msg中的时间戳。
不做推理延迟是多长时间，也就是回调里面订阅到图片，统计后直接返回，不做后续处理。
延迟为27ms，这个时间是否正常
那说明推理耗时比较长，订阅回调被长时间阻塞导致没有及时处理订阅到的图像数据。可以设置成异步推理模式。
队列已设置为1的情况下，没有及时处理的数据应该被丢弃了吧，此时为什么推理耗时还会影响订阅延迟呢？
另外，不做推理时，订阅延迟27ms是不是也偏高了，我理解应该1-2ms就被订阅到。
1、推理影响订阅延迟。
摄像头采集图像的帧率是30fps，也就是两帧图像数据的时间间隔是33ms。
队列长度设置为1时，一帧图像数据最长在队列里面缓存时间是33ms。
如果图像数据从产生到进入到订阅队列的延迟是N ms，推理耗时比较长（超过帧间隔也就是33ms）的情况下订阅回调中订阅到图像数据时最大延迟是N+33ms。
2、订阅延迟。
不做推理的情况下，图像数据从产生到订阅到的延迟时间主要有三部分组成：图像曝光时间、图像发布前的处理、传输时间。
图像数据的时间戳是开始曝光的时间，曝光时间大概是30ms左右，图像发布前的处理在几个ms，对于零拷贝传输时间也是几个ms。
所以不做推理的情况下延迟时间是30ms左右。做推理并且队列长度为1时，最大延迟是30+33=63ms。
1. “图像数据从产生到进入到订阅队列的延迟是N ms“应该怎么理解呢？如果图像采集的帧率是30fps，那么采集间隔应该固定为33ms，延迟N应该就是在33ms的基础上增加了传输时间几个ms吧，延迟N>33?。
2. 《队列长度设置为1时，一帧图像数据最长在队列里面缓存时间是33ms。》缓存时间为什么是33，而不是延迟N呢？队列里的图像在新的图像进队之后才会被替换掉。
2. “回调中订阅到图像数据时最大延迟是N+33ms“这个应该怎么理解？
1、首先要理解帧间隔和延迟这两个概念。
帧间隔指的是两帧数据之间的时间间隔，由帧率决定。如果帧率是30fps，帧间隔就是固定的33ms（假设图像处理、传输的总时间小于33ms）。
延迟指的是一个过程的耗时。例如图像采集完成到订阅端订阅到图像，这是一个过程，这个时间就是图像的延迟。对于图像的延迟（例如N毫秒），可以理解成订阅到的图像数据是物理世界N毫秒之前的状态。
2、缓存时间是由帧间隔决定，而不是帧延迟。
因为在下一帧数据来之前，当前帧可以一直存在于缓存中，而下一帧是33ms之后才会到来。
3、理解了帧间隔和延迟这两个概念之后，回调中订阅到图像数据的最大延迟是N+33ms这一点应该能够理解吧。
4、可以做下实验，对比下发布和订阅端图像数据的时间戳，以及每个处理步骤的时间戳。