简介本资源面向瑞芯微RK3588平台上的音视频开发工程师与嵌入式学习者聚焦于使用ffmpeg-rockchip库实现MPP视频硬件编解码的完整项目源码。内容围绕C代码示例展开演示如何读取MP4文件、调用h264_rkmpp解码器完成硬件解码再通过hevc_rkmpp编码器输出HEVC格式文件同时对比传统硬件编解码开发方法的不足说明ffmpeg-rockchip在简化流程、降低学习成本方面的优势并提及编解码效率的优化思路。资源包共6个文件包含cpp源码、Makefile构建脚本、README说明文档、html演示页面及mp4测试素材等压缩包约11KB结构精简便于快速上手。目前已有294人学习关注适合希望从命令行过渡到代码实现、掌握RK3588硬件编解码链路的开发者参考也可作为后续RGA 2D图形加速学习的铺垫。1. 从软解卡顿到硬编起飞RK3588 编解码到底能解决什么如果你手头有一块 RK3588 的板子跑过 4K 视频转码或者多路摄像头实时编码大概率经历过这样的场景CPU 八个核全跑满风扇呼呼转帧率还是往下掉延迟越堆越高。问题不在你的代码写得烂而是软编码把通用计算单元当成了专用视频流水线在用。RK3588 这颗芯片里塞了独立的 VPU视频处理单元支持 H.264/H.265 的硬件编解码还有瑞芯微自家的 MPPMedia Process Platform中间件来调度。这套源码包做的事情就是把 MPP 的能力通过 FFmpeg 的接口暴露出来让你用熟悉的avcodec那一套 API 就能吃到硬件的红利。适合谁做边缘计算盒子、NVR、直播转码、视频会议终端的嵌入式工程师尤其是那些已经在 RK3588 上跑通了系统、但被软编性能卡住脖子的团队。硬编不是玄学但它的坑和软编完全不在一个维度上——内存对齐、格式转换、码率控制模式每一项都能让你翻车。2. MPP 与 FFmpeg 的对接原理为什么不能直接调/dev/mpp_service2.1 从内核驱动到用户态中间件的三层结构RK3588 的硬件编解码不是你在应用层 open 一个设备节点就能用的。它分三层最底下是内核态的mpp_service驱动负责和 VPU 硬件寄存器打交道中间是用户态的 MPP 库librockchip_mpp.so封装了 buffer 管理、任务队列、码率控制这些逻辑最上面才是 FFmpeg 的rkmpi或rkmpp封装层。源码包里通常包含ffmpeg的 patch 或者独立的libavcodec/rkmppdec.c、rkmppenc.c文件编译进去之后FFmpeg 在avcodec_find_decoder_by_name(h264_rkmpp)的时候就能找到硬件解码器。为什么不能直接调/dev/mpp_service因为 MPP 库帮你处理了 DMA buffer 的分配、物理地址映射、以及多实例并发时的硬件队列调度。你自己去 ioctl 不是不行但那是另一个量级的工作量而且大概率会在内存对齐上栽跟头。2.2 编译与集成把 rkmpp 塞进 FFmpeg 的两种路径源码包一般提供两种集成方式一种是给 FFmpeg 打 patch 然后重新编译另一种是编译成独立的libavcodec插件动态加载。我一般推荐第一种因为 patch 里通常已经处理好了AVCodec结构体的注册和AVPixelFormat的映射。具体步骤# 假设源码包目录结构为 rk3588_mpp_ffmpeg/ # 1. 先编译安装 MPP 库 cd rk3588_mpp_ffmpeg/mpp cmake -DRKPLATFORMON -DHAVE_DRMON .. make -j$(nproc) sudo make install # 2. 给 FFmpeg 打 patch cd ../ffmpeg git apply ../patches/0001-add-rkmpp-support.patch # 3. 配置 FFmpeg显式启用 rkmpp ./configure \ --enable-rkmpp \ --enable-libdrm \ --enable-decoderh264_rkmpp \ --enable-decoderhevc_rkmpp \ --enable-encoderh264_rkmpp \ --enable-encoderhevc_rkmpp \ --extra-cflags-I/usr/local/include \ --extra-ldflags-L/usr/local/lib -lrockchip_mpp # 4. 编译安装 make -j$(nproc) sudo make install这段脚本的关键参数在--enable-rkmpp和--enable-libdrm。libdrm是必须的因为 MPP 在输出帧的时候需要 DRM 的 prime fd 来做零拷贝。如果你漏了--enable-libdrm编译能过但运行时会报drm prime handle to fd failed。另外--extra-cflags和--extra-ldflags要指向你实际安装 MPP 的路径默认是/usr/local但有些板子的 BSP 会装到/usr下这个得看你的环境。2.3 解码器初始化AVCodecContext里必须设对的三个字段硬解码器初始化的时候有三个字段不设对要么直接失败要么性能打对折AVCodecContext *ctx avcodec_alloc_context3(codec); // 1. 指定硬件像素格式让 FFmpeg 知道输出的是 DRM prime 还是 NV12 ctx-pix_fmt AV_PIX_FMT_DRM_PRIME; // 2. 设置线程数硬解一般设 1多线程交给 MPP 内部队列 ctx-thread_count 1; // 3. 打开低延迟模式实时场景必开 ctx-flags | AV_CODEC_FLAG_LOW_DELAY; if (avcodec_open2(ctx, codec, NULL) 0) { // 如果失败先检查 pix_fmt 是否被 MPP 支持 }AV_PIX_FMT_DRM_PRIME是零拷贝的关键。如果你设成AV_PIX_FMT_NV12FFmpeg 会在硬解之后把帧从 DRM buffer 拷贝到普通内存这一拷贝在 4K 下就是几个毫秒的额外延迟。thread_count设 1 是因为 MPP 内部有自己的任务队列FFmpeg 层面的多线程反而会引入锁竞争。LOW_DELAY标志会关掉解码器的帧重排序如果你做的是实时预览或者视频会议这个必须开但如果是点播转码开了可能会影响 B 帧的处理得看片源。3. 编码参数实战码率控制、GOP 与低延迟的三角平衡3.1 CBR、VBR、CQP 三种模式在 RK3588 上的实际表现MPP 的编码器支持三种码率控制模式通过AVCodecContext的rc_mode字段设置这个字段是 rkmpp 扩展的不是 FFmpeg 原生的。我实测下来的结论是模式适用场景码率波动画质稳定性设置方式CBR直播推流、固定带宽极小运动场景会糊rc_mode 0VBR本地存储、点播中等整体较好rc_mode 1CQP画质优先、离线转码极大最好rc_mode 2CBR 模式下bit_rate设多少就出多少适合 RTMP 推流这种带宽受限的场景。但要注意CBR 在画面剧烈运动的时候会疯狂降画质来保码率所以gop_size不能设太大一般 30 到 60 之间。VBR 适合 NVR 本地录像码率上限设成平均值的 1.5 倍左右比较稳妥。CQP 模式不看码率只看 QP 值qp_init设 26 左右是画质和体积的平衡点设 18 以下文件会大到怀疑人生。3.2 编码器初始化代码与参数逐行拆解AVCodecContext *enc_ctx avcodec_alloc_context3(encoder); enc_ctx-width 3840; enc_ctx-height 2160; enc_ctx-time_base (AVRational){1, 30}; enc_ctx-framerate (AVRational){30, 1}; enc_ctx-pix_fmt AV_PIX_FMT_NV12; // 编码器输入必须是 NV12 或 YUV420P enc_ctx-bit_rate 8000000; // 8 Mbps enc_ctx-rc_mode 0; // CBR enc_ctx-gop_size 60; // 2 秒一个 I 帧 enc_ctx-max_b_frames 0; // 低延迟场景关 B 帧 enc_ctx-profile FF_PROFILE_H264_HIGH; enc_ctx-level 51; // rkmpp 扩展参数 av_opt_set(enc_ctx-priv_data, rc_mode, cbr, 0); av_opt_set_int(enc_ctx-priv_data, qp_init, 26, 0); av_opt_set_int(enc_ctx-priv_data, qp_min, 10, 0); av_opt_set_int(enc_ctx-priv_data, qp_max, 51, 0); if (avcodec_open2(enc_ctx, encoder, NULL) 0) { // 检查 pix_fmt 是否为 NV12MPP 编码器不接受 YUV420P }pix_fmt必须是AV_PIX_FMT_NV12这是 MPP 编码器的硬性要求。如果你从摄像头拿到的就是 NV12那可以直接送进去如果是 YUV420P得先做一次格式转换这个转换在 4K 下大概消耗 2 到 3 毫秒能避免就避免。max_b_frames 0是低延迟的代价B 帧能提升压缩率但会引入额外的重排序延迟实时场景直接关掉。qp_min和qp_max是 QP 的钳位范围CBR 模式下这两个值决定了码率控制的激进程度设得太窄会导致码率控不住设得太宽画质波动会很明显。3.3 零拷贝链路从 DRM prime 到编码器输入如果你做的是解码再编码的转码链路零拷贝能省掉两次内存搬运。解码器输出AV_PIX_FMT_DRM_PRIME的帧通过av_map_videotoframe或者直接操作AVDRMFrameDescriptor拿到 prime fd然后把这个 fd 导入到编码器的输入 buffer 里。源码包里一般会提供一个rkmpi_transcode.c的示例核心逻辑是// 解码得到 DRM prime 帧 AVFrame *dec_frame av_frame_alloc(); // ... 解码循环 ... AVDRMFrameDescriptor *desc (AVDRMFrameDescriptor *)dec_frame-data[0]; int prime_fd desc-objects[0].fd; // 导入到编码器 AVFrame *enc_frame av_frame_alloc(); enc_frame-format AV_PIX_FMT_DRM_PRIME; enc_frame-data[0] (uint8_t *)desc; enc_frame-width dec_frame-width; enc_frame-height dec_frame-height; // 直接送编码 avcodec_send_frame(enc_ctx, enc_frame);这段代码省掉了av_hwframe_transfer_data的拷贝。但要注意desc的生命周期必须覆盖到编码器消费完这一帧如果你在avcodec_send_frame之后立刻av_frame_free(dec_frame)编码器可能还在读这块内存结果就是花屏或者段错误。我一般会在编码器回调里加一个引用计数或者用av_frame_ref把 desc 的引用 hold 住。4. 避坑排查RK3588 硬编解码的五个血泪教训4.1 现象解码器打开成功但第一帧就报mpp_buffer_group_limit_config failed原因MPP 的 buffer 组默认限制是 24 个 buffer4K 解码的时候每个 buffer 大概 12MB24 个就是 288MB如果系统 CMA 内存不够就会在这个地方失败。解决在avcodec_open2之前通过av_opt_set_int(dec_ctx-priv_data, buf_group_size, 16, 0)把 buffer 组调小或者去内核 cmdline 里把cma调大比如cma512M。4.2 现象编码出来的视频在 PC 上播放花屏但用 ffplay 在板子上放正常原因MPP 编码器输出的码流里 SPS/PPS 的插入方式跟标准 FFmpeg 不一样有些播放器不认。解决在编码器初始化的时候设av_opt_set(enc_ctx-priv_data, repeat_headers, 1, 0)强制每个 I 帧前面都带 SPS/PPS。另外检查profile和level是否跟播放器兼容H.264 High Profile Level 5.1 不是所有播放器都吃。4.3 现象多路编码的时候第二路开始帧率掉到个位数原因MPP 的编码器实例默认是共享 VPU 的如果两路都设 4K30硬件带宽不够。解决要么降分辨率要么在av_opt_set里设av_opt_set_int(enc_ctx-priv_data, instance_id, 1, 0)让 MPP 做负载均衡。但根本的解决办法是算清楚 VPU 的总吞吐RK3588 的编码能力大概是 4K60 或者 1080P240超过这个数就得做取舍。4.4 现象avcodec_send_frame返回EAGAIN但avcodec_receive_packet也拿不到包原因编码器的输入队列满了但输出队列还没准备好。这种情况在 CBR 模式下码率设得太低、QP 钳位太窄的时候特别容易出。解决先调avcodec_receive_packet把已有的包取出来再重试send_frame。如果持续出现把qp_max放宽到 45 以上或者把bit_rate提高 20%。4.5 现象系统运行一段时间后dmesg里刷mpp_service: reset timeout原因VPU 硬件挂死了通常是输入数据有问题比如送进去的码流不是 Annex B 格式或者分辨率跟 SPS 里声明的不一致。解决先检查输入源确保extradata正确解析。如果确认输入没问题在 MPP 初始化的时候加av_opt_set(enc_ctx-priv_data, timeout, 1000, 0)让驱动在 1 秒后自动复位避免整个系统卡死。5. 进阶技巧用mpi_enc_test验证硬件极限与性能调优源码包里通常会带一个mpi_enc_test的工具在mpp/test/目录下。这个工具比 FFmpeg 更底层能直接压测 VPU 的极限。我一般用它来摸清楚板子的真实能力再决定 FFmpeg 层的参数怎么设。编译和运行cd mpp/test make mpi_enc_test # 用法mpi_enc_test -w 3840 -h 2160 -t 7 -n 300 -o out.h264 # -t 7 表示 H.265-n 300 表示编码 300 帧 ./mpi_enc_test -w 3840 -h 2160 -t 7 -n 300 -o /tmp/out.h265跑完之后看输出的 fps 和 CPU 占用。如果 4K30 的编码 CPU 占用超过 15%说明有额外的拷贝或者格式转换在拖后腿。这时候回到 FFmpeg 层检查pix_fmt是不是 NV12检查有没有多余的sws_scale。另一个技巧是调av_opt_set_int(enc_ctx-priv_data, gop_mode, 1, 0)这是 MPP 的智能 GOP 模式能在场景切换的时候自动插 I 帧对直播推流很有用但会稍微增加码率波动。从那以后我每次在 RK3588 上做硬编解码都强制走一遍mpi_enc_test摸极限再跑 FFmpeg 的转码链路对比 CPU 和延迟。这套源码包的价值不在于它封装了多少 API而在于它把 MPP 的底层能力和 FFmpeg 的生态接上了让你不用从零去啃瑞芯微的文档。希望帮到你。本文还有配套的精品资源点击获取
