1. 从一颗芯片说起MPP 到底是个什么东西第一次在 RK3588 的数据手册里翻到 MPP 这三个字母的时候我下意识以为是 MPI 打错了。毕竟做并行计算的人对 MPIMessage Passing Interface太熟了脑子里第一反应就是消息传递那一套。结果仔细一看MPP 是 Media Process Platform 的缩写跟并行计算没有半毛钱关系它是瑞芯微Rockchip给自家 SoC 配套的一套媒体处理框架。这个误会挺典型的因为 MPP 这个缩写在不同的技术圈子里含义完全不同——搞数据库的人听到 MPP 想到的是大规模并行处理Massively Parallel Processing搞并行计算的人想到的是消息传递而搞嵌入式多媒体的人想到的是瑞芯微的媒体处理平台。所以先把范围框死这篇聊的是瑞芯微平台上的 MPP尤其是 RK3588 这颗芯片上的 MPP。那 MPP 具体干什么简单说它把视频编解码、图像处理这些活儿从应用层接过来往下丢给硬件加速器去跑。RK3588 里面有一块专门的 VPUVideo Processing Unit支持 H.264、H.265、VP9、AV1 等格式的硬件编解码还有独立的 JPEG 编解码器、RGARaster Graphic Acceleration2D 图形加速单元。这些硬件模块如果让应用层直接去操作寄存器那基本没法用——寄存器手册几百页时序要求严格还要处理中断、DMA、内存对齐。MPP 的价值就在于它在这些硬件之上包了一层统一的软件接口应用层通过 MPP 提供的 API 提交任务MPP 负责调度硬件、管理内存、处理同步。你可以把它理解成一个翻译官加调度员的角色。为什么这件事值得单独写一篇因为在实际项目里尤其是做边缘计算盒子、NVR、视频会议终端这类产品的时候视频编解码的性能和功耗直接决定方案能不能落地。纯软件编解码在 RK3588 这种 ARM 平台上跑 1080p 可能就占满 CPU 了而走 MPP 调硬件编码器CPU 占用能降到个位数功耗和发热也完全不是一个量级。但 MPP 的文档相对零散官方 GitHub 上的说明偏简略很多细节要靠读源码和实际调试才能摸清楚。我踩过的坑包括编译出来的库跟内核驱动版本不匹配导致初始化失败、内存类型选错导致编码花屏、多路并发时没做流控直接把 VPU 队列打爆。这些问题在文档里基本找不到答案只能靠一遍遍试。这篇文章适合谁看如果你正在 RK3588 或者类似瑞芯微平台上做视频相关的开发不管是做解码显示、编码推流还是做 AI 推理前的图像预处理MPP 都是绕不开的一环。如果你只是听说过 MPP 但没实际用过这篇能帮你建立完整的认知框架。如果你已经在用但遇到了一些奇怪的问题里面的排查思路和避坑经验应该能省你不少时间。下面我会从架构设计、核心模块、平台支持、实操编译、常见问题几个维度展开尽量把我知道的都倒出来。2. MPP 的整体架构与模块拆解2.1 分层设计从应用到硬件的完整链路MPP 的架构是典型的分层设计从上到下大致可以分成四层。最上面是应用层你写的播放器、推流工具、AI 预处理程序都在这一层通过 MPP 提供的 C 接口调用功能。往下一层是 MPP 框架层这是核心包含了任务调度、内存管理、格式转换、错误处理等逻辑。再往下是硬件抽象层HAL这一层把不同芯片平台的差异屏蔽掉对上提供统一的接口。最底下是内核驱动层包括 VPU 驱动、RGA 驱动、DMA-BUF 等直接跟硬件打交道。这种分层的好处是应用层不需要关心具体用的是哪颗芯片只要 MPP 支持代码基本可以平移。比如你在 RK3399 上写的解码程序搬到 RK3588 上大概率能直接跑只需要重新编译链接对应的库。但要注意不同芯片支持的编解码格式和性能上限不一样RK3588 支持 8K 解码和 8K 编码老芯片可能只到 4K这个差异是硬件决定的MPP 屏蔽不了。框架层里面有几个关键组件值得单独说。一个是MppCtx这是 MPP 的上下文对象所有的操作都围绕它展开。创建的时候要指定编码还是解码、用哪种协议H.264/H.265 等。另一个是MppApi这是一组函数指针实际上就是 MPP 对外的接口集合包括decode_put_packet、decode_get_frame、encode_put_frame、encode_get_packet这些。还有MppBuffer和MppBufferGroup负责内存的分配和管理这个后面会详细讲因为内存管理是 MPP 里最容易出问题的地方。2.2 核心模块VPU、RGA 与 JPEG 编解码器RK3588 上的 MPP 主要驱动三类硬件模块。第一类是VPU负责视频编解码。RK3588 的 VPU 是双核设计解码和编码可以并行官方标称 8K60fps 解码、8K30fps 编码。实际项目中我们跑 4 路 1080p30fps 的 H.265 解码加 1 路 1080p30fps 编码CPU 占用大概在 15% 左右大部分活儿都是 VPU 干的。VPU 支持的主要格式包括 H.264、H.265、VP9、AV1、MPEG-2/4 等具体支持列表要看芯片手册。第二类是RGA这是 2D 图形加速单元做图像缩放、旋转、格式转换、叠加这些操作。在视频处理流水线里RGA 经常用在解码之后、显示之前比如把解码出来的 NV12 格式转成 RGB 给显示用或者把 4K 画面缩放到 1080p。RGA 的吞吐量比 VPU 还大做 1080p 缩放基本是微秒级的事。但 RGA 有个坑不同版本的 RGA 硬件支持的缩放比例范围不一样有的只支持 1/8 到 8 倍缩放超出范围会直接报错或者出黑边。第三类是JPEG 编解码器独立于 VPU 存在专门处理 MJPEG 格式。做 IPC网络摄像头方案的时候经常用到因为很多摄像头输出的是 MJPEG 流。JPEG 编码器支持到 8192x8192 分辨率解码也差不多。这个模块相对简单但要注意它和 VPU 是共享内存带宽的如果同时跑高负载任务带宽可能成为瓶颈。2.3 内存管理MppBuffer 与 DMA-BUF 的配合MPP 的内存管理是理解整个框架的关键也是最容易踩坑的地方。MPP 内部用MppBuffer来抽象一块内存这块内存可能是普通的内存也可能是 DMA 内存还可能是从外部导入的 DMA-BUF。为什么要这么设计因为 VPU 和 RGA 这些硬件模块需要访问物理地址连续的内存普通的 malloc 出来的内存在物理上可能是分散的硬件没法直接访问。MPP 提供了几种内存分配方式。一种是mpp_buffer_get从 MppBufferGroup 里拿一块 buffer这种方式分配的内存是 MPP 内部管理的适合大多数场景。另一种是mpp_buffer_import把外部的 DMA-BUF 导入进来这个在跟其他模块比如 DRM、V4L2协作的时候很有用。还有一种是mpp_buffer_group_limit_config用来限制 buffer group 的总大小防止内存无限增长。实际用的时候有个经验解码器的输出 buffer 数量要控制好。MPP 解码器内部会维护一个 buffer 队列如果应用层拿帧的速度跟不上解码速度buffer 会越积越多最后要么内存爆掉要么解码器直接卡死。我们的做法是设置一个上限比如 8 个 buffer拿完就还还的时候用mpp_frame_deinit释放。编码器那边类似输入 frame 的 buffer 也要及时回收。注意MPP 的 buffer 释放不是立即生效的硬件可能还在用。所以不要在mpp_frame_deinit之后马上把内存挪作他用最好等一帧或者用 fence 机制同步。3. 平台支持与 RK3588 上的特殊考量3.1 官方支持的芯片列表与差异MPP 官方支持的芯片覆盖了瑞芯微大部分中高端 SoC从早期的 RK3288、RK3399到后来的 RK3328、RK3568、RK3588基本都有对应的支持。但不同芯片上的 MPP 能力差异挺大的主要体现在三个方面支持的编解码格式、最大分辨率和帧率、以及并发路数。拿 RK3588 和 RK3399 对比RK3399 的 VPU 只支持到 4K60fps 解码编码是 1080p30fps而且不支持 AV1。RK3588 直接跳到 8K60fps 解码、8K30fps 编码还多了 AV1 解码。这个差异在做产品选型的时候很关键如果你要做 8K 相关的产品RK3399 根本不在考虑范围内。另外 RK3588 的 VPU 是双核的可以同时跑解码和编码而 RK3399 的 VPU 是单核的解码和编码要分时复用并发性能差很多。还有一个容易被忽略的点不同芯片的 MPP 库版本可能不一样。瑞芯微的 MPP 是开源在 GitHub 上的但芯片原厂给的 SDK 里通常会带一个特定版本的 MPP这个版本可能跟 GitHub 主线有差异可能包含一些未合并的补丁。所以你在 RK3588 上编译 MPP 的时候最好用 SDK 里自带的版本或者确认 GitHub 上的版本跟你的内核驱动兼容。我们就遇到过用 GitHub 最新版编译出来的库跑起来解码正常但编码花屏换回 SDK 版本就好了。3.2 RK3588 的 VPU 特性与性能边界RK3588 的 VPU 是这颗芯片在多媒体方面最大的卖点之一。它支持 8K60fps 的 H.265/VP9/AV1 解码8K30fps 的 H.264/H.265 编码。但要注意这些是理论峰值实际能跑多少取决于内存带宽、散热条件和并发任务数。我们实测下来单路 8K30fps 解码 CPU 占用大概 5%但内存带宽占用很高如果同时跑其他大内存任务帧率会掉。VPU 内部有独立的解码核和编码核可以同时工作。这意味着你可以一边解码一路视频流一边把另一路视频编码推出去两者互不干扰。这个特性在做转码或者视频会议的时候很有用。但要注意解码和编码共享内存带宽如果两路都是高分辨率高帧率带宽可能不够。我们的经验是4K 解码加 4K 编码同时跑基本能稳住再高就要看具体场景了。还有一个细节RK3588 的 VPU 支持10bit 色深做 HDR 视频处理的时候会用到。但 MPP 的接口对 10bit 的支持不是默认开启的需要在创建 MppCtx 的时候指定格式比如MPP_FMT_YUV420SP_10BIT。如果格式设错了解码出来的画面颜色会不对这个坑我们踩过排查了半天才发现是格式没对上。3.3 与其他模块的协作RGA、GPU、NPU在实际项目里MPP 很少单独使用通常要跟 RGA、GPU、NPU 这些模块配合。比如做 AI 视频分析典型的流水线是VPU 解码 → RGA 缩放和格式转换 → NPU 推理。这个流水线里RGA 的作用是把解码出来的大分辨率画面缩放到 NPU 需要的输入尺寸比如 640x640同时把 NV12 转成 RGB。RGA 做这件事比用 CPU 或者 GPU 快得多而且不占 CPU 资源。RGA 和 MPP 的配合主要通过 DMA-BUF 实现。VPU 解码出来的 frame 可以导出成 DMA-BUF fd然后把这个 fd 传给 RGA 模块RGA 直接访问这块内存做处理不需要拷贝。这个零拷贝的链路对性能提升很大尤其是高分辨率场景。但要注意DMA-BUF 的导入导出需要内核支持而且不同版本的 RGA 驱动接口可能不一样移植的时候要留意。GPU 在 MPP 流水线里通常负责显示相关的处理比如 OpenGL ES 渲染、图层合成。NPU 则是做推理。这三个模块加上 MPP基本构成了 RK3588 上多媒体处理的完整拼图。它们之间的数据流转如果都能走 DMA-BUF整个链路的延迟和 CPU 占用都会很低。我们做过一个测试1080p 解码 RGA 缩放 NPU 推理端到端延迟大概在 30ms 左右其中 MPP 解码占了不到 5ms。4. 实操编译、配置与第一个 MPP 程序4.1 编译 MPP 库的完整流程编译 MPP 本身不复杂但依赖和配置选项容易出错。首先从 GitHub 或者 SDK 里拿到源码目录结构大概是mpp/下面有inc/、mpp/、osal/、utils/等。编译用 CMake基本流程是mkdir build cd build cmake .. -DCMAKE_BUILD_TYPERelease -DRKPLATFORMON make -j$(nproc) sudo make install这里有几个关键点。RKPLATFORMON是必须的否则编译出来的库不带硬件加速支持。CMAKE_BUILD_TYPE建议用 ReleaseDebug 版本性能差很多。如果目标平台是 aarch64RK3588 就是要在 CMake 里指定交叉编译工具链或者直接在板子上编译。板子上编译的话注意内存要够make -j的并行数别开太大否则容易 OOM。编译产物主要是librockchip_mpp.so还有一堆测试工具在test/目录下比如mpi_dec_test、mpi_enc_test。这些工具很有用可以用来快速验证 MPP 是否正常工作。比如跑一个解码测试./mpi_dec_test -i test.h264 -t 7 -n 100 -o output.yuv-t 7表示 H.264 解码-n 100表示解 100 帧-o指定输出文件。如果这个命令能正常跑完并输出 YUV 文件说明 MPP 基本环境没问题。注意编译之前确认内核里的 VPU 驱动已经加载。用lsmod | grep vpu或者dmesg | grep vpu看一下。如果驱动没加载MPP 初始化会失败报mpp_dev_init相关的错误。4.2 一个最小解码程序的代码结构写一个最小的 MPP 解码程序核心步骤大概是创建 MppCtx → 配置解码参数 → 循环送 packet → 取 frame → 释放资源。下面是一个简化版的代码骨架MppCtx ctx; MppApi *mpi; MppCtxCreate(ctx, MPP_CTX_DEC, MPP_VIDEO_CodingAVC); mpp_init(ctx, MPP_CTX_DEC, MPP_VIDEO_CodingAVC); ctx-control(ctx, MPP_DEC_SET_PARSER_SPLIT_MODE, need_split); while (has_data) { MppPacket packet; mpp_packet_init(packet, data, size); mpi-decode_put_packet(ctx, packet); mpp_packet_deinit(packet); while (1) { MppFrame frame; MPP_RET ret mpi-decode_get_frame(ctx, frame); if (ret ! MPP_OK || !frame) break; // 处理 frame比如送显示或者送 RGA mpp_frame_deinit(frame); } } mpp_destroy(ctx);这段代码里MPP_DEC_SET_PARSER_SPLIT_MODE这个配置很关键。它告诉 MPP 每个 packet 是一帧完整的码流还是一个分片。如果设错了解码器可能一直等不到完整帧导致卡住。另外decode_get_frame返回的 frame 用完必须mpp_frame_deinit否则内存泄漏。实际项目中解码器的输入通常来自网络或者文件需要自己处理码流的边界。H.264 的 NALU 边界可以用起始码00 00 00 01来分割但有些流可能没有起始码需要用 SPS/PPS 信息来判断。MPP 内部有 parser 可以帮忙做这件事但配置要对。4.3 编码参数的选择与调优编码这边参数选择对输出质量和性能影响很大。MPP 编码器支持 CBR、VBR、FIXQP 等码率控制模式。CBR 适合推流场景码率稳定VBR 适合存储场景画质优先FIXQP 适合固定质量要求的场景。我们做推流一般用 CBR码率设 4Mbps 左右1080p30fps 画质够用。关键参数包括参数说明推荐值rc_mode码率控制模式CBRbitrate目标码率根据分辨率定fps_in_num/fps_in_den输入帧率30/1gop_lenGOP 长度60qp_init初始 QP26profile编码 profileHighGOP 长度设 60 意味着每 2 秒一个 I 帧这个对推流来说比较平衡。I 帧太频繁码率浪费太少则丢包后恢复慢。QP 初始值 26 是中等质量调低画质好但码率高调高反之。这些参数不是固定的要根据实际场景调。编码器的输入是 MppFrame需要自己填充 YUV 数据。如果数据来自 RGA 或者 VPU 解码可以直接用 DMA-BUF 导入避免拷贝。填充 frame 的时候要注意 stride 对齐MPP 对 stride 有要求一般是 16 或 32 字节对齐。如果 stride 不对编码出来的画面会错位。5. 常见问题与排查技巧实录5.1 初始化失败与驱动不匹配最常见的问题就是 MPP 初始化失败报错通常是mpp_dev_init failed或者ioctl failed。这个九成是驱动问题。先确认内核里 VPU 驱动有没有加载ls /dev/mpp_service看设备节点在不在。如果不在可能是内核配置里没开 VPU 驱动或者设备树里没使能。RK3588 的设备树里 VPU 节点一般是vpufdc00000之类的确认 status 是okay。如果设备节点在但初始化还是失败可能是 MPP 库版本和驱动版本不匹配。MPP 库和内核驱动之间有一套 ioctl 接口版本对不上就会失败。解决办法是用 SDK 里配套的 MPP 版本或者查一下驱动的版本号找对应的 MPP 分支。我们遇到过一次GitHub 最新版 MPP 跑在旧版驱动上解码正常但编码直接返回错误换回 SDK 版本就好了。还有一个隐蔽的问题权限。/dev/mpp_service默认可能只有 root 能访问普通用户跑程序会报权限错误。解决办法是加 udev 规则或者直接chmod 666。生产环境建议用 udev 规则根据设备节点设置权限。5.2 解码花屏与内存问题解码花屏的原因很多按概率排序大概是码流问题、内存问题、格式问题。码流问题最好排查用 ffmpeg 或者别的工具先确认码流本身没问题。如果码流没问题但 MPP 解出来花屏大概率是内存或者格式。内存问题常见的是 buffer 不够或者 buffer 被提前释放。MPP 解码器需要一定数量的参考帧 buffer如果 buffer group 设得太小解码器会报buffer not enough或者直接输出花屏。解决办法是增大 buffer group 的 limit或者检查应用层有没有及时归还 buffer。我们遇到过一次应用层拿帧之后忘了mpp_frame_deinit跑了几分钟之后 buffer 耗尽画面开始花。格式问题主要是输出格式设错了。比如码流是 10bit 的但 MPP 配置成了 8bit 输出颜色就会不对。或者 NV12 和 NV21 搞混了UV 分量顺序反了画面颜色会偏。这个用mpp_frame_get_fmt确认一下实际输出格式跟预期对比。5.3 多路并发时的性能瓶颈多路并发是实际项目里绕不开的场景比如 NVR 要同时解 8 路 1080p。这时候瓶颈通常不在 VPU 本身而在内存带宽和 CPU 调度。RK3588 的 VPU 双核可以同时处理两路解码但 8 路就要分时复用每路分到的算力就少了。我们的经验是8 路 1080p25fps 解码CPU 占用大概 40%VPU 占用率接近 100%但还能稳住。如果并发路数更多或者分辨率更高就要考虑用多颗芯片或者降低帧率。另外多路并发时要注意中断风暴的问题。VPU 每解完一帧都会产生中断如果中断太频繁CPU 会被中断处理占满。MPP 内部有中断合并机制但可以通过配置调整。还有一个技巧是用 poll 或者 epoll 来等 frame而不是忙等这样能降低 CPU 占用。内存带宽方面可以用devfreq或者ddr相关的工具监控。如果带宽接近饱和就要考虑降低分辨率或者减少并发路数。RK3588 的内存带宽大概是 10GB/s 左右8 路 1080p 解码加编码大概用到 3-4GB/s还有余量但再加 NPU 推理就要小心了。5.4 常见问题速查表现象可能原因排查方法解决初始化失败驱动未加载ls /dev/mpp_service加载驱动或检查设备树初始化失败版本不匹配查驱动和库版本换配套版本解码花屏buffer 不足看日志有无 buffer 报错增大 buffer group解码花屏格式错误mpp_frame_get_fmt修正输出格式编码花屏stride 不对检查 frame stride对齐到 16/32多路卡顿带宽瓶颈监控 DDR 带宽降分辨率或路数内存泄漏frame 未释放valgrind 或日志确保 deinit 调用提示MPP 的日志可以通过mpp_log_set_level调整调试的时候开到 DEBUG 级别能看到很多内部状态对排查问题很有帮助。但生产环境记得关掉否则日志量很大。6. 一些个人体会与后续方向MPP 这套框架用熟了之后做视频相关的开发效率会高很多。它的接口设计不算特别优雅文档也偏简略但胜在稳定和性能好。RK3588 上的 MPP 配合 RGA 和 NPU基本能覆盖边缘侧视频处理的大部分需求。我个人的建议是刚开始用的时候不要急着写复杂程序先用官方测试工具把基本功能跑通确认环境没问题再逐步加自己的逻辑。后续如果要做更深入的东西比如自定义码率控制、多路智能调度、跟 AI 推理的流水线优化就需要读 MPP 的源码了。源码里mpp_dec和mpp_enc这两个目录是核心里面的状态机和 buffer 管理逻辑值得花时间研究。另外瑞芯微的社区和 GitHub issue 里也有一些有价值的讨论遇到奇怪问题的时候可以搜一下。最后分享一个小技巧MPP 的测试工具mpi_dec_test和mpi_enc_test支持很多参数用-h看一下基本能覆盖大部分调试场景。比如-f可以指定输出帧数-s可以指定输出文件大小-v可以打印详细日志。把这些工具用好了很多问题不用写代码就能定位。