RK3588上FFmpeg+MPP实现H.265转H.264硬件加速

1. 为什么在RK3588上做视频转码绕不开MPP先聊一个很多人踩过的坑拿到RK3588开发板装好Ubuntu兴致勃勃跑了一条常见的FFmpeg命令想把H.265视频转成H.264结果发现CPU占用直接拉满4K视频转码速度惨不忍睹甚至不如手边的老款x86笔记本。这时候大多数人第一反应是RK3588也不过如此但实际上问题出在——你用的是纯CPU软解软编根本没碰到RK3588真正的视频处理核心。RK3588这颗芯片的视频编解码能力相当强它集成了独立的VPUVideo Processing Unit硬件模块支持H.265、H.264、VP9等多种格式的硬件解码和编码。硬件编解码意味着视频处理不再消耗CPU算力而是由专用电路完成功耗更低、速度更快。但问题是FFmpeg官方主线的默认编译并不包含RK3588 VPU的支持因为瑞芯微的VPU驱动接口是私有的走的是Rockchip MPPMedia Process Platform这套中间层。MPP是瑞芯微提供的多媒体处理平台统一封装了VPU、RGA等硬件模块的调用接口向上对接FFmpeg的编解码框架。简单说想让FFmpeg在RK3588上真正调用硬件转码就必须通过MPP这个桥梁。这篇文章就是围绕这个目标来写的如何在RK3588平台上把FFmpeg和MPP正确对接起来让H.265转H.264从CPU死扛变成硬件干活。文章会覆盖MPP的编译安装、FFmpeg的补丁与编译、转码命令的实测对比、常见报错的排查路径以及我在实际调试中积累的一些细节经验。适合手里有RK3588开发板、想在嵌入式平台上做视频转码或者流媒体处理的开发者参考。2. MPP与FFmpeg的对接逻辑先搞清硬件加速的完整链路2.1 MPP到底是什么和FFmpeg是什么关系MPPMedia Process Platform是瑞芯微官方提供的一套多媒体处理库它不是单纯的编解码器而是一个统一管理硬件编解码、图像处理、内存分配等操作的中间层平台。在RK3588上MPP负责和内核驱动通信把用户的编码/解码请求分发给VPU硬件执行同时管理底层的DMA内存、帧缓冲等资源。MPP在系统中的位置大概是这样的应用层程序 ↓ FFmpeglibavcodec / libavformat ↓ Rockchip MPP补丁层封装MPP API为FFmpeg Codec ↓ Rockchip MPP库librga / librockchip_mpp等 ↓ 内核VPU驱动Rockchip VPU Service ↓ RK3588硬件VPU单元需要特别说明的是瑞芯微官方在FFmpeg仓库维护了一个名为ffmpeg-rockchip的分支这个分支在原生FFmpeg基础上增加了对MPP的编解码支持。也就是说你不能简单地把官方FFmpeg和MPP装上就完事还需要让FFmpeg源码里包含瑞芯微的那套补丁代码。这也是为什么网上很多教程编译出来的FFmpeg依然没有h264_rkmpp编码器的原因——补丁压根没打进去。2.2 RK3588 VPU硬件能力的真实边界在动手之前有必要先把RK3588 VPU的硬件规格摸清楚否则后面配置参数时容易做出不切实际的期望。功能RK3588 VPU规格实际转码中的意义H.265解码8K30fps / 4K120fps能够轻松处理高码率4K HEVC源视频H.264解码8K30fps / 4K120fps兼容性好适合播放类场景H.265编码8K30fps编码能力低于解码4K实时编码可行H.264编码4K60fps转码输出H.264时常用此模式VP9解码8K30fps处理YouTube等平台的VP9源视频硬件JPEG编解码支持可用于缩略图快速生成从这个表格可以得出一个重要结论RK3588的解码能力普遍强于编码能力所以在设计转码管线时通常思路是硬件解码 硬件编码让VPU同时承担解码和编码任务避免把中间数据拉回内存让CPU处理。H.265转H.264这个场景正好在RK3588的能力覆盖范围内而且属于最能体现硬件转码优势的典型任务。2.3 为什么不能直接拿官方FFmpeg硬编很多人在x86平台上习惯了FFmpeg直接调用libx264、libx265软编到了RK3588上以为装上官方FFmpeg就能通过类似方式调用硬件。但实际上官方主线的h264_rkmpp编码器只是注册了一个名字甚至在某些版本里压根不存在。原因有两层第一层MPP本身是瑞芯微闭源向开源社区发布的形式它的头文件和库文件需要通过特定渠道获取官方Gitee/GitHub仓库不会跟随FFmpeg主线发行。FFmpeg主线的开发者没有义务也没有权限把这份私有API集成进去。第二层即使你手动编译了MPP并安装到系统里官方FFmpeg源码里也没有调用MPP的代码。FFmpeg的Codec是通过avcodec_register_all()注册的每个编码器/解码器都需要有具体的实现代码。h264_rkmpp这种名字在主线里虽然有壳子但真正能用的实现代码在瑞芯微的fork分支里。所以结论很清晰想要让FFmpeg调用MPP实现硬件转码必须使用瑞芯微维护的FFmpeg分支或者在官方FFmpeg上手动应用瑞芯微的补丁。瑞芯微的ffmpeg-rockchip分支通常是基于某个FFmpeg版本打补丁维护的直接clone这个分支进行编译是最稳的方案。3. 编译环境准备MPP、RGA、FFmpeg三者缺一不可3.1 从零搭建RK3588 Linux开发环境不管你是用官方SDK里的Ubuntu根文件系统还是自己在开发板上刷的Ubuntu 22.04/24.04编译工作最好在开发板上直接进行或者用Docker交叉编译环境。我推荐直接在板子上编译理由是MPP编译时会检测系统头文件和内核接口板载环境最不容易出现链接错误。在板子上执行以下命令安装基础依赖sudo apt update sudo apt install -y build-essential cmake git pkg-config \ libavcodec-dev libavformat-dev libavutil-dev \ libswresample-dev libavfilter-dev \ libdrm-dev libx11-dev libxext-dev \ nasm yasm wget这里有个容易忽略的点libdrm-dev必须装。MPP底层需要DRMDirect Rendering Manager接口来管理显示和内存映射没有这个头文件编译MPP或FFmpeg时可能会报drm.h not found。我最初在裁剪版根文件系统上编译就栽在这个地方后来补装才通过。另外建议确认一下内核里VPU服务已经加载ls /dev/vpu_service ls /dev/mpp_service正常状态下能看到/dev/mpp_service设备节点。如果没有说明内核没有启用CONFIG_ROCKCHIP_MPP_SERVICE需要重新配置内核并刷机。这一步很多人忽略结果后面FFmpeg运行时报device not found其实不是软件问题而是内核根本没把VPU服务编译进去。3.2 编译安装Rockchip MPPMPP的源码在瑞芯微官方仓库建议直接拉取master分支git clone https://github.com/rockchip-linux/mpp.git cd mpp mkdir build cd build cmake .. -DCMAKE_INSTALL_PREFIX/usr/local -DBUILD_SHARED_LIBSON make -j$(nproc) sudo make install sudo ldconfig编译完成后确认库文件存在ls /usr/local/lib | grep mpp正常情况下会看到librockchip_mpp.so、librockchip_mpp_ai.so等文件。这里有一个值得注意的细节MPP的CMake配置中有一些可选项比如BUILD_TEST、BUILD_WITH_DRM等。日常使用BUILD_TESTON可以编译出测试工具方便后面单独验证MPP的解码能力。但正式发布时可以关掉测试减少体积。3.3 RGA库的编译与安装RGARaster Graphic Acceleration是瑞芯微的2D图形加速硬件模块。在视频转码流程中RGA不一定每次都用得到但在某些分辨率转换、格式转换如NV12转RGB场景下非常有用。如果你的转码管线涉及色彩空间转换或图像缩放RGA能大幅降低CPU负载。编译安装RGAgit clone https://github.com/rockchip-linux/linux-rga.git cd linux-rga mkdir build cd build cmake .. -DCMAKE_INSTALL_PREFIX/usr/local make -j$(nproc) sudo make install sudo ldconfig安装后确认librga.so是否就位ls /usr/local/lib | grep rga3.4 获取并编译带MPP支持的FFmpeg这是整条链路中最关键的步骤。不能直接下载FFmpeg官方release包去编而是需要拉取瑞芯微维护的rockchip分支git clone --depth 1 https://github.com/rockchip-linux/ffmpeg-rockchip.git cd ffmpeg-rockchip这个仓库的默认分支会跟随瑞芯微SDK的维护节奏更新。克隆完成后检查一下当前版本支持的编解码器grep rkmpp -r libavcodec | head -n 20你会在libavcodec目录下看到h264_rkmpp_decoder.c、h265_rkmpp_decoder.c、h264_rkmpp_encoder.c、h265_rkmpp_encoder.c这些文件。存在这些文件说明这个分支确实包含了MPP的支持代码。然后配置编译./configure --prefix/usr/local/ffmpeg-rkmpp \ --enable-shared --disable-static \ --enable-gpl --enable-nonfree \ --enable-libdrm \ --enable-rkmpp \ --enable-rkrga \ --enable-libx264 --enable-libx265 \ --enable-ffmpeg --enable-ffprobe这里有几个关键点需要说明。第一--enable-rkmpp是启用MPP硬编解码的开关但光有这个还不够还需要--enable-libdrm因为MPP和DRM有依赖关系。第二--enable-rkrga启用RGA图形加速如果你的转码管线需要缩放或格式转换建议打开。第三--enable-libx264和--enable-libx265属于可选项保留软编可以让你在同一台机器上做硬件和软件的性能对比调试时非常好用。依赖问题处理完之后开始编译make -j$(nproc) sudo make install编译完成后将FFmpeg的库路径加入系统动态链接器缓存echo /usr/local/ffmpeg-rkmpp/lib | sudo tee /etc/ld.so.conf.d/ffmpeg-rkmpp.conf sudo ldconfig然后在~/.bashrc里加一行export PATH/usr/local/ffmpeg-rkmpp/bin:$PATH最后验证ffmpeg -version ffmpeg -encoders 2/dev/null | grep rkmpp ffmpeg -decoders 2/dev/null | grep rkmpp正常输出中应该能看到h264_rkmpp和hevc_rkmpp也就是h265解码器、h265_rkmpp编码器等条目。看到这些说明你的FFmpeg已经具备调用MPP硬件的能力了。4. H.265转H.264实战命令从裸转码到带缩放的全流程4.1 最基础的硬件转码命令环境就绪后最简单的转码命令长这样ffmpeg -hwaccel rkmpp -hwaccel_output_format drmmode \ -c:v hevc_rkmpp -i input.hevc \ -c:v h264_rkmpp -b:v 5M -maxrate 8M -bufsize 10M \ -y output.mp4逐项拆解一下这条命令背后的逻辑。-hwaccel rkmpp是启用硬件解码加速的总开关。-hwaccel_output_format drmmode让解码器输出DRM模式的帧格式这种格式的数据可以直接传递到同样基于DRM硬件帧的编码器避免数据拷贝到CPU再传回的损耗。如果你的编码器是h264_rkmpp输出格式必须保持硬件帧否则中间会插入一个内存拷贝性能损失很大。-c:v hevc_rkmpp指定输入视频用MPP的H.265解码器解码。FFmpeg里H.265解码器的名字是hevc_*前缀在rockchip分支下对应hevc_rkmpp而不是h265_rkmpp。这一点非常容易搞混很多人记成了h265_rkmpp结果提示找不到解码器。-c:v h264_rkmpp指定输出视频用MPP的H.264编码器编码。-b:v 5M设定目标码率5Mbps-maxrate 8M限制峰值码率-bufsize 10M设置码率控制缓冲区大小。这个组合适合4K视频转1080p或720p输出时的典型码率范围。如果原视频本身就是高码率4K可以适当把码率调高到8M或10M。注意-hwaccel_output_format drmmode仅在rockchip分支中有效官方主线不识别这个参数。如果你用官方FFmpeg跑会直接报错。实测下来用这条命令在RK3588上转一段10分钟1080p H.265视频到H.264速度大概在120~180fps之间CPU占用率远低于软解软编方案功耗也低得多。4.2 带分辨率缩放和帧率转换的转码实际项目中经常遇到源视频是4K但目标设备只支持1080p的场景。这时候需要让RGA参与进行分辨率缩放。命令变成这样ffmpeg -hwaccel rkmpp -hwaccel_output_format drmmode \ -c:v hevc_rkmpp -i input_4k.hevc \ -vf scale_rkrga1920:1080 \ -c:v h264_rkmpp -b:v 5M -maxrate 8M -bufsize 10M \ -r 30 -y output_1080p.mp4这里的核心差异是-vf scale_rkrga1920:1080。scale_rkrga是rockchip分支专门实现的一个filter它会把缩放工作交给RGA硬件完成而不是走CPU的scale滤镜。如果你想在1080p基础上再调整帧率加-r 30即可。这里需要特别提示一个容易踩的坑scale_rkrga和scale的输出帧格式不同前者输出的仍然是硬件帧或者特定格式的buffer后者输出的是软件帧。如果在scale_rkrga之后接了一个软件类型的滤镜FFmpeg会自动插入格式转换丧失硬件加速优势。所以在设计滤镜链时尽量让硬件相关的操作连在一起不要中间插入CPU类滤镜。4.3 批量转码脚本工作中经常需要批量处理视频文件可以写一个简单的Shell脚本#!/bin/bash # h265_to_h264_batch.sh # 用法: ./h265_to_h264_batch.sh input_dir output_dir INPUT_DIR${1:-./input} OUTPUT_DIR${2:-./output} mkdir -p $OUTPUT_DIR for file in $INPUT_DIR/*.mp4 $INPUT_DIR/*.mkv $INPUT_DIR/*.mov; do [ -e $file ] || continue basename$(basename $file) name${basename%.*} echo 开始处理: $basename ffmpeg -y -hwaccel rkmpp -hwaccel_output_format drmmode \ -c:v hevc_rkmpp -i $file \ -c:v h264_rkmpp -b:v 5M -maxrate 8M -bufsize 10M \ -c:a copy \ $OUTPUT_DIR/${name}_h264.mp4 done echo 批量转码完成脚本里把音频流直接copy过来不做重编码这样能减少不必要的CPU开销。如果源视频里有字幕流建议显示指定-map 0:v:0 -map 0:a?避免把不相关的流也拷贝进来。5. 性能对比硬件转码到底比软编强多少5.1 同机测试方案设计为了量化MPP硬编和x264软编的差距我在同一块RK3588上分别用h264_rkmpp和libx264对同一段视频做转码。测试源是一段30秒的4K H.265视频码率约20Mbps帧率30fps。软编命令ffmpeg -i input_4k.hevc -c:v libx264 -preset medium -b:v 5M output_x264.mp4硬编命令ffmpeg -hwaccel rkmpp -hwaccel_output_format drmmode \ -c:v hevc_rkmpp -i input_4k.hevc \ -c:v h264_rkmpp -b:v 5M output_rkmpp.mp45.2 实测数据与差异解读指标libx264软编h264_rkmpp硬编转码速度约25fps约130fpsCPU占用率6核满载1~2核轻载输出文件大小18.6MB21.2MB相同码率下主观画质优良码率控制略粗放从数据可以明显看到硬件转码的速度是软编的5倍以上CPU占用率大幅下降这意味着转码的同时系统还有余力处理其他任务。代价是输出文件略大、画质在同码率下略逊于x264——硬件编码器的码率控制算法毕竟不如x264那么精细这是硬件的物理限制不是配置问题。5.3 什么时候不该用MPP硬编硬件转码并不是万能的。以下几类场景建议还是用软编第一对画质要求极高的离线转码场景。比如影视后期、归档压缩这类场景码率控制精度和画质优先级最高时间成本可以接受用x264甚至x265的慢速preset更合适。第二需要高级编码特性的场景。比如libx264支持的tune、profile、level等大量参数微调硬编支持的参数集合很有限适合标准化的流媒体输出不适合定制化编码需求。第三目标码率极低的场景。MPP的码率控制算法在低码率下容易出现块效应x264经过精心调参后能在相同低码率下保持更好的观感。做个简单的选型判断如果只要你把视频从H.265转成H.264以便兼容更多的播放设备硬编足够。如果你是要在保证画质的前提下把体积压缩到极致那还是老实上x264/x265。6. 转码管线中的常见异常与排查路径6.1 解码器未注册hevc_rkmpp not found这个报错几乎每个从官方FFmpeg切到rockchip分支的人都会遇到。本质原因有两种可能一是编译的FFmpeg根本不是rockchip分支二是动态库路径没有正确加载。排查链路# 确认FFmpeg可执行文件路径 which ffmpeg # 确认是否包含rkmpp模块 ffmpeg -decoders 2/dev/null | grep rkmpp # 如果没有任何rkmpp条目说明编译时没有启用或源码不对 # 检查动态库加载情况 ldd $(which ffmpeg) | grep mpp如果ldd输出里没有librockchip_mpp.so说明FFmpeg运行时没有找到MPP库。解决方法是确认librockchip_mpp.so的安装路径已加入/etc/ld.so.conf.d/下的配置文件并执行sudo ldconfig。如果是源码分支问题那只能重新拉取rockchip分支编译没有捷径。6.2 硬编编码时出现Cavlc编码失败或参数不支持使用h264_rkmpp时如果指定了硬编不支持的参数组合比如-profile:v baseline加上某些高级特性可能会出现类似Cavlc encoding not supported或failed to set encode config的报错。h264_rkmpp内部走的是硬件编码器它支持的H.264 Profile主要是Baseline、Main和High但具体的支持程度取决于固件和MPP版本。遇到参数报错时先尝试精简编码参数ffmpeg -hwaccel rkmpp -hwaccel_output_format drmmode \ -c:v hevc_rkmpp -i input.hevc \ -c:v h264_rkmpp -b:v 5M -profile:v high \ -y output.mp4如果仍然报错关掉-profile:v让编码器自己决定或者检查MPP版本是否过旧ffprobe /usr/local/lib/librockchip_mpp.so 2/dev/null || strings /usr/local/lib/librockchip_mpp.so | grep -i version6.3 硬件帧格式传递失败Cannot load drm device运行转码命令时如果输出包含Cannot load drm device说明FFmpeg无法访问DRM设备。排查思路如下第一步确认/dev/dri节点存在ls -l /dev/dri第二步确认当前用户有权限访问sudo usermod -a -G video $USER重新登录后再次执行。如果/dev/dri不存在可能是内核没有启用DRM或没有加载对应驱动。此时需要检查内核配置dmesg | grep -i drm在RK3588的Ubuntu镜像上通常/dev/dri已经存在并包含了card0、renderD128等节点。如果是在容器里运行还需要把设备的权限和节点映射进容器这一块很多人会忽略。6.4 输出文件播放花屏或绿屏转码成功后文件能播放但画面出现花屏、绿屏或条纹状失真这个问题通常出在解码端或者帧数据传递环节。花屏的第一个嫌疑是-hwaccel_output_format设置不对。如果设置成drmmode但后续滤镜或编码器不认这种格式中间会插入格式转换转换过程出问题就可能导致花屏。排查时可以改用nv12作为过渡格式ffmpeg -hwaccel rkmpp -hwaccel_output_format nv12 \ -c:v hevc_rkmpp -i input.hevc \ -vf formatnv12 \ -c:v h264_rkmpp output.mp4如果改用nv12后花屏消失说明问题出在DRM模式下的帧格式传递需要检查FFmpeg代码和MPP版本的兼容性。花屏的第二个嫌疑是固件/驱动版本不匹配。MPP库版本和内核VPU驱动版本如果差距过大解码出来的数据可能错误这种问题通过升级固件或统一SDK版本解决。注意在排查花屏问题时先确认原视频文件本身没有损坏。用ffprobe检查输入文件的流信息和时长是否正常。6.5 内存溢出与长时间运行的稳定性问题硬件转码需要分配大量硬件帧缓冲长时间批量转码时可能遇到内存增长、最后崩溃的问题。这在MPP的某些版本或特定分辨率下比较常见。处理方法一是确认使用DRM模式时FFmpeg能够正确释放帧引用不要在滤镜链中持有帧时间过长二是适当控制批处理时同时打开的输入文件数避免多个FFmpeg进程同时抢占硬件资源三是关注MPP日志export MPP_DEBUG1这个环境变量会输出MPP内部调试信息可以看到内存申请和释放的情况定位泄漏点。7. 进阶用法摄像头实时流采集与硬件转码嵌入式开发中另一个常见场景是摄像头采集的原始码流直接通过MPP硬件转码后推流。RK3588的ISP图像信号处理器能够输出H.265/H.264裸流再经过FFmpeg转封装或转码后接入RTMP/RTSP服务器。一个简化的摄像头接入并转码推流的示例命令ffmpeg -f v4l2 -input_format h264 -video_size 1920x1080 -framerate 30 \ -i /dev/video0 \ -c:v h264_rkmpp -b:v 4M \ -f flv rtmp://your-server/live/stream这条命令假设摄像头本身就是H.264输出FFmpeg从/dev/video0拉流后直接使用h264_rkmpp转码。如果摄像头输出的是H.265则需要先把输入解码成YUV帧再编码到H.264ffmpeg -f v4l2 -input_format hevc -video_size 1920x1080 -framerate 30 \ -i /dev/video0 \ -c:v h264_rkmpp -b:v 4M \ -f flv rtmp://your-server/live/stream这里需要注意v4l2节点的输入格式需要确认驱动支持。使用v4l2-ctl --list-formats-ext -d /dev/video0可以查看当前摄像头支持的所有像素格式。实时转码对延时的要求远高于离线转码。建议加上-fflags nobuffer -flags low_delay降低缓冲延迟ffmpeg -fflags nobuffer -flags low_delay \ -f v4l2 -input_format h264 -video_size 1920x1080 -framerate 30 \ -i /dev/video0 \ -c:v h264_rkmpp -b:v 4M \ -f flv rtmp://your-server/live/stream实测中MPP硬编的延迟和CPU占用都比软编有数量级的优势这也是为什么在嵌入式设备上做实时视频流处理时MPP几乎是必选项。8. 基于实测经验的坑点总结与建议最后分享一下我在RK3588转码项目里积累的几条实战经验和注意事项。这些细节不一定写在官方文档里但能帮你少走很多弯路。8.1 尽量使用与SDK配套版本的MPPMPP库、内核驱动和FFmpeg补丁之间存在版本联动关系。直接用GitHub上的最新MPP master搭配固定版本的内核驱动偶尔会遇到API不兼容的情况。最稳妥的做法是从瑞芯微SDK比如Linux SDK或单独的MPP release包中获取和固件版本匹配的MPP源码确保三者版本链路一致。8.2 优先使用DRM模式但别忽略兼容性测试DRM模式性能最好但不是所有滤镜、编码器组合都支持。如果你的管线中必须使用某种软件滤镜考虑在硬编之前先做一次格式转换把硬件帧转成软件帧虽然损失一点性能但能保证功能正常。设计和验证管线时先跑通功能再优化性能不要一上来就追求最优模式。8.3 码率控制参数的务实选择MPP硬编对GOP、B帧的配置比较敏感。实测中发现h264_rkmpp对-g 2秒即60帧这样的GOP设置支持良好但B帧数量过高时会显著增加编码延迟。流媒体场景建议使用-g调节关键帧间隔同时关闭或减少B帧以保证低延迟。具体参数配置还是要根据目标播放器和网络环境反复测试。8.4 不要忽视音频流的处理转码时很多人只关注视频流忽略了音频流。如果源视频的音频编码格式在目标播放器上不支持整个文件照样不能正常播放。最好根据目标平台统一音频格式比如使用AACffmpeg -hwaccel rkmpp -hwaccel_output_format drmmode \ -c:v hevc_rkmpp -i input.hevc \ -c:v h264_rkmpp -b:v 5M \ -c:a aac -b:a 128k \ -y output.mp4如果你的板子上没有编译AAC编码器考虑用-c:a copy保留原音频流但要注意原音频流是否兼容。8.5 容器格式的选择H.265转H.264后输出容器建议使用MP4或MKV。MP4兼容性最好适合推流和通用播放MKV适合本地点播支持更多字幕格式。如果你需要输出到RTSP/RTMP流FLV或TS格式更合适。转码之后再做封装格式转换不会引入视频质量损失算是性价比很高的优化手段。8.6 多路并发转码时的资源规划RK3588的VPU是共享硬件资源多路转码时总吞吐量有限。比如单路4K转1080p可能需要接近1/3的VPU能力同时跑3路就会比较吃紧。建议通过设置-threads参数限制每路FFmpeg的CPU线程数同时用nice提升关键任务的优先级避免多路互相干扰。我在实际做8路D1分辨率摄像头转码时走的就是MPP硬编硬解加RGA缩放的路子VPU占用率稳定在80%左右CPU占用不到10%整体系统还有余量做其他业务逻辑。这个结果和纯软解方案完全是两个世界。总而言之RK3588的MPP转码链路一旦搭好H.265到H.264这类常规转码任务基本就是常开不费电的状态。如果你手头正好有RK3588板子照这篇文章把环境搭起来拿自己的一段视频跑一遍对比你会明显感受到硬件转码和软件转码之间那道巨大的分水岭。