1. 从单帧抓取到连续取流为什么这一步非改不可摄像头从抓一帧改成循环连续取流这个改动听起来像是把while循环外面那层壳去掉就完事了但真正在香橙派 RK3588 上跑过 yolov5s 的人都知道这里面的坑比想象中多得多。我最初跑通单帧抓取的时候心里想的是“检测结果出来了后面接循环不就完了”结果一上连续取流帧率掉到个位数、内存缓慢上涨、画面延迟越积越大甚至跑十几分钟之后 NPU 直接罢工。这篇文章就把我从单帧到连续取流这一路踩过的坑、调过的参数、改过的代码结构完整梳理一遍适合已经在香橙派 RK3588 上把 yolov5s 单帧推理跑通、准备往实时视频流方向推进的朋友参考。先说清楚这个改动的本质单帧抓取是“打开摄像头 → 取一帧 → 推理 → 输出 → 结束”整个流程是一次性的资源随用随开随关。而连续取流是“打开摄像头 → 持续取帧 → 每帧推理 → 持续输出”摄像头句柄、NPU 上下文、内存缓冲区都要长期驻留。这两者在代码结构上看着只差一个循环但在资源管理、线程模型、缓冲策略上完全是两套逻辑。很多人第一次改完发现程序能跑但跑不稳根子就在这里。香橙派 5 搭载的 RK3588 芯片有 6TOPS 的 NPU 算力跑 yolov5s 这种轻量模型理论上是够用的但前提是你得把数据通路理顺。摄像头出流、格式转换、模型输入预处理、NPU 推理、后处理、结果显示这六个环节只要有一个环节拖后腿整个流水线就会被拉垮。单帧模式下这些问题被“只跑一次”掩盖了连续取流会把它们全部暴露出来。所以这篇文章不只是讲怎么加循环更重要的是讲清楚连续取流场景下每个环节该怎么配置、怎么排查、怎么优化。2. 连续取流的整体架构设计思路2.1 单帧模式与连续模式的本质差异单帧抓取模式下典型的代码流程是这样的初始化摄像头调用一次取帧接口拿到一帧图像把图像送进模型推理拿到结果画框显示然后释放摄像头和模型资源。整个过程是线性的任何一个环节慢一点都无所谓因为只跑一次。这种模式适合验证模型能不能跑通、检测效果对不对但它不能反映真实运行时的性能表现。连续取流模式则完全不同。摄像头会以固定帧率持续产出图像帧比如 30fps 就是每 33 毫秒出一帧。如果你的推理速度跟不上这个节奏就会面临一个选择要么丢帧要么积压。丢帧会导致检测不连续快速移动的物体会被漏掉积压则会导致延迟越来越大画面和现实脱节同时内存持续增长最终崩溃。所以连续取流的核心问题不是“能不能跑”而是“怎么让取流和推理这两个速度不匹配的环节协调工作”。我在实际项目中的做法是采用生产者-消费者模型一个线程专门负责从摄像头取帧并放入缓冲队列另一个线程专门从队列取帧做推理。取流线程只管取推理线程只管算两者通过队列解耦。这样即使推理偶尔慢了一拍取流线程也不会被阻塞摄像头驱动内部的缓冲区不会溢出。当然队列不能无限长需要设置一个上限满了就丢弃最旧的帧保证处理的永远是最新画面。2.2 为什么选择多线程而不是单线程轮询有人可能会想单线程里写个while True先取帧再推理不就行了吗理论上可以但实际跑下来问题很大。单线程模式下取帧和推理是串行的推理花 50 毫秒取帧花 10 毫秒那整个循环就是 60 毫秒一轮等效帧率不到 17fps。而且摄像头驱动内部的缓冲区只有几帧的深度如果你 60 毫秒才去取一次驱动缓冲区早就被新帧覆盖了你拿到的可能是几十毫秒前的旧帧延迟感非常明显。多线程之后取流线程可以保持 30fps 的节奏稳定取帧推理线程按自己的能力消费。假设推理只能做到 20fps那队列里会慢慢积压但因为设置了最大长度并丢弃旧帧实际处理的永远是最新的帧延迟控制在可接受范围内。这种设计在香橙派 RK3588 这种 CPU 和 NPU 异构的平台上尤其重要因为取流是 CPU 和摄像头驱动的事推理是 NPU 的事两者本来就该并行。2.3 缓冲队列的长度怎么定队列长度这个参数看着不起眼但对系统行为影响很大。设得太短比如长度为 1那取流线程刚放进去一帧推理线程还没来得及取下一帧就来了取流线程要么阻塞等待要么丢弃实际上退化成单线程模式。设得太长比如长度为 100那积压的帧就太多了延迟会非常大你看到画面里人已经走过去了框才画出来。我的经验值是队列长度设为 2 到 4 比较合适。以 30fps 取流、20fps 推理为例每秒积压 10 帧队列长度 3 的话大约 300 毫秒就会填满然后开始丢旧帧实际延迟稳定在 100 到 150 毫秒左右。这个延迟对于大多数实时检测场景是可以接受的。如果你做的是需要极低延迟的交互应用那队列长度设为 1 甚至 0 也行但那样就必须保证推理速度跟得上取流速度否则会频繁丢帧。3. 摄像头取流环节的关键配置与实操3.1 摄像头设备节点与驱动确认在香橙派 RK3588 上接摄像头第一步是确认设备节点。USB 摄像头通常枚举为/dev/video0、/dev/video1这样的节点MIPI 摄像头则可能是/dev/video0到/dev/video11中的某几个。你可以用v4l2-ctl --list-devices命令列出所有视频设备看清楚哪个节点对应哪个摄像头。我遇到过有人把 MIPI 摄像头的节点和 USB 摄像头的节点搞混结果 OpenCV 打开的是错误的设备取到的全是绿屏或者黑屏。确认节点之后还要确认摄像头支持的像素格式和分辨率。用v4l2-ctl -d /dev/video0 --list-formats-ext可以列出所有支持的格式。常见的 USB 摄像头支持 MJPG 和 YUYV 两种格式MJPG 是压缩格式传输带宽小适合高分辨率YUYV 是原始格式带宽大但不需要解码。在 RK3588 上如果摄像头支持 MJPG我建议优先用 MJPG因为 USB 2.0 的带宽有限YUYV 在 1080p 下根本跑不到 30fps。3.2 OpenCV 取流参数设置与避坑用 OpenCV 的VideoCapture取流是最方便的方式但默认参数往往不是最优的。下面是我常用的初始化代码import cv2 cap cv2.VideoCapture(/dev/video0, cv2.CAP_V4L2) cap.set(cv2.CAP_PROP_FOURCC, cv2.VideoWriter_fourcc(M, J, P, G)) cap.set(cv2.CAP_PROP_FRAME_WIDTH, 640) cap.set(cv2.CAP_PROP_FRAME_HEIGHT, 480) cap.set(cv2.CAP_PROP_FPS, 30) cap.set(cv2.CAP_PROP_BUFFERSIZE, 1)这里有几个关键点。第一cv2.CAP_V4L2显式指定后端避免 OpenCV 自动选择 GStreamer 或其他后端导致行为不一致。第二CAP_PROP_FOURCC设置为 MJPG强制使用压缩格式。第三分辨率设为 640x480因为 yolov5s 的输入是 640x640取流分辨率太大会增加格式转换的开销。第四CAP_PROP_BUFFERSIZE设为 1让驱动内部只保留一帧缓冲这样每次取到的都是最新帧减少延迟。注意CAP_PROP_BUFFERSIZE这个参数不是所有摄像头驱动都支持有些 USB 摄像头设了也不生效。如果发现设了没用可以在取流线程里连续调用两次cap.read()丢弃第一帧这样也能达到类似的效果。3.3 取流线程的实现细节取流线程的核心逻辑就是一个循环不断从摄像头读帧并放入队列。但这里有几个细节要注意。第一cap.read()是阻塞调用如果摄像头出问题不返回线程会卡死所以最好加一个超时机制或者心跳检测。第二读到的帧要做一个拷贝再放入队列因为 OpenCV 返回的 numpy 数组在下次read()时会被覆盖不拷贝的话队列里的帧会变成同一帧。第三队列满的时候要丢弃旧帧而不是阻塞否则取流线程会被推理线程拖慢。import threading import queue import cv2 import numpy as np frame_queue queue.Queue(maxsize3) def capture_thread(cap): while True: ret, frame cap.read() if not ret: continue if frame_queue.full(): try: frame_queue.get_nowait() except queue.Empty: pass frame_queue.put(frame.copy())这段代码里frame.copy()是必须的我见过有人忘了拷贝结果队列里三帧全是同一个内容推理结果自然也是重复的。另外frame_queue.full()判断和get_nowait()之间理论上存在竞态但在单生产者单消费者的场景下问题不大如果追求严谨可以加锁。4. 推理环节的连续化改造与性能调优4.1 模型加载与 NPU 上下文复用单帧模式下很多人习惯每次推理都重新加载模型或者至少重新初始化一次 NPU 上下文。连续取流模式下这样做是灾难性的因为加载模型和初始化 NPU 上下文可能要几百毫秒甚至几秒每帧都做一次的话帧率会低到无法接受。正确的做法是在进入循环之前就把模型加载好、NPU 上下文初始化好循环里只做推理调用。在 RK3588 上用 RKNN 跑 yolov5s典型的初始化流程是加载.rknn模型文件、调用rknn_init()、然后rknn_query()查询输入输出信息。这些操作只做一次把返回的rknn_context保存下来循环里反复使用。如果你用的是 Python 接口RKNN对象本身就是上下文创建一次即可。4.2 输入预处理的效率优化yolov5s 的输入是 640x640 的 RGB 图像而摄像头出来的是 640x480 的 BGR 图像。预处理要做的事情包括BGR 转 RGB、缩放到 640x640、归一化、维度变换。这些操作如果用 Python 的 numpy 逐像素做速度会很慢一帧可能要几十毫秒。我的做法是尽量用 OpenCV 的向量化操作比如cv2.cvtColor做颜色转换、cv2.resize做缩放这些底层都是 C 实现的速度快很多。还有一个技巧是直接用 RKNN 的rknn_inputs_set接口它支持传入 numpy 数组并自动做部分预处理。但要注意它的预处理逻辑和训练时的预处理必须一致否则检测精度会下降。我一般会在 PC 上先用同样的预处理跑一遍验证确认结果对齐之后再上板子。4.3 推理线程与结果输出的配合推理线程从队列取帧做预处理、推理、后处理然后把结果画到帧上或者通过其他方式输出。这里要注意的是后处理NMS 非极大值抑制也是比较耗时的操作如果检测框很多NMS 可能占用十几毫秒。如果对帧率要求高可以考虑用 RKNN 自带的 NPU 加速 NMS或者简化 NMS 逻辑。结果输出方面如果只是本地显示用cv2.imshow就行但要注意imshow必须在主线程调用否则在某些平台上会出问题。如果是推流或者网络传输那就要另开线程做编码和发送不要阻塞推理线程。我一般会把画好框的帧放入另一个队列由显示线程或推流线程消费。5. 常见问题排查与实战避坑指南5.1 帧率上不去的排查思路连续取流跑起来之后最常见的问题就是帧率低。排查的时候要分段计时看时间花在哪里。我的做法是在代码里加计时器分别记录取帧耗时、预处理耗时、推理耗时、后处理耗时、显示耗时。如果取帧耗时超过 30 毫秒那说明摄像头配置有问题可能是格式不对或者分辨率太高。如果推理耗时超过 50 毫秒那说明模型或 NPU 配置有问题可能是没用到 NPU 或者模型太大。如果后处理耗时超过 20 毫秒那说明检测框太多需要调整置信度阈值。下面是我常用的问题速查表现象可能原因排查方法解决方案帧率低于 10fps推理耗时过长计时推理环节确认使用 NPU 推理检查模型输入尺寸画面延迟越来越大队列积压打印队列长度减小队列长度丢弃旧帧内存持续增长帧未释放监控内存占用检查是否有循环引用及时释放帧运行一段时间后崩溃NPU 上下文泄漏查看系统日志确保推理上下文复用而非重复创建画面卡顿但帧率正常显示线程阻塞检查 imshow 调用位置将显示放在独立线程或主线程5.2 内存泄漏的定位与解决连续取流模式下内存泄漏是很隐蔽的问题因为单帧模式下看不出来。我遇到过一次跑两个小时内存涨了 2GB 的情况最后定位到是每次推理都创建了新的 RKNN 输出缓冲区而没有释放。解决方法是把输出缓冲区也做成复用的在循环外分配好循环里反复使用。另一个常见泄漏点是 OpenCV 的VideoCapture对象。如果你在循环里反复VideoCapture和release某些版本的 OpenCV 会有资源泄漏。正确做法是只创建一次循环结束后再释放。还有 numpy 数组的拷贝也要注意不必要的拷贝既浪费内存又浪费时间。5.3 摄像头断流与重连处理USB 摄像头在长时间运行后可能会因为供电不稳或驱动问题断流表现为cap.read()返回 False。如果不处理程序会一直空转。我的做法是加一个计数器连续读到失败超过一定次数就尝试重新打开摄像头。重连的时候要先release再重新VideoCapture并且重新设置所有参数。fail_count 0 while True: ret, frame cap.read() if not ret: fail_count 1 if fail_count 30: cap.release() time.sleep(1) cap cv2.VideoCapture(/dev/video0, cv2.CAP_V4L2) # 重新设置参数 fail_count 0 continue fail_count 0 # 正常处理这段逻辑在实际项目里救过我好几次尤其是用 POE 摄像头或者长线 USB 延长的时候断流是家常便饭。6. 从能跑到跑稳连续取流的工程化建议6.1 日志与监控的加入连续取流程序跑起来之后你不可能一直盯着屏幕看。加一些日志输出是很有必要的比如每秒打印一次实际帧率、队列长度、推理耗时。这些数据能帮你判断系统是否健康。我一般会用 Python 的logging模块设置成每 5 秒输出一次统计信息。如果发现帧率突然下降或者队列长度持续增长就说明有问题需要处理。监控方面可以用psutil库读取 CPU、内存、温度等信息。RK3588 长时间高负载运行会发热温度过高会触发降频帧率会明显下降。如果发现温度超过 80 度就要考虑加散热片或者风扇了。我在香橙派 5 上加了一个小风扇温度能控制在 60 度左右帧率稳定很多。6.2 优雅退出的实现连续取流程序通常是while True死循环按 CtrlC 的时候要能优雅退出释放摄像头和 NPU 资源。如果不处理可能会导致摄像头设备被占用下次运行打不开。我的做法是用signal模块捕获SIGINT设置一个全局标志位循环里检查这个标志位退出前释放资源。import signal import sys running True def signal_handler(sig, frame): global running running False signal.signal(signal.SIGINT, signal_handler) while running: # 主循环逻辑 pass cap.release() rknn.release()这样按 CtrlC 之后程序会正常退出不会留下僵尸进程或者占用的设备节点。6.3 性能与精度的平衡取舍连续取流场景下性能和精度往往需要权衡。yolov5s 在 640x640 输入下精度不错但推理耗时也相对较高。如果帧率不够可以考虑把输入降到 320x320推理速度能提升一倍以上但小目标的检测精度会下降。另一个思路是降低取流帧率比如从 30fps 降到 15fps给推理留更多时间。具体怎么选要看你的应用场景如果是检测大目标比如人、车320x320 够用如果是检测小目标比如零件缺陷那还是得用 640x640。我在实际项目中的体会是先把帧率跑稳再逐步优化精度。一开始不要追求最高精度先把整个流水线跑通跑稳然后根据实际检测效果调整模型输入尺寸和置信度阈值。很多时候稍微降低一点置信度阈值就能在不增加计算量的情况下提升召回率。最后再分享一个小技巧如果你的应用场景是固定摄像头、背景变化不大可以考虑加一个简单的背景差分或者运动检测作为前置过滤只有画面有变化的时候才触发推理。这样在画面静止的时候可以大幅降低 NPU 负载整体功耗和发热都会好很多。这个思路在智能车摄像头循迹、安防监控这类场景里特别实用。
1. 从单帧抓取到连续取流为什么这一步非改不可摄像头从抓一帧改成循环连续取流这个改动听起来像是把while循环外面那层壳去掉就完事了但真正在香橙派 RK3588 上跑过 yolov5s 的人都知道这里面的坑比想象中多得多。我最初跑通单帧抓取的时候心里想的是“检测结果出来了后面接循环不就完了”结果一上连续取流帧率掉到个位数、内存缓慢上涨、画面延迟越积越大甚至跑十几分钟之后 NPU 直接罢工。这篇文章就把我从单帧到连续取流这一路踩过的坑、调过的参数、改过的代码结构完整梳理一遍适合已经在香橙派 RK3588 上把 yolov5s 单帧推理跑通、准备往实时视频流方向推进的朋友参考。先说清楚这个改动的本质单帧抓取是“打开摄像头 → 取一帧 → 推理 → 输出 → 结束”整个流程是一次性的资源随用随开随关。而连续取流是“打开摄像头 → 持续取帧 → 每帧推理 → 持续输出”摄像头句柄、NPU 上下文、内存缓冲区都要长期驻留。这两者在代码结构上看着只差一个循环但在资源管理、线程模型、缓冲策略上完全是两套逻辑。很多人第一次改完发现程序能跑但跑不稳根子就在这里。香橙派 5 搭载的 RK3588 芯片有 6TOPS 的 NPU 算力跑 yolov5s 这种轻量模型理论上是够用的但前提是你得把数据通路理顺。摄像头出流、格式转换、模型输入预处理、NPU 推理、后处理、结果显示这六个环节只要有一个环节拖后腿整个流水线就会被拉垮。单帧模式下这些问题被“只跑一次”掩盖了连续取流会把它们全部暴露出来。所以这篇文章不只是讲怎么加循环更重要的是讲清楚连续取流场景下每个环节该怎么配置、怎么排查、怎么优化。2. 连续取流的整体架构设计思路2.1 单帧模式与连续模式的本质差异单帧抓取模式下典型的代码流程是这样的初始化摄像头调用一次取帧接口拿到一帧图像把图像送进模型推理拿到结果画框显示然后释放摄像头和模型资源。整个过程是线性的任何一个环节慢一点都无所谓因为只跑一次。这种模式适合验证模型能不能跑通、检测效果对不对但它不能反映真实运行时的性能表现。连续取流模式则完全不同。摄像头会以固定帧率持续产出图像帧比如 30fps 就是每 33 毫秒出一帧。如果你的推理速度跟不上这个节奏就会面临一个选择要么丢帧要么积压。丢帧会导致检测不连续快速移动的物体会被漏掉积压则会导致延迟越来越大画面和现实脱节同时内存持续增长最终崩溃。所以连续取流的核心问题不是“能不能跑”而是“怎么让取流和推理这两个速度不匹配的环节协调工作”。我在实际项目中的做法是采用生产者-消费者模型一个线程专门负责从摄像头取帧并放入缓冲队列另一个线程专门从队列取帧做推理。取流线程只管取推理线程只管算两者通过队列解耦。这样即使推理偶尔慢了一拍取流线程也不会被阻塞摄像头驱动内部的缓冲区不会溢出。当然队列不能无限长需要设置一个上限满了就丢弃最旧的帧保证处理的永远是最新画面。2.2 为什么选择多线程而不是单线程轮询有人可能会想单线程里写个while True先取帧再推理不就行了吗理论上可以但实际跑下来问题很大。单线程模式下取帧和推理是串行的推理花 50 毫秒取帧花 10 毫秒那整个循环就是 60 毫秒一轮等效帧率不到 17fps。而且摄像头驱动内部的缓冲区只有几帧的深度如果你 60 毫秒才去取一次驱动缓冲区早就被新帧覆盖了你拿到的可能是几十毫秒前的旧帧延迟感非常明显。多线程之后取流线程可以保持 30fps 的节奏稳定取帧推理线程按自己的能力消费。假设推理只能做到 20fps那队列里会慢慢积压但因为设置了最大长度并丢弃旧帧实际处理的永远是最新的帧延迟控制在可接受范围内。这种设计在香橙派 RK3588 这种 CPU 和 NPU 异构的平台上尤其重要因为取流是 CPU 和摄像头驱动的事推理是 NPU 的事两者本来就该并行。2.3 缓冲队列的长度怎么定队列长度这个参数看着不起眼但对系统行为影响很大。设得太短比如长度为 1那取流线程刚放进去一帧推理线程还没来得及取下一帧就来了取流线程要么阻塞等待要么丢弃实际上退化成单线程模式。设得太长比如长度为 100那积压的帧就太多了延迟会非常大你看到画面里人已经走过去了框才画出来。我的经验值是队列长度设为 2 到 4 比较合适。以 30fps 取流、20fps 推理为例每秒积压 10 帧队列长度 3 的话大约 300 毫秒就会填满然后开始丢旧帧实际延迟稳定在 100 到 150 毫秒左右。这个延迟对于大多数实时检测场景是可以接受的。如果你做的是需要极低延迟的交互应用那队列长度设为 1 甚至 0 也行但那样就必须保证推理速度跟得上取流速度否则会频繁丢帧。3. 摄像头取流环节的关键配置与实操3.1 摄像头设备节点与驱动确认在香橙派 RK3588 上接摄像头第一步是确认设备节点。USB 摄像头通常枚举为/dev/video0、/dev/video1这样的节点MIPI 摄像头则可能是/dev/video0到/dev/video11中的某几个。你可以用v4l2-ctl --list-devices命令列出所有视频设备看清楚哪个节点对应哪个摄像头。我遇到过有人把 MIPI 摄像头的节点和 USB 摄像头的节点搞混结果 OpenCV 打开的是错误的设备取到的全是绿屏或者黑屏。确认节点之后还要确认摄像头支持的像素格式和分辨率。用v4l2-ctl -d /dev/video0 --list-formats-ext可以列出所有支持的格式。常见的 USB 摄像头支持 MJPG 和 YUYV 两种格式MJPG 是压缩格式传输带宽小适合高分辨率YUYV 是原始格式带宽大但不需要解码。在 RK3588 上如果摄像头支持 MJPG我建议优先用 MJPG因为 USB 2.0 的带宽有限YUYV 在 1080p 下根本跑不到 30fps。3.2 OpenCV 取流参数设置与避坑用 OpenCV 的VideoCapture取流是最方便的方式但默认参数往往不是最优的。下面是我常用的初始化代码import cv2 cap cv2.VideoCapture(/dev/video0, cv2.CAP_V4L2) cap.set(cv2.CAP_PROP_FOURCC, cv2.VideoWriter_fourcc(M, J, P, G)) cap.set(cv2.CAP_PROP_FRAME_WIDTH, 640) cap.set(cv2.CAP_PROP_FRAME_HEIGHT, 480) cap.set(cv2.CAP_PROP_FPS, 30) cap.set(cv2.CAP_PROP_BUFFERSIZE, 1)这里有几个关键点。第一cv2.CAP_V4L2显式指定后端避免 OpenCV 自动选择 GStreamer 或其他后端导致行为不一致。第二CAP_PROP_FOURCC设置为 MJPG强制使用压缩格式。第三分辨率设为 640x480因为 yolov5s 的输入是 640x640取流分辨率太大会增加格式转换的开销。第四CAP_PROP_BUFFERSIZE设为 1让驱动内部只保留一帧缓冲这样每次取到的都是最新帧减少延迟。注意CAP_PROP_BUFFERSIZE这个参数不是所有摄像头驱动都支持有些 USB 摄像头设了也不生效。如果发现设了没用可以在取流线程里连续调用两次cap.read()丢弃第一帧这样也能达到类似的效果。3.3 取流线程的实现细节取流线程的核心逻辑就是一个循环不断从摄像头读帧并放入队列。但这里有几个细节要注意。第一cap.read()是阻塞调用如果摄像头出问题不返回线程会卡死所以最好加一个超时机制或者心跳检测。第二读到的帧要做一个拷贝再放入队列因为 OpenCV 返回的 numpy 数组在下次read()时会被覆盖不拷贝的话队列里的帧会变成同一帧。第三队列满的时候要丢弃旧帧而不是阻塞否则取流线程会被推理线程拖慢。import threading import queue import cv2 import numpy as np frame_queue queue.Queue(maxsize3) def capture_thread(cap): while True: ret, frame cap.read() if not ret: continue if frame_queue.full(): try: frame_queue.get_nowait() except queue.Empty: pass frame_queue.put(frame.copy())这段代码里frame.copy()是必须的我见过有人忘了拷贝结果队列里三帧全是同一个内容推理结果自然也是重复的。另外frame_queue.full()判断和get_nowait()之间理论上存在竞态但在单生产者单消费者的场景下问题不大如果追求严谨可以加锁。4. 推理环节的连续化改造与性能调优4.1 模型加载与 NPU 上下文复用单帧模式下很多人习惯每次推理都重新加载模型或者至少重新初始化一次 NPU 上下文。连续取流模式下这样做是灾难性的因为加载模型和初始化 NPU 上下文可能要几百毫秒甚至几秒每帧都做一次的话帧率会低到无法接受。正确的做法是在进入循环之前就把模型加载好、NPU 上下文初始化好循环里只做推理调用。在 RK3588 上用 RKNN 跑 yolov5s典型的初始化流程是加载.rknn模型文件、调用rknn_init()、然后rknn_query()查询输入输出信息。这些操作只做一次把返回的rknn_context保存下来循环里反复使用。如果你用的是 Python 接口RKNN对象本身就是上下文创建一次即可。4.2 输入预处理的效率优化yolov5s 的输入是 640x640 的 RGB 图像而摄像头出来的是 640x480 的 BGR 图像。预处理要做的事情包括BGR 转 RGB、缩放到 640x640、归一化、维度变换。这些操作如果用 Python 的 numpy 逐像素做速度会很慢一帧可能要几十毫秒。我的做法是尽量用 OpenCV 的向量化操作比如cv2.cvtColor做颜色转换、cv2.resize做缩放这些底层都是 C 实现的速度快很多。还有一个技巧是直接用 RKNN 的rknn_inputs_set接口它支持传入 numpy 数组并自动做部分预处理。但要注意它的预处理逻辑和训练时的预处理必须一致否则检测精度会下降。我一般会在 PC 上先用同样的预处理跑一遍验证确认结果对齐之后再上板子。4.3 推理线程与结果输出的配合推理线程从队列取帧做预处理、推理、后处理然后把结果画到帧上或者通过其他方式输出。这里要注意的是后处理NMS 非极大值抑制也是比较耗时的操作如果检测框很多NMS 可能占用十几毫秒。如果对帧率要求高可以考虑用 RKNN 自带的 NPU 加速 NMS或者简化 NMS 逻辑。结果输出方面如果只是本地显示用cv2.imshow就行但要注意imshow必须在主线程调用否则在某些平台上会出问题。如果是推流或者网络传输那就要另开线程做编码和发送不要阻塞推理线程。我一般会把画好框的帧放入另一个队列由显示线程或推流线程消费。5. 常见问题排查与实战避坑指南5.1 帧率上不去的排查思路连续取流跑起来之后最常见的问题就是帧率低。排查的时候要分段计时看时间花在哪里。我的做法是在代码里加计时器分别记录取帧耗时、预处理耗时、推理耗时、后处理耗时、显示耗时。如果取帧耗时超过 30 毫秒那说明摄像头配置有问题可能是格式不对或者分辨率太高。如果推理耗时超过 50 毫秒那说明模型或 NPU 配置有问题可能是没用到 NPU 或者模型太大。如果后处理耗时超过 20 毫秒那说明检测框太多需要调整置信度阈值。下面是我常用的问题速查表现象可能原因排查方法解决方案帧率低于 10fps推理耗时过长计时推理环节确认使用 NPU 推理检查模型输入尺寸画面延迟越来越大队列积压打印队列长度减小队列长度丢弃旧帧内存持续增长帧未释放监控内存占用检查是否有循环引用及时释放帧运行一段时间后崩溃NPU 上下文泄漏查看系统日志确保推理上下文复用而非重复创建画面卡顿但帧率正常显示线程阻塞检查 imshow 调用位置将显示放在独立线程或主线程5.2 内存泄漏的定位与解决连续取流模式下内存泄漏是很隐蔽的问题因为单帧模式下看不出来。我遇到过一次跑两个小时内存涨了 2GB 的情况最后定位到是每次推理都创建了新的 RKNN 输出缓冲区而没有释放。解决方法是把输出缓冲区也做成复用的在循环外分配好循环里反复使用。另一个常见泄漏点是 OpenCV 的VideoCapture对象。如果你在循环里反复VideoCapture和release某些版本的 OpenCV 会有资源泄漏。正确做法是只创建一次循环结束后再释放。还有 numpy 数组的拷贝也要注意不必要的拷贝既浪费内存又浪费时间。5.3 摄像头断流与重连处理USB 摄像头在长时间运行后可能会因为供电不稳或驱动问题断流表现为cap.read()返回 False。如果不处理程序会一直空转。我的做法是加一个计数器连续读到失败超过一定次数就尝试重新打开摄像头。重连的时候要先release再重新VideoCapture并且重新设置所有参数。fail_count 0 while True: ret, frame cap.read() if not ret: fail_count 1 if fail_count 30: cap.release() time.sleep(1) cap cv2.VideoCapture(/dev/video0, cv2.CAP_V4L2) # 重新设置参数 fail_count 0 continue fail_count 0 # 正常处理这段逻辑在实际项目里救过我好几次尤其是用 POE 摄像头或者长线 USB 延长的时候断流是家常便饭。6. 从能跑到跑稳连续取流的工程化建议6.1 日志与监控的加入连续取流程序跑起来之后你不可能一直盯着屏幕看。加一些日志输出是很有必要的比如每秒打印一次实际帧率、队列长度、推理耗时。这些数据能帮你判断系统是否健康。我一般会用 Python 的logging模块设置成每 5 秒输出一次统计信息。如果发现帧率突然下降或者队列长度持续增长就说明有问题需要处理。监控方面可以用psutil库读取 CPU、内存、温度等信息。RK3588 长时间高负载运行会发热温度过高会触发降频帧率会明显下降。如果发现温度超过 80 度就要考虑加散热片或者风扇了。我在香橙派 5 上加了一个小风扇温度能控制在 60 度左右帧率稳定很多。6.2 优雅退出的实现连续取流程序通常是while True死循环按 CtrlC 的时候要能优雅退出释放摄像头和 NPU 资源。如果不处理可能会导致摄像头设备被占用下次运行打不开。我的做法是用signal模块捕获SIGINT设置一个全局标志位循环里检查这个标志位退出前释放资源。import signal import sys running True def signal_handler(sig, frame): global running running False signal.signal(signal.SIGINT, signal_handler) while running: # 主循环逻辑 pass cap.release() rknn.release()这样按 CtrlC 之后程序会正常退出不会留下僵尸进程或者占用的设备节点。6.3 性能与精度的平衡取舍连续取流场景下性能和精度往往需要权衡。yolov5s 在 640x640 输入下精度不错但推理耗时也相对较高。如果帧率不够可以考虑把输入降到 320x320推理速度能提升一倍以上但小目标的检测精度会下降。另一个思路是降低取流帧率比如从 30fps 降到 15fps给推理留更多时间。具体怎么选要看你的应用场景如果是检测大目标比如人、车320x320 够用如果是检测小目标比如零件缺陷那还是得用 640x640。我在实际项目中的体会是先把帧率跑稳再逐步优化精度。一开始不要追求最高精度先把整个流水线跑通跑稳然后根据实际检测效果调整模型输入尺寸和置信度阈值。很多时候稍微降低一点置信度阈值就能在不增加计算量的情况下提升召回率。最后再分享一个小技巧如果你的应用场景是固定摄像头、背景变化不大可以考虑加一个简单的背景差分或者运动检测作为前置过滤只有画面有变化的时候才触发推理。这样在画面静止的时候可以大幅降低 NPU 负载整体功耗和发热都会好很多。这个思路在智能车摄像头循迹、安防监控这类场景里特别实用。
