RK3588一路视频流如何同时跑实时入侵检测和定时视频诊断上一篇我们分享了 MPP 硬解码和 RGA 硬加速的实战经验把 8 路 1080P 视频处理的 CPU 占用降到了 20% 以下。但解码能力上来之后新的问题又来了——同一个摄像头客户既想跑实时人员入侵检测每秒 10 帧又想跑定时视频诊断每 2 小时抽一帧还想跑定时烟火检测每 30 分钟抽一帧。难道要对同一路视频拉三次流、解三次码本文分享我们的「同源多任务调度」设计以及如何用一路视频流同时支撑多个算法任务。一、背景边缘视频分析的任务多样性做工业 AI 视觉很少有客户只需要一个算法任务。真实场景里同一个摄像头往往要同时承担多种检测任务。举个典型的例子——某工厂园区的周界摄像头实时人员入侵检测7×24 小时运行每秒分析 10 帧有人进入警戒区域立即告警定时摄像头遮挡检测每 2 小时抽一帧检测摄像头是否被遮挡、偏转、模糊定时烟火检测每 30 分钟抽一帧检测是否有烟雾或明火工作时间违章停放检测工作日 8:00-18:00 运行实时检测是否有车辆违停这四个任务针对的是同一个摄像头的同一路视频流但它们的特性完全不同任务触发模式频率实时性要求算力需求人员入侵实时流10 帧/秒高秒级告警高遮挡检测定时抽帧1 帧/2 小时低极低烟火检测定时抽帧1 帧/30 分钟低低违章停放实时流仅工作时间5 帧/秒中中实时流任务需要持续拉流、持续解码、持续推理对实时性要求高算力需求大。定时抽帧任务只需要在特定时间点取一帧分析对实时性要求低算力需求极小。这两种任务混在一起怎么调度这就是我们要解决的问题。二、踩坑实录「每个任务单独拉流」的三大浪费刚开始做的时候我们的方案很简单粗暴每个任务独立拉流、独立解码、独立推理。人员入侵任务拉一路 RTSP 流遮挡检测任务再拉一路烟火检测再拉一路……同一个摄像头被拉了三四路流。跑起来之后发现问题很大。浪费一带宽翻倍摄像头连接数超限每拉一路 RTSP 流就要占用一份带宽。1080P 视频流的码率通常是 4-8Mbps拉 4 路就是 16-32Mbps。一个园区几十路摄像头带宽直接爆了。更严重的是很多网络摄像头IPC的并发连接数有限——便宜的摄像头可能只支持 2-3 路并发 RTSP 连接好一点的支持 5-8 路。我们拉 4 路流可能就把摄像头的连接数占满了其他系统比如客户原有的视频监控平台就连不上了。客户的反馈很直接「你们装了 AI 分析之后我们原来的监控平台看不了这个摄像头的画面了怎么回事」浪费二解码算力重复占用每一路流都要独立解码。虽然我们用了 MPP 硬解码CPU 占用不高但 MPP 的解码通道数也是有限的——RK3588 虽然能硬解 16 路以上 1080P但如果每个摄像头都重复解码 3-4 次实际能支持的摄像头数量就大打折扣。而且重复解码还会增加内存占用——每路解码都要分配一组输入输出缓冲区4 路就是 4 组内存浪费严重。浪费三系统复杂度飙升故障排查困难每个任务独立拉流意味着每个任务都要管理自己的 RTSP 连接、重连、解码、错误处理。同一个摄像头的 4 个任务可能这个任务连接正常那个任务断线了另一个任务解码花屏了——状态不一致排查起来非常痛苦。有一次客户说「这个摄像头的入侵检测不告警了」我们查了半天发现入侵检测任务的 RTSP 连接断了没重连但遮挡检测任务的连接是好的——因为是独立连接一个断了不影响另一个但用户看到的是「这个摄像头时好时坏」。「每个任务单独拉流」这个方案本质上是把同一个物理资源摄像头的视频流重复使用了多次既浪费带宽、浪费算力又增加了系统复杂度。三、我们的方案同源多任务复用调度 [Yuewell Inside]踩了这些坑之后我们重新设计了调度机制。核心思想很简单同一个摄像头的视频流只拉一次、只解一次多个任务共享这一路解码后的帧。我们把任务分成两种模式模式一LIVE实时长连任务需要持续分析视频流的任务如人员入侵、违章停放采用 LIVE 模式。系统对该摄像头建立一条常驻 RTSP 长连接MPP 硬解码持续运行把最新的帧写入越微自研共享帧池所有 LIVE 任务从共享帧池取帧按各自的采样频率送检比如人员入侵任务每 100ms 取一帧10fps违章停放任务每 200ms 取一帧5fps关键点不管有多少个 LIVE 任务RTSP 只拉一路、解码只做一次。多个任务只是从同一个帧池里按各自的节奏取帧互不干扰。模式二CRON定时抽帧任务只需要在特定时间点取一帧分析的任务如遮挡检测、烟火检测采用 CRON 模式。任务到期时不单独拉流而是从该摄像头当前的共享帧池里取最新一帧给这一帧打上该任务的 ID单帧送入推理推理完成后结果按该任务的规则处理告警、推送、记录关键点CRON 任务「借道」LIVE 任务的长连接和解码零额外开销。对 LIVE 任务完全没有影响——只是从帧池里多取了一帧而已。闲置相机按需拉流阅后即焚如果某个摄像头没有任何 LIVE 任务只有 CRON 任务或者所有任务都在非工作时间那怎么办我们的策略是按需拉流CRON 任务到期时临时建立 RTSP 连接拉流、硬解第一张合规的 I 帧关键帧不需要等前面的帧把这一帧送入推理推理结束后立即断开连接、释放解码内存系统回到静默状态等待下一次任务触发我们把这个策略叫做「阅后即焚」——用完就断不占资源。对于只有定时任务的摄像头比如仓库里的烟火检测每小时抽一帧这个策略能节省 99% 以上的带宽和解码资源——因为大部分时间摄像头是静默的只在抽帧的那一瞬间短暂连接。点播复用客户端预览也不重复拉流还有一种情况运维人员用客户端UI/交互层进程实时预览某路摄像头的画面。这时候也不应该重复拉流——如果该摄像头已经有 LIVE 任务在跑预览直接从当前的解码帧路径订阅复用和 CRON 任务一样「借道」。如果该摄像头没有 LIVE 任务那预览就触发一次按需拉流预览结束后断开。总之整个系统中同一个摄像头在任何时刻最多只有一路 RTSP 连接、一个解码会话。所有需要帧的消费者LIVE 任务、CRON 任务、客户端预览都从这一路解码输出中取帧共享复用。四、调度机制的几个关键设计关键设计一越微自研共享帧池生产者-消费者模式整个调度机制的核心是共享帧池——一个摄像头对应一个帧池MPP 解码是生产者持续把最新的帧写入帧池各个任务是消费者按各自的节奏从帧池取帧。帧池的设计要点只保留最新一帧帧池不需要存很多帧只需要存当前最新的一帧。因为 AI 分析只关心最新的画面旧帧没有意义。这样内存占用极小。线程安全生产者解码线程和多个消费者任务线程并发访问帧池需要用锁或无锁队列保证线程安全。零拷贝帧池里存的是 DMA-BUF fd硬解码输出的硬件缓冲区句柄消费者取帧的时候只是增加引用计数不拷贝图像数据。用完之后减少引用计数引用计数为 0 时归还 MPP。关键设计二任务级别的采样频率控制不同的 LIVE 任务有不同的采样频率——人员入侵要 10fps违章停放 5fps 就够了。我们在任务级别控制采样频率而不是统一按解码帧率送检。这样做的好处是节省 NPU 算力——不需要每个任务都按 25fps 送检按实际需求来任务之间互不干扰——一个任务调整采样频率不影响其他任务灵活适配不同场景——高安全级别的区域用高帧率低风险区域用低帧率关键设计三时间窗控制很多任务不是 7×24 小时运行的——比如违章停放检测只在工作日 8:00-18:00 运行夜间不需要。我们支持按时间窗控制任务的启停。时间窗的设计每个任务可以配置「运行时间窗」如工作日 8:00-18:00进入时间窗时任务激活开始从帧池取帧送检离开时间窗时任务休眠不再取帧如果一个摄像头的所有 LIVE 任务都进入休眠且没有预览那 RTSP 连接也会断开回到静默状态时间窗控制能进一步节省资源——非工作时间整个系统的负载会大幅下降。关键设计四CRON 任务强制单帧确认CRON 任务是定时抽帧几小时才一帧这种任务不适合做「连续 N 帧确认」的事件融合因为两帧之间隔了几小时根本不是连续的。所以我们对 CRON 任务强制单帧确认——检测到目标就立即告警推送不需要连续多帧确认。这样做的原因定时任务两帧间隔太久连续帧确认没有意义定时任务通常用于状态检测如摄像头是否被遮挡、仓库里是否有烟火一帧就能判断状态避免和跳帧策略冲突——定时任务本身就是低频抽帧如果还要求多帧确认可能永远凑不齐但定时任务的单帧确认意味着误报率可能比实时任务高一些——因为没有连续帧过滤。所以定时任务更依赖 ROI 过滤和模型本身的精度。对于误报率要求高的定时任务我们会建议用更精准的专用模型如烟火检测用专模而不是通用检测模型。五、实战案例某园区 16 路相机的调度优化我们在一个客户现场做了调度优化前后的对比。这个客户有 16 路摄像头每路摄像头平均配置 3 个任务1 个实时任务 2 个定时任务。优化前每个任务单独拉流RTSP 连接数16 路 × 3 任务 48 路连接带宽占用48 路 × 4Mbps 192Mbps客户的千兆网络都快扛不住了MPP 解码通道48 路很多摄像头的连接数超限频繁掉线系统状态不稳定频繁出现某个任务断线、某个摄像头连接失败的情况优化后同源多任务复用RTSP 连接数16 路每个摄像头一路有实时任务的常驻只有定时任务的按需拉流带宽占用16 路 × 4Mbps 64Mbps按需拉流的摄像头大部分时间静默实际带宽更低MPP 解码通道16 路每个摄像头解一次所有任务共享系统状态稳定运行不再出现连接数超限的问题优化效果连接数降到原来的 1/3带宽降到原来的 1/3系统稳定性大幅提升。而且因为解码只做一次CPU 占用也进一步下降。客户的运维人员说「优化之后原来的监控平台也能正常看画面了再也没有出现过摄像头连不上的情况。」六、踩坑实录同源多任务调度的实现过程中我们也踩了不少坑。坑一共享帧池的竞态条件偶发花屏共享帧池被生产者解码线程和多个消费者任务线程并发访问如果同步机制做得不好就会出现竞态条件——消费者正在读一帧生产者刚好把这一帧释放了消费者读到一半数据就变了导致花屏。我们一开始用简单的互斥锁保护帧池但在高并发下锁竞争严重影响性能。后来改成了无锁队列 引用计数的方式性能和稳定性都好了很多。经验共享资源的并发访问是嵌入式系统中最容易出问题的地方一定要充分测试特别是长时间运行的稳定性测试。坑二按需拉流的「第一张 I 帧」问题闲置相机的按需拉流策略是「临时连接 → 硬解第一张 I 帧 → 推理 → 断开」。但实际实现中「第一张 I 帧」并不总是那么好拿——有些摄像头的 I 帧间隔很长比如 5 秒一个 I 帧连接后可能要等好几秒才拿到 I 帧有些摄像头的码流开头是 P 帧非关键帧没有前面的 I 帧就解不出来网络抖动可能导致前几个包丢失第一个 I 帧可能丢了我们的解决方案是连接后设置一个超时时间比如 3 秒在超时时间内等第一个 I 帧如果超时还没拿到就重试一次重试还不行就告警标记该摄像头抽帧失败。经验按需拉流看起来简单但「拿第一帧」的细节很多要做好超时和重试机制。坑三时间窗切换时的状态不一致时间窗控制中任务在进入/离开时间窗时会激活/休眠。如果多个任务的时间窗不一样比如人员入侵是 7×24违章停放是工作日 8-18 点在时间窗切换的瞬间可能出现状态不一致——违章停放任务离开时间窗休眠了但它的推理请求还在处理中人员入侵任务还在跑但摄像头因为「所有 LIVE 任务都休眠了」被断开了实际上人员入侵还在跑我们的解决方案是用引用计数管理摄像头的连接状态——每个 LIVE 任务激活时增加引用计数休眠时减少引用计数只有当引用计数降到 0 时才断开摄像头连接。这样就不会出现「还有任务在跑但摄像头被断开」的情况。⚠️ 工程坑点与技术壁垒警告提示同源多任务调度的思想不难理解但工程落地中有几个高壁垒问题多消费者无锁帧池的稳定性一个生产者 N 个消费者的无锁帧池在长时间高并发运行下任何一个引用计数的 race condition 都可能导致偶发花屏、内存泄漏或进程崩溃。越微团队在内核态与用户态构建了专属的无锁队列与帧同步状态机经过上百小时的压测和故障注入才确保零崩溃运行。按需拉流的异常码流与 I 帧等待工业现场摄像头品牌杂按需拉流时可能遇到 I 帧间隔过长、码流开头异常、网络抖动丢包等问题。简单的「连接→取帧→断开」流程在真实环境中会频繁失败。越微自研的按需拉流引擎做了多层超时、重试、降级处理才能在复杂现场环境中稳定运行。这些细节不是看几篇博客就能搞定的需要在真实设备上反复调试、压测、故障注入。越微团队在这上面投入了大量时间才打磨出稳定的同源多任务调度引擎。七、几点经验总结回头看同源多任务调度的设计和落地过程总结几点1. 边缘视频分析「拉流次数」是比「解码性能」更先遇到的瓶颈很多人一开始关注的是「RK3588 能解多少路」但实际项目中先遇到的瓶颈往往是「摄像头能支持多少路并发连接」和「网络带宽够不够」。同源复用把拉流次数降到最低是比硬解码更优先的优化。2. 越微自研共享帧池 零拷贝是同源复用的技术基础多个任务共享一路解码输出核心是共享帧池的设计。帧池要做到只存最新帧、线程安全、零拷贝。引用计数管理 DMA-BUF fd 的生命周期是保证不内存泄漏、不花屏的关键。这个机制看起来简单但实现细节很多race condition 很容易出问题要充分测试。3. 「阅后即焚」的按需拉流对只有定时任务的摄像头特别有效很多摄像头比如仓库、库房不需要实时分析只需要定时抽帧检测烟火、遮挡。这种摄像头如果常驻拉流99% 的时间都是浪费。按需拉流、用完就断能把带宽和解码资源节省到极致。对于大规模部署几十上百路摄像头这个策略能显著降低整体资源需求。4. 任务级别的采样频率控制比统一帧率更灵活、更省算力不同任务对帧率的需求不同——入侵检测要高帧率违章停放低帧率就够。在任务级别控制采样频率而不是统一按解码帧率送检既能满足不同任务的需求又能节省 NPU 算力。NPU 是边缘设备最宝贵的资源能省则省。5. 时间窗控制是被低估的节能手段很多任务只在特定时间运行工作时间、白天。支持时间窗控制让任务在非运行时间休眠甚至让整个摄像头的拉流都断开能让系统在非高峰时段的负载大幅下降。这不仅省电也减少了硬件的长时间高负载运行延长设备寿命。写在最后同源多任务调度本质上是「资源共享」思想在边缘视频分析中的具体应用——同一个摄像头的视频流是一种有限的物理资源带宽、连接数、解码能力不应该被重复浪费。通过越微自研共享帧池、按需拉流、任务级采样控制我们让一路视频流同时支撑多个算法任务把资源利用率提到最高。这些经验都是我们越微智能在实际项目中踩坑踩出来的。我们团队一直在做工业 AI 视觉、边缘计算部署、机器人二次开发这些落地工作边缘 AI 视频分析系统是我们的核心产品之一。后面的文章我们会继续拆解——零拷贝跨进程通信、多模型推理、事件融合与证据链、部署与 OTA 升级把更多实战经验分享出来。如果你也在做边缘视频分析、多路视频调度、RK3588 开发相关的工作欢迎交流我们一起踩坑、一起进步。关于作者与团队越微智能Yuewell是一支专注具身智能与工业 AI 视觉落地的技术团队提供工业级视觉算法定制30 算法、RK3588 边缘一体机、具身机器人调度管理平台、全品牌机器人二次开发适配宇树/优必选/智元/傅利叶等、ROS2 系统开发等产品和服务支持从算法、硬件到产线实机部署的全栈交付。我们将这套经过大规模现场验证的同源多任务调度引擎封装为了**工业级边缘 AI 视觉基座Yuewell Edge Framework**的核心模块支持硬件/算法快速二次开发帮助客户跳过最痛苦的工程踩坑阶段。下一篇预告《零拷贝跨进程通信边缘服务和算法服务之间如何做到近零 CPU 负载的图像传输》我们将分享边缘 AI 系统中进程间通信的瓶颈、基于 DMA-BUF 的无锁零拷贝共享内存环形缓冲区设计、背压控制策略队列深度为 1、忙则跳帧以及零拷贝 vs 传统传输的性能对比敬请关注。