1.

为什么要在RK3588上折腾FFmpeg硬件加速？

如果你手头正好有一台基于Rockchip

RK3588芯片的Armbian小盒子，比如一些流行的开发板或者迷你主机，你可能会发现一个挺有意思的现象：用它来跑一些视频转码或者AI推理任务，CPU动不动就飙到100%，风扇呼呼转，但实际处理速度却慢得让人着急。

这其实不是RK3588性能不行，恰恰相反，这颗芯片内置了非常强大的多媒体处理单元（NPU、VPU、RGA），只是你没用上它。

这就好比买了一辆跑车，却一直用一档在市区里慢慢开，完全没发挥出它的实力。

我自己就踩过这个坑。

最早拿到RK3588盒子时，我直接用apt安装的FFmpeg来转码一个4K视频，结果CPU占用率直接拉满，转码速度还不到5帧每秒。

当时我就纳闷，这宣传的8K解码能力去哪了？后来才明白，默认的FFmpeg根本没有启用针对RK3588的硬件加速后端，所有的编解码、缩放、色彩空间转换这些重活累活，全扔给了CPU。

CPU当然不堪重负。

所以，今天我要分享的，就是如何给你的Armbian系统“魔改”一个完全体的FFmpeg，让它能彻底调用RK3588的硬件加速能力。

整个过程，说白了就是自己动手，编译三个关键的东西：rkmpp（负责视频编解码）、rkrga（负责2D图形加速，比如缩放、旋转）、以及最终集成了这两者的FFmpeg。

听起来有点复杂？别怕，我一步步带你走，把每个坑都提前标出来。

实测下来，编译成功后，同样的4K视频转码，GPU占用率上来了，CPU轻松了，帧率能提升十几倍，而且盒子几乎没什么发热，这才是RK3588该有的样子。

2.

编译前的环境准备与依赖梳理

在开始敲命令之前，我们必须把“地基”打好。

Armbian系统默认是比较精简的，很多编译需要的工具和库都没有。

盲目开干，百分百会碰到各种“找不到xxx”的错误。

2.1

系统与基础工具确认

首先，用cat

/etc/os-release看看你的Armbian版本。

我推荐使用基于Debian

Bullseye或Bookworm的版本，社区支持比较好。

然后，第一件事就是更新软件源并安装最基础的编译工具链：

sudo
apt
pkg-config

这里重点说一下meson和ninja。

传统的./configure

&&

make组合大家很熟，但rkrga这个库用的是更现代的meson构建系统。

meson负责生成构建描述文件，ninja才是真正执行高速编译的那个引擎。

所以这两个必须装。

2.2

安装FFmpeg编译的常见依赖

FFmpeg是个“大杂烩”，它支持无数种编码格式和协议。

我们虽然主要是为了硬件加速，但一些基础且常用的软件编解码库和工具最好也装上，避免编译出来的FFmpeg功能残缺。

执行下面这一长串命令：

sudo
apt
zlib1g-dev

我解释几个关键的：

• libdrm-dev：极其重要。

  这是Direct

  Rendering

  Manager的库，是Linux内核图形子系统与用户空间（比如我们的rkmpp）通信的桥梁。

  没有它，硬件加速无从谈起。

• libx264-dev和libx265-dev：分别是H.264和HEVC的软件编码器。

  即使有硬件编码，有时也需要软件编码作为备用或用于某些特定场景。

• libfreetype-dev和libass-dev：如果你需要给视频加字幕（无论是硬字幕还是软字幕），这两个库是必须的。

安装完依赖，建议重启一下盒子，确保所有新安装的库文件都被系统正确加载。

3.

攻克第一个堡垒：编译rkmpp

rkmpp，全称Rockchip

Media

Platform，是Rockchip官方提供的媒体处理中间件。

你可以把它理解成一个“翻译官”，FFmpeg把视频处理任务（比如解码一个H.265文件）交给它，它再翻译成RK3588内部VPU（视频处理单元）能听懂的命令。

没有这个“翻译官”，FFmpeg和硬件之间就无法沟通。

3.1

获取源码与配置

Rockchip的官方代码库访问可能不太稳定，我们可以用一些社区维护的镜像。

这里我推荐一个更新比较及时的：

git
clone
https://github.com/JyHu/rockchip_mpp.git
rockchip_mpp

进入，这样后续编译FFmpeg时更容易找到它。

3.2

编译安装与验证

配置完成后，就可以开始编译了：

make
-j$(nproc)
install

-j$(nproc)表示使用你CPU的所有核心进行并行编译，能大大加快速度。

编译过程大概需要5-10分钟，取决于你的盒子性能。

安装完成后，如何验证rkmpp是否安装成功呢？你可以检查一下相关的库文件是否被放置到了正确的位置：

ls
/usr/lib/librkmpp*
/usr/include/rockchip/

应该能看到librkmpp.so等动态库文件以及一堆头文件。

更进一步的验证，可以尝试运行mpp自带的例子（如果有编译的话），或者留到后面和FFmpeg一起测试。

4.

拿下第二个关键：编译rkrga

如果说rkmpp是负责视频编解码的“翻译官”，那么rkrga（Rockchip

Raster

Acceleration）就是负责图像处理的“魔术师”。

视频处理中，除了编解码，还有大量像缩放、裁剪、旋转、格式转换（如NV12转RGB）这样的操作。

这些用CPU做也很慢，而RK3588的RGA硬件模块干这个是小菜一碟。

FFmpeg通过rkrga库来调用这个硬件模块。

4.1

使用社区优化版本

Rockchip官方的rga库有些历史了，对FFmpeg的新接口支持可能不够好。

幸运的是，有社区大佬做了适配和优化。

我强烈推荐使用nyanmisaka维护的专门为Jellyfin等媒体服务器优化过的分支：

git
clone
https://github.com/nyanmisaka/rk-mirrors.git
rkrga
rkrga

这个分支已经为我们配置好了很多适合FFmpeg的选项。

4.2

Meson构建流程详解

接下来我们使用Meson构建系统。

命令看起来比CMake复杂一点，但结构很清晰：

meson
setup
-Dlibrga_demo=false

逐条解释：

• meson

  setup

  rkrga_build：在当前。

• --prefix=/usr：同样安装到系统并编译安装：

  cd
  rkrga_build
  install

  完成后，检查/usr/lib/librga.so和/usr/include/rga/，因为rkmpp和rkrga我们装到了/usr下。

  后面那个路径是FFmpeg自己安装产出的路径，第一次编译时可能还没有，但先写上没关系。

• --disable-doc：不编译文档，节省大量时间。

运行这个配置命令后，一定要仔细看输出的总结！在最后几行，你会看到一个表格，检查rkmpp和rkrga后面是不是yes。

如果显示no，说明配置没找到这些库，需要回头检查它们的安装路径是否正确，或者pkg-config是否能找到。

5.3

编译与安装

配置成功，就可以开始漫长的编译了（在RK3588上可能需要30分钟到1小时）：

make
-j$(nproc)
install

编译完成后，会在当前。

6.

测试与集成实战

编译成功只是第一步，能不能用、好不好用才是关键。

6.1

基础功能验证

首先，进入install/bin目录，测试一下最基本的硬件解码：

./ffmpeg
-hwaccel
-

• -hwaccel

  rkmpp：指定使用rkmpp硬件加速。

• -hwaccel_device

  /dev/dri/renderD128：指定DRM设备节点，通常就是这个。

• -c:v

  h264_rkmpp：指定使用rkmpp的H.264解码器。

• -f

  null

  -：解码后不输出文件，只测试流程。

如果命令能顺利跑完，没有报错，并且输出信息中能看到hwaccel和rkmpp相关的字样，同时CPU占用率很低，那就说明解码通路成功了！

再测试一个包含缩放和编码的完整流程：

./ffmpeg
-hwaccel
"scale_rkrga=1280:720"
-c:v
output_720p.mp4

这个命令做了三件事：1)

用rkmpp硬件编码成H.264。

你可以用htop命令观察，理想情况下CPU占用应该是个位数，而通过cat

/sys/class/devfreq/*/load或sudo

cat

/sys/kernel/debug/rkrga/load（如果调试接口存在）可以观察到RGA或VPU模块的负载。

6.2

在自有项目中集成

如果你不是直接用ffmpeg命令行，而是要在自己的C/C++程序里调用FFmpeg库，那么就需要链接我们编译的库。

在你的项目的编译脚本（如Makefile或CMakeLists.txt）中，关键是要正确设置链接路径和库。

假设你的程序my_transcoder.c使用了FFmpeg，一个简单的Makefile示例如下：

CC
=
-I/path/to/your/ffmpeg-rockchip/install/include
LDFLAGS
-L/path/to/your/ffmpeg-rockchip/install/lib
-lavcodec
my_transcoder

这里有个巨坑我踩过：链接顺序很重要。

-lrkmpp和-lrga最好放在-lavcodec等FFmpeg库的后面，放在-ldrm的前面。

因为链接器是按顺序解析依赖的。

如果顺序不对，可能会报“未定义的引用”错误。

6.3

调试技巧分享

在Armbian小盒子上调试，确实不如x86电脑方便，没有图形化IDE，GDB也可能没装或者不好用。

我常用的“土法”调试方法：

1. 日志大法：在代码里大量使用av_log（FFmpeg

   API）或fprintf(stderr,

   ...)。

   编译时确保没有开启-s（strip）选项，保留调试符号。

2. 分段测试：不要一次性跑完整流程。

   先单独测试解码，再单独测试缩放，最后测试编码。

   用ffprobe分析中间生成的文件。

3. 系统日志：多使用dmesg

   -w命令观察内核日志。

   有时候硬件加速失败，内核DRM驱动或MPP驱动会打印出错误信息，这是定位问题的关键。

4. 简化复现：如果程序崩溃，尝试制作一个最小的、能复现问题的测试用例。

   这能帮你排除是业务逻辑错误还是FFmpeg集成错误。

我第一次集成时，程序一运行就段错误，盒子上又没gdb，确实让人头大。

后来就是靠dmesg发现是DRM权限问题（用户不在video和render组），以及通过注释代码段，逐步缩小范围，最终发现是初始化rkrga上下文时，传入的像素格式不支持。

所以，耐心和细致的日志是你的最佳伙伴。