RK3328+SPR5801边缘视频分析流水线实践：解码与推理解耦

最近在折腾一个边缘视频分析盒子的预研项目，需求看起来挺朴素：一路4K@30fps的RTSP监控流进来，本机要完成硬件解码、目标检测，再把结果叠加到画面上送出去，整机功耗尽量压在15W以内。一开始我也想偷懒，想着问题不大，直接在RK3328这颗四核A53的SoC上把解码和推理全包了。结果第一轮调下来就发现是个坑：VPU硬件解码没问题，但CPU推理这块纯粹是拿柴火烧锅炉，A53那点算力连720P的检测模型都跑不顺，更别说4K画面上要稳定跑目标框。

后来方案被我拆成两半：解码交给RK3328自带的VPU模块，推理交给SPR5801这个独立边缘加速模块。这么一分，整条链路彻底清爽了，端到端延迟、吞吐、功耗都有了可以量化的数据。这篇文章把我从选型、解码、模型接入到整管线联调的完整过程都拆开讲，连踩过的坑都给你留了清单，后面想做类似边缘视频智能设备的朋友可以直接抄作业。

1. 项目需求拆解：为什么把解码和推理拆成两颗芯片

1.1 单SOC方案的死结：A53核扛不动实时检测

RK3328这颗SoC本身不弱，四核Cortex-A53，频率能到1.5GHz左右，带一个支持H.264/H.265/VP9硬解的VPU，也带Mali GPU。如果你只是做视频转码、做录像存储、做ONVIF接入，它完全够用，而且整套BSP都给你配好了，跑起来很省心。

但问题出在“视频分析”四个字上。目标检测这类任务本质是大量的卷积运算，A53这种低功耗核心跑卷积的效率极低。我当时在板子上直接扔了个轻量级的人体检测模型，输入分辨率压到640x640，单帧推理耗时大概在200到300毫秒。什么意思呢，也就是每秒只能处理三四帧，解码出来的其余二十多帧全得丢。这还不能叫实时，只能叫“抽帧检测”。

有人会问，那GPU呢？RK3328集成的Mali-450MP2是2012年左右的玩意儿，做显示合成没问题，拿它跑计算管线基本是找罪受，OpenCL支持也残废，我没有继续深入。

选来选去只剩两条路：要么换一颗带NPU的更高阶SoC，要么外挂一颗边缘加速模块。换SoC涉及整块板子重画、全部驱动重调、成本和周期都不可控。所以我的结论很直接：保留手里的RK3328主板，外挂SPR5801加速模块，解码用VPU，推理用SPR5801。

1.2 算力账和带宽账怎么算才不亏

两颗芯片之间要来回导数据，很多人一听就嫌麻烦。但真把账算下来，其实非常划算。

先说解码这头。H.264/H.265的4K解码，VPU硬件做也就是几十毫秒的事，CPU参与几乎为零。VPU输出的帧直接是解码后的YUV数据，走的内存是物理连续的DMA缓冲。

再说推理这头。SPR5801模块标称算力在几个TOPS这个级别，对于单路4K场景下跑一个基于轻量骨干网络的检测模型，余量很足。关键在于：解码后的原始帧是1920x1080或者3840x2160的NV12，直接送模型不现实，必须经过缩放和格式转换。这块你又不可能用CPU去做，A53做一次4K到640x640的resize就得十几毫秒，等于把VPU省下来的时间全还回去了。

所以最终的数据通路一定是：VPU解码出NV12帧，交给SoC自带的2D硬件加速模块RGA做缩放和NV12到RGB的转换，再把转换后的紧凑RGB数据送到SPR5801做推理。整条链路上CPU尽量不碰像素数据，只做控制流和结果后处理。

带宽账其实也在可控范围内：一路4K@30解码后NV12的数据量大概在370MB/s左右，但解码帧经过RGA缩放成640x640后，RGB数据只有1.2MB左右，走PCIe或者USB3.0链路毫无压力。真正关键的优化点是把RGA输出直接映射给SPR5801，而不是在中间多一次拷贝。

2. RK3328 VPU解码落地：MPP调用、帧缓冲与RGA预处理

2.1 解码其实不是调一个库就能完事

RK3328的VPU对外体现为SoC内部的一个内存映射设备节点，厂商SDK里管它叫MPP（Media Process Platform）。你要做的就是通过MPP库把封装好的视频喂进去，再把解码后的图像帧取出来。流程骨架大概是这样：

// 伪代码，不同版本SDK的函数封装略有差异，但流程一致 mpp_ctx *ctx = mpp_create(); mpp_init(ctx, MPP_CTX_DEC, MPP_CODEC_HEVC); // 按码流编码类型设置 // 设置输出格式，这里我一开始用默认NV12，后面才改的 mpp_dec_cfg cfg; mpp_dec_cfg_init(&cfg); mpp_dec_cfg_set(cfg, MPP_DEC_CFG_OUTPUT_FORMAT, MPP_FORMAT_NV12); mpp_dec_control(ctx, MPP_DEC_SET_CFG, cfg); while (1) { // 从ffmpeg的demuxer拿一个AVPacket MppPacket pkt = ffmpeg_packet_to_mpp(av_pkt); mpp_dec_send_packet(ctx, pkt); // 收到解码完的帧，返回的是硬件缓冲句柄 MppFrame frame; if (mpp_dec_get_frame(ctx, &frame) == MPP_OK) { process_frame(frame); mpp_frame_put(frame); } mpp_packet_put(pkt); }

这里面有几个地方特别容易想当然。第一，MPP库本身不管理码流解析，你要自己先用FFmpeg或者h264bitstream去做demux和splitter拿到一个个完整Video ES帧。我当时图省事，直接让FFmpeg做解封装，然后把AVPacket的data指针和size传给MPP。注意，这里的data必须包含完整的编码帧，包括start code，FFmpeg的AVPacket一般能满足，但如果你的码流来自自己的RTP接收代码，就得小心帧边界切分。

第二，不是每一帧都能立刻取出来，B帧重排会导致有几帧的延迟。所以循环里send packet和get frame不能写成一次发送一定取到一帧，一定要独立维护发送和接收的节奏，否则容易出现队列堵塞或者帧序错乱。

2.2 缓冲对齐：一个看起来小但能卡你三天的问题

我在这里卡得比较久，分享出来希望你能绕过。VPU输出的物理缓冲区，每行字节数不是简单按分辨率乘3/2算出来的。它有自己的对齐规则，常见是按64或256字节对齐一行。也就是说，一个1920x1080的NV12帧，宽度行不一定等于1920字节，实际stride可能是1920补到2560之类的值。

我第一次取到帧之后，拿着解码出来的物理地址直接在RGA里配了分辨率宽度1920，结果画面右侧出来一条或者多条垂直亮带，颜色整个是扭曲的。折腾了两个小时才发现是stride没同步过去。后来统一用一个结构体包装帧描述，分辨率、stride、色度偏移、物理地址全部一起往下游传，这个问题的坑才彻底填上。

关键是别自己在代码里到处重新推算stride，下游所有模块都从帧描述结构体里读取。这就是一个“信息口径统一”的问题，越早就越省事。

2.3 颜色空间转换和缩放为什么要交给RGA

RK3328自带的RGA模块是个2D图形硬件加速器，能搬运、缩放、旋转、格式转换。解码输出NV12，你直接扔给RGA去缩放并转RGB，一次操作全干完，大概只要几毫秒。注意RGA输入端口的参数同样要按帧描述里的stride去设置，否则又会碰到上一节说的错位问题。

rga_req r = {0}; r.src = { .fd = frame->fd, .wstride = frame->stride, .hstride = frame->h, .format = NV12, .x = 0, .y = 0, .w = frame->w, .h = frame->h }; r.dst = { .fd = out_fd, .wstride = 640, .hstride = 640, .format = RGB888, .x = 0, .y = 0, .w = 640, .h = 640 }; ioctl(rga_fd, RGA_BLIT_SYNC, &r);

RGA输出缓冲区最好直接用物理连续的DMA内存，后面给SPR5801用的时候就不用再做一次拷贝。很多NPU加速卡对输入内存有“必须连续”的强制要求，如果提前分配在DMA heap上，后面就是映射的事，一步到位。

3. SPR5801模块的接入：模型转换、驱动接口与共享内存

3.1 模型怎么变成它认识的格式

SPR5801这类边缘加速模块，本质是集成了专用神经网络内核的协处理器。它在PC上跑TensorFlow也好、PyTorch也罢，到板子上都必须转成它能直接吃的指令流和权重格式。我这边拿到的SDK提供了一条命令行转换工具，流程和现在市面上常见的NPU工具链大致相同：

# 先训练/导出ONNX模型，再做量化校准 python export_tf_model.py --ckpt ./model.ckpt --out ./model.onnx spr_convert model.onnx --input-size 640x640 --mean 128 128 128 \ --std 128 128 128 --quantize int8 \ --calibration ./calibration_images/ --output ./model.spr

有个点坑了我：量化校准用的图片集不能随便拿网上的风景图凑数，一定要贴近你实际部署的镜头视角。我第一次全部用室内光照的图做的校准，结果拿到户外强逆光场景下，检测置信度整个掉了一截，找原因找了好久，最后换了校准图集重新出模型，效果才回来。做边缘侧模型部署，量化这步一定得认真对待。

3.2 PCIe枚举、驱动加载与内存共享

我手头的SPR5801模块走的是PCIe接口，板卡插到RK3328主板扩展槽上，系统启动后在/sys/bus/pci下能看到新设备，SDK的驱动加载后生成一个字符设备，这就是用户态和加速模块通信的入口。

驱动典型的职责有两块：一是把板卡上的BAR空间映射给用户态，供状态查询和寄存器访问用；二是提供中断处理，推理完成时通知CPU。实际开发中我基本没直接操作BAR寄存器，而是通过SDK提供的用户态库来提交任务。

用户态库的内部逻辑大概是：从DMA heap分配一块共享内存，把要推理的测试图像拷贝进去，然后构造一个任务描述结构，里面填输入缓冲的物理地址、大小、输入张量的shape，以及输出缓冲地址，再通过ioctl提交给内核驱动，驱动拿这个物理地址告诉SPR5801的DMA引擎去读。

注意，这里说“物理地址”是简化了。真实流程里涉及IOMMU的映射管理，好在这套SDK封装完了，我只负责在用户态申请内存、mmap拿到虚拟地址，再把句柄交给库函数处理即可。

3.3 推理接口调用：要输入排好序的连续内存

我遇到的一个实践要点是：SPR5801对外接口非常古板。你在CPU上写惯了的非连续输入、多平面输入，在它这儿基本都行不通。它要求每个输入tensor就是一段连续DMA内存，里面按NHWC或者NCHW严丝合缝排好，RGB顺序也不能错。

RGA输出的RGB888默认是RGB平面连续排列的，正好能匹配。如果你在RGA里把输出配成BRG888之类，那模型识别率会瞬间崩掉，因为通道顺序对不上。很多加速内核其实不关心你叫它什么，它就按固定通道排列取数，配错了你跑出来的结果完全不可信，还特别不好排查。我建议在RGA输出和推理输入之间做一个校验接口，专门验证前几个像素的通道值。

推理调用本身很简单，准备好输入后，提交任务、等待完成即可：

spr_result res; spr_input in = { .dma_fd = out_fd, // RGA输出的DMA缓冲 .fmt = SPR_FMT_RGB888, .w = 640, .h = 640, .size = 640 * 640 * 3, .model_handle = model_handle, }; spr_run(&in, &res); // 内部ioctl提交，等待中断/轮询完成

这里有个同步问题要处理：提交任务之后，主线程如果直接阻塞等待，会浪费很多时间。我这边用了一个单独的处理线程，提交完就去取下一帧解码，等推理完成信号来了再做后处理。两条线程用环形缓冲衔接，整体延迟反而比一帧一帧串行低不少。

4. 打通整条管线：从RTSP流到检测结果的数据通路

4.1 帧同步策略：解码线程和推理线程如何衔接

管线分成三个线程会清晰很多。

解码线程负责从FFmpeg拉RTSP流，送MPP解码，解码出来的帧按顺序放进一个带计数器的环形缓冲。RGA线程从这个环形缓冲取帧，做缩放转换，同时把上一步空出来的DMA缓冲还回去复用。推理线程则等RGA完成信号，把数据提交给SPR5801，取回检测结果。

这里容易出的问题是帧率不匹配。4K@30解码全速跑，但如果SPR5801单帧推理需要25毫秒，理论最大处理帧率就是40fps，看起来够，但RGA和缓冲区搬运还会占用时间，实际上经常只能到20到25fps。这种场景下不要因为丢帧就慌乱，直接做“丢旧帧保新帧”策略：如果推理线程还没处理完，RGA拿到新帧时直接覆盖缓冲，不排队堆积。视频分析场景里实时性优先，延迟比丢帧严重得多。

4.2 关键代码：RGA输出直接给SPR5801

管线核心衔接处的代码，简化下来大概是这个样子：

// 解码线程 MppFrame f = mpp_dec_get_frame(ctx); frame_node *node = get_free_node(ringbuf); node->fd = mpp_frame_get_fd(f); node->w = mpp_frame_get_width(f); node->h = mpp_frame_get_height(f); update_stride_info(node, f); signal_rga_thread(node); // RGA线程 void rga_thread_loop(void) { frame_node *node = wait_rga_task(); // 输出缓冲用的是推理侧分配好的DMA fd rga_scale_rgb(node->fd, node->stride, node->h, inf_dma_fd, 640, 640); notify_infer_thread(inf_dma_fd); } // 推理线程 void infer_thread_loop(void) { int fd = wait_infer_task(); spr_input in = { .dma_fd = fd, .w = 640, .h = 640, .fmt = SPR_FMT_RGB888 }; res = spr_run(&in); draw_boxes(res.boxes, overlay_fd); }

注意几个细节。环形缓冲的空闲node不是按申请时的数量固定死就完了，要在一开始就给RGA输出侧留好几个备用node，否则图像到达有抖动，缓冲池排满，VPU那一头会因为没有空位拿不出下一帧，直接导致解码卡住。

还有，释放MPP帧的mpp_frame_put什么时候调用？一定要等RGA把数据读完了才能释放。因为RGA可能还在DMA搬运这个帧的内容，你提前释放，VPU会复用这块内存开始解码后面的帧，画面上就会出现花屏或者撕裂。用硬件帧句柄做引用计数，或者简单点，在RGA完成信号里再释放，别偷懒。

4.3 延迟都藏在哪儿

我把端到端延迟拆开测过一轮，各部分大概这个数量级：

• VPU解码一帧：5到10毫秒，主要取决于码流复杂度和参考帧数量
• RGA缩放转换：2到4毫秒，4K到640这个跨度不算大
• 内存同步与拷贝：1到2毫秒
• SPR5801推理：20毫秒左右
• 后处理画框：1毫秒以内

整体在35到40毫秒左右。如果你对这数字不满意，最快能优化的点是推理模型换更小的输入分辨率或者精简骨干。另外RGA输出之所以有内存同步开销，是因为DMA写完之后，CPU或者NPU要读，需要做cache一致性同步，这个开销躲不掉。

有个更激进的做法是让SPR5801直接支持读取NV12格式输入、内部自己转RGB，把RGA这步省掉。我试过一次，发现模块内部转换质量不如RGA，而且延迟只省了3毫秒，所以最终没有用。不同型号加速模块差异很大，建议你自己实测对比。

5. 实测数据：解码与检测的真实吞吐和功耗

5.1 测试环境与用例

我组了个台架测试环境：RK3328主板外挂SPR5801模块，输入是本地推流器模拟的一路4K@30 H.264码流，场景是固定机位拍室外道路。模型用的是SSD类轻量检测网络，输入640x640，检测目标是人。整机供电12V直流，串了电流表记录功耗。

测试指标就三个：解码侧吞吐（会不会丢帧）、SPR5801推理吞吐（平均延迟和帧率）、整机实时功耗。

5.2 结果数据表

自己上手调的时候别把上表当绝对标准，同一颗芯片在不同主板散热、不同码流复杂度下差异不小，但这个量级可信，因为是我多次测量取稳定值得到的。

有个很有意思的点，CPU全程闲得很，负载只有13%左右，基本上就是做解封装、控制流、后处理。VPU引擎的利用率大概50%，SPR5801基本满载。这说明链路瓶颈在推理侧，解码和预处理反而很富余。

5.3 与纯CPU方案对比，差在哪

纯CPU方案跑同一模型，之所以只有3到4fps，是因为解码已经让CPU忙不过来了。当你让CPU既做bitstream parsing又做颜色转换、再跑卷积，每个环节都在抢算术单元，最后所有环节都是半吊子。

混合方案能跑25fps，核心原因是把“同步执行的硬件”变成了“并行流水线”。解码单元、RGA单元、NPU单元，三者物理上是独立的，只要缓冲管理得当，它们可以同时忙各自的事。这在体系结构上叫流水线并行，你做边缘设备、想榨干小主控性能的时候，永远要把这条原则放在心上。

功耗方面，纯CPU方案虽然看起来峰值11W不高，但帧率只有混合方案的几分之一，换算成“每有效帧功耗”，差距拉得更大。做产品预研时不能只看绝对瓦数，要算单位产出。

6. 复盘：踩过的坑和提前准备的建议

6.1 解码侧三个最容易踩的坑

第一个坑是stride对齐，前面提过，不再重复。这里补一个现象学特征：如果画面上右侧出现周期性竖条颜色错位，八成是stride不一致。

第二个坑是10bit码流。现在的摄像头不少默认H.265 main10，VPU如果按8bit NV12去输出，颜色会平淡且出现轻微banding。我们需要把解码输出格式设置成P010这类10bit半平面格式。这个事情如果到了现场才发现，会特别被动，因为很多老显示链路根本不支持10bit直通，你得在RGA里做tone mapping之后才能正常看。

第三个坑是内存泄漏。MPP帧如果不及时mpp_frame_put，它的缓冲池会被占满，然后解码器开始丢帧，而且不会给你任何报错，只会在日志里刷一句buffer不够。我当时排查了很久才发现是某个分支路径漏了释放，把代码过了一遍加上智能指针托管，问题就彻底消失了。

6.2 推理侧三个容易踩的坑

第一个是输入内存不连续。有些加速模块会支持“分平面”输入，但实际性能一塌糊涂，甚至随机出错。老老实实分配一整块连续DMA内存，把数据排得紧凑整齐，哪怕多花一次拷贝也值得。

第二个是cache一致性。如果你在CPU侧往共享内存里写数据，写完直接提交推理，不主动flush cache，NPU读到的内容很有可能是旧缓存，推理结果东一个西一个。反过来，推理完成，CPU去读输出结果时，也要做invalidate。大部分SDK提供对应接口，但有的平台不会自动帮你做，这属于纯靠自己警惕的问题。

第三个是模型输入分辨率和RGA输出不一致。RGA缩放会有rounding，WxH配得不严丝合缝，出来的数据可能是643x637之类的，直接送进去模型直接报错或者乱框。我用一个统一的额全局分辨率常量管住所有配置，RGA、共享内存、模型输入、显示叠加全都读这一个常量，彻底杜绝了不一致。

6.3 项目收尾后我的一些体会

重新让我做一次，我开头就会先把模型在真实场景数据上做量化校准和精度验证，再定硬件方案细节。模型这件事是整个链路的天花板，VPU和NPU只要照着规格书调用就行，但模型在边缘设备上的表现，永远是水最深的。

还有一件事多数教程不说：散热。SPR5801连续满载跑半小时后发热明显，温度一上来推理芯片会自动降频，延迟从18ms慢慢爬到30ms。你要是做十万火急的报警类应用，这种隐性降级会很致命。我在板卡上加了散热片和一个小风扇，延迟就稳住了。做边缘盒子的散热预算必须和整机功耗放一起规划，别到了现场再救火。

做完了这一轮，我也算摸清了RK3328这类小主控的脾气：它单打独斗不出彩，但一旦你给它配上合适的硬件加速外设，并把流水线做好，它能以极低的功耗干出远超预期的事。SPR5801这种加速模块，说白了就是给老平台续命的最佳搭档。以后再遇到类似的边缘算力紧缺项目，我大概率还会走这条“复用老主板、外挂加速卡”的老路。