1. 问题背景在 RK3588 平台上构建多路 RTSP 视频流处理管线时流水线如下RTSP → FFmpeg 拉流 → MPP 硬解码 → RGA 缩放与色彩转换 → 640×640 RGB 输出启用 RGA 后系统频繁出现驱动报错严重时直接触发内核异常重启。典型用户态日志如下整理自实际输出RgaBlit(1528) RGA BLIT fail: Invalid argument handle: fd:0, virt:0x7f254637b0, phys:0, format:0 rect[0,0,1920,1080,1920,1080,2560,0] rect[0,0,1920,1080,1920,1080,0,0] ... RgaBlit(1527) RGA_BLIT fail: Invalid argument同时内核 dmesg 中刷出大量 RGA MMU 错误并伴随内存管理 BUGRGA_MMU unsupported memory Larger than 4G! rga_mm_map_buffer map virtual address error! rga mm buffer map failed! src channel map job buffer failed! rga_job_commit: failed to map job info rga request submit failed! BUG: Bad rss-counter state mm:00000000b3118dae type:MM_FILEPAGES val:30096 BUG: non-zero pgtables bytes on freeing mm: 1638400该问题与 RTSP 服务端、FFmpeg 拉流参数、MPP 解码器实例数无关焦点指向 RGA 的内存使用方式。2. 根因分析错误的核心在于RGA 目标图像使用了 C 堆内存即std::vectoruint8_t分配的缓冲区。问题复现代码如下std::vectoruint8_t rga_output_(kOutputWidth * kOutputHeight * 3); rga_buffer_t dst wrapbuffer_virtualaddr( rga_output_.data(), kOutputWidth, kOutputHeight, RK_FORMAT_RGB_888);在 64 位 Linux 系统中堆上分配的大块内存的虚拟地址通常高于 4 GB例如0x7f254637b0。而 RK3588 当前板端 RGA 驱动的虚拟地址映射能力受限无法处理地址空间高于 4 GB 的用户态 buffer。因此当调用improcess()提交 RGA 任务时内核在rga_mm_map_buffer阶段映射失败触发RGA_MMU unsupported memory Larger than 4G! map virtual address error!任务提交失败后驱动内部资源未正确回收进一步引发rss-counter异常乃至内核 Oops 重启。这一问题无法通过忽略improcess()返回值规避必须从根本上改变 RGA 使用的内存类型。3. 修复原则核心思路不再将普通 CPU 虚拟地址直接交给 RGA。利用 Rockchip MPP 提供的 DRM DMA‑BUF 作为 RGA 的输入和输出。错误方式wrapbuffer_virtualaddr(std::vector::data(), ...) 正确方式MPP 分配 MPP_BUFFER_TYPE_DRM → 获得 DMA‑BUF fd → wrapbuffer_fd(fd, ...)新的数据通路MPP decoder output MppFrame → MppBuffer → source DMA‑BUF fd ↓ RGA input ↓ MPP DRM allocation → destination DMA‑BUF fd → RGA output此时 RGA 的输入和输出均由 DMA‑BUF fd 描述绕过了高地址虚拟内存的硬件限制。4. 具体代码修复以下改动基于项目实际代码涉及头文件和核心处理逻辑。4.1 增加成员变量在StreamDecoder类中添加MppBufferGroup frame_group_ nullptr; // MPP 解码输出的 DRM buffer group MppBufferGroup rga_output_group_ nullptr; // RGA 输出专用的 DRM buffer group MppBuffer rga_output_buffer_ nullptr; // 复用的一块 RGA 输出 DMA‑BUF4.2 获取 MPP 解码帧的 DMA‑BUF fd在每一帧处理时从解码得到的MppFrame中取出MppBuffer再通过mpp_buffer_get_fd()获取文件描述符MppBuffer buffer mpp_frame_get_buffer(frame); if (!buffer) return false; int source_fd mpp_buffer_get_fd(buffer); if (source_fd 0) return false; // 同时获取真实宽高与 stride用于后续 RGA 设置 int width mpp_frame_get_width(frame); int height mpp_frame_get_height(frame); int h_stride mpp_frame_get_hor_stride(frame); int v_stride mpp_frame_get_ver_stride(frame);4.3 为 RGA 输出分配 DRM DMA‑BUF每个StreamDecoder实例独占一块 640×640 RGB 输出 buffer仅分配一次后续帧复用const size_t output_size kOutputWidth * kOutputHeight * 3; // RGB888 if (!rga_output_buffer_) { // 1. 创建 DRM 类型的 buffer group if (mpp_buffer_group_get_internal(rga_output_group_, MPP_BUFFER_TYPE_DRM) ! MPP_OK) return false; // 2. 从 group 中申请 buffer if (mpp_buffer_get(rga_output_group_, rga_output_buffer_, output_size) ! MPP_OK) { mpp_buffer_group_put(rga_output_group_); rga_output_group_ nullptr; return false; } } int destination_fd mpp_buffer_get_fd(rga_output_buffer_); if (destination_fd 0) return false;4.4 使用 fd 构造 RGA buffer 并执行操作rga_buffer_t src wrapbuffer_fd(source_fd, h_stride, v_stride, RK_FORMAT_YCbCr_420_SP); rga_buffer_t dst wrapbuffer_fd(destination_fd, kOutputWidth, kOutputHeight, RK_FORMAT_RGB_888); im_rect src_rect {0, 0, width, height}; im_rect dst_rect {0, 0, kOutputWidth, kOutputHeight}; IM_STATUS ret improcess(src, dst, {}, src_rect, dst_rect, {}, IM_SYNC); return (ret IM_STATUS_SUCCESS);关键点src传入h_stride / v_stride避免使用图像真实宽高导致寻址错误src_rect使用真实宽高width / height限制有效像素区域dst固定为 640×640dst_rect与输出尺寸一致IM_SYNC确保函数返回时 RGA 已写入完毕后续可立即消费。4.5 资源释放在close_pipeline()或析构时必须先释放 buffer 再释放 groupif (rga_output_buffer_) { mpp_buffer_put(rga_output_buffer_); rga_output_buffer_ nullptr; } if (rga_output_group_) { mpp_buffer_group_put(rga_output_group_); rga_output_group_ nullptr; }RTSP 重连、worker 退出等场景均会调用该释放逻辑避免残留 DMA‑BUF。5. 格式与 stride 注意事项MPP 解码输出通常为 NV12 (RK_FORMAT_YCbCr_420_SP)必须与 RGA 输入格式严格一致wrapbuffer_fd()的宽高应使用buffer strideh_stride,v_stride而非图像真实宽高im_rect中的宽高则必须为真实图像宽高否则会出现花屏或越界目标尺寸和格式修改时如变为 RGBA8888需同步更新output_size和wrapbuffer_fd的格式参数。6. 并发与多路流下的 buffer 管理当前设计为每路流持有单个 RGA 输出 DMA‑BUF并使用同步模式IM_SYNC。只要在improcess返回后立即同步消费如推理、编码就不会发生数据竞争。如果后续引入异步消费者例如独立推理线程单 buffer 会因覆盖而损坏数据。此时需升级为多 buffer 环形队列并添加状态标志空闲 / 写入中 / 使用中。9. 总结本文记录了一次典型的 RK3588 RGA 高地址虚拟内存崩溃问题其根源在于将 4 GB 以上的堆内存直接传递给 RGA 驱动而驱动无法映射该地址。解决方案是全面切换为 MPP DRM DMA‑BUF使 RGA 通过文件描述符操作物理连续且地址可控的缓冲区。修复后的管线稳定可靠同时也为后续直接对接 RKNN 等硬件加速器铺平了道路。如果你的场景中仍然不得不使用堆内存可尝试通过mpp_buffer_import或设置系统vm.overcommit_memory等方式将堆内存“伪装”成 DMA‑BUF但此类方法并非官方推荐极易引入新的兼容性问题。最稳妥的方案仍是文中所述的全 DRM DMA‑BUF 链路。