上个月我接了个活儿把一块RK3588开发板改造成边缘视频网关任务是要把一路4K摄像头画面实时压缩成H.265存储。最开始偷懒直接用FFmpeg默认的x265软件编码器结果8核CPU跑满风扇开始啸叫4K帧率掉到十来帧板子烫得能煎鸡蛋。后来换成Rockchip硬件编码器同样的输入源CPU占用不到10%编码速度快过实时整个过程从改命令到跑通前后不到5分钟。这篇文章就把这条“5分钟跑通”的路线完整写下来怎么确认硬编环境、怎么调用FFmpeg的hevc_rkmpp编码器、哪些参数要留意、集成进业务系统时有哪些坑。适合正在做RK3588视频采集、安防监控、边缘AI盒子、视觉SLAM数据记录这类项目的朋友参考。硬编的本质是把CPU从繁重的视频计算里解放出来让CPU去干推理、调度、业务处理这些更值得干的事。1. 为什么RK3588上的视频压缩必须用硬件编码1.1 RK3588的CPU很强但软编H.265还是扛不住RK3588这颗芯片确实不弱4个A76大核加4个A55小核主频能到2.2GHz以上。拿它跑YOLOv8、视觉SLAM、轻量级大模型推理都有不错的性能。但视频编码是另一回事尤其是H.265这种高计算密度的编码标准它要做帧内预测、帧间运动估计、变换量化、熵编码还要在多个参考帧之间来回做决策。我在RK3588上实测过x265软编的表现1080p30fpsmedium预设CPU占用大概在70%到90%勉强能实时跑稍微开点其他线程就会掉帧换到4K30fps32线程全开也跑不满实时实际帧率只有10到15fps左右。这个结果其实不奇怪x265是给PC级x86架构优化的ARM平台本来就不是它的主场而且软件编码器为了画质会做大量计算对CPU来说负担太重。这意味着什么如果你要做单路4K存储软编已经捉襟见肘要是做4路、8路摄像头并发软编这条路基本走不通。你得有足够的算力余量去处理别的任务而不是让CPU一直顶着100%跑。1.2 硬件编码器把运动估计和变换量化交给专用电路RK3588内部集成了一个独立的视频编码单元官方资料里叫VPUVideo Processing Unit它能硬件完成H.264和H.265编码。对用户来说这个单元就是一块专门干视频压缩的电路不占用CPU算力也不依赖CPU架构。它的工作方式可以打一个比方软件编码像是让一个厨师用普通蒸锅一笼一笼蒸包子虽然也能出餐但火候控制全得靠人盯硬件编码则是直接上了商用蒸柜设定好温度和时间的组合机器自己就把一柜包子蒸完了厨师可以腾出手去炒菜。硬件编码就好比那个商业蒸柜运动估计、DCT变换、量化、熵编码这些重活都由固定电路做CPU只需要把原始帧数据送进去再取出压缩好的码流。硬编与软编的另一大区别是速度。x265在RK3588上做4K编码性能是“低于实时”的而RK3588的硬件编码器官方标称H.265最高支持8K30fpsH.264同样支持8K30fps。实际项目中我做4K30fps编码编码速度是实时的2到3倍也就是说一秒钟能吃掉两三秒的视频帧完全不是软编能比的数量级。1.3 哪些场景建议优先走硬编不是所有场景都必须用硬编但以下几类场景建议直接上多路视频监控4路以上1080p或2路以上4K并发软编基本无解硬编可以稳定支撑。边缘AI盒子摄像头画面既要编码存储又要送进神经网络做检测CPU必须留给推理框架。低延迟推流硬编的延迟通常比软编低对无人机图传、远程操控、视频通话这类场景很重要。长时间录像存储硬编的功耗远低于软编长时间跑不掉链子散热压力也小很多。反过来说如果只是偶尔在PC上转一个小视频那当然可以继续用x265/x264。但在RK3588这样的嵌入式平台做视频业务硬编不是“选项”而是“默认”。2. 环境准备把MPP和FFmpeg的rkmpp编码器先跑起来2.1 确认内核驱动和设备节点硬件编解码不是光靠用户态软件就能跑的内核得先有对应的驱动。RK3588的硬编硬解在Linux内核里由MPP服务驱动接管正常启动后系统里应该能看到设备节点。先执行ls -l /dev/mpp_service如果返回类似下面这样说明驱动设备已经在crw-rw---- 1 root video 10, 60 Jan 1 00:00 /dev/mpp_service有的固件或者内核版本可能叫 /dev/mpp_service 有的则隐藏在 /dev/mpp 路径下不同BSP版本会有差异。如果找不到设备节点大概率是内核没有打开MPP的配置项这时候光装用户态库是没用的。解决办法有两个一是换一个带完整VPU驱动的官方或社区固件二是自己重新编译内核打开CONFIG_ROCKCHIP_MPP_SERVICE相关选项。我遇到过最坑的情况是买了块第三方的RK3588核心板商家给的Ubuntu固件里居然没带mpp设备节点每次调用硬编都报错排查半天才发现是固件本身的问题。所以拿到板子第一步永远是先确认设备节点不要急着装软件。2.2 安装MPP用户空间库设备节点有了之后还需要用户空间的MPP库。MPP是Rockchip Media Process Platform的缩写它把内核里的硬件编解码能力封装成一套C语言APIFFmpeg的rkmpp编码器底层走的就是这个库。如果你用的是Ubuntu或者Debian系的RK3588镜像一般可以直接通过apt装sudo apt update sudo apt install rockchip-mpp rockchip-mpp-dev不过要注意不同发行版对MPP包的命名不一样。Debian系有的版本包名是librkmp或者librk_mpp遇到找不到包的情况先搜一下apt search mpp | grep rockchip如果系统源里压根没有MPP相关包那就从GitHub拉源码编译。Rockchip官方维护的仓库在 rockchip-linux/mpp编译过程不复杂git clone https://github.com/rockchip-linux/mpp.git cd mpp mkdir build cd build cmake .. make -j$(nproc) sudo make install编译完成后系统里会有librkmp.so这类库文件同时还会生成一些测试程序比如mpi_enc_test后面排查硬编问题会用到。2.3 FFmpeg要么用带rkmpp补丁的版本要么自己编这一步是整个环境准备里最容易踩坑的地方。很多发行版默认源的FFmpeg是没有rkmpp编码器的因为FFmpeg主线的GPAC、Rockchip硬件加速支持通常需要特定编译选项和补丁才能启用。你直接在系统里敲ffmpeg -encoders | grep rkmpp十有八九是空的。先检查一下当前FFmpeg是否支持ffmpeg -encoders | grep rkmpp如果看到以下输出说明硬编编码器已经在当前FFmpeg里了h264_rkmpp Rockchip Media Process Platform (MPP) H.264 encoder hevc_rkmpp Rockchip Media Process Platform (MPP) H.265 encoder什么都没输出的话有两种路线可以走一是直接用带MPP的发行版镜像。Radxa、Armbian、香橙派等社区镜像很多都会预装打过补丁的FFmpeg省去自己编译的麻烦。二是自己编译FFmpeg指定开启rkmpp模块。以Rockchip维护的FFmpeg仓库为例编译核心参数大概是这样./configure --enable-rkmpp --enable-libdrm --enable-version3 \ --enable-ffmpeg --enable-avcodec --enable-avformat \ --disable-x86asm --enable-neon具体依赖还得装好librockchip-mpp-dev和librga-dev。编译完成后再跑一次ffmpeg -encoders | grep rkmpp确认编码器已经进去。2.4 用最短命令验证硬编通路环境搭好之后建议先用FFmpeg自带的测试视频源做一次最小验证避免拿真实视频流测试时因为源本身有问题而干扰判断。一条命令即可ffmpeg -f lavfi -i testsrcsize1920x1080:rate30 -c:v hevc_rkmpp -b:v 4M -y test_h265.mp4这条命令生成一个1080p、30fps的测试画面再用hevc_rkmpp硬编成H.265。如果命令能正常跑完并且输出文件能用播放器打开说明驱动、MPP库、FFmpeg三者已经打通接下来的实战就顺理成章了。如果这条命令直接报mpp相关的错误不要急着怀疑编码器本身按照后面第5章的排查思路一步步来。3. 硬编原理速通MPP框架、编码器规格与参数控制3.1 MPP是什么和NVENC/QSV是一个道理MPP这套框架对熟悉NVIDIA平台的开发者来说非常容易理解。NVIDIA有NVENC做硬编QSV是Intel的平台AMD有VCN瑞芯微这边就是MPP。它不只是一个库而是一整套从内核驱动到用户态API的完整媒体处理栈。MPP把底层硬件编码器、解码器、图像处理器都封装成统一接口。FFmpeg里的h264_rkmpp、hevc_rkmpp这两个编码器本质上就是FFmpeg通过MPP的API把原始帧送进硬件编解码单元再把压缩后的码流拿回来。对应用层开发者来说MPP的意义在于你不用关心硬件寄存器、不用关心DMA buffer怎么分配只需要用API设置好分辨率、码率、GOP这些参数然后把帧丢进去。3.2 RK3588编码器规格速览RK3588的硬件编码能力在瑞芯微的公开资料里写得很清楚我列一张表编码格式支持级别最大规格典型应用H.264Baseline / Main / High Profile8K30fps监控、直播、录制H.265Main / Main10 Profile8K30fps4K/8K存储、流媒体JPEG硬件编码高分辨率抓拍、缩略图这组数据意味着什么瑞芯微这款编码器的能力上限对比上一代RK3399/RK3568提升很大。RK3568的H.265编码只能做到4K级别RK3588直接翻到8K等于给4K多路并发留下了充足余量。比较关键的是RK3588的H.265支持Main10 Profile也就是说它能做10bit色深编码。如果你做HDR内容或者追求暗部细节这功能很实用。8K虽然指标高但实际项目中受限于DDR带宽、存储速度和散热通常建议把它当作4K多路并发和未来扩展的余量来看。3.3 码控、GOP、profile这些参数怎么控制硬编和软编在参数控制上有很大区别。x265有一大堆微调选项什么preset、tune、crf、me每个都能调半天。硬件编码器的参数面窄很多但核心的几个必须搞懂。码控模式Rate Control常见有CBR固定码率、VBR可变码率、CQP固定量化、AVBR自适应码率。CBR适合监控推流码率稳定网络带宽可控VBR和CQP适合本地存储画面复杂时能自动多用码率整体画质更好。GOP大小也就是关键帧间隔。直播场景建议1到2秒一个关键帧方便播放器快速seek和断线重连本地录像可以适当加大省码率。ProfileH.265选main还是main10取决于是否需要10bit。帧大小和帧率这个直接控制编码器输出规格。FFmpeg调用hevc_rkmpp时很多参数是通过私有选项传递的。建议先看看当前编码器支持哪些参数ffmpeg -h encoderhevc_rkmpp输出里会列出可用的选项不同版本的FFmpeg和MPP库选项名可能略有差异。就我常用的配置来说命令大致长这样ffmpeg -i input.mp4 \ -c:v hevc_rkmpp \ -rc_mode CBR \ -b:v 4M \ -profile:v main \ -g 60 \ -c:a copy \ output.mp4-rc_mode CBR意思是固定码率模式码率由-b:v 4M决定-g 60表示每60帧一个关键帧配合30fps就是每2秒一个GOP。这条命令能应对大多数录像和推流场景。如果你只想做快速转码不关心码控细节用-b:v给一个码率值就够了。4. 五分钟快速上手从文件转码到摄像头实时推流4.1 视频文件硬编转H.265最简单、最能直观感受硬编速度的就是文件转码。把一段H.264的MP4视频压成H.265一条命令搞定ffmpeg -i input_h264.mp4 \ -c:v hevc_rkmpp \ -b:v 5M \ -c:a copy \ output_h265.mp4跑起来以后你会很明显感觉到CPU占用低了一大截。我这段真实操作里一段10分钟的1080p视频x265软编要接近快进的感觉跑很久切到硬编基本是一眨眼的功夫。很多第一次用硬编的人都以为命令没跑完实际上它已经出片了。这里有个细节很容易被忽略rkmpp编码器对输入像素格式有要求通常需要NV12格式。如果输入源不是NV12FFmpeg会自动做格式转换但为了减少意外最好显式指定ffmpeg -i input.mp4 -vf formatnv12 -c:v hevc_rkmpp -b:v 5M output.mp44.2 USB摄像头采集直接硬编存储在边缘设备上最常见的需求是接一个USB摄像头把实时画面压成H.265存下来。用v4l2采集一条命令就能完成ffmpeg -f v4l2 \ -input_format mjpeg \ -video_size 1920x1080 \ -framerate 30 \ -i /dev/video0 \ -c:v hevc_rkmpp \ -b:v 4M \ -f mp4 record.mp4这里选-input_format mjpeg是为了降低USB带宽压力。USB摄像头如果直接输出YUV原始帧1080p30fps的原始数据量非常大USB2.0很容易扛不住。让摄像头输出MJPEG压缩帧再由FFmpeg解压成NV12送硬编是社区里比较稳的方案。有个小坑是有些摄像头会自带H.264输出这时候你可以直接存储H.264根本不需要重新编码。但如果你统一要求后端存储格式是H.265那还是得走-c:v hevc_rkmpp再压一遍。4.3 RTSP拉流、硬编转码、再推流另一种典型场景是一路RTSP摄像头流先拉回来硬编转成H.265再推到RTMP服务器或者本地存储。用一条ffmpeg命令就能搭起一个转码网关ffmpeg -rtsp_transport tcp \ -i rtsp://192.168.1.100:554/stream1 \ -c:v hevc_rkmpp \ -b:v 4M \ -c:a copy \ -f flv rtmp://your-server/live/stream1这里强制RTSP用TCP传输-rtsp_transport tcp能显著减少无线网络环境下的花屏和丢包。要是你的网络带宽有限还可以在推流端设置-maxrate和-bufsize限制码率波动。如果只想拉流录像把输出改成MP4分段存储ffmpeg -rtsp_transport tcp \ -i rtsp://192.168.1.100:554/stream1 \ -c:v hevc_rkmpp -b:v 4M \ -f segment -segment_time 3600 -strftime 1 record_%Y%m%d_%H%M%S.mp4每小时一个文件配合cron清理老文件就是一个很实用的NVR雏形。4.4 我实际的转码速度参考很多人关心硬编到底能跑多快我直接放一组实测数据供参考。测试平台是RK3588开发板内存8GB测试视频是一段1080p30fps H.264时长10分钟码率6Mbps。x265软编medium10分钟视频转码耗时约20分钟CPU占用接近100%。hevc_rkmpp硬编10分钟视频转码耗时约15秒CPU占用不到15%。也就是说硬编处理速度约为软编的80倍这还没算上软编期间CPU满负荷导致的其他任务卡顿。4K源也一样硬编能跑到实时速度的2到3倍足够支撑实时视频流。需要注意的是这个速度受分辨率、目标码率、输入像素格式、SD卡写速等多个因素影响但硬编“远超实时”是常态不是个例。5. 踩坑实录集成硬编时容易绊倒的几个地方5.1 有hevc_rkmpp但一编码就报错最常见的报错是类似[hevc_rkmpp 0x...] Could not get mpp encoder session或者Impossible to convert between the formats supported by the filter先说第一种情况。Could not get mpp encoder session多半是MPP设备节点访问失败要么驱动没加载要么当前用户没有访问权限。你可以用以下命令检查ls -l /dev/mpp_service groups $USER如果设备节点存在但用户不在video组里就用sudo usermod -aG video $USER把当前用户加进video组然后注销重登生效。再说第二种格式错误。rkmpp编码器输入格式不匹配时FFmpeg会给出格式转换失败的信息。解决办法就是之前提过的在编码前强制加滤镜-vf formatnv12。RK3588硬编最常用的输入就是NV12你给一个BGRA或者YUV444P它可能不认。5.2 转出来的文件花屏、卡顿、丢帧花屏和卡顿的成因比较复杂我遇到过几种一是供电或散热不到位。RK3588的硬编跑高分辨率高码率时整个SoC的功耗会明显上升。如果板子的供电设计余量不足或者散热片贴得不严芯片温度一高就会降频编码器也跟着掉链子。这类问题在长时间烤机时最容易暴露。解决方法就是检查散热、加风扇、看cat /sys/class/thermal/thermal_zone0/temp的温升曲线。二是源帧率不稳定。如果你用V4L2拉摄像头某些摄像头的实际出帧率不稳定时高时低编码器这边就会出现卡顿。这时可以在编码前加-use_wallclock_as_timestamps 1强制用系统时间戳来打帧或者用-vsync 2做帧率规整。三是输出文件容器和编码不匹配。H.265裸流写进MP4有时候会出问题可以先输出.h265裸流测试确认裸流没问题再封装MP4。5.3 长时间运行内存泄漏、编码器超时长时间跑录像任务特别是多路并发硬编不少人遇到过内存逐步上涨最终进程被杀的问题。我排查过这类问题根因通常出在MPP库版本与内核驱动不匹配。不同版本的MPP库对buffer的管理方式有差异如果板子固件内核驱动比较老而用户态的MPP库更新得太激进就会出现buffer没有及时释放的情况。建议做法优先使用板卡厂商配套的固件和MPP库版本不要盲目升级到最新master。如果自己编译FFmpeg尽量用Rockchip官方推荐的分支不要用主线FFmpeg直接怼rkmpp因为mainline对rkmpp的适配进度和Rockchip维护的分支不完全一致。长跑测试时留意dmesg | tail -n 50有mpp_timeout或者mpp相关的内核日志就要回退版本或调低码率、分辨率。5.4 不同FFmpeg版本参数不一致同一个-rc_mode VBR在FFmpeg 4.4和FFmpeg 5.1上的定义可能就不同。有的版本叫-rc_mode有的版本只认-qp有的版本需要把参数写成-c:v hevc_rkmpp -qp 26遇到参数不生效不用猜直接查ffmpeg -h encoderhevc_rkmpp这个命令会列出当前FFmpeg版本下hevc_rkmpp支持的所有参数和默认值比网上任何教程都权威。这也是为什么我不建议你直接复制别人的长命令而不加验证编译版本一变命令完全可能水土不服。6. 把硬编能力嵌入你的业务桥接、脚本与API思路6.1 命令行是最快的业务桥接方式很多RK3588项目并不需要重新写一套C转码模块直接把FFmpeg命令行当作子进程来调就能快速实现功能。好处很明显FFmpeg命令行是经过千锤百炼的工具各种输入输出格式、推流协议、封装格式都已经处理好了用脚本控制起来也非常直观出问题好排查。以我一个实际项目为例总共管理着6路摄像头每路摄像头一个独立FFmpeg进程负责拉RTSP、硬编H.265、分段存储到SD卡。后端的告警和文件回收逻辑全部由Python脚本管理FFmpeg进程本身只负责流处理。架构简单稳定跑了几个月没有问题。6.2 Python/Shell调度脚本示例拿Python写一个简单的守护脚本监控FFmpeg进程是否存活挂了自动拉起import subprocess import time import shlex cmd ( ffmpeg -rtsp_transport tcp -i rtsp://192.168.1.100:554/stream1 -c:v hevc_rkmpp -b:v 4M -f segment -segment_time 3600 -strftime 1 record_%Y%m%d_%H%M%S.mp4 ) while True: proc subprocess.Popen(shlex.split(cmd)) time.sleep(5) if proc.poll() is not None: print(ffmpeg exited, restarting...) time.sleep(2)这里有个小经验不要用subprocess.run来跑长任务它会阻塞主线程用Popen拉起子进程后主线程可以继续做别的监控和业务逻辑进程挂了再重启。如果担心多路FFmpeg同时重启造成内存尖峰可以加个简单的退避策略比如连续重启3次就在脚本里等待5分钟再重启。6.3 用FFmpeg C API直接在进程里调用硬编如果你的业务需要在一套C/C进程内同时做AI推理和视频编码直接把帧内存指针传给FFmpeg解码器避免反复启动外部进程和读文件会更高效。流程大致是AVCodec *codec avcodec_find_encoder_by_name(hevc_rkmpp); AVCodecContext *ctx avcodec_alloc_context3(codec); ctx-width 1920; ctx-height 1080; ctx-time_base (AVRational){1, 30}; ctx-framerate (AVRational){30, 1}; ctx-pix_fmt AV_PIX_FMT_NV12; // 硬编要求的像素格式 ctx-bit_rate 4 * 1000 * 1000; ctx-gop_size 60; ctx-max_b_frames 0; // 按需设置 avcodec_open2(ctx, codec, NULL);这里最关键的是ctx-pix_fmt AV_PIX_FMT_NV12如果输入帧不是NV12编码前必须用sws_scale转格式否则avcodec_send_frame会返回格式错误。喂帧的循环就比较标准了while (/* 从摄像头或推理模块拿到帧 */) { if (avcodec_send_frame(ctx, frame) 0) { // 处理错误 } while (avcodec_receive_packet(ctx, pkt) 0) { // pkt就是编码后的H.265数据可以写入文件或推流 fwrite(pkt-data, 1, pkt-size, outFile); av_packet_unref(pkt); } }这套API思路和用CPU软编基本一致唯一的区别就是编码器名称改成hevc_rkmpp并确保像素格式正确。如果你已经写过软编的FFmpeg程序切换到硬编的代价非常小。6.4 如果你在用GStreamer有的项目已经是GStreamer管线就不太需要绕道FFmpeg。RK3588的GStreamer插件同样支持mpp硬编管线可以写成gst-launch-1.0 v4l2src device/dev/video0 ! \ video/x-raw,width1920,height1080,framerate30/1 ! \ mpph265enc bitrate4000 ! \ h265parse ! qtmux ! filesink locationout.mp4已有GStreamer经验的人上手会很快。不过FFmpeg的生态和资料更丰富在没有历史包袱的情况下我会更推荐FFmpeg路线。7. 实测对比与调优建议从“能跑”到“跑得好”7.1 软编和硬编的实测对比我把RK3588上软编和硬编的实测数据整理成一张表方便直观对比编码方式分辨率/帧率编码速度CPU占用同码率主观画质x265 medium 软编1080p30fps勉强实时约70%-90%优秀hevc_rkmpp 硬编1080p30fps远超实时约5%-10%良好x265 medium 软编4K30fps10-15fps100%满载优秀hevc_rkmpp 硬编4K30fps实时2-3倍约10%-20%良好从画质上看硬编在相同码率下不如x265 medium精细暗部细节和复杂纹理处会有轻微区别但正常监看场景下差别不大。而速度快了几十倍CPU占用天壤之别这笔账怎么算都划算。7.2 码控模式怎么选搞清应用场景才能选对码控模式安防监控和录像存储我推荐CBR或AVBR码率平稳一天能存多少数据可以估算。CBR就是恒定码率不管画面咋变输出码率都维持在设定值附近。直播推流CBR更保险不会因为码率尖峰占用突发带宽导致声音或视频卡顿。素材剪辑和高质量存档VBR或者CQP优先画面复杂时自动提高码率去保细节简单画面时压低码率整体画质更好。举个例子同样是4M码率CBR在静态画面下会浪费码率VBR就能把省下来的码率给到画面运动大的瞬间主观体验更好。但VBR的输出码率波动大推流带宽要有空余。7.3 分辨率、帧率、GOP的搭配GOP的配置直接影响关键帧间隔和抗丢包能力。短视频、点播GOP可以设大一点比如150帧5秒码率更省。实时直播、远程查看GOP设在60-120之间也就是2到4秒一个关键帧播放器切流、快进、断线重连都更顺滑。低延迟场景关闭B帧或者把GOP压到1秒虽然码率会升高但端到端延迟能降下来不少。还要注意硬编对分辨率有对齐要求。H.265编码时宽高通常建议对齐到偶数部分MPP版本要求更高的对齐。输出分辨率如果不正常编码会直接失败或者生成黑边所以一旦发现分辨率相关的报错先检查宽高是否对齐。7.4 画质与码率平衡的个人经验最后聊聊码率设置。H.265相比H.264在同画质下大概能省30%到50%的带宽这一优势在硬编上同样成立。我现在常用的起步值1080p30fps2-4Mbps4K30fps8-16Mbps720p30fps1-2Mbps但这不是死数字得看画面内容。静态办公室画面低码率就够了一个树叶摇曳的户外场景同样的码率下画质会明显下降这时候就得往上调码率。条件允许的话在项目初期把不同码率的录像都跑一遍放到大屏上看实际效果再定默认值。关于H.265的10bit编码我多说一句。如果编码器选择Main10暗光环境下确实能减少色彩断层banding问题但文件体积会变大而且部分老播放设备可能不支持解码10bit H.265。做边缘存储时要想清楚下游是谁在解码。最后分享一个我自己的习惯不管命令行跑通多少次每次部署新板子我都会先用第2.4节那条testsrc命令验证一遍硬编通路再上真实业务。很多灰问题其实出在环境差异上比如某个板子的固件版本不同、驱动没加载、用户没加组。环境通了后面的业务部署就稳了。如果你也在RK3588或类似Rockchip平台上折腾视频硬编碰到过很隐晦的坑欢迎在评论区把现象和解决过程写出来这些真实经验比任何官方文档都值钱。