1. 项目缘起为什么要在ARM上折腾ZLMediaKit最近在折腾一个边缘计算的项目场景是在一个ARM架构的嵌入式工控板上做视频流的汇聚和转发。板子性能不错跑的是Ubuntu系统但资源毕竟和x86服务器没法比。最初图省事直接用了某个轻量级的RTSP服务器结果在实际压测时问题就暴露出来了多路高清流并发一上来不是卡顿就是直接崩掉协议兼容性也一般有些厂家的摄像头死活连不上。这时候ZLMediaKit这个名字就跳进了我的视野。它在流媒体服务器圈子里口碑一直很好以高性能、高并发和丰富的协议支持RTSP/RTMP/HLS/HTTP-FLV/WebSocket-FLV等著称很多互联网直播和安防项目都在用。但翻遍官方文档和社区讨论发现大家默认的使用场景都是x86_64的Linux服务器或者Windows。关于在ARM平台特别是资源受限的嵌入式ARM环境下的移植和部署资料非常零散几乎都是只言片语。这不就巧了吗需求撞上了空白区。把ZLMediaKit这套为高性能服务器设计的“重武器”成功地移植并优化到ARM平台上让它稳定、高效地跑起来就成了一个既有挑战又有实际价值的事情。这不仅仅是跑通一个程序更涉及到交叉编译工具链的适配、第三方库的依赖处理、针对ARM架构的编译参数调优以及最终在目标板上的性能验证和问题排查。整个过程可以说是一步一个坑但也积累了不少在ARM平台部署复杂C项目的实战经验。2. 环境侦察与作战准备理解你的战场在开始动手编译之前盲目地敲命令是最要不得的。我们必须先搞清楚“敌我”形势我们的开发环境宿主机是什么我们要攻击的目标目标板又是什么这两者之间的桥梁交叉编译工具链是否就位2.1 明确目标平台与宿主机构型这是最基础也最容易出错的一步。ARM平台本身就是一个庞大的家族从低功耗的Cortex-M系列单片机到高性能的Cortex-A系列应用处理器架构和指令集都有差异。目标平台 (Target) 我这次使用的是一块基于Cortex-A72内核的工控板运行Ubuntu 18.04系统。通过执行uname -m命令确认其架构为aarch64即ARM 64位。这一点至关重要因为它决定了我们需要寻找或构建对应的交叉编译工具链。如果你的板子是armv7l32位ARM那么整个工具链和后续的编译选项都会不同。宿主机 (Host) 为了编译效率我选择在一台x86_64的Ubuntu 20.04虚拟机上完成所有编译工作。这构成了典型的交叉编译场景在X86机器上生成能在ARM机器上运行的二进制文件。核心任务 因此我们的核心就是搭建一套x86_64-linux-gnu 到 aarch64-linux-gnu的交叉编译环境。2.2 交叉编译工具链的选型与部署工具链是交叉编译的“武器”。对于aarch64常见的选择有Linaro GCC 老牌且稳定的ARM工具链提供商社区支持好。ARM官方GCC (Arm GNU Toolchain) ARM公司自己维护的工具链更新及时对ARM新特性支持最好。目标板系统自带工具链 有些嵌入式Linux发行版如Buildroot、Yocto定制出的系统会提供配套的SDK里面就包含了完美的交叉编译工具链。这是最推荐的方式因为它和板子上运行的系统库版本完全一致能最大程度避免兼容性问题。我这次很幸运板子供应商提供了一个完整的SDK。如果没有从ARM官网下载是最稳妥的选择。以下以ARM官方工具链为例展示部署过程# 1. 在宿主机上创建工具链目录并下载请替换为最新版本链接 mkdir -p /opt/toolchains cd /opt/toolchains wget https://developer.arm.com/-/media/Files/downloads/gnu-a/10.3-2021.07/binrel/arm-gnu-toolchain-10.3-2021.07-x86_64-aarch64-none-linux-gnu.tar.xz # 2. 解压 tar -xf arm-gnu-toolchain-10.3-2021.07-x86_64-aarch64-none-linux-gnu.tar.xz # 3. 将工具链路径加入系统环境变量方便调用 echo export PATH/opt/toolchains/arm-gnu-toolchain-10.3-2021.07-x86_64-aarch64-none-linux-gnu/bin:$PATH ~/.bashrc source ~/.bashrc # 4. 验证工具链是否安装成功 aarch64-none-linux-gnu-gcc --version如果成功输出了gcc的版本信息并且前缀是aarch64-none-linux-gnu-那么恭喜你最关键的武器已经到手了。注意 不同工具链的“前缀prefix”可能不同例如可能是aarch64-linux-gnu-或aarch64-buildroot-linux-gnu-。后续所有的CC、CXX环境变量以及configure、cmake参数都需要使用这个正确的前缀。用ls /opt/toolchains/你的工具链目录/bin/查看一下就能确认。2.3 ZLMediaKit源码与依赖库分析工欲善其事必先利其器。接下来我们需要把ZLMediaKit的“图纸”和“零部件”准备好。# 克隆ZLMediaKit源码及子模块非常重要 git clone --depth 1 https://github.com/ZLMediaKit/ZLMediaKit.git cd ZLMediaKit git submodule update --init --recursiveZLMediaKit依赖于几个关键的第三方库这部分是移植的重点和难点OpenSSL 用于TLS/DTLS加密RTMPS等协议必需。libsrtp 用于SRTP加密WebRTC流传输必需。ffmpeg 用于转码、复用/解复用。如果只需要流转发而不需要转码可以在编译时关闭此特性。usrsctp 用于SCTP协议WebRTC数据通道必需。核心矛盾在于ZLMediaKit的编译脚本默认会从网络下载预编译好的x86_64版本的这些依赖库这显然不符合我们交叉编译的需求。我们必须手动为ARM平台交叉编译这些依赖库或者确保目标板上已经安装了这些库的ARM版本。3. 攻坚战交叉编译依赖库与ZLMediaKit这是整个移植过程最核心、最繁琐的环节。我们的策略是在宿主机上使用交叉编译工具链为ARM目标板编译所有必需的依赖库并安装到某个特定的目录例如/opt/arm-libs下。然后在编译ZLMediaKit时告诉它去这个目录里找ARM版本的库和头文件。3.1 交叉编译OpenSSLOpenSSL的交叉编译需要仔细配置。# 在宿主机上操作 cd /path/to/your/workdir wget https://www.openssl.org/source/openssl-1.1.1w.tar.gz # 下载稳定版本版本号请更新 tar -zxf openssl-1.1.1w.tar.gz cd openssl-1.1.1w # 配置交叉编译参数 ./Configure linux-aarch64 \ --prefix/opt/arm-libs/openssl \ # 指定安装路径 --cross-compile-prefixaarch64-none-linux-gnu- \ # 你的工具链前缀 no-shared \ # 静态链接避免运行时依赖问题简化部署 no-asm \ # 如果不确定目标板汇编兼容性可以先关闭 no-dso \ no-engine # 编译并安装 make -j$(nproc) make install编译完成后/opt/arm-libs/openssl目录下就会有include和lib子目录里面就是ARM架构的OpenSSL文件。3.2 交叉编译其他依赖以libsrtp为例其他库的流程类似核心都是设置正确的--host、--prefix和环境变量。# 编译libsrtp cd /path/to/your/workdir git clone https://github.com/cisco/libsrtp.git cd libsrtp ./configure --hostaarch64-none-linux-gnu \ # 指定目标主机类型 --prefix/opt/arm-libs/libsrtp \ --enable-openssl \ --with-openssl-dir/opt/arm-libs/openssl # 指向我们刚编译的OpenSSL make -j$(nproc) make install对于ffmpeg交叉编译的配置更为复杂通常需要写一个详细的配置脚本来启用或禁用众多编解码器和特性。如果不需要转码功能在ZLMediaKit中关闭FFmpeg支持是更简单的方法。3.3 交叉编译ZLMediaKit本体依赖库准备就绪后终于可以编译主角了。ZLMediaKit使用CMake构建我们需要通过一个工具链文件Toolchain File来告诉CMake所有交叉编译的设定。创建工具链文件arm_toolchain.cmake# arm_toolchain.cmake set(CMAKE_SYSTEM_NAME Linux) set(CMAKE_SYSTEM_PROCESSOR aarch64) # 指定交叉编译工具链前缀 set(TOOLCHAIN_PREFIX aarch64-none-linux-gnu-) set(CMAKE_C_COMPILER ${TOOLCHAIN_PREFIX}gcc) set(CMAKE_CXX_COMPILER ${TOOLCHAIN_PREFIX}g) # 指定目标环境根目录即我们存放ARM库的地方 set(CMAKE_FIND_ROOT_PATH /opt/arm-libs) # 只在目标根目录中查找库和头文件 set(CMAKE_FIND_ROOT_PATH_MODE_PROGRAM NEVER) set(CMAKE_FIND_ROOT_PATH_MODE_LIBRARY ONLY) set(CMAKE_FIND_ROOT_PATH_MODE_INCLUDE ONLY) set(CMAKE_FIND_ROOT_PATH_MODE_PACKAGE ONLY)配置和编译ZLMediaKitcd /path/to/ZLMediaKit mkdir -p build_arm cd build_arm # 使用工具链文件进行配置 cmake .. \ -DCMAKE_TOOLCHAIN_FILE../arm_toolchain.cmake \ -DCMAKE_INSTALL_PREFIX/opt/arm-libs/zlm \ -DENABLE_WEBRTCON \ -DOPENSSL_ROOT_DIR/opt/arm-libs/openssl \ -DOPENSSL_LIBRARIES/opt/arm-libs/openssl/lib \ -DOPENSSL_INCLUDE_DIR/opt/arm-libs/openssl/include \ -DENABLE_FFMPEGOFF \ # 根据需求开关关闭可简化编译 -DCMAKE_BUILD_TYPERelease # 开始编译 make -j$(nproc)这个过程可能会比较长并且可能会遇到各种依赖路径找不到的错误。你需要根据CMake的报错信息灵活地通过-Dxxx_DIR或-Dxxx_LIBRARY、-Dxxx_INCLUDE_DIR等参数将我们之前编译好的ARM库的路径一一指定给CMake。4. 战场移交与实战部署让服务在ARM板跑起来编译成功在build_arm目录下会生成MediaServer这个可执行文件。用file命令检查一下file MediaServer输出应该是MediaServer: ELF 64-bit LSB executable, ARM aarch64, version 1 (GNU/Linux)...这确认了它是ARM 64位程序。4.1 部署到目标板将编译产物拷贝到ARM开发板上。你需要将以下内容打包MediaServer可执行文件。相关的配置文件config.ini,default.pem等从源码目录conf/下获取。所有依赖的动态库.so文件。这是最容易出问题的地方。可以使用ldd命令在宿主机上检查MediaServer的依赖注意需要用工具链里的ldd或者用aarch64-none-linux-gnu-readelf -d MediaServer | grep NEEDED查看。# 在宿主机上使用工具链的readelf aarch64-none-linux-gnu-readelf -d MediaServer | grep NEEDED然后去/opt/arm-libs下对应的lib目录里找到这些.so文件一并拷贝到目标板的某个目录例如/opt/zlm/lib。最后在目标板上通过设置LD_LIBRARY_PATH环境变量让程序能找到这些库。# 在ARM目标板上操作 export LD_LIBRARY_PATH/opt/zlm/lib:$LD_LIBRARY_PATH cd /opt/zlm ./MediaServer -c config.ini -s ./ssl.pem 4.2 常见问题与排坑指南“找不到符号”或“版本GLIBCXX_3.4.29’未找到”原因 宿主机交叉编译工具链的C标准库版本高于目标板系统自带的版本。解决 这是交叉编译的经典难题。有两种思路一是降低宿主机工具链的版本使其与目标板系统匹配二是将工具链中的对应C标准库如libstdc.so.6也拷贝到目标板的LD_LIBRARY_PATH目录下。更推荐静态链接C标准库在CMake配置时加上-DCMAKE_EXE_LINKER_FLAGS-static-libstdc这样可以彻底摆脱对目标板系统库版本的依赖。程序启动后秒退或无响应原因 配置文件路径错误、依赖库没找到、或者端口被占用。排查 首先在目标板上运行./MediaServer -c config.ini -d-d参数在前台运行并输出日志观察控制台输出的错误信息。检查日志文件logs/下的内容。用netstat -tlnp检查ZLMediaKit默认的端口如1935、554、80、443等是否已被占用。性能不佳原因 ARM平台的CPU和内存带宽通常弱于服务器。默认配置可能不适合。优化 编辑config.ini根据板子核心数调整threads相关配置如general.thread_num。对于视频流可以尝试关闭不必要协议如HLS以减少开销。如果只是做流转发确保ENABLE_FFMPEGOFF避免编解码消耗大量CPU。5. 进阶思考从“能用”到“好用”当服务稳定跑起来后我们可以考虑更多生产环境的问题。5.1 系统服务化通过编写systemd服务文件让ZLMediaKit能够开机自启、崩溃重启、方便地查看日志。# /etc/systemd/system/zlm.service [Unit] DescriptionZLMediaKit Media Server Afternetwork.target [Service] Typesimple Userroot WorkingDirectory/opt/zlm ExecStart/opt/zlm/MediaServer -c /opt/zlm/config.ini -m 3 Restartalways RestartSec3 [Install] WantedBymulti-user.target然后使用systemctl enable --now zlm启用服务。5.2 资源监控与告警对于嵌入式设备资源监控尤为重要。可以编写简单的脚本定期检查MediaServer进程的CPU、内存占用以及网络连接数。结合crontab和邮件/短信网关实现异常告警。5.3 针对特定硬件的优化如果ARM板子有GPU或专用的视频编解码硬件如RK3568/RK3588的NPU、Jetson系列的NVDEC/NVENCZLMediaKit的默认FFmpeg可能无法调用。这就需要深入下去编译开启了对应硬件加速支持的FFmpeg并集成到ZLMediaKit中。这又是一个复杂的专项任务但能极大提升性能和解码路数。整个移植过程就像是一场精心策划的战役。从环境侦察、武器工具链准备到逐个攻破依赖库的堡垒最后完成主程序的编译和部署每一步都需要耐心和细致。最大的体会就是交叉编译的问题90%都出在环境变量和路径上。保持清晰的思路用好--prefix、CMAKE_PREFIX_PATH、LD_LIBRARY_PATH这些“路标”遇到错误时仔细阅读输出信息大部分难关都能攻克。最终看到自己编译的MediaServer在ARM板上流畅地推送出视频流时那种成就感就是对我们这些“底层”工程师最好的回馈。