RK3588多路视频零拷贝实战：MPP硬解码+RGA加速全解析

1. 开局先聊：为什么我最终选 RK3588 作为多路视频处理平台

先说说背景。我手上有一个边缘视频接入类项目，需求本身不算复杂：接入 8 路 1080p@30fps 的 RTSP 摄像头流，做实时预览、关键帧抓图，再把画面缩略拼接后送进后续的 AI 推理流程。最初评估过两种路线：一是直接用 x86 平台，用 Intel QSV 或 NVIDIA NVENC/NVDEC 硬解，走 GPU 做缩放拼接；二是走嵌入式 ARM 平台，用 SoC 自带的 VPU 处理。

选型时对比过几款主流开发板，最终敲定 RK3588。原因很简单：这颗 SoC 内置了 8K VPU 解码单元、独立的 RGA（Raster Graphic Acceleration）2D 加速引擎，加上 6 TOPS 的 NPU，一颗片子就能覆盖"解码 -> 缩放拼接 -> 推理"全链路，不需要外挂 GPU 或独立视频处理芯片，BOM 成本和功耗都低很多，非常适合做边缘视频处理盒子。

但真正让我决定写这篇实战记录的原因，是 RK3588 这套 MPP + RGA 的软件栈有个非常关键的优化点：零拷贝。如果只是按最直接的方式去调用硬解码，然后从内存里把 YUV 数据拷出来再做格式转换和缩放，CPU 占用会高到离谱，多路场景直接崩。把 MPP 解码输出和 RGA 加速之间打通零拷贝通道之后，8 路 1080p 解码 + 缩放的 CPU 占用能从 40% 以上压到不足 10%，帧率稳定在满帧。

这篇内容面向的是正在基于 RK3588 做视频接入、视频预览、智能分析盒子的嵌入式 Linux 开发工程师。我会把 MPP 硬解码、RGA 2D 加速、dma-buf 零拷贝这条链路的完整用法、背后的原理、以及实际调优过程中踩过的坑都讲清楚。不需要你之前接触过 Rockchip 平台，但最好有基本的 Linux 多媒体开发经验，熟悉 V4L2 或 GStreamer 的基本概念。

2. 硬解码前的认知补齐：RK3588 的 VPU 能力边界与 MPP 库到底是个什么层次

很多人第一次接触 RK3588 的硬解码，最迷茫的地方不是 API 怎么调，而是这套东西在整个系统里的位置。所以我先用我理解的方式把硬件架构和软件层次讲明白。

2.1 VPU、RGA、NPU 三者之间怎么分工

RK3588 在音视频处理上其实是三个独立硬件单元协同工作：

• VPU（Video Processing Unit）：专门做视频编解码，支持 H.264/H.265/VP9/AV1 等多种格式，解码能力最高到 8K@30fps 或者多路 4K/1080p 同时解码。它只负责把压缩码流变成 YUV 原始图像，不负责缩放和叠加。
• RGA（Raster Graphic Acceleration）：专门做 2D 图像操作，包括缩放、格式转换（比如 NV12 转 BGR）、旋转、镜像、裁剪、alpha 混合等。它相当于一个轻量级 GPU 的 2D 部分。
• NPU（Neural Processing Unit）：专做神经网络推理，对视频来说就是 YOLO 目标检测、姿态估计这类任务。

流水线很清晰：RTSP 拉流 -> VPU 硬解码 -> RGA 做预处理 -> NPU 推理。这三者之间用 dma-buf 共享内存，数据不需要经过 CPU 拷贝，这就是零拷贝的核心硬件基础。

2.2 MPP 不是播放器，它是一层底层编解码封装库

Rockchip MPP（Media Process Platform）是瑞芯微官方提供的编解码库，直接跑在 VPU 之上，向上提供统一的解码/编码接口。它不是一个播放器，没有 RTSP 客户端、没有文件解析、没有音频处理，它的职责边界非常明确：喂给它一个视频码流分片，它给你吐出一帧 YUV 图像。

这里有个重要概念需要区分：RKMPP 库（用户态 API 层）和 MPP 服务进程（古代 mpp_service）的区别。现在的 RK3588 平台上，Mpp 解码主要是通过内核提供的 V4L2 接口或者用户态直接操作 dma-buf 来实现。MppDec 是它的解码 API 封装，我们平常调用mpi_dec系列函数，就是走这条路径。

2.3 什么时候用 MPP，什么时候用 GStreamer/FFmpeg

这是新手最容易纠结的问题。我的建议如下：

• 如果你只是在开发板上快速验证解一个 RTSP 流是否正常，直接用 GStreamer 插件，两行命令搞定。
• 如果是做正式产品，特别是要对每一帧做 AI 预处理、要精细控制解码缓冲、要优化内存复用，JDK 用 MPP 或者 FFmpeg 的rkmpp后端。GStreamer 的插件封装层级太高，你对内存流向的掌控能力会弱很多。

我最终是直接用 MPP 的 C API 做的解码线程，RGA 的 C API 做的图像处理，再配合 dma-buf 做共享内存，把整条链路的每一环都控制在自己手里。

3. 环境准备与第一个坑：librga 和 librknnrt 的版本千万别混装

在开始写任何代码之前，先把环境折腾好。这一步我浪费了两天时间，值得单独拿出来讲。

3.1 官方 SDK 里的库并不是全的

RK3588 的系统开发环境，大部分人首选 Buildroot 或 Debian。我实际用的是 Rockchip 官方提供的 Debian11 rootfs，带桌面的版本。这个基础系统里已经有 librga 了（就是 RGA 的用户态库），版本一般在 1.9 左右。但注意：这个版本可能和你的内核驱动版本不匹配，或者缺少某些新接口。

我的建议是：从 Rockchip 官方的 GitHub 仓库单独拉最新版本的 librga 源码手动编译安装，同时确保内核里的 RGA 驱动版本对应。判断库和驱动是否匹配，看/dev/rga节点的存在只是第一步，真正跑起来要看rga_info结构体里的版本号。

# 检查 RGA 设备节点是否存在 ls -l /dev/rga # 用 rga_im2d 的版本查询函数确认驱动版本

3.2 FFmpeg 和 MPP 的版本绑定关系

如果你打算让 FFmpeg 也走 RK3588 硬解（它在很多场景下确实方便），必须用 Rockchip 的 FFmpeg fork，不要用上游版本。上游 FFmpeg 的 rkmpp 支持虽然已经合入主分支，但很多时候缺少针对新固件的适配。

我踩过的一个具体坑：官方 SDK 的 FFmpeg 版本和直接 apt 装的 FFmpeg 版本冲突，导致能够编出来，但一运行就报 h264 解码参数解析错误。后来我把PKG_CONFIG_PATH单独指到 SDK 编译出来的库目录，才把这个坑填平。

3.3 推荐的目标环境配置

我的最终环境是这样搭配的，目前非常稳定：

重要：不要分别从 GitHub 上各个仓库拉最新代码来混搭。官方 SDK 是一个整体验证过的软件栈，库之间的兼容性已经测过，你自己混一套可能编译全过，但运行期各种莫名其妙的问题会消耗大量精力。

4. MPP 硬解码：从打开设备到拿到 YUV 帧的核心流程拆解

零拷贝的关键链路是 MPP -> RGA。要理解这条链路，得先把 MPP 解码的经典流程走一遍。

4.1 MPP 解码的经典调用逻辑

MPP 解码的流程大致如下：

1. 创建解码器实例mpp_create
2. 绑定解码类型（H.264/H.265 等）和码流格式（如 Annex B）
3. 初始化解码器mpp_init
4. 循环做：从码流读取一个分片（packet） -> 送入解码器 -> 取出一个帧（frame） -> 处理帧
5. 结束解码，释放资源

源码里最核心的发送接收逻辑片段如下：

// 解码主循环 while (!(quit)) { // 从 demuxer 读取一个 packet size_t read_size = fread(pkt_buf, 1, pkt_size, f); mpp_packet_init(&pkt, pkt_buf, read_size); mpp_meta_set_packet(pkt, META_KEY_PACKET_POSITION, &pos); // 发送到解码器 ret = mpi->decode_put_packet(ctx, pkt); if (ret == MPP_OK) { // 从解码器取回解码后的帧 ret = mpi->decode_get_frame(ctx, &frame); if (frame) { // 这里是零拷贝的关键：把 frame 的 fd 取出来 MppBuffer buffer = mpp_frame_get_buffer(frame); int fd = mpp_buffer_get_fd(buffer); // 传给 RGA 或其他硬件模块 process_frame_with_rga(fd, frame_info); mpp_frame_deinit(&frame); } } mpp_packet_deinit(&pkt); }

这段代码最关键的一行是mpp_buffer_get_fd。它拿到的 fd 指向的是 MPP 内部管理的一块 dma-buf 内存。这块内存可以直接通过 RGA 的 import 机制传给 RGA 硬件去读，不需要把里面的 YUV 数据 copy 到用户态再用软件缩放。

4.2 关键：解码帧的 buffer 类型决定了你能不能零拷贝

MPP 输出帧的 buffer 所在的内存类型由输入码流决定，更准确地说由解码器的内存模式决定。MPP 支持两种模式：

• MPP_BUFFER_MODE_NORMAL：内部管理内存，从系统内存池分配
• MPP_BUFFER_MODE_DMA_HEAP：从 dma-heap 分配，这种内存可以被多个设备共享

在 RK3588 上做零拷贝，必须用 DMA_HEAP 模式。初始化方式是在mpp_init之后再调用一次：

recommend use 'MPP_DEC_SET_MMU_MODE'? 不对 // 正确做法：设置解码器的内存模式 MppDecSetCfg cmd; cmd.buf_mode = MPP_BUFFER_MODE_DMA_HEAP; mpi->control(ctx, MPP_DEC_SET_CFG, &cmd);

实际上 MPP 的 API 里，这个控制命令是通过MPP_DEC_SET_CFG传入一个MppDecCfg结构体来实现的。多路解码时这个配置尤其重要，直接影响内存分配策略。

4.3 多路解码时如何避免线程模型踩坑

8 路 RTSP 解码，最自然的设计是每个流一个线程，每个线程一个 MPP 解码器实例。我刚做的时候就是这么干的，结果发现 CPU 占用还是偏高，仔细分析发现线程之间因为 MPP 内部全局锁和 dma-buf 分配竞争导致不少等待。

后面换成了"解码线程池 + 事件分发"模型。简单说：固定 4 个解码线程，每个线程可以处理多个解码上下文，用 epoll 在网络事件和数据就绪事件之间做多路复用。每个解码上下文只负责一个流。这个改造让 CPU 占用下降了 5-8%，多路并发时更稳定。

不过这个优化有点超前，先初始化基础功能，后期再考虑。第一部分先把"能解出画面"这件事做对。

4.4 解码异常排查：延迟线、花屏、丢帧怎么应对

接入了 8 路摄像头之后我陆陆续续遇到几个怪问题：

• 偶尔出现花屏，多发生在摄像头画面变动剧烈时
• 某一路出现"can't find suitable delayline"这类内核日志（这个随机性很强，不是必然出现）
• 长时间运行之后，解码延迟越来越大，最后掉帧严重

花屏的原因我排查了比较久，最终定位是：部分低端摄像头的 H.264 码流不是干净的 Annex B 格式，里面存在长度码（AVCC 格式）混入的情况。MPP 对纯 Annex B 支持最好，所以我写了一个简单的码流规整层，把所有送入 MPP 的分片都格式化为 Annex B。处理好之后花屏基本消灭。

延迟变大的问题：那是因为解码器输出队列里堆积的 frame 太多，用户态消费速度跟不上。解决办法是检测到队列超过阈值时主动丢帧，具体做法是判断mpp_frame_get_eos和帧时间戳，如果当前帧与已处理帧的间隔太大，直接不传给 RGA 处理，只释放 buffer。

5. RGA 2D 加速：从 NV12 到 RGB、缩放、拼接的硬件飞驰

5.1 一个反直觉的事实：RGA 做格式转换比 CPU 快两个数量级

如果不用 RGA，用 CPU 做 NV12 到 RGB 的转换，1080p 的单帧在 RK3588 的 Cortex-A76 核上大概需要 12-18ms。12 路就是每路每秒 30 帧，你自己算 CPU 要用多少核才能转得动。但同样的转换交给 RGA，单帧时间在 1ms 甚至更低（看数据宽度），CPU 几乎不用参与。

很多来自纯 x86 背景的朋友，习惯用 SIMD 优化或者 OpenCV 的cvtColor去解决格式转换问题。嵌入式平台上的最佳实践不是优化 CPU 代码，而是直接把活交给硬件去做。这是我一开始做这个项目时最难扭转的思维定势。

RGA 能做的常见操作：

• 格式转换：NV12、NV21、YUYV、RGB888、BGR888、RGBA8888、BGRA8888 等
• 几何变换：任意角度旋转（0/90/180/270 和任意角度）、水平/垂直镜像
• 缩放：双线性、最近邻等多种滤波模式，最大支持 8192x8192 输入
• 裁剪和拼接：把一块 buffer 的多个区域分别贴到目标 buffer 的不同位置
• Alpha 混合：两层叠图

5.2 RGA 的三种 API 编写方式：ioctl、im2d、librga 的 C API

RK3588 平台操作 RGA 有三条路径：

1. 直接 ioctl 操作/dev/rga，原始但繁琐
2. 使用 librga 提供的 im2d API，函数名一看就明白（imscale、imtransfer、imcvtcolor）
3. 使用更高层的 GStreamer 插件

真正做产品我建议用 librga 的 im2d API。它封装好了所有参数构造细节，上手快，并且有较好的错误提示。

一个典型的 NV12 转 RGB888 + 缩放的调用：

#include <im2d.h> #include <rga.h> // 输入：decoder 解码出来的 NV12 帧 rga_buffer_t src = wrapbuffer_fd_t(fd_src, src_w, src_h, RK_FORMAT_YCbCr_420_SP); // 输出：预分配好的 RGB888 buffer rga_buffer_t dst = wrapbuffer_fd_t(fd_dst, dst_w, dst_h, RK_FORMAT_RGB_888); im_rect src_rect = {0, 0, src_w, src_h}; im_rect dst_rect = {0, 0, dst_w, dst_h}; int ret = imresize(src, dst, src_rect, dst_rect, IM_INTER_LINEAR, IM_SYNC); if (ret != IM_STATUS_SUCCESS) { printf("RGA resize failed: %s\n", imStrError(ret)); }

这里的wrapbuffer_fd_t是零拷贝的关键。它不拷贝数据，只是告诉 RGA 驱动从 fd 对应的 dma-buf 里去读数据。输入 fd 就是上一节从 MPP frame 里拿到的那个 fd。

5.3 零拷贝链路中的 buffer 生命周期管理

这是整篇文章最核心的实操经验。零拷贝不等于不管理内存，而是让你可以在不同硬件单元之间共享同一块内存，但你必须非常小心地管理这块内存的生命周期：

• 谁分配谁释放：建议所有 buffer 都由自己统一分配，不要依赖 MPP 内部 buffer 向外借用（除非你非常清楚引用计数的规则）
• RGA 读 MPP 输出的 buffer，是"借用"关系，不是"持有"关系
• 必须在 RGA 操作完成（同步模式）之后，才能把 buffer 还给 MPP 继续使用

具体做法是：我自己维护一个 buffer 池，按需从 dma-heap 分配 fb 大小的 dma-buf，然后把这些 fd 提前注册给 MPP 作为它的输出 buffer（MPP 支持外部 buffer 池模式）。这样解码器直接解到我的 buffer 池里，RGA 从池里取用，处理完放回池子，循环往复。这个方案彻底避开了"每次解码都向内核申请一块新内存"的开销。

// 初始化 buffer 池：每个 pool_count 够用即可 int pool_count = 8; // 解码深度 + 处理中帧数量的和 for (int i = 0; i < pool_count; ++i) { int fd = dma_heap_alloc(heap_fd, img_size); mp_pool_add_fd(pool, fd); } // 把这个 pool 挂到 MPP 解码器的 external buffer group 上 mpp_buffer_group_import(ext_buf_grp, pool->fds, pool_count); mpi->control(ctx, MPP_DEC_SET_EXT_BUF_GRP, ext_buf_grp);

注意：设置外部 buffer 组必须在解码器开始接收 packet 之前完成，而且要保证 buffer 池的数量足以容纳解码线程当前的工作深度。太少了会阻塞解码流程，太多了会浪费内存。

5.4 RGA 拼接：8 路画面的矩阵贴图体验

多路视频接入之后，最常见的需求是做一个 N 宫格预览墙。RGA 天然适合干这个事。

思路不复杂：准备一个大 buffer（比如 1920x1080，格式 NV12），然后对每一路解码帧，通过imblend或者improcess把缩略图贴到对应的小格子里。

这里有个关键点：如果使用improcess可以在一次调用里传入多个源和目标描述符，那效率最高；如果拆成 8 次单路叠加，性能会打折扣。

实测下来，8 路 1080p 缩放到 480x270 后拼接成一个 1920x1080 的画面，整次操作耗时约 3-4ms，CPU 占用接近于 0。这是 CPU 纯软件拼接完全做不到的数字。

6. 零拷贝的底层原理解析：dma-buf、ion/dma-heap 与硬件一致性

聊到这儿，很多人会问：为什么你用 fd 传一传，数据就不需要拷了？这不是魔法，这是 Linux 内核 dma-buf 框架的作用。

6.1 物理内存、dma-buf、fd 三者是什么关系

简化版解释可以这么说：dma-buf 是内核里一块可以被多个设备访问的物理内存的描述。它通过一个 fd 暴露给用户态。这个 fd 可以被传递、被复用。

• MPP 解码器执行完一帧后，VPU 已经把 YUV 数据写进了这块内存
• 你把 fd 传给 RGA 驱动
• RGA 驱动拿到 fd，在内核里把 fd 换算到对应的 sg_table（物理页列表），然后配置 RGA2/RGA3 硬件的 DMA 引擎去读这些页
• 整个过程中，用户态和内核态之间没有数据拷贝，只有元数据传递

6.2 RK3588 上的 DMA 内存分配方式：dma-heap vs ION

RK3588 内核同时支持 ION 和新的 dma-heap。新代码建议直接用 dma-heap，它是 ION 的后继者，更简洁，兼容性更好。

设备树里通常会定义rk_dma_heap节点。用户态分配 dma-buf 的方法：

// 打开 dma heap 设备 int heap_fd = open("/dev/dma_heap/linux,cma", O_RDWR); // 分配一块 1080p NV12 大小的内存 struct dma_heap_allocation_data alloc = { .len = img_size, .fd_flags = O_RDWR | O_CLOEXEC, }; ioctl(heap_fd, DMA_HEAP_IOCTL_ALLOC, &alloc); int dma_buf_fd = alloc.fd;

RK3588 上有linux,cma和linux,system两个 heap。CMA 用于连续物理内存，适合 VPU/RGA 这类需要 DMA 的设备；system 是分散页，适合某些不需要连续性的场景。视频帧建议用 CMA，路径是/dev/dma_heap/linux,cma。

6.3 多设备访问时需要显式同步吗

这是个容易踩的细节。在 RK3588 上，MPP 和 RGA 挂在不同的 IOMMU 域，但访问的都是同一块物理内存。大多场景不需要手动做 cache 一致性维护，因为 VPU 和 RGA 都是通过 DMA 访问内存，它们走的是硬件 cache 一致性。但在某些边界条件下（比如你又要用 CPU 去读这块 buffer 做调试），就必须做显式 sync。

librga 提供了imsync接口，内核里有DMA_BUF_IOCTL_SYNC。如果画面一直是马赛克或者花屏，而你确认格式和缩放参数没问题，检查一下是不是缺了 sync。

7. 实战性能优化：从 40% CPU 到 8% CPU 的调优过程

7.1 第一版实现：最容易想到但性能很差的方案

第一版代码完全可以用，但性能惨不忍睹。我做了一个简单的性能基线测试，结果如下：

第一版我用mpp_buffer_get_fd拿到 fd 之后，用 mmap 把 YUV 数据映射到用户态，再用swscale做缩放和格式转换。这种方式能跑满 8 路，但 CPU 长期高负载，边缘设备稳定性很差，散热压不住，系统偶发卡顿。第一版性能不佳的根源在于：数据在"内核物理内存 -> 用户态虚拟内存"之间来回搬运了好几次，每次 mmap 和 memcpy 都是开销。

7.2 定位瓶颈：perf top 看看 CPU 都去哪儿了

我一开始也不确定瓶颈在哪，就用了perf top和简单的top -H -p <pid>观察。结论非常明确：CPU 大量的时间花在memcpy和swscale的色彩转换函数里，也就是说，这不是解码器不够快，而是我在解码器和 RGB 数据使用方之间做了太多"中介"。

然后用trace-cmd或bpftrace观察内核中 dma buf 相关操作，看到频繁地dma_buf_attach和dma_buf_detach，那是每次我 mmap 和 ummap 引起的重复建立映射。这些操作虽然单个很快，但每帧、每路累积起来，开销就很明显。

7.3 优化策略：reserve buffer pool + 零拷贝调度

优化方案分三步走：

1. 把 MPP 解码输出设置为 external buffer pool 模式，让解码器直接解到我们自己管理的内存池里
2. 所有 RGA 操作的源和目的都使用 fd 传递，杜绝 mmap 用户态映射
3. 加一个帧池调度模块：解码线程拿到 frame 后，投递到一个无锁队列；RGA 线程从队列取出 fd 并处理，处理完把 fd 归还池子

这套方案跑通之后的收益是：CPU 占用从 40% 以上降到 8% 左右，7x24 小时稳定运行，内存占用反而比原来少了 30%（因为没有了反复的内存映射和 torture 拷贝）。

7.4 最终性能数据

一个比较有代表性的性能测试结果（RK3588 Development Board，Linux 5.10 kernel，板载 8GB RAM）：

这个数据对边缘盒子的硬件资源预算非常有参考价值。8 路视频处理的片子，CPU 还能腾出大部分资源去做别的事，比如跑一些轻量级的 AI 检测任务。

8. 疑难杂症排查记录：这段代码跑不过去？大概率是这些原因

8.1 解码直接报错或程序崩溃

• 报错MppDecIsEndOfStream相关异常：确认码流格式是 Annex B 开头，不要直接把 AVCC 数据喂给 MPP
• Segmentation fault：检查mpp_frame_get_buffer返回的 MppBuffer 是否为 NULL，多路解码时尤其容易因为 buffer 竞争导致这种问题
• 初始化失败：检查/dev/dma_heap/linux,cma是否存在，有些旧内核路径是/dev/ion

8.2 RGA 操作异常

• 输出的图片是黑色的：目标 buffer 没有正确 mapped，或者 fd 传错了（常见于 buffer pool 管理混乱导致 fd 复用问题）
• 图片颜色错乱：格式宏写错了，注意 NV12 是RK_FORMAT_YCbCr_420_SP，BGR888 是RK_FORMAT_BGR_888，很容易搞混
• 图片有条纹变形：缩放尺寸设置问题，检查源和目的的 stride（行字节数）是不是按照 16 字节对齐计算的

我遇到过一个特别隐蔽的问题：librga 中的RGA_BUF_VERSION和内核驱动版本不匹配，导致某些函数调用返回IM_STATUS_FAILED，但日志不打印具体原因。后来在 librga 的 im2d 头文件里看到版本检查逻辑，后续升级了内核驱动才彻底解决。

8.3 RTSP 拉流环节容易忽略的点

RTSP 拉流本身不在 MPP/RGA 的范围内，但多路视频处理和它强相关。我遇到最经典的问题是：

• 某些摄像头的 RTP 时间戳不准，导致解码帧时间间隔忽大忽小
• 网络抖动引起 RTSP 重传，解码端收到乱序的 SPS/PPS

我的处理方式是：拉流用 FFmpeg 的 RTSP 客户端，做 1-2 秒的 jitter buffer，并且定期刷新 SPS/PPS。这个做法基本可以覆盖市面主流摄像头。

8.4 风扇转速和散热对长时间稳定性的影响

RK3588 满负荷解码时发热非常可观，尤其是多路 4K 场景。如果你的板子有风扇接口，建议用 PWM 风扇根据温度自动调速。这虽然不属于视频链路的技术话题，但我在实际测试中发现，高温降频对解码性能的影响远比想象中大，特别是多路并发场景，一个不小心系统降到低频率，掉帧就开始了。

系统读取风扇转速和 CPU 温度的方法是通用的：

# 查看 CPU 温度 cat /sys/class/thermal/thermal_zone0/temp # 查看风扇转速（根风扇接口不同路径有差异） cat /sys/devices/platform/pwm-fan/hwmon/hwmon*/fan1_input

9. 进一步扩展：把 RGA 预处理接到 NPU 推理链路上

写到这里，零拷贝的视频解码链路已经全部打通。如果只做预览墙和录像，到这就够了。但我的场景还要做 AI 检测，这里顺便讲讲 RGA 输出如何直接喂给 NPU。

RK3588 的 NPU 推理工具链中，rknn-toolkit2 支持传入 dma-buf fd 作为输入。这意味着 RGA 处理完的 RGB 图像，也不需要拷贝到 CPU，直接rknn_inputs里设置buf = (void*)buf_fd（对应版本 API 不同），然后调用推理接口。

链路就成了：

VPU 解码 -> dma-buf fd -> RGA 缩放/格式转换 -> dma-buf fd -> NPU 推理

整条流水线没有任何 memcpy。我在 YOLOv8s 模型实测中，输入 640x640，8 路并发做检测，NPU 单次推理大约 25-35ms（看模型优化程度），CPU 占用可以忽略不计。这个数字对智能视频分析盒子来说相当可用了。

需要注意，RKNN 的输入 buffer 格式有严格对齐要求（通常 16 字节对齐），RGA 输出的 stride 要手动设置对齐，否则推理结果会错位。

10. 最后分享一点踩坑后的心得

一开始做这个项目时，以为把 MPP 和 RGA 的 API 调通就完事了，真正做完才发现，性能调优的难点从来不在 API，而在数据的流向设计。你为每帧数据多安排一次不经意的拷贝，整个 8 路吞吐量就会下降一个量级。

RK3588 这套 MPP + RGA + RKNN 的组合，硬件能力确实足够强，但软件栈的门槛也在调用的层次和版本的匹配上。强烈建议在做产品之前，先把官方 SDK 版本的库关系和设备树配置捋清楚，能省下至少一周的零碎时间。

如果你正在做多路视频类的边缘计算设备，我的建议是先画清楚数据流图，明确每一帧内存从哪来、到哪去、谁读谁写，然后再去写代码。硬件资源不会骗人，把这份功夫花在前面，后端的稳定性和性能会很从容。