参考文章: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推理程序的延迟。