1. 为什么我要折腾NPU转码这件事做视频处理这行的朋友应该都有体会FFmpeg 是绕不开的基础设施。不管是做点播平台的转码流水线还是本地批量压缩素材甚至是给监控系统做实时流处理FFmpeg 几乎无处不在。但问题也很明显默认情况下 FFmpeg 走的是纯 CPU 软编软解一旦并发量上来CPU 直接跑满机器风扇狂转转码速度还慢得让人抓狂。我之前负责过一个项目需要把大量历史视频素材统一转成 H.264 加 AAC 的标准格式。一开始用的是 x264 软编码16 核的服务器跑 1080p 转码单路速度大概在 1.2 倍速左右也就是说一个 10 分钟的视频要花 8 分多钟才能转完。批量处理几千个文件的时候那个等待时间真的让人崩溃。后来尝试过用 GPU 加速NVIDIA 的 NVENC 确实快但显卡成本高而且很多国产化场景里根本不允许用国外显卡。直到我接触到昇腾 310P 这块 NPU 加速卡才算是找到了一个在成本和性能之间比较平衡的方案。昇腾 310P 是专门做推理和视频处理的 AI 加速芯片内置了专门的视频编解码硬件单元支持 H.264、H.265 的硬件编解码而且功耗控制得不错半高半长的 PCIe 卡形态单卡就能塞进 1U 服务器里。这篇文章我打算把整个折腾过程完整记录下来从环境搭建、FFmpeg 编译适配、到实际转码测试和性能对比最后再聊聊踩过的坑和优化经验。如果你也在做视频转码相关的工作或者手头正好有昇腾的硬件想物尽其用这篇内容应该能帮你省下不少查文档和试错的时间。2. 昇腾310P做视频转码到底靠不靠谱2.1 先搞清楚NPU转码和CPU转码的本质区别很多人第一次听到“NPU 转码”会有点懵觉得 NPU 不是做 AI 推理的吗怎么还能转码其实这里要分清楚两个概念。CPU 转码走的是通用计算路径x264、x265 这些编码器本质上是一堆复杂的数学运算靠 CPU 的通用核心一条条指令去算。好处是灵活参数随便调画质可以精细控制坏处是效率低尤其是高分辨率高码率的时候CPU 的算力很快就不够用了。NPU 转码走的是专用硬件路径。昇腾 310P 芯片内部集成了独立的视频编解码模块这个模块是专门为 H.264/H.265 设计的 ASIC 电路做 DCT 变换、量化、熵编码这些步骤的时候速度比 CPU 快一个数量级而且几乎不占用主 CPU 的资源。你可以理解为CPU 转码是让一个数学教授去搬砖NPU 转码是直接叫了一台起重机。但这里有个关键点需要注意NPU 的硬件编码器在画质调优的灵活性上不如 x264 软编。硬件编码器通常只提供有限的几个参数档位比如码率控制模式、GOP 长度、QP 范围这些你没法像 x264 那样精细地调 psy-rd、aq-mode 之类的心理视觉参数。所以 NPU 转码更适合对速度要求高、对画质要求相对标准的场景比如监控视频归档、短视频平台批量转码、直播录制回存这些。2.2 昇腾310P的硬件编解码能力参数昇腾 310P 的视频编解码规格我整理了一个表格方便大家对照自己的需求项目规格解码能力H.264/H.265最大 4K120fps 或 1080p480fps编码能力H.264/H.265最大 4K60fps 或 1080p240fps编码档位Baseline/Main/High Profile码率控制CBR/VBR/AVBR最大码率单路 100Mbps色度采样4:2:0位深8bit/10bit接口PCIe 4.0 x16向下兼容 x8功耗最大 72W从参数上看单卡 1080p 编码能跑到 240fps意味着理论上可以同时处理 8 路 1080p30fps 的转码任务。这个吞吐量对于大多数中小型转码场景来说已经相当充裕了。2.3 为什么选择FFmpeg作为接入层市面上做视频转码的方案很多有直接用厂商 SDK 的有走 GStreamer 的也有自己写调用逻辑的。我选择 FFmpeg 作为接入层主要考虑几个因素。第一是生态成熟。FFmpeg 的滤镜系统、封装格式支持、协议支持都是最全的你可以在转码前后灵活地加各种处理比如缩放、裁剪、加水印、拼接这些用 FFmpeg 的 filter graph 几行命令就能搞定换成自己写代码工作量翻好几倍。第二是团队熟悉度高。做视频的团队基本都会 FFmpeg学习成本低维护起来也方便。如果换成厂商私有 SDK人员流动的时候交接成本很高。第三是昇腾官方提供了 FFmpeg 的适配补丁。华为的 Ascend 社区里有专门的 FFmpeg 插件把硬件编解码器封装成了 FFmpeg 的 codec用起来跟普通的h264_ascend编码器一样命令行参数风格也保持一致。这就意味着现有的 FFmpeg 脚本只需要改编码器名字就能迁移改动量极小。3. 环境搭建与FFmpeg编译实操3.1 硬件和系统环境准备先说一下我的测试环境配置服务器鲲鹏 920 平台ARM64 架构NPU昇腾 310PPCIe 4.0 x16 插槽系统openEuler 22.03 LTS内存64GB DDR4存储NVMe SSD 1TB如果你用的是 x86 平台昇腾 310P 也有对应的驱动和固件流程基本一致只是编译工具链要换成 x86 的版本。这里我以 ARM64 为例来写x86 的朋友把对应的包名换一下就行。第一步是确认硬件识别正常。装好卡之后用lspci看一下lspci | grep -i ascend正常的话应该能看到类似Processing accelerators: Huawei Technologies Co., Ltd. Device d801的输出。如果看不到检查一下卡是否插紧、PCIe 供电是否接好。第二步是安装 NPU 驱动和固件。昇腾的驱动包分为 driver 和 firmware 两部分需要从昇腾社区下载对应版本的 run 包。安装命令chmod x Ascend-hdk-310p-npu-driver_*.run ./Ascend-hdk-310p-npu-driver_*.run --full安装完成后用npu-smi info检查状态npu-smi info这个命令会输出芯片温度、功耗、内存占用等信息。如果显示正常说明驱动层没问题。注意驱动版本和后续的 CANN 版本必须匹配否则会出现各种奇怪的错误。建议先确定 CANN 版本再倒推驱动版本。3.2 CANN工具包安装与配置CANN 是昇腾的计算架构层提供了 FFmpeg 插件依赖的底层库。我用的版本是 CANN 7.0安装步骤chmod x Ascend-cann-toolkit_7.0.0_linux-aarch64.run ./Ascend-cann-toolkit_7.0.0_linux-aarch64.run --install安装完成后需要设置环境变量把下面这些加到~/.bashrc里export ASCEND_HOME/usr/local/Ascend export PATH$ASCEND_HOME/ascend-toolkit/latest/bin:$PATH export LD_LIBRARY_PATH$ASCEND_HOME/ascend-toolkit/latest/lib64:$LD_LIBRARY_PATH export PYTHONPATH$ASCEND_HOME/ascend-toolkit/latest/pyACL/python/site-packages:$PYTHONPATH然后source ~/.bashrc生效。验证一下atc --version能输出版本号就说明 CANN 装好了。3.3 编译带昇腾插件的FFmpeg昇腾社区提供了 FFmpeg 的补丁包需要下载对应版本的源码和补丁。我用的 FFmpeg 版本是 4.4.8补丁包在昇腾社区的“媒体数据处理”板块可以找到。编译步骤大致如下# 下载FFmpeg源码 wget https://ffmpeg.org/releases/ffmpeg-4.4.8.tar.gz tar -zxvf ffmpeg-4.4.8.tar.gz cd ffmpeg-4.4.8 # 打昇腾补丁 patch -p1 ../ffmpeg_ascend_patch/ffmpeg_ascend.patch # 配置编译选项 ./configure \ --prefix/usr/local/ffmpeg-ascend \ --enable-shared \ --enable-static \ --enable-ascend \ --enable-libx264 \ --enable-libx265 \ --enable-gpl \ --extra-cflags-I$ASCEND_HOME/ascend-toolkit/latest/include \ --extra-ldflags-L$ASCEND_HOME/ascend-toolkit/latest/lib64 -lascendcl -lacl_dvpp # 编译安装 make -j16 make install这里有几个关键点要说明--enable-ascend是补丁引入的选项开启后才会编译昇腾的编解码器模块。--extra-cflags和--extra-ldflags指定了 CANN 的头文件和库路径如果路径不对编译时会报找不到acl.h之类的错误。编译过程中如果遇到undefined reference to aclrtMalloc这类链接错误大概率是LD_LIBRARY_PATH没设对或者 CANN 的库路径跟实际安装位置不一致。可以用find / -name libascendcl.so找一下实际位置。编译完成后验证/usr/local/ffmpeg-ascend/bin/ffmpeg -codecs | grep ascend应该能看到h264_ascend和h265_ascend两个编码器以及对应的解码器。4. 实际转码测试与性能对比4.1 测试素材与转码命令我准备了三种典型素材来测试素材 A1080p30fpsH.2648Mbps时长 10 分钟素材 B4K30fpsH.26520Mbps时长 5 分钟素材 C720p25fpsH.2644Mbps时长 30 分钟CPU 转码命令x264 软编ffmpeg -i input.mp4 -c:v libx264 -preset medium -b:v 4M -c:a aac -b:a 128k output_cpu.mp4NPU 转码命令昇腾硬编ffmpeg -i input.mp4 -c:v h264_ascend -b:v 4M -c:a aac -b:a 128k output_npu.mp4注意 NPU 编码器不需要指定-preset硬件编码器的速度是固定的没有软编那种 preset 档位。4.2 实测数据对比测试结果我整理成了表格素材CPU转码耗时NPU转码耗时加速比CPU占用CPU/NPUA1080p 10min8分12秒52秒9.5倍780%/12%B4K 5min12分30秒1分08秒11倍920%/15%C720p 30min9分45秒1分22秒7.1倍650%/10%这个数据还是挺震撼的。1080p 素材从 8 分多钟压缩到 52 秒加速比接近 10 倍。而且 CPU 占用从 780% 降到了 12%意味着转码任务几乎不占用主 CPU 资源服务器可以同时跑其他业务。4K 素材的加速比更高达到 11 倍。这是因为 4K 分辨率下 CPU 软编的计算量急剧增加而 NPU 的硬件编码器处理 4K 和 1080p 的差距没有 CPU 那么大所以相对优势更明显。720p 素材的加速比最低7.1 倍。原因是低分辨率下 CPU 软编本身就不算太慢而且 NPU 编码器有固定的启动开销素材越长这个开销占比越小。但即便如此7 倍的提升也足够可观了。4.3 画质对比与码率控制速度上去了画质能不能接受是另一个关键问题。我用 VMAF 做了客观画质评估以原始素材为参考对比 CPU 和 NPU 转码后的画质素材CPU VMAFNPU VMAF差距A93.291.8-1.4B94.592.6-1.9C92.891.2-1.6NPU 转码的 VMAF 比 CPU 低 1.4 到 1.9 分。这个差距在大多数场景下是可以接受的人眼几乎看不出明显区别。但如果你是做影视级后期或者对画质有极致要求的场景这个差距可能需要考虑。码率控制方面NPU 编码器支持 CBR、VBR、AVBR 三种模式。实测下来VBR 模式下实际码率跟目标码率的偏差在 5% 以内CBR 模式下偏差在 2% 以内控制精度还是不错的。实操心得如果对画质要求高可以适当提高 NPU 转码的目标码率比如比 CPU 转码高 10% 到 15%这样 VMAF 差距可以缩小到 1 分以内而文件体积增加有限。5. 常见问题与排查技巧实录5.1 编码器初始化失败这是最常见的问题报错信息通常是Failed to init ascend encoder或者aclrtMalloc failed。排查思路分三步走第一检查 NPU 是否被其他进程占用。用npu-smi info看芯片状态如果显示busy说明有别的进程在用。昇腾 310P 的编码器资源是独占的同一时间只能有一个进程调用编码单元。第二检查 CANN 环境变量是否生效。echo $LD_LIBRARY_PATH看看有没有包含 CANN 的 lib64 路径。很多人编译的时候设了环境变量但运行的时候忘了 source导致找不到动态库。第三检查驱动版本和 CANN 版本是否匹配。用npu-smi info看驱动版本用atc --version看 CANN 版本对照昇腾官方的版本配套表确认。5.2 转码过程中断或花屏如果转码到一半报错退出或者输出视频有花屏、绿屏通常是以下几个原因输入素材的编码格式不支持。昇腾 310P 的硬件解码器只支持 H.264 和 H.265如果你输入的是 MPEG-2、VP9 这些格式需要先软解再硬编或者先转成 H.264 再处理。输入素材的色度采样是 4:2:2 或 4:4:4。硬件编解码器只支持 4:2:0遇到其他采样格式需要先做格式转换。输入素材的位深是 12bit。硬件只支持 8bit 和 10bit12bit 需要先转成 10bit。解决办法是在 FFmpeg 命令里加滤镜做预处理ffmpeg -i input.mp4 -vf formatyuv420p -c:v h264_ascend -b:v 4M output.mp45.3 多路并发时的资源竞争昇腾 310P 单卡的编码能力是 1080p240fps理论上可以跑 8 路 1080p30fps。但实际测试发现如果同时启动 8 个 FFmpeg 进程每个进程都去初始化编码器会出现资源竞争部分进程初始化失败。正确的做法是用 FFmpeg 的多路复用能力在一个进程里处理多路输入。或者用任务队列控制并发数实测下来单卡同时跑 6 路比较稳定留一点余量给解码和其他操作。# 单进程处理多路输入的示例 ffmpeg -i input1.mp4 -i input2.mp4 \ -map 0 -c:v h264_ascend -b:v 4M output1.mp4 \ -map 1 -c:v h264_ascend -b:v 4M output2.mp45.4 常见问题速查表问题现象可能原因解决方法编码器初始化失败NPU被占用/环境变量未生效/版本不匹配检查npu-smi状态确认LD_LIBRARY_PATH核对版本配套表转码中断输入格式不支持/色度采样不匹配加format滤镜预处理确认输入编码格式输出花屏位深不支持/解码异常转成8bit或10bit检查输入文件完整性多路并发失败编码器资源竞争减少并发数或改用单进程多路复用速度不达预期解码成为瓶颈/PCIe带宽不足检查输入素材解码方式确认PCIe插槽带宽6. 一些实战优化经验6.1 解码环节的优化很多人只关注编码加速忽略了解码。如果输入素材是 H.264 的用 CPU 软解再送给 NPU 硬编解码环节可能成为瓶颈。正确的做法是解码也用 NPU 硬解ffmpeg -c:v h264_ascend -i input.mp4 -c:v h264_ascend -b:v 4M output.mp4这样解码和编码都走硬件CPU 占用可以降到 5% 以下。但要注意如果输入素材的编码格式 NPU 不支持硬解那就只能软解这时候整体速度会受限于解码环节。6.2 内存和显存的管理昇腾 310P 有独立的内存空间FFmpeg 插件会在初始化时申请一块设备内存用于存放帧数据。如果转码分辨率很高或者并发路数多设备内存可能不够用。可以通过环境变量调整内存池大小export ASCEND_RT_MEM_POOL_SIZE2048单位是 MB默认值比较保守适当调大可以避免频繁申请释放内存带来的开销。但也不要调太大设备内存是有限的调太大反而会导致初始化失败。6.3 批量转码的脚本模板最后分享一个我实际在用的批量转码脚本模板用 Bash 写的支持断点续传和日志记录#!/bin/bash INPUT_DIR/data/input OUTPUT_DIR/data/output LOG_FILE/var/log/transcode.log FFMPEG/usr/local/ffmpeg-ascend/bin/ffmpeg mkdir -p $OUTPUT_DIR for file in $INPUT_DIR/*.mp4; do filename$(basename $file) output$OUTPUT_DIR/$filename if [ -f $output ]; then echo $(date) SKIP: $filename already exists $LOG_FILE continue fi echo $(date) START: $filename $LOG_FILE $FFMPEG -c:v h264_ascend -i $file \ -c:v h264_ascend -b:v 4M \ -c:a aac -b:a 128k \ -y $output $LOG_FILE 21 if [ $? -eq 0 ]; then echo $(date) DONE: $filename $LOG_FILE else echo $(date) FAIL: $filename $LOG_FILE rm -f $output fi done这个脚本的逻辑很简单遍历输入目录如果输出文件已存在就跳过否则调用 FFmpeg 转码成功记录 DONE失败删除半成品并记录 FAIL。配合 crontab 定时执行就能实现无人值守的批量转码。6.4 关于成本的一点个人看法最后聊一下成本。昇腾 310P 单卡的价格大概在几千到一万出头具体看采购渠道和批量。对比同价位的 NVIDIA 显卡NPU 在视频编解码的吞吐量上有优势而且功耗更低72W 的功耗对服务器电源和散热压力小很多。但 NPU 的生态确实不如 CUDA 成熟遇到问题查资料的时候中文社区的内容相对有限很多时候需要自己看源码和日志去定位。如果你团队里有熟悉昇腾平台的人或者愿意花时间踩坑那 NPU 转码方案的性价比是很高的。如果追求开箱即用、生态完善那可能还是得考虑其他方案。我在实际使用中最大的体会是NPU 转码不是银弹它适合的是“批量、标准、对画质要求不极端”的场景。如果你的业务正好符合这个画像那昇腾 310P 加 FFmpeg 的组合值得一试。转码速度提升一个数量级的同时还能把 CPU 解放出来跑其他业务这笔账算下来是划算的。