双路摄像头同时跑 yolov5s在 RK3588 上最让人头疼的不是模型跑不动而是两路视频流一进来NPU 和 CPU 的节奏就开始互相拖后腿。我最早做双路方案的时候两路各 30fps 的 MIPI 输入推理单帧大概 40ms 左右结果就是队列越堆越长画面延迟从 100ms 一路涨到 2 秒以上最后整个系统像卡死一样。后来我把方案拆成几个阶段来迭代这一篇专门讲阶段二的核心思路——丢旧帧背压。它解决的就是处理不过来时到底该丢谁、在哪丢、怎么丢得干净这个问题。如果你正在用香橙派 5 或者任意 RK3588 板子做多路视觉尤其是 yolov5s 这类轻量检测模型并且已经踩过延迟越跑越大的坑那这篇内容基本就是给你写的。我会从背压的本质讲起把丢帧策略的设计逻辑、代码落点、参数选择、实测数据都摊开说最后再聊聊这个方案在什么情况下会失效、该怎么兜底。全程按我实际调试的顺序来不跳步。1. 为什么双路视觉一定会遇到越跑越慢1.1 双路 30fps 输入和单帧 40ms 推理之间的数学账先把账算清楚很多问题一看数字就明白了。假设两路摄像头都是 1080p30fps那么每秒进入系统的帧数是 60 帧。yolov5s 在 RK3588 的 NPU 上用 RKNN 量化后的模型单帧推理时间我实测大概在 35ms 到 50ms 之间取个中间值 40ms。那么单靠一个 NPU 核心理论最大吞吐是 1000/40 25fps。也就是说输入 60fps处理能力 25fps缺口是 35fps。这个缺口不会凭空消失它只会变成队列里的积压。如果队列不设上限积压会线性增长延迟 积压帧数 × 单帧处理时间。跑 10 秒积压 350 帧延迟就是 14 秒。这就是为什么很多人跑着跑着发现画面越来越慢最后完全对不上实时。这里有个容易被忽略的点RK3588 的 NPU 是 6TOPS 算力但它不是无限并行的。yolov5s 的算子在不同核心上的调度有开销多核并行跑同一个模型实际加速比往往到不了 3 倍。我实测三核并行大概能到 1.8 到 2.2 倍所以即便开满三核吞吐也就 50fps 上下还是填不满 60fps 的坑。这个结论很重要它意味着堆算力解决不了根本问题必须从数据流层面做取舍。1.2 队列积压的本质生产快于消费用生产者-消费者模型来看就很清楚。摄像头是生产者NPU 推理是消费者中间用队列连接。当生产速率大于消费速率队列长度单调递增。这是排队论里最基础的不稳定系统。很多人第一反应是加大队列觉得缓冲大一点就能扛住突发。这个思路在短时突发场景下是对的但在持续过载场景下是灾难。因为队列越大延迟越高而且延迟是单调累积的不会自己回落。你加大队列只是把崩溃推迟了几十秒而已。正确的思路是反过来队列要小甚至要主动丢帧。当系统处理不过来时必须承认这个事实然后决定丢哪些帧。这就是背压backpressure的核心——不是让数据无限堆积而是让上游感知到下游的压力主动降速或丢弃。1.3 丢帧不是妥协是实时系统的必要设计我见过不少做视觉的朋友一听到丢帧就觉得是偷工减料。其实在实时系统里丢帧是标准操作。你想想一个监控场景用户要看的是现在发生了什么而不是3 秒前发生了什么。如果延迟 3 秒那这个检测结果对实时决策毫无价值还不如丢掉旧帧保证当前帧的新鲜度。这里的关键指标不是处理了多少帧而是端到端延迟和有效帧率。有效帧率指的是用户实际看到的、延迟可接受的帧率。丢帧策略的目标就是让有效帧率最大化同时把延迟压在一个固定范围内。提示判断一个视觉系统是否健康先看延迟是否稳定。延迟稳定在 200ms 以内比平均延迟 100ms 但偶尔飙到 2 秒要好得多。稳定性比绝对值更重要。2. 背压方案的整体架构与数据流设计2.1 从无界队列到有界队列丢弃策略阶段一我用的其实是最朴素的无界队列结果就是前面说的延迟爆炸。阶段二的核心改动是把队列换成有界队列并且明确丢弃策略。具体来说每一路摄像头对应一个独立的采集线程和一个有界队列队列容量设为 N。当采集线程要入队时先检查队列是否已满。如果满了就执行丢弃动作。丢弃动作有两种选择丢队首最旧的帧或者丢当前帧最新的帧。这两种选择对应完全不同的语义后面会详细讲。有界队列的容量 N 是个关键参数。N 太小系统对突发抖动没有缓冲能力容易误丢N 太大延迟上限就高。我一般按可接受最大延迟 / 单帧处理时间来估算。比如可接受延迟 200ms单帧 40ms那 N 大概取 5。实际我会取 3 到 5 之间留一点余量。2.2 双路独立队列还是共享队列这是阶段二设计时我纠结最久的一个点。两种方案各有道理方案优点缺点适用场景双路独立队列两路互不干扰一路卡顿不影响另一路总内存占用高NPU 调度需要仲裁两路优先级相同、独立分析共享队列内存利用率高NPU 调度简单一路突发会挤占另一路两路可统一调度、有优先级我最后选了双路独立队列。原因是双路视觉通常两路是独立任务比如一路做全景检测、一路做特写跟踪它们的实时性要求可能不同。独立队列能让每路根据自己的节奏丢帧不会因为另一路的突发把好帧挤掉。但独立队列带来一个新问题NPU 是共享资源两个队列的帧都要抢 NPU。如果两路同时有帧要推理就得有个仲裁机制。我的做法是给每路一个权重按权重轮询取帧。权重可以根据业务优先级设比如跟踪路权重高一点保证它优先拿到算力。2.3 丢旧帧 vs 丢新帧语义差异这是背压方案里最核心的一个决策点很多人没想清楚就随便选了一个。丢旧帧drop oldest队列满时把队首最旧的帧扔掉把新帧放进去。语义是永远保留最新的帧。适合实时性要求高的场景比如实时跟踪、交互式应用。代价是可能丢掉一些中间帧导致运动估计不连续。丢新帧drop newest队列满时直接丢弃当前新来的帧队列内容不变。语义是优先处理已经排队的帧。适合需要完整序列的场景比如视频录制、逐帧分析。代价是延迟会累积因为队列里的旧帧还在慢慢处理。对于 yolov5s 双路检测这种场景我强烈建议丢旧帧。因为检测结果的价值随时间衰减3 秒前的检测框对当前决策没意义。丢旧帧能保证你处理的永远是最新鲜的画面延迟稳定。注意丢旧帧时如果队列用普通数组实现删除队首是 O(n) 操作帧率高的时候这个开销不能忽略。建议用环形缓冲区ring buffer入队和丢弃都是 O(1)。3. 丢旧帧背压的具体实现落点3.1 环形缓冲区作为有界队列的载体环形缓冲区是丢旧帧方案的最佳载体。它用一块固定大小的内存通过读写指针循环使用天然支持 O(1) 的入队和出队而且内存零分配不会因为频繁 malloc/free 造成碎片。我用 C 实现了一个简化版核心逻辑大概是这样templatetypename T, size_t N class RingBuffer { public: // 入队队列满时丢弃最旧元素 bool push_drop_oldest(const T item) { std::lock_guardstd::mutex lock(mtx_); if (count_ N) { // 队列满移动读指针丢弃最旧 read_ (read_ 1) % N; count_--; dropped_; } buffer_[write_] item; write_ (write_ 1) % N; count_; return true; } bool pop(T item) { std::lock_guardstd::mutex lock(mtx_); if (count_ 0) return false; item buffer_[read_]; read_ (read_ 1) % N; count_--; return true; } size_t dropped() const { return dropped_; } private: T buffer_[N]; size_t read_ 0, write_ 0, count_ 0; size_t dropped_ 0; std::mutex mtx_; };这里有个细节push_drop_oldest在队列满时先移动读指针再写入这样最旧的元素就被新元素覆盖了。dropped_计数器用来统计丢帧数这个指标在调试时非常有用能直接告诉你系统过载程度。3.2 采集线程与推理线程的职责划分线程模型我分成三类采集线程每路一个负责从 MIPI 或 USB 摄像头取帧做必要的格式转换比如 NV12 转 RGB然后 push 到对应队列。推理线程从队列 pop 帧调用 RKNN 推理输出检测结果。后处理/显示线程接收推理结果画框、推流或显示。采集线程的节奏由摄像头帧率决定它不管下游处理得过来处理不过来只管往队列里塞。队列满了就触发丢旧帧。这样采集线程永远不会阻塞摄像头驱动也不会因为应用层慢而丢帧驱动层丢帧和应用层丢帧是两回事前者不可控后者可控。推理线程的节奏由自己的处理速度决定它 pop 一帧处理一帧处理完再 pop。如果队列空了就短暂 sleep 或等待条件变量避免空转烧 CPU。这里有个坑如果采集线程和推理线程共用一个 mutex高帧率下锁竞争会很严重。我的做法是采集和推理用不同的锁粒度或者用无锁队列。不过无锁队列实现复杂容易出 bug帧率不是特别高的话普通 mutex 加细粒度锁就够了。我实测 60fps 下 mutex 开销可以忽略。3.3 关键参数队列深度、丢帧阈值、统计窗口参数选择直接决定方案效果我把我调过的参数和依据列一下参数我的取值依据调整方向队列深度 N3~5可接受延迟 200ms / 单帧 40ms ≈ 5延迟要求高就减小丢帧统计窗口1 秒足够反映瞬时过载抖动大就加长推理线程 sleep1ms平衡响应和 CPU 占用CPU 紧张就加大双路权重1:1 或 2:1按业务优先级按需调整队列深度 N 是最关键的。N1 意味着完全没有缓冲任何抖动都会丢帧但延迟最低。N5 能吸收一定抖动延迟上限 200ms。我一般从 3 开始调观察丢帧率如果丢帧率长期高于 30%说明系统确实过载这时候要么降分辨率、要么降帧率、要么换更轻的模型光靠调 N 是救不回来的。丢帧统计窗口用来算丢帧率。丢帧率 窗口内丢弃帧数 / 窗口内总帧数。这个指标比绝对丢帧数更有意义。丢帧率 10% 以内系统算健康10% 到 30%勉强能用超过 30%用户体验会明显变差得考虑降载。4. 实测数据与调优过程4.1 测试环境与基线数据我的测试环境是香橙派 5RK358816GB系统是 Ubuntu 20.04两路 MIPI 摄像头 1080p30fpsyolov5s 用 RKNN Toolkit2 转成 rknn 模型量化到 int8。NPU 开三核。基线阶段一无界队列的数据单帧推理约 42ms初始延迟约 80ms运行 30 秒后延迟超过 2.5 秒有效帧率持续下降最后接近 0这个数据很典型就是典型的队列爆炸。延迟单调上升系统实际上已经失去实时性。4.2 丢旧帧方案上线后的延迟曲线换成丢旧帧背压后同样的负载单帧推理约 42ms不变延迟稳定在 150ms 到 220ms 之间波动丢帧率约 45%有效帧率每路约 16fps延迟从单调上升变成稳定波动这是最本质的改善。虽然丢帧率高达 45%但用户看到的画面始终是新鲜的延迟可控。有效帧率 16fps 对于检测任务来说虽然不算高但足够做实时跟踪和告警。这里要说明一下45% 的丢帧率听起来吓人但它是系统过载的必然结果。输入 60fps处理能力 25fps理论丢帧率就是 (60-25)/60 ≈ 58%。我实测 45%说明 NPU 调度比我预估的稍好一点。这个数字是符合预期的。4.3 队列深度从 1 调到 8 的对比我做了组对比实验固定其他条件只改队列深度 N队列深度平均延迟延迟抖动丢帧率有效帧率195ms小58%25fps3160ms中47%25fps5230ms中43%25fps8380ms大40%25fps有意思的发现有效帧率几乎不变都是 25fps 左右因为瓶颈在 NPU 吞吐不在队列。队列深度只影响延迟和丢帧率的分配。N 越大延迟越高但丢帧率略低。这是因为大队列能吸收更多抖动减少误丢。所以选 N 的本质是权衡延迟和丢帧率。我最终选 N3因为 160ms 延迟对大多数实时应用可接受丢帧率 47% 也在预期内。如果应用对延迟极敏感比如机械臂抓取那就选 N1牺牲丢帧率换最低延迟。4.4 双路权重调整对公平性的影响双路权重我试过 1:1 和 2:1。1:1 时两路有效帧率基本一致都是 12fps 左右因为总吞吐 25fps 要分给两路。2:1 时高权重路能到 16fps低权重路只有 8fps。这个调整的意义在于业务适配。如果一路是主检测、一路是辅助监控那 2:1 甚至 3:1 是合理的把算力倾斜给重要任务。如果两路同等重要就 1:1。权重不是技术问题是业务问题得根据实际需求定。提示权重调整要配合丢帧统计一起看。如果低权重路丢帧率超过 60%说明它基本没在正常工作这时候要么提高权重要么干脆关掉一路别让它占着资源还出不了结果。5. 这套方案在什么情况下会失效5.1 单帧推理时间波动过大时的抖动放大丢旧帧方案有个隐含假设单帧推理时间相对稳定。如果推理时间波动很大比如有时 30ms 有时 200ms那队列深度的估算就失效了。200ms 的帧会把队列瞬间填满触发大量丢帧然后系统进入丢帧-空闲-丢帧的震荡。我遇到过这种情况原因是 NPU 被其他进程抢占或者模型里有动态 shape 的算子导致调度不稳定。解决办法是给推理线程设实时优先级或者把 NPU 独占别让其他任务抢。另外模型尽量用固定 shape避免动态调度。5.2 摄像头驱动层丢帧与应用层丢帧的叠加这是个隐蔽的坑。应用层丢帧是我们主动控制的但摄像头驱动层也可能丢帧而且我们控制不了。当应用层处理慢导致 MIPI 缓冲区满驱动层就会丢帧。这时候你看到的总丢帧率是两层叠加的但统计里只反映了应用层的。判断方法看摄像头驱动的丢帧计数v4l2 一般有 frame drop 统计。如果驱动层也在丢说明应用层消费太慢得从根上降载而不是调队列参数。我一般会同时监控两层丢帧确保驱动层丢帧接近 0所有丢帧都发生在应用层可控范围内。5.3 多路扩展到四路时的算力天花板双路方案跑通后很容易想扩展到四路。但 RK3588 的 NPU 吞吐是硬天花板双路已经 45% 丢帧了四路只会更惨。四路 30fps 输入是 120fps处理能力 25fps丢帧率会到 79%有效帧率每路只有 6fps基本没法用。这时候丢旧帧方案本身没错但它救不了算力不足。正确的做法是降载降分辨率到 720p、降帧率到 15fps、换更轻的模型比如 yolov5n或者做区域检测只检测 ROI 区域减少计算量。丢帧方案是过载时的优雅降级不是过载的解决方案。6. 几个我踩过的具体坑和绕法6.1 帧内存的生命周期管理丢旧帧时被丢弃的帧内存必须正确释放否则会内存泄漏。我用的是引用计数或者内存池。如果每帧都是独立 malloc 的丢弃时要 free如果用内存池丢弃时归还到池里。我推荐内存池因为频繁 malloc/free 在高帧率下开销明显而且容易碎片化。具体做法预分配 N2 个帧缓冲N 是队列深度2 是给正在采集和正在推理的帧留余量用空闲链表管理。采集线程从空闲链表取缓冲推理完归还。这样内存零分配稳定可靠。6.2 条件变量的虚假唤醒推理线程等待队列非空时如果用条件变量要注意虚假唤醒。标准写法是 while 循环检查条件而不是 ifstd::unique_lockstd::mutex lock(mtx_); while (count_ 0 !stop_) { cv_.wait(lock); }用 if 的话虚假唤醒会导致 pop 空队列拿到垃圾数据。这个 bug 很隐蔽因为虚假唤醒不常发生测试时可能碰不到上线后偶发崩溃。6.3 时间戳对齐与丢帧后的时序丢帧后帧的时间戳会不连续。如果下游做运动估计或轨迹跟踪时间戳跳变会导致速度计算错误。我的做法是每帧都带采集时间戳下游用时间戳算实际间隔而不是假设固定帧间隔。这样即使丢帧速度估计也是准的。另外双路的时间戳要统一时钟源。如果两路用各自的系统时钟会有偏差。我用的是同一个 monotonic clock采集时打时间戳保证两路可比。7. 阶段二之后还能往哪走阶段二解决了过载时怎么优雅降级但它是个被动方案——系统过载了才丢帧。阶段三我打算做主动降载根据丢帧率动态调整采集帧率或分辨率。丢帧率高了就主动把摄像头帧率从 30fps 降到 20fps从源头减少输入而不是在队列里丢。主动降载的好处是减少无效采集和格式转换的开销。丢旧帧虽然不推理旧帧但采集和转换的开销还是花了。主动降载能把这部分也省下来整体效率更高。另一个方向是模型层面的优化。yolov5s 换成 yolov5n或者做模型剪枝、量化感知训练把单帧推理从 42ms 压到 25ms吞吐直接翻倍丢帧率大幅下降。这是治本的方向但需要重新训练和转换模型工作量比调数据流大。我个人在实际操作中的体会是数据流层面的优化丢帧、背压、队列管理性价比最高改动小、见效快应该先做。模型优化是第二步等数据流稳定了再动。两者结合才能把 RK3588 的双路视觉真正跑稳。