最近在搞RK3588平台的视频处理板卡手头的活儿是把FFmpeg完整跑起来还要支持RTSP推流和拉流。最早我也想着直接用apt装一个完事儿但实际落地时就发现不行——板子上的Ubuntu镜像裁剪得厉害官方仓库的FFmpeg版本旧不说x264、x265这些扩展库一个都没有更别提调用RK3588自带的硬件编解码单元了。没辙只能老老实实从源码做交叉编译然后一步步把整个流媒体链路打通。这篇内容算是对这次移植过程的一个完整记录从交叉编译工具链怎么选到依赖库怎么一个个编过去再到FFmpeg本体如何配置、板子上怎么部署、RTSP怎么测试。其中还穿插了我在实际踩坑中整理的排查思路和性能调优经验。如果你刚好也在折腾RK3588、RK3576这类ARM平台想把FFmpeg跑起来做视频流处理这篇文章应该能帮你省不少时间。1. 项目背景与整体移植思路1.1 为什么不直接用apt安装FFmpeg这是很多人一开始会问的问题。说实话如果只是简单地在板子上跑一条ffmpeg -version看看输出apt安装确实够用。一旦你开始接真实业务问题就全暴露出来了仓库版本滞后常用的filter和协议支持不完整比如某些H.265的扩展参数、SRT协议可能压根没编译进去无法整合自有业务代码像我要在一个C服务里通过libavcodec直接做硬编码apt版本根本不带RK3588的硬件编解码插件交叉编译的产物可以很方便地放进rootfs或SD卡系统镜像里批量烧录部署而apt安装适合单板调试不适合产线复制。所以本次移植的目标就定成从源码交叉编译出FFmpeg可执行程序和开发库让它在RK3588板子上能跑通软编软解、能通过libx264做H.264编码、能借助Rockchip MPP和V4L2接口调用硬件编解码最后用RTSP推流和拉流来做端到端验证。1.2 整个移植链路的关键阶段整个过程可以拆成五个阶段每个阶段之间是严格依赖的交叉编译工具链准备与验证FFmpeg依赖库交叉编译重点x264、x265、opus等FFmpeg本体交叉编译与安装部署到RK3588目标板做基础运行验证RTSP推拉流测试及性能调优。我当时卡得最久的是第一阶段和第二阶段尤其是pkg-config的变量设置稍不留神就会让configure误判依赖库的存在。后面详细说。2. 交叉编译工具链选型、安装与验证2.1 工具链选择系统自带交叉编译器还是SDK工具链RK3588是64位的ARMv8架构交叉编译最简单的方式是直接装Ubuntu自带的GCC交叉编译器sudo apt install gcc-aarch64-linux-gnu g-aarch64-linux-gnu装完以后aarch64-linux-gnu-gcc就能用了。这适合快速验证、编一些通用工具。不过我实际使用后发现如果编出来要在Rockchip官方SDK的rootfs里跑或者要用到比较新的C库特性时Ubuntu自带的这个交叉编译器版本可能跟目标系统C库存在微小差异偶尔会在链接时冒出一些警告甚至运行动态链接错误。所以我更推荐使用Rockchip SDK自带的工具链。下载SDK后在prebuilts/gcc/linux-x86/aarch64/目录下能找到例如gcc-arm-10.3-x86_64-aarch64-none-linux-gnu这样的版本。这类工具链针对Rockchip的BSP做过验证编出来和SDK里的rootfs兼容性更好。无论用哪种都要在~/.bashrc里把工具链的bin目录加到PATH最前面避免与系统自带的aarch64编译器冲突。2.2 工具链安装与基础验证我这里以SDK工具链为例整理一下完整流程# 解压工具链到opt目录 sudo tar -xvf gcc-arm-10.3-x86_64-aarch64-none-linux-gnu.tar.xz -C /opt/ # 设置环境变量 export PATH/opt/gcc-arm-10.3-x86_64-aarch64-none-linux-gnu/bin:$PATH export CROSSaarch64-none-linux-gnu # 验证版本 $CROSS-gcc -v验证编译最简单的办法是写一段hello.c交叉编译后在板子上跑#include stdio.h int main(void) { printf(hello rk3588, cross ok!\n); return 0; }编译并检查架构类型$CROSS-gcc hello.c -o hello file hello # 输出里应包含 ELF 64-bit LSB executable, ARM aarch64把hello传到板子上执行看到输出就说明工具链基本没问题。这一步虽然简单但它能一次性排除“工具链路径不对、架构选错、动态库链接失败”等好几个基础问题。2.3 架构参数PKG_CONFIG环境变量的规划交叉编译FFmpeg时pkg-config是个关键工具。它负责在configure阶段找到依赖库的头文件和库文件位置。如果环境变量设置错了编译时会报“libx264 not found”之类的错误而实际上x264已经编好了只是pkg-config根本没去找它。这里我建议在做依赖库之前先把环境变量规划好统一放到一个环境脚本里比如我习惯建一个env_rk3588_ffmpeg.shexport CROSSaarch64-none-linux-gnu export TOOLCHAIN_PATH/opt/gcc-arm-10.3-x86_64-aarch64-none-linux-gnu export SYSROOT$TOOLCHAIN_PATH/aarch64-none-linux-gnu export PATH$TOOLCHAIN_PATH/bin:$PATH export PREFIX$HOME/rk3588_ffmpeg_install export PKG_CONFIG_PATH$PREFIX/lib/pkgconfig export PKG_CONFIG_LIBDIR$PREFIX/lib/pkgconfig export PKG_CONFIG_SYSROOT_DIR$PREFIX这个脚本的核心思想是所有交叉编译出来的依赖库都装到统一的$PREFIX目录下pkg-config只在这个目录里找.pc文件。后面编x264、x265、FFmpeg时都source这个脚本路径问题一次性全解决。3. FFmpeg核心依赖库的交叉编译3.1 依赖库选型确定需要哪些扩展FFmpeg本身是一个框架要让它具备实际业务能力就得围绕需要选择外部库。我这里按用途分了三类编码与转码libx264、libx265这是最常见的H.264/H.265软件编码库音频处理libopus、libmp3lame用于音频编码硬件编解码与采集RK3588平台上主要依赖V4L2接口和Rockchip MPPFFmpeg源码已经自带v4l2 m2m的编解码封装不需要额外编第三方库但需要确保内核驱动和头文件版本匹配。还有一类是libsrt、libsrtp这类流媒体传输库用来扩展传输协议我这阶段没有编等项目后期需要SRT协议再补。3.2 编译libx264libx264的编译相对简单因为它不依赖其他库。从官网或GitHub拉代码后这样操作git clone https://code.videolan.org/videolan/x264.git cd x264 export PATH/opt/gcc-arm-10.3-x86_64-aarch64-none-linux-gnu/bin:$PATH ./configure --prefix$PREFIX --hostaarch64-none-linux-gnu --enable-static --cross-prefixaarch64-none-linux-gnu- --disable-cli make -j$(nproc) make install重点说两个参数--enable-static建议静态编库运行时就不用把一堆.so拷到板子上省去动态库依赖匹配的麻烦--disable-cli不生成x264命令行工具只要库文件编起来更快。编完之后可以去$PREFIX/lib/pkgconfig里确认有没有x264.pc。如果没有这个文件后面FFmpeg configure一定会报找不到x264。正常编完都会有可以这样检查cat $PREFIX/lib/pkgconfig/x264.pc # 应能看到 Libs和Cflags指向$PREFIX目录3.3 编译libx265x265的编译比x264麻烦一些它的构建系统基于CMake还要分12bit、10bit、8bit的库版本。RK3588上如果没有特殊的10bit需求编默认8bit版就够了。操作流程git clone https://bitbucket.org/multicoreware/x265_git.git cd x265_git/build/linux export PATH/opt/gcc-arm-10.3-x86_64-aarch64-none-linux-gnu/bin:$PATH cmake -DCMAKE_TOOLCHAIN_FILE../../../cmake/toolchains/aarch64-linux-gnu.cmake \ -DCMAKE_INSTALL_PREFIX$PREFIX \ -DENABLE_SHAREDOFF \ -DENABLE_CLIOFF \ ../../source make -j$(nproc) make install这里的重点是CMAKE_TOOLCHAIN_FILE。FFmpeg的交叉编译可以用环境变量直接指定编译器但CMake工程通常需要toolchain file来告诉它完整的交叉编译环境包括编译器、链接器、sysroot路径。不同版本的x265仓库toolchain文件路径可能略有变化找不到就自己新建一个内容核心是set(CMAKE_SYSTEM_NAME Linux) set(CMAKE_SYSTEM_PROCESSOR arm64) set(CMAKE_C_COMPILER aarch64-none-linux-gnu-gcc) set(CMAKE_CXX_COMPILER aarch64-none-linux-gnu-g)如果你只做H.264的RTSP流x265可以暂时不编但建议还是一起编上后面做H.265推流、测试RK3588硬编性能对比时都用得上。3.4 其他常见扩展库的编译注意点opus音频编解码库在语音对讲场景比较常用编译命令git clone https://github.com/xiph/opus.git cd opus ./autogen.sh ./configure --prefix$PREFIX --hostaarch64-none-linux-gnu --disable-shared --enable-static make -j$(nproc) make install这个库一般一次能过。需要注意的一点是autogen.sh要在宿主机上执行它会生成configure脚本交叉编译时不需要宿主机编译源码。如果还需要MP3编码可以编lame它是单C文件库交叉编译更加简单。不过arm平台下lame对NEON优化支持一般测试下来编码性能不如直接用AAC。4. FFmpeg本体交叉编译configure参数与编译细节4.1 获取源码与解压FFmpeg官方Git仓库地址是https://git.ffmpeg.org/ffmpeg.gitGitHub上的镜像也可以拉。版本建议选择4.4.x或者6.x以上的release分支这两个固件上测试比较多社区问题也好搜。我这里用的是FFmpeg 6.0对V4L2 m2m的支持已经比较成熟。wget https://ffmpeg.org/releases/ffmpeg-6.0.tar.xz tar -xvf ffmpeg-6.0.tar.xz cd ffmpeg-6.0拉Git仓库也可以但release tar包更稳不会有中间commit引起的编译问题。4.2 configure参数详细说明这是整个移植过程的关键。我第一次配置时漏了--pkg-config-flags--static这个参数导致编译链接阶段始终找不到静态库的依赖链折腾了半天。最终使用的config命令如下source ~/env_rk3588_ffmpeg.sh ./configure \ --prefix$PREFIX \ --target-oslinux \ --archaarch64 \ --enable-cross-compile \ --cross-prefixaarch64-none-linux-gnu- \ --pkg-configpkg-config \ --pkg-config-flags--static \ --enable-gpl \ --enable-nonfree \ --enable-libx264 \ --enable-libx265 \ --enable-libopus \ --enable-libv4l2 \ --enable-static \ --disable-shared \ --disable-doc \ --disable-debug逐个解释关键参数--target-oslinux目标系统类型FFmpeg需要根据这个参数决定一些平台相关的封装逻辑--archaarch64目标CPU架构。如果工具链是64位的ARM必须明确写成aarch64写成arm会导致生成32位代码或编译失败--enable-cross-compile告诉configure这是交叉编译环境不要尝试在宿主机运行测试程序--enable-libx264等启用外部解码库配套需要有前面编好的.pc文件--enable-libv4l2启用V4L2用户空间API库这是FFmpeg调用RK3588硬件编解码的关键接口--enable-static --disable-shared全部静态连接得到单文件二进制方便部署到板子--pkg-config-flags--static让pkg-config静态模式下把依赖库的Libs.private字段也带上否则链接时容易出现undefined reference错误。配置成功后configure末尾会打印一份编译选项汇总这时候建议仔细看一下Codecs、Encoders、Decoders列表里有没有h264_v4l2m2m、hevc_v4l2m2m等硬件编解码模块。如果只看x264后面硬编基本没法玩。4.3 编译与常见编译错误configure通过后就是编译安装make -j$(nproc) make install编译过程中我遇到过几个报错速查如下报错信息原因解决办法ERROR: x264 not foundpkg-config路径不对或x264.pc缺失source环境脚本确认PKG_CONFIG_LIBDIR指向$PREFIX/lib/pkgconfigundefined reference to x264_encoder_open静态库链接顺序依赖问题configure加上--pkg-config-flags--staticlibavcodec/v4l2_m2m.c: No such file or directory内核头文件不匹配确认SDK工具链的sysroot里有linux/videodev2.h必要时从SDK内核源码复制include/uapi/linux到sysrootnasm not foundx86工具链缺少汇编器这是宿主机的nasm不是目标板编译直接apt install nasm编译完成后在$PREFIX/bin/下会生成ffmpeg、ffprobe、ffplay三个可执行文件。注意ffplay默认依赖SDL如果configure时没加--enable-sdl2可能不会生成ffplay。但我们是嵌入式板子不需要在板子上做窗口播放一般用ffprobe和ffmpeg就够了。想验证解码拉流可以用ffmpeg带-f null -的方式丢弃输出只测解码链路也可以把rtsp流转存成文件。5. 部署到RK3588板子与基础运行验证5.1 拷贝文件到目标板我这里是通过ADB把编译产物推送到板子如果你的开发环境是SSH用scp也可以命令如下adb push $PREFIX/bin/ffmpeg /userdata/ adb push $PREFIX/bin/ffprobe /userdata/ adb shell chmod x /userdata/ffmpeg因为采用静态编译ldd查看时几乎没有任何动态库依赖放到板子上直接就能跑。这一步出来的二进制在构建rootfs或批量刷机时非常方便。如果板子上不是Rockchip SDK的rootfs而是你自己定制的Ubuntu根文件系统工具链sysroot和运行环境的C库版本有差异时可能会出现运行时报version GLIBC_X.XX not found。遇到这种问题最好就直接改用Ubuntu的aarch64交叉编译器重编一版或者用SDK里配套的libc版本更低的工具链。5.2 基础验证版本信息与编码器列表先在板子上确认基础运行正常/userdata/ffmpeg -version # 输出应包含 ffmpeg version 6.0 ... configuration信息 /userdata/ffmpeg -encoders | grep 264能看到libx264和h264_v4l2m2m这两项就说明软编和硬编驱动都已经被FFmpeg识别。接着在板子上自己生成一段测试视频验证编码通路/userdata/ffmpeg -f lavfi -i testsrcduration5:size1280x720:rate30 \ -c:v libx264 -preset veryfast -b:v 2M test.mp4这条命令如果顺利跑完说明FFmpeg在板子上的基本运行环境没问题编码链路也能走通。返回的帧编码速度和fps数值可以作为后续性能调优的基线参考。5.3 测试RTSP拉流用FFmpeg直接解析RTSP流RK3588平台上最常遇到的场景是从IP摄像头拉流FFmpeg可以通过RTSP协议直接读取摄像头的流。命令如下/userdata/ffmpeg -rtsp_transport tcp -i rtsp://192.168.1.100:554/stream1 \ -c:v copy -c:a copy -f flv output.flv或者直接丢弃解码测试能不能正常拿到流/userdata/ffmpeg -rtsp_transport tcp -i rtsp://192.168.1.100:554/stream1 \ -f null -这里需要说明-rtsp_transport tcp这个参数。RTSP默认走UDP拉流但UDP在弱网环境丢包严重会出现花屏和马赛克。TCP虽然延迟稍微大一点点但稳定性好很多。在有线局域网内测试建议直接TCP优先。测试时如果卡在Opening rtsp://...这一步不动大多是网络不通或端口没开。可以先在板子上用ping和nc -vz 192.168.1.100 554排查连接问题。5.4 测试RTSP推流用FFmpeg把本地视频推给流媒体服务器推流测试需要有一个RTSP服务器作接收端。在RK3588板子上直接推流到服务器命令如下/userdata/ffmpeg -re -i /userdata/test.mp4 \ -c:v copy -c:a copy \ -f rtsp -rtsp_transport tcp rtsp://192.168.1.50:554/live/test这里面的-re参数很关键它的作用是让FFmpeg按视频原始帧率读取文件模拟实时推流。如果不加-reFFmpeg会以最快速度把文件推完服务器端看到的画面就会像快进一样。对RTSP这种实时流协议来说-re几乎是必选项。如果没有现成的RTSP服务器本地也可以临时搭一个轻量的mediamtx原rtsp-simple-server进程直接下载ARM64版本放到板子上跑几秒钟就能启动一个支持RTSP的server然后再用FFmpeg往它推流。这个组合在联调时特别方便。5.5 硬解码与硬编码验证纯软件编码在RK3588上其实性能也还行x264的veryfast编码1280x720视频能跑到几十帧但如果要处理4K流软编就很吃力了。这时候就需要调用RK3588的硬件编解码单元。FFmpeg在RK3588上调用硬编硬解有两条路子直接使用h264_v4l2m2m、hevc_v4l2m2m编码器/解码器。这是V4L2框架的m2m设备FFmpeg通过/dev/video*节点与内核驱动交互通过Rockchip的MPPMedia Process Platform库这条封装在社区版本FFmpeg里集成度不如V4L2高一般需要打补丁。我建议优先用V4L2 m2m路线它是主线FFmpeg自带的支持不需要额外补丁维护也省心。使用方式很简单# 硬编码 /userdata/ffmpeg -i input.yuv -c:v h264_v4l2m2m -b:v 4M output.h264 # 硬解码 /userdata/ffmpeg -c:v h264_v4l2m2m -i input.h264 -f null -特别注意h264_v4l2m2m对输入帧格式有要求一般需要NV12格式。如果你给的输入是YUV420P需要先用-pix_fmt nv12转换。这次移植测试时我在一条命令里同时加了-s 1920x1080 -pix_fmt nv12转格式再用硬件编码器编码效果好很多/userdata/ffmpeg -f lavfi -i testsrcduration5:size1920x1080:rate30 \ -pix_fmt nv12 -c:v h264_v4l2m2m -b:v 4M output.h264硬编的同时也可以配合RTSP直接做硬件编码后的RTSP推流/userdata/ffmpeg -re -i /userdata/test.mp4 \ -pix_fmt nv12 -c:v h264_v4l2m2m -b:v 4M \ -f rtsp -rtsp_transport tcp rtsp://192.168.1.50:554/live/hw这样就能验证一个典型场景解码或读取视频文件后由RK3588硬件编码器实时编码再通过RTSP推出去。整个链路的CPU占用比纯libx264低很多从top里能明显看到差别。6. RTSP流测试中的关键排查思路6.1 拉流花屏、绿屏与NALU异常RTSP拉流测试时最常遇到的就是画面花屏或者绿色条纹。很多时候第一反应是网络问题但实际排查下来RK3588平台更多是解码器格式不匹配导致的。常见原因之一是拉到的H.264流是High Profile的而板子上某些简化版解码器只支持到Main Profile。这时可以用ffprobe查看流编码信息/userdata/ffprobe -show_streams rtsp://192.168.1.100:554/stream1 \ | grep -A 5 codec_nameh264如果profile显示High可以尝试在解码前转成Main Profile。但RTSP拉流转码会引入延时更推荐确认播放器或解码API支持High Profile。常见原因之二是RTSP交互模式。UDP传输出错后I帧丢失会导致后续画面一直花屏直到下一个关键帧到达。解决方式是强制TCP模式以及使用-fflags nobuffer -flags low_delay这类低延迟参数/userdata/ffmpeg -rtsp_transport tcp -fflags nobuffer -flags low_delay \ -i rtsp://192.168.1.100:554/stream1 -f null -6.2 推流卡顿与时间戳问题推流端最常见的问题是推出去以后对端播放时画面一卡一卡的或者音画不同步。这里我总结出三个排查方向-re是否加了如果不加FFmpeg会以机器最大速度读取文件RTSP服务器收到的是大量突发帧播放端缓冲会被打乱-vsync和-fps_mode参数是否合理FFmpeg 6.0中-vsync已倾向于用-fps_mode替代推流时建议设置-fps_mode cfr保证输出帧率恒定TCP还是UDP如果推流到公网服务器UDP在弱网下会大量丢包推流端也建议改用TCP。举个例子一个比较稳定的推流命令如下/userdata/ffmpeg -re -stream_loop -1 -i /userdata/test.mp4 \ -fps_mode cfr -c:v copy \ -f rtsp -rtsp_transport tcp rtsp://192.168.1.50:554/live/loop这里-stream_loop -1让视频无限循环适合长时间稳定性测试。我实际让它跑了一整晚第二天早上检查时依然在推流内存和CPU占用都很平稳。6.3 板载mpp资源冲突RK3588的硬编硬解功能统一走VPUVideo Processing Unit如果同时多个进程在抢占硬编硬解会导致部分任务排队或失败。用V4L2 m2m的时候报错信息往往不直观。排查时可以查看板上有哪些进程占用了/dev/video*节点ls -l /dev/video* fuser -v /dev/video0如果业务上确实需要多路硬编解码并存需要确认RK3588的VPU实例数是否够用或者调整业务架构把部分编解码让给软件实现。这块是硬件资源规划的问题不是FFmpeg本身能解决的。6.4 网络带宽估算RTSP流测试时很多人容易忽略带宽问题。假设推的是1080p30 H.264 4Mbps码流实际网络传输还要加上RTSP/RTP头开销tcp模式下大概会占到5Mbps左右。在百兆网口的内网环境完全没问题但如果是多路同时推或者板子用的是Wi-Fi带宽就很容易成为瓶颈。可以用板上的工具看实时流量cat /proc/net/dev对比推流前后的eth0字节数增量就能估算出实际网络占用避免凭感觉判断网络是否够跑。7. 性能调优与后续扩展的一些经验7.1 看准编码器、分辨率和码率之间的平衡在RK3588上做RTSP推流编码器选择直接决定系统负载。实测下来1080p30的链路libx264medium预设编码CPU占用大约能占到4个大核中的1到2个核心h264_v4l2m2m硬编码CPU占用很低基本可以忽略编码开销如果只是做多路视频转发不强需求改编码尽量用-c:v copy直接透传完全不做编码CPU占用最低。我在实际项目中多路接入时基本都是“硬解硬编RTSP转发”的方式。RK3588的VPU对1080p的硬编硬解有足够余量但每路都软编就很容易打满CPU。硬编码率控制方面h264_v4l2m2m的码控精度相对于x264弱一些。如果你对视频体积或画质有严格要求建议让它输出较高码率再配合-maxrate限制峰值不要让它完全自动。我曾经设置-b:v 4M实际输出码率在3.5M到5.5M之间波动而libx264的码控稳定得多。7.2 用ffprobe快速验证RTSP链路的可行性调试RTSP时ffprobe是个非常好的排障工具。它可以快速打印流媒体信息而不用真正解码数据/userdata/ffprobe -rtsp_transport tcp -show_format -show_streams rtsp://192.168.1.100:554/stream1观察输出里的start_time、duration、nb_frames等信息能判断流是否稳定。如果start_time一直很小或者duration不断变化说明源端的推流不是标准实时流后端的播放器可能会受到影响。7.3 与YOLO等AI推理结合时的数据通路设计搜索热词里很多人也在问“RK3588部署yolov8”。这里简单提一个架构经验视频流处理链路最好是“RTSP拉流 - 硬解码 - 缩放/格式转换 - NPU推理 - 编码/推流”这样的流水线。FFmpeg在中间主要承担前段的拉流、解码和末端编码推流。RK3588的NPURKNN则负责推理。整个过程中图像格式流转要做到零拷贝或尽可能减少拷贝否则CPU内存带宽会成为瓶颈。如果只是简单地在FFmpeg解码后逐帧转成RGB再送NPU1080p下性能会损失很大。我自己目前的方案是通过V4L2 m2m解码后拿到DMABUF再通过RGA做格式转换直接把带FD的buffer传给RKNN。这条路代码复杂度高一些但性能收益明显。如果只是做验证原型其实用ffmpeg命令行拉流存文件再离线跑推理就够了。7.4 FFmpeg后续扩展的方向本次移植只是基础版本后续如果业务迭代很可能要补充加入SRT协议支持用于跨公网传输需要在编译时增加--enable-libsrt集成Rockchip MPP补丁获得更精细的硬件编解码控制比如帧率控制、RC模式选择社区和Rockchip的GitHub上都有相关patch加入SDL2重新编译ffplay在带显示器的板子上直接播放RTSP流做桌面端原型验证编译FFmpeg的Python绑定比如ffmpeg-python只是命令行封装如果要在Python里调用库函数需要额外考虑。每加一个新模块都要回到第4章的configure流程把对应的--enable-xxx加上然后重新编译、重新部署。好在基础的依赖库和交叉编译环境都搭好了加模块只是重复走一遍configure和make的流程并不会很复杂。编译这版FFmpeg前前后后花了两三天中间踩过pkg-config的坑、踩过工具链sysroot不匹配的坑、也踩过硬编码格式不对导致全绿屏的坑。现在把工具链、依赖库和编译参数固定下来之后后续重新出一版只是跑几条命令的事。RK3588本身性能很强把FFmpeg这层基础设施打好后面做多路视频接入、AI视频分析、流媒体网关都会顺利很多。 RK3588平台FFmpeg交叉编译与RTSP推流实践指南
最近在搞RK3588平台的视频处理板卡手头的活儿是把FFmpeg完整跑起来还要支持RTSP推流和拉流。最早我也想着直接用apt装一个完事儿但实际落地时就发现不行——板子上的Ubuntu镜像裁剪得厉害官方仓库的FFmpeg版本旧不说x264、x265这些扩展库一个都没有更别提调用RK3588自带的硬件编解码单元了。没辙只能老老实实从源码做交叉编译然后一步步把整个流媒体链路打通。这篇内容算是对这次移植过程的一个完整记录从交叉编译工具链怎么选到依赖库怎么一个个编过去再到FFmpeg本体如何配置、板子上怎么部署、RTSP怎么测试。其中还穿插了我在实际踩坑中整理的排查思路和性能调优经验。如果你刚好也在折腾RK3588、RK3576这类ARM平台想把FFmpeg跑起来做视频流处理这篇文章应该能帮你省不少时间。1. 项目背景与整体移植思路1.1 为什么不直接用apt安装FFmpeg这是很多人一开始会问的问题。说实话如果只是简单地在板子上跑一条ffmpeg -version看看输出apt安装确实够用。一旦你开始接真实业务问题就全暴露出来了仓库版本滞后常用的filter和协议支持不完整比如某些H.265的扩展参数、SRT协议可能压根没编译进去无法整合自有业务代码像我要在一个C服务里通过libavcodec直接做硬编码apt版本根本不带RK3588的硬件编解码插件交叉编译的产物可以很方便地放进rootfs或SD卡系统镜像里批量烧录部署而apt安装适合单板调试不适合产线复制。所以本次移植的目标就定成从源码交叉编译出FFmpeg可执行程序和开发库让它在RK3588板子上能跑通软编软解、能通过libx264做H.264编码、能借助Rockchip MPP和V4L2接口调用硬件编解码最后用RTSP推流和拉流来做端到端验证。1.2 整个移植链路的关键阶段整个过程可以拆成五个阶段每个阶段之间是严格依赖的交叉编译工具链准备与验证FFmpeg依赖库交叉编译重点x264、x265、opus等FFmpeg本体交叉编译与安装部署到RK3588目标板做基础运行验证RTSP推拉流测试及性能调优。我当时卡得最久的是第一阶段和第二阶段尤其是pkg-config的变量设置稍不留神就会让configure误判依赖库的存在。后面详细说。2. 交叉编译工具链选型、安装与验证2.1 工具链选择系统自带交叉编译器还是SDK工具链RK3588是64位的ARMv8架构交叉编译最简单的方式是直接装Ubuntu自带的GCC交叉编译器sudo apt install gcc-aarch64-linux-gnu g-aarch64-linux-gnu装完以后aarch64-linux-gnu-gcc就能用了。这适合快速验证、编一些通用工具。不过我实际使用后发现如果编出来要在Rockchip官方SDK的rootfs里跑或者要用到比较新的C库特性时Ubuntu自带的这个交叉编译器版本可能跟目标系统C库存在微小差异偶尔会在链接时冒出一些警告甚至运行动态链接错误。所以我更推荐使用Rockchip SDK自带的工具链。下载SDK后在prebuilts/gcc/linux-x86/aarch64/目录下能找到例如gcc-arm-10.3-x86_64-aarch64-none-linux-gnu这样的版本。这类工具链针对Rockchip的BSP做过验证编出来和SDK里的rootfs兼容性更好。无论用哪种都要在~/.bashrc里把工具链的bin目录加到PATH最前面避免与系统自带的aarch64编译器冲突。2.2 工具链安装与基础验证我这里以SDK工具链为例整理一下完整流程# 解压工具链到opt目录 sudo tar -xvf gcc-arm-10.3-x86_64-aarch64-none-linux-gnu.tar.xz -C /opt/ # 设置环境变量 export PATH/opt/gcc-arm-10.3-x86_64-aarch64-none-linux-gnu/bin:$PATH export CROSSaarch64-none-linux-gnu # 验证版本 $CROSS-gcc -v验证编译最简单的办法是写一段hello.c交叉编译后在板子上跑#include stdio.h int main(void) { printf(hello rk3588, cross ok!\n); return 0; }编译并检查架构类型$CROSS-gcc hello.c -o hello file hello # 输出里应包含 ELF 64-bit LSB executable, ARM aarch64把hello传到板子上执行看到输出就说明工具链基本没问题。这一步虽然简单但它能一次性排除“工具链路径不对、架构选错、动态库链接失败”等好几个基础问题。2.3 架构参数PKG_CONFIG环境变量的规划交叉编译FFmpeg时pkg-config是个关键工具。它负责在configure阶段找到依赖库的头文件和库文件位置。如果环境变量设置错了编译时会报“libx264 not found”之类的错误而实际上x264已经编好了只是pkg-config根本没去找它。这里我建议在做依赖库之前先把环境变量规划好统一放到一个环境脚本里比如我习惯建一个env_rk3588_ffmpeg.shexport CROSSaarch64-none-linux-gnu export TOOLCHAIN_PATH/opt/gcc-arm-10.3-x86_64-aarch64-none-linux-gnu export SYSROOT$TOOLCHAIN_PATH/aarch64-none-linux-gnu export PATH$TOOLCHAIN_PATH/bin:$PATH export PREFIX$HOME/rk3588_ffmpeg_install export PKG_CONFIG_PATH$PREFIX/lib/pkgconfig export PKG_CONFIG_LIBDIR$PREFIX/lib/pkgconfig export PKG_CONFIG_SYSROOT_DIR$PREFIX这个脚本的核心思想是所有交叉编译出来的依赖库都装到统一的$PREFIX目录下pkg-config只在这个目录里找.pc文件。后面编x264、x265、FFmpeg时都source这个脚本路径问题一次性全解决。3. FFmpeg核心依赖库的交叉编译3.1 依赖库选型确定需要哪些扩展FFmpeg本身是一个框架要让它具备实际业务能力就得围绕需要选择外部库。我这里按用途分了三类编码与转码libx264、libx265这是最常见的H.264/H.265软件编码库音频处理libopus、libmp3lame用于音频编码硬件编解码与采集RK3588平台上主要依赖V4L2接口和Rockchip MPPFFmpeg源码已经自带v4l2 m2m的编解码封装不需要额外编第三方库但需要确保内核驱动和头文件版本匹配。还有一类是libsrt、libsrtp这类流媒体传输库用来扩展传输协议我这阶段没有编等项目后期需要SRT协议再补。3.2 编译libx264libx264的编译相对简单因为它不依赖其他库。从官网或GitHub拉代码后这样操作git clone https://code.videolan.org/videolan/x264.git cd x264 export PATH/opt/gcc-arm-10.3-x86_64-aarch64-none-linux-gnu/bin:$PATH ./configure --prefix$PREFIX --hostaarch64-none-linux-gnu --enable-static --cross-prefixaarch64-none-linux-gnu- --disable-cli make -j$(nproc) make install重点说两个参数--enable-static建议静态编库运行时就不用把一堆.so拷到板子上省去动态库依赖匹配的麻烦--disable-cli不生成x264命令行工具只要库文件编起来更快。编完之后可以去$PREFIX/lib/pkgconfig里确认有没有x264.pc。如果没有这个文件后面FFmpeg configure一定会报找不到x264。正常编完都会有可以这样检查cat $PREFIX/lib/pkgconfig/x264.pc # 应能看到 Libs和Cflags指向$PREFIX目录3.3 编译libx265x265的编译比x264麻烦一些它的构建系统基于CMake还要分12bit、10bit、8bit的库版本。RK3588上如果没有特殊的10bit需求编默认8bit版就够了。操作流程git clone https://bitbucket.org/multicoreware/x265_git.git cd x265_git/build/linux export PATH/opt/gcc-arm-10.3-x86_64-aarch64-none-linux-gnu/bin:$PATH cmake -DCMAKE_TOOLCHAIN_FILE../../../cmake/toolchains/aarch64-linux-gnu.cmake \ -DCMAKE_INSTALL_PREFIX$PREFIX \ -DENABLE_SHAREDOFF \ -DENABLE_CLIOFF \ ../../source make -j$(nproc) make install这里的重点是CMAKE_TOOLCHAIN_FILE。FFmpeg的交叉编译可以用环境变量直接指定编译器但CMake工程通常需要toolchain file来告诉它完整的交叉编译环境包括编译器、链接器、sysroot路径。不同版本的x265仓库toolchain文件路径可能略有变化找不到就自己新建一个内容核心是set(CMAKE_SYSTEM_NAME Linux) set(CMAKE_SYSTEM_PROCESSOR arm64) set(CMAKE_C_COMPILER aarch64-none-linux-gnu-gcc) set(CMAKE_CXX_COMPILER aarch64-none-linux-gnu-g)如果你只做H.264的RTSP流x265可以暂时不编但建议还是一起编上后面做H.265推流、测试RK3588硬编性能对比时都用得上。3.4 其他常见扩展库的编译注意点opus音频编解码库在语音对讲场景比较常用编译命令git clone https://github.com/xiph/opus.git cd opus ./autogen.sh ./configure --prefix$PREFIX --hostaarch64-none-linux-gnu --disable-shared --enable-static make -j$(nproc) make install这个库一般一次能过。需要注意的一点是autogen.sh要在宿主机上执行它会生成configure脚本交叉编译时不需要宿主机编译源码。如果还需要MP3编码可以编lame它是单C文件库交叉编译更加简单。不过arm平台下lame对NEON优化支持一般测试下来编码性能不如直接用AAC。4. FFmpeg本体交叉编译configure参数与编译细节4.1 获取源码与解压FFmpeg官方Git仓库地址是https://git.ffmpeg.org/ffmpeg.gitGitHub上的镜像也可以拉。版本建议选择4.4.x或者6.x以上的release分支这两个固件上测试比较多社区问题也好搜。我这里用的是FFmpeg 6.0对V4L2 m2m的支持已经比较成熟。wget https://ffmpeg.org/releases/ffmpeg-6.0.tar.xz tar -xvf ffmpeg-6.0.tar.xz cd ffmpeg-6.0拉Git仓库也可以但release tar包更稳不会有中间commit引起的编译问题。4.2 configure参数详细说明这是整个移植过程的关键。我第一次配置时漏了--pkg-config-flags--static这个参数导致编译链接阶段始终找不到静态库的依赖链折腾了半天。最终使用的config命令如下source ~/env_rk3588_ffmpeg.sh ./configure \ --prefix$PREFIX \ --target-oslinux \ --archaarch64 \ --enable-cross-compile \ --cross-prefixaarch64-none-linux-gnu- \ --pkg-configpkg-config \ --pkg-config-flags--static \ --enable-gpl \ --enable-nonfree \ --enable-libx264 \ --enable-libx265 \ --enable-libopus \ --enable-libv4l2 \ --enable-static \ --disable-shared \ --disable-doc \ --disable-debug逐个解释关键参数--target-oslinux目标系统类型FFmpeg需要根据这个参数决定一些平台相关的封装逻辑--archaarch64目标CPU架构。如果工具链是64位的ARM必须明确写成aarch64写成arm会导致生成32位代码或编译失败--enable-cross-compile告诉configure这是交叉编译环境不要尝试在宿主机运行测试程序--enable-libx264等启用外部解码库配套需要有前面编好的.pc文件--enable-libv4l2启用V4L2用户空间API库这是FFmpeg调用RK3588硬件编解码的关键接口--enable-static --disable-shared全部静态连接得到单文件二进制方便部署到板子--pkg-config-flags--static让pkg-config静态模式下把依赖库的Libs.private字段也带上否则链接时容易出现undefined reference错误。配置成功后configure末尾会打印一份编译选项汇总这时候建议仔细看一下Codecs、Encoders、Decoders列表里有没有h264_v4l2m2m、hevc_v4l2m2m等硬件编解码模块。如果只看x264后面硬编基本没法玩。4.3 编译与常见编译错误configure通过后就是编译安装make -j$(nproc) make install编译过程中我遇到过几个报错速查如下报错信息原因解决办法ERROR: x264 not foundpkg-config路径不对或x264.pc缺失source环境脚本确认PKG_CONFIG_LIBDIR指向$PREFIX/lib/pkgconfigundefined reference to x264_encoder_open静态库链接顺序依赖问题configure加上--pkg-config-flags--staticlibavcodec/v4l2_m2m.c: No such file or directory内核头文件不匹配确认SDK工具链的sysroot里有linux/videodev2.h必要时从SDK内核源码复制include/uapi/linux到sysrootnasm not foundx86工具链缺少汇编器这是宿主机的nasm不是目标板编译直接apt install nasm编译完成后在$PREFIX/bin/下会生成ffmpeg、ffprobe、ffplay三个可执行文件。注意ffplay默认依赖SDL如果configure时没加--enable-sdl2可能不会生成ffplay。但我们是嵌入式板子不需要在板子上做窗口播放一般用ffprobe和ffmpeg就够了。想验证解码拉流可以用ffmpeg带-f null -的方式丢弃输出只测解码链路也可以把rtsp流转存成文件。5. 部署到RK3588板子与基础运行验证5.1 拷贝文件到目标板我这里是通过ADB把编译产物推送到板子如果你的开发环境是SSH用scp也可以命令如下adb push $PREFIX/bin/ffmpeg /userdata/ adb push $PREFIX/bin/ffprobe /userdata/ adb shell chmod x /userdata/ffmpeg因为采用静态编译ldd查看时几乎没有任何动态库依赖放到板子上直接就能跑。这一步出来的二进制在构建rootfs或批量刷机时非常方便。如果板子上不是Rockchip SDK的rootfs而是你自己定制的Ubuntu根文件系统工具链sysroot和运行环境的C库版本有差异时可能会出现运行时报version GLIBC_X.XX not found。遇到这种问题最好就直接改用Ubuntu的aarch64交叉编译器重编一版或者用SDK里配套的libc版本更低的工具链。5.2 基础验证版本信息与编码器列表先在板子上确认基础运行正常/userdata/ffmpeg -version # 输出应包含 ffmpeg version 6.0 ... configuration信息 /userdata/ffmpeg -encoders | grep 264能看到libx264和h264_v4l2m2m这两项就说明软编和硬编驱动都已经被FFmpeg识别。接着在板子上自己生成一段测试视频验证编码通路/userdata/ffmpeg -f lavfi -i testsrcduration5:size1280x720:rate30 \ -c:v libx264 -preset veryfast -b:v 2M test.mp4这条命令如果顺利跑完说明FFmpeg在板子上的基本运行环境没问题编码链路也能走通。返回的帧编码速度和fps数值可以作为后续性能调优的基线参考。5.3 测试RTSP拉流用FFmpeg直接解析RTSP流RK3588平台上最常遇到的场景是从IP摄像头拉流FFmpeg可以通过RTSP协议直接读取摄像头的流。命令如下/userdata/ffmpeg -rtsp_transport tcp -i rtsp://192.168.1.100:554/stream1 \ -c:v copy -c:a copy -f flv output.flv或者直接丢弃解码测试能不能正常拿到流/userdata/ffmpeg -rtsp_transport tcp -i rtsp://192.168.1.100:554/stream1 \ -f null -这里需要说明-rtsp_transport tcp这个参数。RTSP默认走UDP拉流但UDP在弱网环境丢包严重会出现花屏和马赛克。TCP虽然延迟稍微大一点点但稳定性好很多。在有线局域网内测试建议直接TCP优先。测试时如果卡在Opening rtsp://...这一步不动大多是网络不通或端口没开。可以先在板子上用ping和nc -vz 192.168.1.100 554排查连接问题。5.4 测试RTSP推流用FFmpeg把本地视频推给流媒体服务器推流测试需要有一个RTSP服务器作接收端。在RK3588板子上直接推流到服务器命令如下/userdata/ffmpeg -re -i /userdata/test.mp4 \ -c:v copy -c:a copy \ -f rtsp -rtsp_transport tcp rtsp://192.168.1.50:554/live/test这里面的-re参数很关键它的作用是让FFmpeg按视频原始帧率读取文件模拟实时推流。如果不加-reFFmpeg会以最快速度把文件推完服务器端看到的画面就会像快进一样。对RTSP这种实时流协议来说-re几乎是必选项。如果没有现成的RTSP服务器本地也可以临时搭一个轻量的mediamtx原rtsp-simple-server进程直接下载ARM64版本放到板子上跑几秒钟就能启动一个支持RTSP的server然后再用FFmpeg往它推流。这个组合在联调时特别方便。5.5 硬解码与硬编码验证纯软件编码在RK3588上其实性能也还行x264的veryfast编码1280x720视频能跑到几十帧但如果要处理4K流软编就很吃力了。这时候就需要调用RK3588的硬件编解码单元。FFmpeg在RK3588上调用硬编硬解有两条路子直接使用h264_v4l2m2m、hevc_v4l2m2m编码器/解码器。这是V4L2框架的m2m设备FFmpeg通过/dev/video*节点与内核驱动交互通过Rockchip的MPPMedia Process Platform库这条封装在社区版本FFmpeg里集成度不如V4L2高一般需要打补丁。我建议优先用V4L2 m2m路线它是主线FFmpeg自带的支持不需要额外补丁维护也省心。使用方式很简单# 硬编码 /userdata/ffmpeg -i input.yuv -c:v h264_v4l2m2m -b:v 4M output.h264 # 硬解码 /userdata/ffmpeg -c:v h264_v4l2m2m -i input.h264 -f null -特别注意h264_v4l2m2m对输入帧格式有要求一般需要NV12格式。如果你给的输入是YUV420P需要先用-pix_fmt nv12转换。这次移植测试时我在一条命令里同时加了-s 1920x1080 -pix_fmt nv12转格式再用硬件编码器编码效果好很多/userdata/ffmpeg -f lavfi -i testsrcduration5:size1920x1080:rate30 \ -pix_fmt nv12 -c:v h264_v4l2m2m -b:v 4M output.h264硬编的同时也可以配合RTSP直接做硬件编码后的RTSP推流/userdata/ffmpeg -re -i /userdata/test.mp4 \ -pix_fmt nv12 -c:v h264_v4l2m2m -b:v 4M \ -f rtsp -rtsp_transport tcp rtsp://192.168.1.50:554/live/hw这样就能验证一个典型场景解码或读取视频文件后由RK3588硬件编码器实时编码再通过RTSP推出去。整个链路的CPU占用比纯libx264低很多从top里能明显看到差别。6. RTSP流测试中的关键排查思路6.1 拉流花屏、绿屏与NALU异常RTSP拉流测试时最常遇到的就是画面花屏或者绿色条纹。很多时候第一反应是网络问题但实际排查下来RK3588平台更多是解码器格式不匹配导致的。常见原因之一是拉到的H.264流是High Profile的而板子上某些简化版解码器只支持到Main Profile。这时可以用ffprobe查看流编码信息/userdata/ffprobe -show_streams rtsp://192.168.1.100:554/stream1 \ | grep -A 5 codec_nameh264如果profile显示High可以尝试在解码前转成Main Profile。但RTSP拉流转码会引入延时更推荐确认播放器或解码API支持High Profile。常见原因之二是RTSP交互模式。UDP传输出错后I帧丢失会导致后续画面一直花屏直到下一个关键帧到达。解决方式是强制TCP模式以及使用-fflags nobuffer -flags low_delay这类低延迟参数/userdata/ffmpeg -rtsp_transport tcp -fflags nobuffer -flags low_delay \ -i rtsp://192.168.1.100:554/stream1 -f null -6.2 推流卡顿与时间戳问题推流端最常见的问题是推出去以后对端播放时画面一卡一卡的或者音画不同步。这里我总结出三个排查方向-re是否加了如果不加FFmpeg会以机器最大速度读取文件RTSP服务器收到的是大量突发帧播放端缓冲会被打乱-vsync和-fps_mode参数是否合理FFmpeg 6.0中-vsync已倾向于用-fps_mode替代推流时建议设置-fps_mode cfr保证输出帧率恒定TCP还是UDP如果推流到公网服务器UDP在弱网下会大量丢包推流端也建议改用TCP。举个例子一个比较稳定的推流命令如下/userdata/ffmpeg -re -stream_loop -1 -i /userdata/test.mp4 \ -fps_mode cfr -c:v copy \ -f rtsp -rtsp_transport tcp rtsp://192.168.1.50:554/live/loop这里-stream_loop -1让视频无限循环适合长时间稳定性测试。我实际让它跑了一整晚第二天早上检查时依然在推流内存和CPU占用都很平稳。6.3 板载mpp资源冲突RK3588的硬编硬解功能统一走VPUVideo Processing Unit如果同时多个进程在抢占硬编硬解会导致部分任务排队或失败。用V4L2 m2m的时候报错信息往往不直观。排查时可以查看板上有哪些进程占用了/dev/video*节点ls -l /dev/video* fuser -v /dev/video0如果业务上确实需要多路硬编解码并存需要确认RK3588的VPU实例数是否够用或者调整业务架构把部分编解码让给软件实现。这块是硬件资源规划的问题不是FFmpeg本身能解决的。6.4 网络带宽估算RTSP流测试时很多人容易忽略带宽问题。假设推的是1080p30 H.264 4Mbps码流实际网络传输还要加上RTSP/RTP头开销tcp模式下大概会占到5Mbps左右。在百兆网口的内网环境完全没问题但如果是多路同时推或者板子用的是Wi-Fi带宽就很容易成为瓶颈。可以用板上的工具看实时流量cat /proc/net/dev对比推流前后的eth0字节数增量就能估算出实际网络占用避免凭感觉判断网络是否够跑。7. 性能调优与后续扩展的一些经验7.1 看准编码器、分辨率和码率之间的平衡在RK3588上做RTSP推流编码器选择直接决定系统负载。实测下来1080p30的链路libx264medium预设编码CPU占用大约能占到4个大核中的1到2个核心h264_v4l2m2m硬编码CPU占用很低基本可以忽略编码开销如果只是做多路视频转发不强需求改编码尽量用-c:v copy直接透传完全不做编码CPU占用最低。我在实际项目中多路接入时基本都是“硬解硬编RTSP转发”的方式。RK3588的VPU对1080p的硬编硬解有足够余量但每路都软编就很容易打满CPU。硬编码率控制方面h264_v4l2m2m的码控精度相对于x264弱一些。如果你对视频体积或画质有严格要求建议让它输出较高码率再配合-maxrate限制峰值不要让它完全自动。我曾经设置-b:v 4M实际输出码率在3.5M到5.5M之间波动而libx264的码控稳定得多。7.2 用ffprobe快速验证RTSP链路的可行性调试RTSP时ffprobe是个非常好的排障工具。它可以快速打印流媒体信息而不用真正解码数据/userdata/ffprobe -rtsp_transport tcp -show_format -show_streams rtsp://192.168.1.100:554/stream1观察输出里的start_time、duration、nb_frames等信息能判断流是否稳定。如果start_time一直很小或者duration不断变化说明源端的推流不是标准实时流后端的播放器可能会受到影响。7.3 与YOLO等AI推理结合时的数据通路设计搜索热词里很多人也在问“RK3588部署yolov8”。这里简单提一个架构经验视频流处理链路最好是“RTSP拉流 - 硬解码 - 缩放/格式转换 - NPU推理 - 编码/推流”这样的流水线。FFmpeg在中间主要承担前段的拉流、解码和末端编码推流。RK3588的NPURKNN则负责推理。整个过程中图像格式流转要做到零拷贝或尽可能减少拷贝否则CPU内存带宽会成为瓶颈。如果只是简单地在FFmpeg解码后逐帧转成RGB再送NPU1080p下性能会损失很大。我自己目前的方案是通过V4L2 m2m解码后拿到DMABUF再通过RGA做格式转换直接把带FD的buffer传给RKNN。这条路代码复杂度高一些但性能收益明显。如果只是做验证原型其实用ffmpeg命令行拉流存文件再离线跑推理就够了。7.4 FFmpeg后续扩展的方向本次移植只是基础版本后续如果业务迭代很可能要补充加入SRT协议支持用于跨公网传输需要在编译时增加--enable-libsrt集成Rockchip MPP补丁获得更精细的硬件编解码控制比如帧率控制、RC模式选择社区和Rockchip的GitHub上都有相关patch加入SDL2重新编译ffplay在带显示器的板子上直接播放RTSP流做桌面端原型验证编译FFmpeg的Python绑定比如ffmpeg-python只是命令行封装如果要在Python里调用库函数需要额外考虑。每加一个新模块都要回到第4章的configure流程把对应的--enable-xxx加上然后重新编译、重新部署。好在基础的依赖库和交叉编译环境都搭好了加模块只是重复走一遍configure和make的流程并不会很复杂。编译这版FFmpeg前前后后花了两三天中间踩过pkg-config的坑、踩过工具链sysroot不匹配的坑、也踩过硬编码格式不对导致全绿屏的坑。现在把工具链、依赖库和编译参数固定下来之后后续重新出一版只是跑几条命令的事。RK3588本身性能很强把FFmpeg这层基础设施打好后面做多路视频接入、AI视频分析、流媒体网关都会顺利很多。