在TX2上多线程读取视频帧进行caffe推理

参考文章：Multi-threaded Camera Caffe Inferencing

背景

一般在TX2上部署深度学习模型时，都是读取摄像头视频或者传入视频文件进行推理，从视频中抽取帧进行目标检测等任务。但对于较大的模型，推理的速度是小于视频的帧率的。如果我们使用单线程进行处理，即读取一帧检测一帧，推理会堵塞视频的正常传输，表现出来就是摄像头视频有很大的延迟，如果是对实时性要求较高，这种延迟是难以接受的。因此，采用多线程的方法，将视频读取与深度学习推理放在两个线程里，互不影响，达到实时的效果。

在上篇博客在Jetson TX2上显示摄像头视频并使用python进行caffe推理实际上使用了单线程。本篇博客采用两个不同的线程，一个进行摄像机捕获，一个进行caffe推理。

程序下载： tegra-cam-caffe-threaded.py

线程间工作的分配

将摄像机捕获图像放入子线程，主线程完成其余所有工作，包括caffe初始化、推理和图像呈现。下面是启动子线程进行摄像机图像捕获并完成后终止它的代码片段

import threading

#
# This 'grab_img' function is designed to be run in the sub-thread.
# Once started, this thread continues to grab new image and put it
# into the global IMG_HANDLE, until THREAD_RUNNING is set to False.
#
def grab_img(cap):
    global THREAD_RUNNING
    global IMG_HANDLE
    while THREAD_RUNNING:
        _, IMG_HANDLE = cap.read()

def main():
    ......
    # Start the sub-thread, which is responsible for grabbing images
    THREAD_RUNNING = True
    th = threading.Thread(target=grab_img, args=(cap,))
    th.start()

    ......
    # Terminate the sub-thread
    THREAD_RUNNING = False
    th.join()

线程间的同步

多线程读取视频帧进行caffe推理适合经典的生产者-消费者模型，如下图

摄像机图形捕获线程充当生产者，主线程（caffe推理）充当消费者。我们需要设计一个队列来处理生产和消费，我们需要监视队列的满度，以决定是否需要删除项目和限制消费者。

在我们的例子中，我们认为生产者（以30帧每秒捕获摄像机）可能比消费者（caffe推理，其速率取决于模型的复杂程度）更快。我们需要跟踪相机捕获线程产生的最新图像帧，通过python中的垃圾收集器，甚至不需要使用互斥锁来保留最新帧。

我使用一个全局变量 IMG_HANDLE 来引用图像帧，每当生产者（摄像机捕获线程）从相机获取新帧时，这个 IMG_HANDLE 就会更新。另一方面，每当消费者（caffe推理线程）准备处理下一个图像帧，它就取消对 IMG_HANDLE 的引用，从而总是获得最新的图像帧。

帧2、4、5被丢弃时，python垃圾回收器自动回收，因为程序不再有对他们的引用。事实上，一旦caffe推理线程完成，帧1、3、6也会被垃圾收集。

程序的使用

python3 tegra-cam-caffe-threaded.py --usb --vid

讨论与总结

但是，这种多线程设计是否有助于提高caffe推理脚本的吞吐量？也就是说能否通过这种设计推断出更多的帧/秒（fps）。答案可能是否定的。例如在最初的单线程设计中，假设摄像机捕获图像生成图像帧的速度比caffe推理的速度快，然后cap.read()总是立即返回（非阻塞方式）。因为总是有图像帧等待处理，更具体的说，旧的图像帧要么在v4l2驱动缓冲区中排队，要么在gstream/opencv堆栈中排队，然后又由cap.read()立即返回。那么旧的相框很可能不是相机捕捉到的最新的相框。

那么，这种多线程设计的真正好处是什么呢？

在tegra-cam-caffe-threaded.py 中，我们只在全局变量IMG_HANDLE中保留最新的一个图像帧。因此，caffe推理(主)线程总是获取最新抓取的图像帧进行处理。总之，我认为这种多线程设计有助于改善caffe推理程序的延迟。