1. 开篇为什么要在RK3399上折腾硬件编解码如果你手头有一块友善RK3399v2的开发板正琢磨着用它做点视频相关的项目比如做个家庭监控、搞个直播推流盒子或者玩点边缘AI视觉那你大概率会遇到一个头疼的问题视频处理太慢了用CPU软编码一个1080p的视频帧率可能直接掉到个位数画面卡成PPTCPU占用率还直接拉满。这时候你就需要请出板子里的“隐藏高手”——VPU。VPU全称Video Processing Unit你可以把它理解成一块专门处理视频编解码的“副显卡”。RK3399这颗芯片里就集成了这么一颗强大的VPU而rkmpp就是Rockchip官方提供的、用来驱动和调用这个VPU的“武功秘籍”Media Process Platform媒体处理平台。我当初拿到这块板子第一想法就是把这硬件加速能力用起来。网上资料虽然不少但东一榔头西一棒子真正从零开始、把编译、测试、到最终推流串起来的完整指南并不多。踩过几次坑之后我决定把整个流程重新梳理一遍写成这篇实战笔记。目标很简单让你跟着步骤走就能在友善RK3399v2上从零搭建环境最终实现流畅的硬件加速视频推流。无论你是嵌入式新手还是想快速验证方案的开发者这篇指南都能帮你省下大量摸索的时间。整个过程我们会分为几个清晰的阶段首先是准备好编译环境把MPP库这个核心“引擎”给装上然后我们会用官方测试工具实实在在地测一下VPU的解码和编码能力看看它的性能到底有多猛接着我们会搭建一个简单的RTMP流媒体服务器作为推流的目标最后也是最关键的一步我们会用FFmpeg和Gstreamer这两种最流行的多媒体框架分别实现硬件加速推流并对比其中的细节和坑点。放心每一步我都会配上详细的命令和结果解读保证你能看懂、能操作。2. 第一步搭建舞台——编译安装Rockchip MPP库万事开头难但这一步走稳了后面就顺了。我们的核心任务就是把Rockchip官方的MPP源代码在我们的RK3399板子上编译成可以调用的库文件。别怕编译其实步骤很固定。2.1 准备工作安装编译工具链首先确保你的RK3399板子已经刷好了Linux系统比如Ubuntu或Debian并且能正常联网。用SSH连上板子打开终端我们开始操作。第一步永远是更新软件源并安装必要的编译工具。这就像做饭前要先备好锅碗瓢盆和食材。sudo apt update sudo apt install -y gcc g cmake make git这几行命令的作用是sudo apt update: 刷新软件包列表确保我们能获取到最新的安装包信息。sudo apt install -y ...: 安装核心的编译工具。gcc和g是C/C编译器cmake和make是项目构建工具git用来下载源代码。-y参数是为了让安装过程自动确认省去手动输入“y”的步骤。2.2 获取源码与针对性配置工具准备好了接下来把MPP的源代码“搬”到我们的板子上。cd ~ git clone https://github.com/rockchip-linux/mpp.git cd mpp/build/linux/aarch64/这里我们直接进入了针对ARM 64位aarch64架构的预设编译目录。RK3399就是这种架构。但这里有个关键坑点需要特别注意官方提供的交叉编译配置文件预设用的是aarch64-linux-gnu-gcc这样的交叉编译工具链前缀那是用在x86电脑上编译给ARM板子用的。而我们现在是在板子上本地编译编译器名字就是简单的gcc和g。如果不修改编译会报错找不到编译器。所以我们需要修改一下配置文件sed -i s/aarch64-linux-gnu-gcc/gcc/g ./arm.linux.cross.cmake sed -i s/aarch64-linux-gnu-g/g/g ./arm.linux.cross.cmake这两条sed命令的作用是在arm.linux.cross.cmake文件里把所有的aarch64-linux-gnu-gcc替换成gcc把所有的aarch64-linux-gnu-g替换成g。这就是“本地编译”和“交叉编译”配置上的核心区别很多朋友卡在这里就是因为没做这一步。2.3 编译与安装配置搞定开始编译。这个过程会花点时间取决于你板子的性能。./make-Makefiles.bash make -j$(nproc) sudo make install./make-Makefiles.bash: 运行脚本生成最终的Makefile。make -j$(nproc): 开始编译。-j$(nproc)是一个超级实用的参数它会让make使用你CPU所有的核心来并行编译能大幅缩短编译时间。nproc命令会自动获取你CPU的核心数。sudo make install: 编译完成后将生成的库文件和头文件安装到系统目录默认是/usr/local/lib和/usr/local/include。这样其他程序比如FFmpeg就能找到它们了。编译安装完成后我强烈建议把MPP自带的几个测试工具也复制到系统路径方便后续随时验证cd ../test sudo cp mpp_info_test /usr/local/bin/ sudo cp mpi_dec_test /usr/local/bin/ sudo cp mpi_enc_test /usr/local/bin/这几个工具是我们下一步验证VPU能力的“试金石”。做完这些MPP库这个强大的“引擎”就已经在你的RK3399里安装就绪了。3. 第二步验明正身——测试VPU硬解与硬编性能库装好了但VPU到底给不给力是骡子是马得拉出来溜溜。我们用官方测试工具进行解码和编码的压力测试用数据说话。3.1 查看MPP版本与系统日志首先快速检查一下MPP是否安装成功并学会查看关键日志。mpp_info_test运行这个命令它会输出MPP库的版本信息和一些基础配置。如果正常显示说明库加载没问题。接下来是一个非常重要的习惯在RK3399上MPP的运行详情会输出到系统日志里。我们通过tail命令可以实时查看tail -f /var/log/syslog在另一个终端执行测试命令时保持这个tail窗口开着你就能看到VPU工作的详细过程、可能出现的错误或警告信息。这是调试的黄金窗口。3.2 硬解码性能测试感受飞一般的速度我们来测试视频解码能力。先从网络下载一个标准的H.264编码的测试视频片段。wget http://112.124.9.243/test/200frames_count.h264 -O 200frames_count.h264然后使用mpi_dec_test工具进行解码测试mpi_dec_test -t 7 -i 200frames_count.h264-t 7: 指定编码格式为H.264。-i: 指定输入文件。运行命令后立刻去看系统日志或者等命令结束你会找到类似这样的一行关键信息mpi_dec_test: decode 200 frames time 213 ms delay 3 ms fps 934.71我们来拆解一下这个性能报告decode 200 frames: 成功解码了200帧图像。time 213 ms:总耗时仅213毫秒也就是0.2秒多一点。delay 3 ms: 平均每帧解码延迟只有3毫秒。fps 934.71: 换算出来的帧率高达934.71 FPS这个数字非常夸张意味着VPU解码这个小分辨率H.264视频的能力远超实时需求通常30或60FPS就够用了。这充分证明了RK3399的VPU在解码方面的强悍性能为后续的播放、分析等应用打下了坚实基础。3.3 硬编码性能测试理解编码的“重量”解码厉害编码呢编码通常比解码更耗费算力。我们下载一个未压缩的YUV原始视频文件来测试编码。wget http://112.124.9.243/test/4k_nv12.yuv.gz -O 4k_nv12.yuv.gz gzip -d 4k_nv12.yuv.gz这是一个4K分辨率3840x2160的NV12格式原始文件。体积会比较大因为它没有经过任何压缩。然后用mpi_enc_test进行编码测试mpi_enc_test -w 3840 -h 2160 -t 7 -i 4k_nv12.yuv -f 0 -o 4k_nv12.h264-w和-h: 指定视频的宽度和高度4K。-t 7: 编码为H.264格式。-i: 输入YUV文件。-f 0: 输入像素格式为NV12对应数字0。-o: 输出的H.264文件。完成后查看日志关键行如下mpi_enc_test: chn 0 encode 241 frames time 31623 ms delay 107 ms fps 7.62 bps 32174975分析编码性能encode 241 frames: 编码了241帧。time 31623 ms: 总耗时约31.6秒。可以看到编码4K视频是非常吃资源的。delay 107 ms: 平均每帧编码延迟107毫秒。fps 7.62: 编码速度约为每秒7.62帧。对于4K实时编码30FPS来说这个速度不够但对于录制、存储等非实时场景或者降低分辨率到1080p性能会大幅提升。bps 32174975: 生成视频码率约为32 Mbps。这个测试告诉我们RK3399的VPU可以进行硬件编码但处理高分辨率如4K实时编码时会有压力。在实际项目中需要根据你的分辨率、帧率和实时性要求来评估和选择。对于常见的1080p30fps推流它是完全能够胜任的。4. 第三步搭建目标——配置简易RTMP流媒体服务器测试完VPU我们知道它有力气干活了。接下来我们需要给它一个“用武之地”。我们将搭建一个最简单的RTMP服务器用来接收RK3399推上来的视频流。这里我选用Nginx加上RTMP模块的方案因为它轻量、稳定、配置简单。4.1 编译安装带RTMP模块的Nginx在RK3399上我们同样采用编译安装的方式以确保RTMP模块被正确集成。首先安装Nginx编译所需的依赖库sudo apt update sudo apt install -y build-essential libpcre3 libpcre3-dev libssl-dev zlib1g-dev然后下载Nginx源码和著名的nginx-rtmp-module模块源码wget http://nginx.org/download/nginx-1.21.6.tar.gz tar -zxvf nginx-1.21.6.tar.gz git clone https://github.com/arut/nginx-rtmp-module.git进入Nginx目录进行配置。关键是要通过--add-module参数把RTMP模块的路径加进去cd nginx-1.21.6 ./configure --with-http_ssl_module --add-module../nginx-rtmp-module配置成功后编译并安装make sudo make install默认安装路径是/usr/local/nginx。4.2 配置Nginx支持RTMP推流与拉流安装完成后需要修改配置文件让Nginx能处理RTMP协议。打开主配置文件sudo vim /usr/local/nginx/conf/nginx.conf在文件的events { ... }区块之后http { ... }区块之前添加RTMP服务器的配置rtmp { server { listen 1935; # RTMP标准端口 chunk_size 4096; # 数据块大小 application live { # 定义一个名为“live”的应用 live on; # 开启直播 record off; # 关闭录制节省磁盘空间 # allow publish 192.168.1.0/24; # 可以按需设置允许推流的IP段 # deny publish all; } } }同时你可以在已有的http { ... }区块里的server中添加一个简单的状态页方便查看推流状态可选但推荐http { server { listen 8080; location / { root html; index index.html index.htm; } # RTMP状态监控页面 location /stat { rtmp_stat all; rtmp_stat_stylesheet stat.xsl; } location /stat.xsl { root /usr/local/nginx/html; # 需要将stat.xsl文件放到这个目录 } } }你需要从nginx-rtmp-module仓库的stat.xsl文件复制到/usr/local/nginx/html/目录下。保存配置文件后启动Nginxsudo /usr/local/nginx/sbin/nginx如果修改了配置需要重启可以用sudo /usr/local/nginx/sbin/nginx -s reload现在你的RTMP服务器就运行在rtmp://你的RK3399板子IP:1935/live上了。任何推流到/live这个应用下的流都可以通过rtmp://你的RK3399板子IP:1935/live/流名称来拉取。你可以先用OBS推个流试试再用VLC播放器拉流验证服务器是否正常。5. 第四步终极实战——FFmpeg与Gstreamer硬件加速推流舞台搭好演员就位好戏开场这是最核心的一步让RK3399捕获摄像头画面通过VPU硬件编码然后推送到我们刚搭建的RTMP服务器。我会分别用FFmpeg和Gstreamer两种方式实现并聊聊其中的门道。5.1 方案一使用FFmpeg配合v4l2m2m编码器FFmpeg是多媒体处理的“瑞士军刀”。在RK3399上我们可以利用其h264_v4l2m2m编码器来调用VPU进行硬件编码。首先确保安装了FFmpeg如果系统自带版本太老建议编译安装支持v4l2m2m的版本sudo apt install -y ffmpeg基本的硬件加速推流命令如下ffmpeg -f v4l2 -input_format mjpeg -framerate 30 -video_size 1920x1080 -i /dev/video10 -c:v h264_v4l2m2m -b:v 2M -f flv rtmp://192.168.137.82/live/stream逐条参数解析-f v4l2: 指定使用Video4Linux2框架来捕获设备摄像头。-input_format mjpeg: 指定摄像头输出的格式为MJPEG。这是一个关键点很多USB摄像头直接输出的是MJPEG或YUYV压缩/半压缩数据比原始RGB数据量小更适合传输。-framerate 30/-video_size 1920x1080: 设置期望的帧率和分辨率。-i /dev/video10: 指定摄像头设备节点。你的可能是/dev/video0请用v4l2-ctl --list-devices命令确认。-c:v h264_v4l2m2m:核心参数指定视频编码器为h264_v4l2m2m这就是调用V4L2接口进而使用VPU进行H.264硬件编码的关键。-b:v 2M: 设置视频码率为2 Mbps。-f flv: 将输出封装格式设置为FLV这是RTMP流常用的格式。最后是推流地址。如果你的摄像头不支持MJPEG只支持YUYV422命令需要调整ffmpeg -f v4l2 -input_format yuyv422 -framerate 10 -video_size 1024x768 -i /dev/video10 -c:v h264_v4l2m2m -b:v 2M -f flv rtmp://192.168.137.82/live/stream注意这里framerate和video_size要根据摄像头实际能力调整否则会报错。实测体验与坑点使用h264_v4l2m2m编码器推流CPU占用率会显著下降从软编码的接近100%降到20%以下说明硬件编码确实生效了。但有时可能会遇到画面绿屏或花屏的问题。这通常是因为像素格式转换不匹配。VPU硬件编码器通常要求输入为NV12格式而摄像头输出可能是YUYV422或MJPEG。FFmpeg的v4l2m2m编码器内部会尝试做转换但有时不奏效。一个更稳定的方法是使用libv4l2进行转换或者考虑下面的Gstreamer方案它在格式转换管道上更灵活。5.2 方案二使用Gstreamer构建精准处理管道Gstreamer采用“管道Pipeline”的概念把数据处理过程分解成一个个连接的“元件Element”控制力更强也更适合处理复杂的格式转换链。首先安装Gstreamer及相关插件sudo apt install -y libgstreamer1.0-dev libgstreamer-plugins-base1.0-dev gstreamer1.0-plugins-good gstreamer1.0-plugins-bad gstreamer1.0-plugins-ugly gstreamer1.0-rtsp一个基础的、使用MPP硬件编解码元件的推流管道如下gst-launch-1.0 -v v4l2src device/dev/video10 ! image/jpeg,width640,height480,framerate30/1 ! jpegdec ! videoconvert ! video/x-raw,formatNV12 ! mpph264enc ! h264parse ! flvmux ! rtmpsink locationrtmp://192.168.137.82/live/stream管道拆解从左到右的数据流v4l2src: 从摄像头设备采集数据。image/jpeg,...: 设置采集数据的格式和参数这里假设是MJPEG格式。jpegdec:软件解码器将MJPEG压缩数据解码成原始视频数据通常是RGB或I420格式。videoconvert: 一个强大的格式转换元件这里负责将解码后的数据转换成下一步所需的格式。video/x-raw,formatNV12:关键过滤器。它指定了管道中下一环节接收的数据必须是NV12格式。videoconvert元件会努力满足这个要求。mpph264enc:核心元件Gstreamer的MPP插件提供的硬件H.264编码器直接调用我们安装的MPP库。h264parse: 解析编码后的H.264流确保其符合标准。flvmux: 将视频流和可能的音频流封装成FLV格式。rtmpsink: 将FLV流推送到指定的RTMP服务器地址。优化版管道如果你的Gstreamer安装了mpp插件可以直接使用硬件JPEG解码器效率更高gst-launch-1.0 -v v4l2src device/dev/video10 ! image/jpeg,width640,height480,framerate30/1 ! mppjpegdec ! videoconvert ! video/x-raw,formatNV12 ! queue max-size-time0 max-size-buffers1 leakydownstream ! mpph264enc ! h264parse ! flvmux streamabletrue ! rtmpsink locationrtmp://192.168.137.82/live/stream这里把jpegdec换成了mppjpegdec并增加了一个queue元件来缓冲数据使管道更稳定。查看日志与排错运行Gstreamer命令时务必同时用tail -f /var/log/syslog查看系统日志。你会看到MPP库详细的初始化、编码参数设置等信息。例如日志明确告诉你unable to create enc h265 for soc rk3399 unsupported这说明RK3399的VPU不支持H.265编码只支持H.264。还会显示编码器设置的码率、帧率、GOP大小等参数这对于调试至关重要。关于延迟我在PC端用VLC播放时观察到大约2秒的延迟。这属于正常范围延迟主要来自几个环节摄像头传感器采集延迟、编码缓冲、网络传输缓冲、以及播放器解码缓冲。Gstreamer管道中的queue元件、编码器的内部缓冲、RTMP协议本身的特性都会引入延迟。如果对延迟要求极高如无人机图传需要深入研究并优化每一个环节的缓冲区大小甚至考虑使用像SRT或WebRTC这类低延迟协议来替代RTMP。但对于大多数监控、直播场景2秒左右的延迟是可以接受的。走到这一步你应该已经成功地在友善RK3399v2上完成了一套从底层驱动编译、性能验证到上层应用推流的完整硬件加速视频处理链路。整个过程虽然步骤不少但每一步都有其明确的目的。最重要的是你亲手验证了那颗VPU的强大能力并掌握了驾驭它的两种主流工具。后续你可以在此基础上结合Python或C程序开发更复杂的视频分析、智能识别应用让RK3399真正成为你的边缘视觉智能终端。