这几年做视频分发的人几乎都绕不开AV1这个格式。省带宽、压画质、跨平台播放兼容性逐步成熟都是它的优势但真到自己搭建编码服务时第一步就卡在编译上FFmpeg默认不带AV1编码器想用libaom-av1必须自己把库编进来。这篇文章就把这条编译链路完整走一遍从工具链准备、libaom构建、FFmpeg配置、编码实测到常见报错全部按实际踩坑的经验来写。适合想把AV1编码能力加入现有FFmpeg的开发者也可以当作离线转码方案搭建的参考。1. 为什么要在FFmpeg中加上AV1编解码能力1.1 AV1与libaom-av1的关系先把这个最基本的概念说清楚。AV1不是某个具体软件而是一个视频编码标准它规定了码流怎么组织、怎么解码类似H.264、H.265那样的语法规范。标准本身不会编码真正干活的是实现这个标准的编码器库。libaom就是AV1标准的官方参考实现FFmpeg中被集成后以libaom-av1的名字对外提供服务。FFmpeg对AV1的支持分成解和编两条线。解码侧不需要libaom也能跑FFmpeg自带的av1解码器以及通过libdav1d接入的解码器都能正常播放AV1视频。所以很多人装上某版本FFmpeg后发现能放AV1就误以为也能压AV1真到编码时一查才发现没有编码器。编码侧是另一回事FFmpeg本身没有内置AV1编码器实现必须通过外部库引入。libaom-av1是目前接入最完整的方案这也是标题里这个编译动作存在的意义。实际开发中我建议把能解码和能编码当成两件事看待。排查环境时先跑ffmpeg -encoders | grep aom确认编码器存在再去处理后面的参数问题这个习惯能帮你少走很多弯路。1.2 编码器选型libaom、SVT-AV1、Rav1e怎么选AV1生态里不止libaom一个编码器。SVT-AV1以多线程优化见长编码速度快质量也能打Rav1e是Rust生态的代表适合深度定制。选型时不能只看压缩率还要看FFmpeg的集成成熟度和团队维护节奏。编码器特点适用场景libaom-av1官方参考实现参数最全压缩率上限高离线转码、高质量存档、标准对照SVT-AV1并行性能好编码速度快软硬件适配广高吞吐转码、近实时场景Rav1e组件化设计Rust实现定制灵活实验性开发、需要深度替换模块的场景如果只推一个入门选择我建议先打通libaom-av1。原因很直接它是AV1标准的参考实现FFmpeg对它的参数封装最完整无论crf、cpu-used这类高频参数还是aom-params传递底层控制项支持度都最好。SVT-AV1虽然速度快但它的调用方式、参数语义和libaom不同混在一起排查问题时容易把概念搅浑。这里要补充一个实际工作中的判断如果你的目标是给高并发转码服务做支撑libaom默认的编码速度会拖后腿。libaom追求的是高压缩率同质量下体积更小代价是耗时更长。SVTAV1走的是并行优化路线多核利用率更高。所以我一般这样定调先花一次编译时间把libaom-av1跑通把质量链路验证好再视吞吐需求引入SVT-AV1两条路子共存也完全没问题。2. 编译环境与版本搭配2.1 工具链准备编译libaom本身不复杂但依赖项一个都不能少。主力工具链是GCC、CMake、NASM、pkg-config。GCC版本建议8以上尽量新一点。AV1编码用到的现代CPU指令集优化在旧编译器上可能无法完全展开编出来的库性能会打折扣。CMake建议3.16以上libaom新版本对CMake版本有硬性要求小版本太老会在构建阶段直接报错。NASM是整个环境里最容易漏掉的一项。libaom的高性能汇编代码依赖NASM来生成没有NASM时CMake会自动关闭一部分汇编优化路径。这不是不能编但编出来的库在x86平台上编码速度会有肉眼可见的差距。我自己实测过同样一段720P素材有没有NASM优化单线程编码耗时能差将近一半。所以在编译阶段多花一分钟装NASM后面跑任务会省回大量时间。如果你是在Debian系的Linux发行版上操作依赖安装一般这样处理sudo apt update sudo apt install build-essential cmake nasm pkg-config git这是最基础的一套实际编译FFmpeg时还可能用到其他库但就libaom而言已经足够。装完之后用nasm -v确认版本如果发行版自带的NASM版本太旧建议手动装新版。libaom对NASM版本的最低要求在2.13左右低于这个版本同样会关闭部分优化。2.2 FFmpeg与libaom的版本搭配策略版本搭配是编译成功与否的关键也是最容易翻车的点。我遇到过的典型场景是FFmpeg是新版本libaom却拉了个main分支最新代码然后configure阶段报出版本兼容错误或者编译倒是过了但运行时编码器初始化失败。稳定做法是两边都用发布分支不要追新。FFmpeg的版本号从5.x到7.x都支持libaom选哪一个取决于你项目里的其他依赖。libaom则建议选已经发布的稳定tag避开main分支的频繁改动。main分支往往超前于FFmpeg封装层支持的接口强行使用时接口签名对不上问题很难排查。版本呼应还有一个容易被忽略的点pkg-config元信息。libaom安装后会在lib/pkgconfig下生成aom.pcFFmpeg configure阶段就是通过这个文件判断libaom是否存在和版本的。如果你系统里另外装了某个软件自带的aom.pc路径又没有隔离FFmpeg有可能找到旧版本导致明明编译了新版libaom却在配置时报错。这个问题的处理方法后文会在排查部分专门展开。3. libaom库的完整编译过程3.1 获取源码与分支选择libaom源码直接从官方git仓库拉取建议先看tag列表再选择具体的稳定版本。日常使用时我习惯在aom源码目录里执行git clone 官方libaom源码仓库 cd aom git tag | tail -20从输出中选择一个看起来稳定的release版本。判断标准不是版本号最大而是看这个tag是否已经被多个下游项目采用。以我个人的经验对外发布的编码服务不要选太新的tag最好让libaom版本比FFmpeg发布晚一个身位这样FFmpeg封装层的兼容性检查已经覆盖过坑最少。源码目录结构不用过于关心重点看构建目录怎么安排。我习惯在源码根目录下建build目录所有编译中间产物都放这里。这样源码目录干净日后想切换libaom版本只需换tag后重建build目录不会被旧的CMake缓存干扰。3.2 CMake配置参数说明libaom通过CMake构建常用配置项围绕安装路径、库类型、测试和文档开关展开。最小且常用的配置如下cd aom mkdir build cd build cmake .. \ -DCMAKE_INSTALL_PREFIX/usr/local \ -DBUILD_SHARED_LIBS0 \ -DENABLE_TESTS0 \ -DENABLE_DOCS0 make -j$(nproc) sudo make installCMAKE_INSTALL_PREFIX决定最终库文件和头文件装到哪里默认/usr/local通常不用改。如果你希望项目里多个版本的libaom共存可以改成带版本标识的路径比如自定义目录FFmpeg编译时通过pkg-config路径指过去即可。BUILD_SHARED_LIBS0是我强烈建议保持的默认选择。关闭共享库后生成的是libaom.a静态库FFmpeg在链接阶段直接把它编进可执行文件。这样部署时不需要额外带上libaom的动态库换机器运行也不会出现libaom.so not found的幺蛾子。运维成本低排查问题也少一个维度。ENABLE_TESTS和ENABLE_DOCS建议关闭。libaom的测试用例编译量不小文档生成也会拉长构建时间。如果只是给FFmpeg提供编码器能力这两项都用不上。想省编译时间的话还可以把ENABLE_TOOLS0加上跳过aomenc这类命令行工具的编译。不过这个开关可选保存一份完整的构建产物有时也方便后续单独做编码实验。3.3 安装路径与验证make install完成后按顺序检查三样东西库文件、头文件、pkg-config文件。ls /usr/local/lib/libaom.a ls /usr/local/include/aom/aom_encoder.h pkg-config --modversion aom如果pkg-config命令找不到aom多半是PKG_CONFIG_PATH没把/usr/local/lib/pkgconfig加进去。此时可以先执行export PKG_CONFIG_PATH/usr/local/lib/pkgconfig:$PKG_CONFIG_PATH再执行pkg-config --modversion aom验证。这里建议直接把这条export写进shell配置文件否则每次开新终端编译FFmpeg时都要重新设置一次很容易漏掉。还有一个容易被忽略的细节如果系统里本来就有系统源安装的旧版aompkg-config可能优先找到系统目录下的aom.pc。这时候要么用-DCMAKE_INSTALL_PREFIX把新版libaom装到独立目录并调整PKG_CONFIG_PATH顺序要么卸载旧包。我遇到过多次混用导致FFmpeg配置阶段显示找到了libaom编译后却链接到旧版本的情况表现非常隐蔽。4. FFmpeg集成libaom-av1的完整编译流程4.1 configure的关键配置项FFmpeg源码获取后进入源码根目录执行configure。和libaom相关的核心配置就是--enable-libaom其余根据项目需要裁剪。git clone 官方FFmpeg源码仓库 cd ffmpeg ./configure \ --enable-libaom \ --enable-gpl \ --disable-doc \ --disable-debug \ --prefix/usr/local为什么需要--enable-gpl这里顺带说明FFmpeg的GPL选项会影响一些滤镜和库的许可策略若项目中只用libaom它本身不是强制依赖GPL的但开启--enable-gpl后后续接x264、x265等GPL库会少很多麻烦。我个人习惯一次性开启避免二次编译时又要加参数重新跑来。非GPL场景如果确定不需要也可以不加我只说常见做法。configure输出里有一段是编码器的汇总执行后别忘了回头看一眼确认包含Enabled encoders: libaom-av1看到这行才说明libaom真正被FFmpeg接受了。如果没出现直接往下走make也白搭。顺便提一句configure阶段的日志建议保留很多问题排查时需要回看那一大段输出。4.2 编译安装与路径注意configure通过后就是常规编译安装make -j$(nproc) sudo make installlibaom的编译量不小FFmpeg的全量编译也得好几分钟。第一次编译建议make -j$(nproc)直接用满所有核心如果内存吃紧导致编译中断再降成-j4重试。安装完成后用which ffmpeg确认找到的是你自己编译的二进制而不是系统预装版本。如果系统里存在包管理器安装的FFmpeg有时候命令路径会被旧版覆盖这时需要调整PATH顺序或者明确指定新编译FFmpeg的路径。深度经验是编译前留意FFmpeg的--pkg-config-flags--static选项。它会让pkg-config以静态库方式解析依赖。既然libaom是用静态库编出来的加上这个参数能避免链接阶段动态库和静态库混着找。不过这不是强制性配置项某些环境下反而会引起别的问题我按需建议不把它写进默认命令里。4.3 功能验证与编码参数速查编译安装完后第一件事验证能力ffmpeg -encoders | grep aom ffmpeg -decoders | grep aom编码器一行应该显示libaom-av1。现在就可以跑一个最基础的压缩测试ffmpeg -y -i input.mp4 -c:v libaom-av1 -b:v 0 -crf 30 -cpu-used 4 -row-mt 1 out.webm参数含义逐个说清楚。-c:v libaom-av1指定AV1编码器-b:v 0配合crf使用强制让码率控制进入质量模式crf是libaom的质量因子取值范围0到63数值越小质量越高。日常网络分发我用28到35之间存档或高要求场景再往低走。cpu-used控制编码速度0最慢画质最好8最快但细节损失明显编码服务一般取3到5比较平衡。row-mt 1是行级多线程开关多核机器上能明显提升编码吞吐建议默认开启。运行过程中你会观察到编码速度非常慢每秒几帧甚至不到1帧都算正常。libaom-av1的定位就是离线高质量压缩耐心等结果就好。编码完成后用ffprobe确认输出流的codec_name是av1并检查实际码率是否落在预期范围内。5. 常见问题与排查心得5.1 configure阶段最常踩的坑第一个遇到最多的问题是configure输出里找不到libaom。多数情况不是FFmpeg的问题而是pkg-config没找到aom.pc。优先执行pkg-config --modversion aom自查环境返回为空就按前面说的导出PKG_CONFIG_PATH再试。如果返回了版本号但FFmpeg仍然不认多半是版本匹配异常检查libaom是否太新或太旧。第二个问题是NASM导致libaom装配优化关闭。这类问题不会让configure失败而是让FFmpeg也能编过但编码性能极差。排查方法是回到libaom的CMake输出里看是否提示NASM not found。如果确认没装补装后需要重新执行一次libaom的cmake和make install并删掉build目录重建避免缓存影响。第三个问题更容易被忽略FFmpeg源码目录里之前编过其他配置旧配置缓存干扰了新的configure结果。遇到诡异报错时我习惯在FFmpeg源码根目录执行make distclean清掉所有旧配置和中间产物再重新configure。这个方法能解决大量明明参数对但就是不行的玄学问题。5.2 运行阶段容易误判的情况运行阶段最常见的问题是编码时提示Unknown encoder libaom-av1。这个错误出现时先别怀疑命令写错要怀疑当前运行的ffmpeg是不是自己编译的那个版本。有人compile和运行在不同机器上或者PATH指向了系统旧版都会出现这种尴尬局面。用which ffmpeg和ffmpeg -version对比一下编译时间就清楚了。另一个高频问题是编码输出无法播放。这里要分清是封装问题还是播放器问题。AV1目前最稳妥的封装容器是WebMMP4也支持但老旧播放器兼容性差。建议先输出WebM并尝试用较新的浏览器打开比如Chrome或Edge对WebM AV1支持都比较成熟。如果换了播放器还是不行再用ffprobe检查输出流的编码参数确认是否存在不支持的像素格式或色彩信息。还有一类问题是crf模式不生效。某些FFmpeg版本对libaom-av1的码率控制处理比较绕表现是设了-crf但输出码率还是乱跳。遇到这种情况可以绕道用底层参数传递ffmpeg -y -i input.mp4 -c:v libaom-av1 \ -aom-params cq-level30:aq-mode1 \ -b:v 0 -cpu-used 4 -row-mt 1 out.webmcq-level是libaom内部的质量等级概念对应crf数值。通过aom-params直接透传能绕过FFmpeg层的一些默认逻辑排查时多一个备选路径。5.3 编码质量和速度的调优实操libaom-av1最让人纠结的就是质量和速度的平衡。我的经验是先用两遍编码处理固定码率需求再用CQ模式处理存档需求。固定码率分发场景两遍编码能让码率分配更合理。第一遍空跑分析视频复杂度第二遍真正编码ffmpeg -y -i input.mp4 -c:v libaom-av1 -b:v 2M -pass 1 -an -f null /dev/null ffmpeg -y -i input.mp4 -c:v libaom-av1 -b:v 2M -pass 2 -cpu-used 5 -row-mt 1 out.webm第一遍输出到/dev/null会把音频也丢弃掉省去无用解码开销。第二遍才是实际产物cpu-used可以比第一遍稍高一些因为第一遍已经建立了分析数据第二遍的搜索空间更小。存档场景我倾向用CQ模式也就是前面说的-crf加-b:v 0。这种方式下码率根据画面复杂度自动浮动适合保证质量优先的转码任务。最后整理一个参数速查表方便日常调用时直接参考参数推荐值说明-cpu-used3-5速度与质量平衡点-row-mt1行级多线程强烈建议开启-crf28-35质量档位小值高质量-b:v0或固定码率0表示CQ模式-aom-params按需底层参数透传通道做高分辨率编码时还可以在aom-params里加tile-columns和tile-rows让画面分块并行编码4K及以上分辨率效果显著。我实测在8核机器上编4K素材增加分块后编码速度能提升接近一倍画质影响不大。再补充一个10bit编码的注意点。libaom支持10bit输入但默认FFmpeg会按8bit处理。如果你的源素材是HDR或者高位深编码命令里记得加-pix_fmt yuv420p10le否则会先转成8bit再编码画质损失不可逆。这一点在调试时很容易忽略效果却非常直接。最后说几点实际体会编译这条路认真走一遍之后你会发现真正花时间的不是敲命令而是理清依赖和版本之间的关系。libaom装好只是开始FFmpeg版本、pkg-config路径、NASM优化、编码参数四者要一起配合才能得到稳定可用的AV1编码环境。我个人的建议是先跑通最小链路再做性能优化最后才考虑多编码器并行接入。遇到xxxx奇怪问题时make distclean重新configure往往比盲目查日志更快让你找到方向。希望这篇文章能帮你少踩几个坑。
这几年做视频分发的人几乎都绕不开AV1这个格式。省带宽、压画质、跨平台播放兼容性逐步成熟都是它的优势但真到自己搭建编码服务时第一步就卡在编译上FFmpeg默认不带AV1编码器想用libaom-av1必须自己把库编进来。这篇文章就把这条编译链路完整走一遍从工具链准备、libaom构建、FFmpeg配置、编码实测到常见报错全部按实际踩坑的经验来写。适合想把AV1编码能力加入现有FFmpeg的开发者也可以当作离线转码方案搭建的参考。1. 为什么要在FFmpeg中加上AV1编解码能力1.1 AV1与libaom-av1的关系先把这个最基本的概念说清楚。AV1不是某个具体软件而是一个视频编码标准它规定了码流怎么组织、怎么解码类似H.264、H.265那样的语法规范。标准本身不会编码真正干活的是实现这个标准的编码器库。libaom就是AV1标准的官方参考实现FFmpeg中被集成后以libaom-av1的名字对外提供服务。FFmpeg对AV1的支持分成解和编两条线。解码侧不需要libaom也能跑FFmpeg自带的av1解码器以及通过libdav1d接入的解码器都能正常播放AV1视频。所以很多人装上某版本FFmpeg后发现能放AV1就误以为也能压AV1真到编码时一查才发现没有编码器。编码侧是另一回事FFmpeg本身没有内置AV1编码器实现必须通过外部库引入。libaom-av1是目前接入最完整的方案这也是标题里这个编译动作存在的意义。实际开发中我建议把能解码和能编码当成两件事看待。排查环境时先跑ffmpeg -encoders | grep aom确认编码器存在再去处理后面的参数问题这个习惯能帮你少走很多弯路。1.2 编码器选型libaom、SVT-AV1、Rav1e怎么选AV1生态里不止libaom一个编码器。SVT-AV1以多线程优化见长编码速度快质量也能打Rav1e是Rust生态的代表适合深度定制。选型时不能只看压缩率还要看FFmpeg的集成成熟度和团队维护节奏。编码器特点适用场景libaom-av1官方参考实现参数最全压缩率上限高离线转码、高质量存档、标准对照SVT-AV1并行性能好编码速度快软硬件适配广高吞吐转码、近实时场景Rav1e组件化设计Rust实现定制灵活实验性开发、需要深度替换模块的场景如果只推一个入门选择我建议先打通libaom-av1。原因很直接它是AV1标准的参考实现FFmpeg对它的参数封装最完整无论crf、cpu-used这类高频参数还是aom-params传递底层控制项支持度都最好。SVT-AV1虽然速度快但它的调用方式、参数语义和libaom不同混在一起排查问题时容易把概念搅浑。这里要补充一个实际工作中的判断如果你的目标是给高并发转码服务做支撑libaom默认的编码速度会拖后腿。libaom追求的是高压缩率同质量下体积更小代价是耗时更长。SVTAV1走的是并行优化路线多核利用率更高。所以我一般这样定调先花一次编译时间把libaom-av1跑通把质量链路验证好再视吞吐需求引入SVT-AV1两条路子共存也完全没问题。2. 编译环境与版本搭配2.1 工具链准备编译libaom本身不复杂但依赖项一个都不能少。主力工具链是GCC、CMake、NASM、pkg-config。GCC版本建议8以上尽量新一点。AV1编码用到的现代CPU指令集优化在旧编译器上可能无法完全展开编出来的库性能会打折扣。CMake建议3.16以上libaom新版本对CMake版本有硬性要求小版本太老会在构建阶段直接报错。NASM是整个环境里最容易漏掉的一项。libaom的高性能汇编代码依赖NASM来生成没有NASM时CMake会自动关闭一部分汇编优化路径。这不是不能编但编出来的库在x86平台上编码速度会有肉眼可见的差距。我自己实测过同样一段720P素材有没有NASM优化单线程编码耗时能差将近一半。所以在编译阶段多花一分钟装NASM后面跑任务会省回大量时间。如果你是在Debian系的Linux发行版上操作依赖安装一般这样处理sudo apt update sudo apt install build-essential cmake nasm pkg-config git这是最基础的一套实际编译FFmpeg时还可能用到其他库但就libaom而言已经足够。装完之后用nasm -v确认版本如果发行版自带的NASM版本太旧建议手动装新版。libaom对NASM版本的最低要求在2.13左右低于这个版本同样会关闭部分优化。2.2 FFmpeg与libaom的版本搭配策略版本搭配是编译成功与否的关键也是最容易翻车的点。我遇到过的典型场景是FFmpeg是新版本libaom却拉了个main分支最新代码然后configure阶段报出版本兼容错误或者编译倒是过了但运行时编码器初始化失败。稳定做法是两边都用发布分支不要追新。FFmpeg的版本号从5.x到7.x都支持libaom选哪一个取决于你项目里的其他依赖。libaom则建议选已经发布的稳定tag避开main分支的频繁改动。main分支往往超前于FFmpeg封装层支持的接口强行使用时接口签名对不上问题很难排查。版本呼应还有一个容易被忽略的点pkg-config元信息。libaom安装后会在lib/pkgconfig下生成aom.pcFFmpeg configure阶段就是通过这个文件判断libaom是否存在和版本的。如果你系统里另外装了某个软件自带的aom.pc路径又没有隔离FFmpeg有可能找到旧版本导致明明编译了新版libaom却在配置时报错。这个问题的处理方法后文会在排查部分专门展开。3. libaom库的完整编译过程3.1 获取源码与分支选择libaom源码直接从官方git仓库拉取建议先看tag列表再选择具体的稳定版本。日常使用时我习惯在aom源码目录里执行git clone 官方libaom源码仓库 cd aom git tag | tail -20从输出中选择一个看起来稳定的release版本。判断标准不是版本号最大而是看这个tag是否已经被多个下游项目采用。以我个人的经验对外发布的编码服务不要选太新的tag最好让libaom版本比FFmpeg发布晚一个身位这样FFmpeg封装层的兼容性检查已经覆盖过坑最少。源码目录结构不用过于关心重点看构建目录怎么安排。我习惯在源码根目录下建build目录所有编译中间产物都放这里。这样源码目录干净日后想切换libaom版本只需换tag后重建build目录不会被旧的CMake缓存干扰。3.2 CMake配置参数说明libaom通过CMake构建常用配置项围绕安装路径、库类型、测试和文档开关展开。最小且常用的配置如下cd aom mkdir build cd build cmake .. \ -DCMAKE_INSTALL_PREFIX/usr/local \ -DBUILD_SHARED_LIBS0 \ -DENABLE_TESTS0 \ -DENABLE_DOCS0 make -j$(nproc) sudo make installCMAKE_INSTALL_PREFIX决定最终库文件和头文件装到哪里默认/usr/local通常不用改。如果你希望项目里多个版本的libaom共存可以改成带版本标识的路径比如自定义目录FFmpeg编译时通过pkg-config路径指过去即可。BUILD_SHARED_LIBS0是我强烈建议保持的默认选择。关闭共享库后生成的是libaom.a静态库FFmpeg在链接阶段直接把它编进可执行文件。这样部署时不需要额外带上libaom的动态库换机器运行也不会出现libaom.so not found的幺蛾子。运维成本低排查问题也少一个维度。ENABLE_TESTS和ENABLE_DOCS建议关闭。libaom的测试用例编译量不小文档生成也会拉长构建时间。如果只是给FFmpeg提供编码器能力这两项都用不上。想省编译时间的话还可以把ENABLE_TOOLS0加上跳过aomenc这类命令行工具的编译。不过这个开关可选保存一份完整的构建产物有时也方便后续单独做编码实验。3.3 安装路径与验证make install完成后按顺序检查三样东西库文件、头文件、pkg-config文件。ls /usr/local/lib/libaom.a ls /usr/local/include/aom/aom_encoder.h pkg-config --modversion aom如果pkg-config命令找不到aom多半是PKG_CONFIG_PATH没把/usr/local/lib/pkgconfig加进去。此时可以先执行export PKG_CONFIG_PATH/usr/local/lib/pkgconfig:$PKG_CONFIG_PATH再执行pkg-config --modversion aom验证。这里建议直接把这条export写进shell配置文件否则每次开新终端编译FFmpeg时都要重新设置一次很容易漏掉。还有一个容易被忽略的细节如果系统里本来就有系统源安装的旧版aompkg-config可能优先找到系统目录下的aom.pc。这时候要么用-DCMAKE_INSTALL_PREFIX把新版libaom装到独立目录并调整PKG_CONFIG_PATH顺序要么卸载旧包。我遇到过多次混用导致FFmpeg配置阶段显示找到了libaom编译后却链接到旧版本的情况表现非常隐蔽。4. FFmpeg集成libaom-av1的完整编译流程4.1 configure的关键配置项FFmpeg源码获取后进入源码根目录执行configure。和libaom相关的核心配置就是--enable-libaom其余根据项目需要裁剪。git clone 官方FFmpeg源码仓库 cd ffmpeg ./configure \ --enable-libaom \ --enable-gpl \ --disable-doc \ --disable-debug \ --prefix/usr/local为什么需要--enable-gpl这里顺带说明FFmpeg的GPL选项会影响一些滤镜和库的许可策略若项目中只用libaom它本身不是强制依赖GPL的但开启--enable-gpl后后续接x264、x265等GPL库会少很多麻烦。我个人习惯一次性开启避免二次编译时又要加参数重新跑来。非GPL场景如果确定不需要也可以不加我只说常见做法。configure输出里有一段是编码器的汇总执行后别忘了回头看一眼确认包含Enabled encoders: libaom-av1看到这行才说明libaom真正被FFmpeg接受了。如果没出现直接往下走make也白搭。顺便提一句configure阶段的日志建议保留很多问题排查时需要回看那一大段输出。4.2 编译安装与路径注意configure通过后就是常规编译安装make -j$(nproc) sudo make installlibaom的编译量不小FFmpeg的全量编译也得好几分钟。第一次编译建议make -j$(nproc)直接用满所有核心如果内存吃紧导致编译中断再降成-j4重试。安装完成后用which ffmpeg确认找到的是你自己编译的二进制而不是系统预装版本。如果系统里存在包管理器安装的FFmpeg有时候命令路径会被旧版覆盖这时需要调整PATH顺序或者明确指定新编译FFmpeg的路径。深度经验是编译前留意FFmpeg的--pkg-config-flags--static选项。它会让pkg-config以静态库方式解析依赖。既然libaom是用静态库编出来的加上这个参数能避免链接阶段动态库和静态库混着找。不过这不是强制性配置项某些环境下反而会引起别的问题我按需建议不把它写进默认命令里。4.3 功能验证与编码参数速查编译安装完后第一件事验证能力ffmpeg -encoders | grep aom ffmpeg -decoders | grep aom编码器一行应该显示libaom-av1。现在就可以跑一个最基础的压缩测试ffmpeg -y -i input.mp4 -c:v libaom-av1 -b:v 0 -crf 30 -cpu-used 4 -row-mt 1 out.webm参数含义逐个说清楚。-c:v libaom-av1指定AV1编码器-b:v 0配合crf使用强制让码率控制进入质量模式crf是libaom的质量因子取值范围0到63数值越小质量越高。日常网络分发我用28到35之间存档或高要求场景再往低走。cpu-used控制编码速度0最慢画质最好8最快但细节损失明显编码服务一般取3到5比较平衡。row-mt 1是行级多线程开关多核机器上能明显提升编码吞吐建议默认开启。运行过程中你会观察到编码速度非常慢每秒几帧甚至不到1帧都算正常。libaom-av1的定位就是离线高质量压缩耐心等结果就好。编码完成后用ffprobe确认输出流的codec_name是av1并检查实际码率是否落在预期范围内。5. 常见问题与排查心得5.1 configure阶段最常踩的坑第一个遇到最多的问题是configure输出里找不到libaom。多数情况不是FFmpeg的问题而是pkg-config没找到aom.pc。优先执行pkg-config --modversion aom自查环境返回为空就按前面说的导出PKG_CONFIG_PATH再试。如果返回了版本号但FFmpeg仍然不认多半是版本匹配异常检查libaom是否太新或太旧。第二个问题是NASM导致libaom装配优化关闭。这类问题不会让configure失败而是让FFmpeg也能编过但编码性能极差。排查方法是回到libaom的CMake输出里看是否提示NASM not found。如果确认没装补装后需要重新执行一次libaom的cmake和make install并删掉build目录重建避免缓存影响。第三个问题更容易被忽略FFmpeg源码目录里之前编过其他配置旧配置缓存干扰了新的configure结果。遇到诡异报错时我习惯在FFmpeg源码根目录执行make distclean清掉所有旧配置和中间产物再重新configure。这个方法能解决大量明明参数对但就是不行的玄学问题。5.2 运行阶段容易误判的情况运行阶段最常见的问题是编码时提示Unknown encoder libaom-av1。这个错误出现时先别怀疑命令写错要怀疑当前运行的ffmpeg是不是自己编译的那个版本。有人compile和运行在不同机器上或者PATH指向了系统旧版都会出现这种尴尬局面。用which ffmpeg和ffmpeg -version对比一下编译时间就清楚了。另一个高频问题是编码输出无法播放。这里要分清是封装问题还是播放器问题。AV1目前最稳妥的封装容器是WebMMP4也支持但老旧播放器兼容性差。建议先输出WebM并尝试用较新的浏览器打开比如Chrome或Edge对WebM AV1支持都比较成熟。如果换了播放器还是不行再用ffprobe检查输出流的编码参数确认是否存在不支持的像素格式或色彩信息。还有一类问题是crf模式不生效。某些FFmpeg版本对libaom-av1的码率控制处理比较绕表现是设了-crf但输出码率还是乱跳。遇到这种情况可以绕道用底层参数传递ffmpeg -y -i input.mp4 -c:v libaom-av1 \ -aom-params cq-level30:aq-mode1 \ -b:v 0 -cpu-used 4 -row-mt 1 out.webmcq-level是libaom内部的质量等级概念对应crf数值。通过aom-params直接透传能绕过FFmpeg层的一些默认逻辑排查时多一个备选路径。5.3 编码质量和速度的调优实操libaom-av1最让人纠结的就是质量和速度的平衡。我的经验是先用两遍编码处理固定码率需求再用CQ模式处理存档需求。固定码率分发场景两遍编码能让码率分配更合理。第一遍空跑分析视频复杂度第二遍真正编码ffmpeg -y -i input.mp4 -c:v libaom-av1 -b:v 2M -pass 1 -an -f null /dev/null ffmpeg -y -i input.mp4 -c:v libaom-av1 -b:v 2M -pass 2 -cpu-used 5 -row-mt 1 out.webm第一遍输出到/dev/null会把音频也丢弃掉省去无用解码开销。第二遍才是实际产物cpu-used可以比第一遍稍高一些因为第一遍已经建立了分析数据第二遍的搜索空间更小。存档场景我倾向用CQ模式也就是前面说的-crf加-b:v 0。这种方式下码率根据画面复杂度自动浮动适合保证质量优先的转码任务。最后整理一个参数速查表方便日常调用时直接参考参数推荐值说明-cpu-used3-5速度与质量平衡点-row-mt1行级多线程强烈建议开启-crf28-35质量档位小值高质量-b:v0或固定码率0表示CQ模式-aom-params按需底层参数透传通道做高分辨率编码时还可以在aom-params里加tile-columns和tile-rows让画面分块并行编码4K及以上分辨率效果显著。我实测在8核机器上编4K素材增加分块后编码速度能提升接近一倍画质影响不大。再补充一个10bit编码的注意点。libaom支持10bit输入但默认FFmpeg会按8bit处理。如果你的源素材是HDR或者高位深编码命令里记得加-pix_fmt yuv420p10le否则会先转成8bit再编码画质损失不可逆。这一点在调试时很容易忽略效果却非常直接。最后说几点实际体会编译这条路认真走一遍之后你会发现真正花时间的不是敲命令而是理清依赖和版本之间的关系。libaom装好只是开始FFmpeg版本、pkg-config路径、NASM优化、编码参数四者要一起配合才能得到稳定可用的AV1编码环境。我个人的建议是先跑通最小链路再做性能优化最后才考虑多编码器并行接入。遇到xxxx奇怪问题时make distclean重新configure往往比盲目查日志更快让你找到方向。希望这篇文章能帮你少踩几个坑。
