1. 双路视觉方案的核心痛点与背压机制引入做双路视觉方案的人迟早会撞上一堵墙两路摄像头同时出流NPU那边还在吭哧吭哧跑yolov5sCPU还要兼顾编码和业务逻辑结果就是帧率忽高忽低延迟越堆越大最后画面卡成幻灯片。我在香橙派RK3588上折腾这套东西的时候前前后后试了三种架构最后才落到“丢旧帧背压”这个方案上。这篇文章就是把这个阶段二的实现思路、代码细节和踩过的坑从头到尾给你捋一遍。先说清楚这个方案要解决什么问题。双路视觉通常是一路做检测、一路做监控或者两路都做检测但视角不同。RK3588的NPU算力虽然不错但yolov5s跑两路1080p输入单核NPU大概能到15-20 FPS左右如果模型输入是640x640的话。问题在于摄像头出帧是固定30 FPS的NPU消费速度跟不上中间如果没有合理的缓冲策略要么丢帧丢得莫名其妙要么队列越积越长导致延迟爆炸。“丢旧帧背压”的核心思想很简单当消费者NPU推理线程处理不过来的时候不要让它去追最新的帧而是主动把队列里积压的旧帧扔掉只保留最新的一帧。同时通过背压信号告诉生产者摄像头采集线程放慢速度避免无效采集。这个策略在实时性要求高的场景下比“缓冲所有帧”要实用得多因为视觉任务通常只关心“当前发生了什么”而不是“过去每一帧发生了什么”。我选择这个方案还有一个原因RK3588的MPP媒体处理平台和RGA2D图形加速器在帧队列管理上有一些硬件特性可以利用。比如RGA可以直接做格式转换和缩放不需要CPU介入这样在丢帧的时候我们可以只丢原始帧保留已经处理过的帧减少重复计算。这个细节后面会展开讲。适合谁来参考这篇文章如果你已经在香橙派RK3588上跑通了单路yolov5s现在想扩展到双路或者你正在设计一个多路视觉系统对延迟和帧率稳定性有要求那这篇内容应该能帮你省下不少试错时间。如果你还没接触过RK3588的NPU开发建议先去看我前面写的环境搭建和模型部署那几篇不然直接看这个会有点跳。2. 方案整体架构与线程模型设计2.1 为什么不用简单的队列缓冲最开始我用的方案很直接两个摄像头采集线程各自往一个队列里塞帧NPU推理线程从队列里取帧处理。队列用互斥锁保护长度设成10。跑起来之后发现两个问题第一延迟越来越大因为队列满了之后采集线程会阻塞但阻塞期间摄像头还在出帧驱动层的缓冲区也会积压最后端到端延迟能到2秒以上第二两路之间的帧不同步做双目或者多视角融合的时候根本对不齐。后来改成队列满了就丢新帧延迟是降下来了但丢帧率太高而且丢的都是最新的帧导致推理线程拿到的永远是旧画面。这个逻辑反了——实时系统应该保证处理的是最新数据旧数据该丢就丢。2.2 丢旧帧背压的核心机制最终方案的结构是这样的每个摄像头对应一个采集线程采集线程不直接往大队列里塞帧而是先写入一个“单帧槽位”。这个槽位只保留最新的一帧新帧来了就把旧帧覆盖掉。NPU推理线程从槽位里取帧取走之后槽位变空采集线程可以继续写。如果槽位里已经有帧没被取走采集线程就等待一个条件变量这就是背压信号。这个设计的关键在于槽位深度为1天然实现了“丢旧帧”。采集线程在写槽位之前会检查槽位状态如果非空说明消费者还没处理完上一帧这时候采集线程可以选择等待或者直接覆盖。我选择的是等待加超时超时时间设成帧间隔的一半这样既不会完全阻塞采集又能给消费者施加背压。两路之间用一个同步屏障来对齐时间戳。具体做法是两路采集线程在写入槽位之前先检查对方的时间戳如果差距超过阈值比如10ms就等待对方追上。这个同步不是强制的可以根据业务需求开关。2.3 线程优先级与CPU亲和性设置RK3588是8核CPU4个A76大核加4个A55小核。我把采集线程绑到A55小核上NPU推理线程绑到A76大核上这样避免采集线程和推理线程抢CPU。具体用pthread_setaffinity_np来设置采集线程绑到CPU 4-7推理线程绑到CPU 0-3。实测下来这样绑核之后推理线程的抖动明显减小帧率更稳定。线程优先级方面推理线程设成SCHED_FIFO优先级80采集线程设成SCHED_FIFO优先级60。注意设置实时优先级需要root权限或者用cap_sys_nice能力。如果你不想用实时调度至少把推理线程的nice值设成-10采集线程设成0。// 绑核示例 cpu_set_t cpuset; CPU_ZERO(cpuset); CPU_SET(4, cpuset); CPU_SET(5, cpuset); CPU_SET(6, cpuset); CPU_SET(7, cpuset); pthread_setaffinity_np(thread, sizeof(cpu_set_t), cpuset);注意绑核不是万能的如果你的NPU驱动本身有线程调度绑核可能会导致驱动内部线程和你的推理线程抢同一个核。建议先用htop观察一下NPU驱动线程的CPU占用分布再决定绑哪个核。3. 核心数据结构与背压信号实现3.1 单帧槽位的设计细节单帧槽位的数据结构不复杂但有几个细节容易踩坑。我用的是pthread_mutex加pthread_cond的组合槽位里存一个帧描述符包含虚拟地址、物理地址、时间戳和序列号。虚拟地址给CPU访问用物理地址给RGA和NPU用这样避免每次都要做地址转换。typedef struct { void *vaddr; int dma_fd; uint64_t timestamp; uint32_t seq; bool valid; } frame_slot_t; typedef struct { frame_slot_t slot; pthread_mutex_t lock; pthread_cond_t cond; bool consumer_waiting; } frame_buffer_t;写入槽位的逻辑先加锁检查slot.valid如果为true说明消费者还没取走这时候有两种策略。策略A是等待cond直到消费者取走或者超时策略B是直接覆盖但记录一次丢帧计数。我两种都实现了通过配置项切换。实测在双路1080p场景下策略A的端到端延迟比策略B低大约30%但策略B的帧率更稳定。如果你的业务对延迟极度敏感选策略A如果对帧率稳定性要求高选策略B。3.2 背压信号的传递路径背压信号从消费者传到生产者路径是这样的消费者取走帧之后会signal条件变量唤醒可能在等待的生产者。生产者被唤醒后检查槽位是否为空如果为空就写入新帧如果不为空就继续等待或者超时返回。这里有个细节pthread_cond_signal和pthread_cond_broadcast的选择。因为每个槽位只有一个生产者和一个消费者用signal就够了。但如果你把两路合并到一个条件变量上那就得用broadcast否则可能唤醒错误的线程。我建议每路独立的条件变量避免这种复杂性。超时时间的设置也有讲究。如果设得太短生产者频繁超时背压效果不明显如果设得太长生产者阻塞太久摄像头驱动层的缓冲区会积压反而增加延迟。我的经验值是帧间隔的0.5到0.8倍。比如30 FPS的摄像头帧间隔33ms超时设20ms左右比较合适。3.3 时间戳同步与帧对齐双路视觉做对齐的时候时间戳的精度很关键。RK3588的VI视频输入模块出来的帧自带硬件时间戳单位是微秒。但两路摄像头的时钟源可能不同步导致时间戳有偏差。我的做法是在采集线程里记录第一帧的时间戳作为基准后续帧的时间戳都减去这个基准得到相对时间。然后两路之间用一个共享的原子变量来同步基准。对齐逻辑是这样的每路采集线程在写入槽位之前先读取对方的相对时间戳如果自己的时间戳比对方大超过阈值比如15ms就等待对方追上。等待的实现是用一个自旋锁加usleep不要用条件变量因为条件变量的唤醒延迟可能比等待时间还长。提示时间戳同步的阈值不要设得太小否则两路会互相等待导致整体帧率下降。我试过5ms的阈值结果两路都卡在20 FPS左右。后来改成15ms帧率恢复到28 FPS对齐误差也在可接受范围内。4. 与NPU推理线程的对接与优化4.1 RKNN推理的输入预处理yolov5s在RK3588上跑输入通常是640x640的RGB图像。摄像头出来的是1080p的NV12格式需要做裁剪、缩放和格式转换。这一步如果用CPU做耗时大概15-20ms两路就是30-40ms直接把帧率拖垮。所以必须用RGA来做。RGA的用法是创建一个RGA缓冲区把摄像头的DMA fd传进去设置源分辨率和目标分辨率设置格式转换NV12到RGB888然后提交任务。RGA是异步的提交之后可以继续做别的事情等RGA完成中断或者轮询状态。我实测RGA做1080p到640x640的转换耗时大概3-5ms比CPU快4倍以上。// RGA转换示例伪代码 rga_buffer_t src wrapbuffer_fd(src_fd, 1920, 1080, RK_FORMAT_YCbCr_420_SP); rga_buffer_t dst wrapbuffer_fd(dst_fd, 640, 640, RK_FORMAT_RGB_888); im_rect src_rect {0, 0, 1920, 1080}; im_rect dst_rect {0, 0, 640, 640}; imcheck(src, dst, src_rect, dst_rect); improcess(src, dst, src_rect, dst_rect);4.2 推理线程的取帧策略推理线程从槽位取帧的时候我用了非阻塞的方式先尝试取帧如果槽位为空就等一个短超时比如5ms然后重试。这样避免推理线程长时间阻塞在条件变量上导致NPU空闲。实测下来推理线程的CPU占用率在30%左右NPU利用率能到85%以上。取到帧之后先做RGA转换然后调用RKNN的推理接口。RKNN的推理是同步的调用rknn_run之后会阻塞直到推理完成。yolov5s在RK3588单核NPU上的推理时间大概是40-50ms两路交替跑的话单路帧率大概10-12 FPS。这个帧率对于很多场景已经够用了如果你需要更高帧率可以考虑用RK3588的双核NPU或者把模型量化成int8。4.3 后处理与结果输出后处理包括解码yolov5s的输出、做NMS、画框。解码和NMS可以在CPU上做但要注意优化。我用的方法是把输出张量从NPU的内存里拷贝到CPU可访问的内存然后用NEON指令加速解码。NMS用简单的IOU阈值过滤阈值设0.45。画框用OpenCV的rectangle但OpenCV的绘制比较慢如果帧率要求高可以用RGA直接画。结果输出方面我用了共享内存加信号量的方式把检测结果传给业务线程。业务线程可以是编码推流、串口输出或者网络发送。共享内存的大小根据最大检测框数量来定我设的是128个框每个框16字节总共2KB足够用了。注意RKNN的输出张量格式和yolov5s的原始输出可能不一样需要根据你用的RKNN工具链版本做调整。我用的RKNN Toolkit2 1.5.0输出是三个张量分别对应80x80、40x40、20x20的特征图。如果你用的是其他版本先跑一下官方的yolov5示例确认输出格式再改代码。5. 实测性能与调优记录5.1 延迟与帧率实测数据我在香橙派5RK35888GB内存上跑了完整的双路方案摄像头是两路1080p30的MIPI摄像头模型是yolov5s int8量化版。实测数据如下指标单路双路无背压双路丢旧帧背压端到端延迟65ms320ms85ms单路帧率18 FPS8 FPS12 FPSCPU占用45%78%62%NPU占用70%95%88%丢帧率0%15%8%从数据可以看出丢旧帧背压方案把端到端延迟从320ms降到了85ms降幅超过70%。帧率虽然比单路低但双路总共24 FPS对于大多数实时检测场景已经够用了。CPU占用也降下来了因为采集线程不再疯狂空转。5.2 调优过程中的关键参数调优过程中有几个参数对性能影响很大。第一个是槽位等待超时时间我试过5ms、10ms、20ms、30ms最后发现20ms是最佳值。太小了背压效果不明显太大了采集线程阻塞太久。第二个是RGA的任务队列深度默认是1我改成2之后RGA的吞吐量提升了15%左右。第三个是NPU的核心数RK3588有两个NPU核心默认是单核跑改成双核之后推理时间从45ms降到了28ms。# 查看NPU核心数 cat /sys/kernel/debug/rknpu/version # 设置NPU核心数需要驱动支持 echo 2 /sys/kernel/debug/rknpu/core_num提示双核NPU的功耗比单核高不少如果你的设备是电池供电建议还是用单核或者根据负载动态切换。我实测双核跑的时候整板功耗从5W涨到了7.5W。5.3 内存与DMA缓冲区管理双路1080p的NV12帧每帧大小是1920x1080x1.5约3MB。如果队列深度是10两路就是60MB。加上RGA和NPU的缓冲区总内存占用大概在150MB左右。香橙派5的8GB内存完全够用但如果你用的是4GB版本就要注意控制队列深度和缓冲区数量。DMA缓冲区的分配我用的是RK3588的DMA heap通过ioctl来分配和释放。注意DMA缓冲区在进程退出的时候一定要释放否则会泄漏。我写了一个简单的引用计数机制每个缓冲区分配的时候计数加1释放的时候减1减到0才真正free。这样可以避免多线程环境下重复释放或者提前释放。6. 常见问题与排查技巧实录6.1 帧率不稳定忽高忽低这个问题我遇到过好几次原因有好几种。最常见的是CPU频率调节器在作怪默认是ondemand会根据负载动态调频。跑视觉任务的时候CPU频率频繁切换导致帧率抖动。解决办法是把调节器设成performance锁定最高频率。# 查看当前调节器 cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor # 设置成performance echo performance /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor另一个原因是NPU驱动的电源管理策略默认会在空闲的时候降频。如果你发现NPU推理时间忽长忽短可以试试关闭NPU的自动降频。具体方法因驱动版本而异我用的驱动是在/sys/kernel/debug/rknpu/下面有个power_save节点写0关闭。6.2 两路时间戳不同步时间戳不同步的表现是两路检测结果在时间上对不齐做融合的时候框位置偏差大。排查方法是在采集线程里打印每帧的时间戳观察两路的差值。如果差值稳定在某个值附近说明是时钟源偏差可以通过软件补偿。如果差值跳变说明是采集线程调度延迟需要调整线程优先级或者绑核。我遇到过一次两路时间戳差值在0到50ms之间跳变后来发现是其中一路的采集线程被NPU驱动线程抢占了CPU。把采集线程绑到A55小核之后差值稳定在5ms以内。6.3 内存泄漏导致跑一段时间后崩溃内存泄漏是双路方案最容易踩的坑。每帧都要分配DMA缓冲区如果释放不及时跑几个小时之后内存就满了。排查方法是用valgrind或者AddressSanitizer跑一遍看看有没有未释放的缓冲区。另外RKNN的上下文也要注意释放每次推理完之后要调用rknn_outputs_release释放输出张量。我写了一个简单的内存监控脚本每10秒打印一次DMA heap的使用量超过阈值就报警。这个脚本帮我抓到了好几次泄漏都是因为异常路径下忘记释放缓冲区。# 查看DMA heap使用情况 cat /sys/kernel/debug/dma_buf/bufinfo | grep -c size6.4 常见问题速查表现象可能原因排查方法解决方案帧率低于预期CPU降频查看scaling_governor设为performance延迟越来越大队列积压打印队列长度启用丢旧帧背压两路不同步线程调度延迟打印时间戳差值绑核提高优先级内存持续增长缓冲区未释放监控DMA heap检查异常路径释放NPU利用率低推理线程阻塞查看线程状态改非阻塞取帧RGA转换慢任务队列满查看RGA状态增加队列深度7. 后续扩展与个人经验分享这套方案跑通之后我又做了几个扩展。一个是把yolov5s换成yolov8n模型更小推理更快单路能到20 FPS以上。另一个是加了RTSP推流用RK3588的硬件编码器做H.264编码两路1080p推流CPU占用不到10%。还有一个是加了串口输出把检测结果发给下位机做控制。如果你也想做类似的项目我的建议是先把单路跑稳再上双路。单路的时候把延迟、帧率、CPU占用都调到一个满意的水平然后复制一份改成双路。双路的核心难点不在NPU而在帧管理和线程同步。丢旧帧背压这个方案本质上是用一点丢帧率换延迟和稳定性对于大多数实时视觉任务来说这个 trade-off 是值得的。最后分享一个小技巧如果你发现两路帧率差异很大比如一路15 FPS一路8 FPS先检查两路摄像头的曝光时间是不是一样。曝光时间长的摄像头出帧间隔会变大导致采集线程的节奏不一致。把两路的曝光时间设成一样帧率差异会小很多。这个坑我踩过调了半天代码才发现是摄像头参数的问题。
