libavif项目构建问题解析：与aom编码器集成时的VMAF/Butteraugli依赖问题

问题背景

在多媒体编码领域，libavif作为AVIF图像格式的参考实现库，其与aom编码器的集成是核心功能之一。近期开发者在构建libavif 1.1.0版本时发现，当aom编码器启用了VMAF或Butteraugli调优选项后，构建过程会失败。这个问题涉及到多个开源多媒体组件的复杂交互，值得深入分析。

技术细节分析

依赖关系链

该问题的核心在于复杂的依赖链：

1. libavif依赖aom作为其AV1编码后端
2. aom可以可选地依赖libvmaf或libjxl-butteraugli来实现质量评估算法
3. 当这些可选依赖启用时，需要正确传递链接依赖

构建失败现象

构建失败表现为链接阶段找不到VMAF相关符号，如：

• vmaf_picture_alloc
• vmaf_read_pictures
• vmaf_picture_unref
• vmaf_score_at_index

类似的问题也会出现在Butteraugli实现上，提示缺少JxlButteraugliApiCreate等符号。

根本原因

经过技术团队深入调查，发现问题的根本原因在于：

1. 静态链接处理不当：当aom以静态库形式构建时，其pkg-config文件中的依赖信息（Requires: libvmaf）没有被正确处理。libavif的构建系统未能将这些传递依赖正确引入最终链接阶段。

2. 历史变更影响：两个关键提交影响了这一行为：

   • 移除了从pkg-config获取的链接标志，认为它们会导致重复链接
   • 重构了构建系统，改用目标属性来管理标志和链接库

3. 动态链接场景：即使用户将aom构建为动态库，也需要确保运行时链接器能找到libvmaf.so，这需要正确设置LD_LIBRARY_PATH环境变量。

解决方案

技术团队提出了多层次的解决方案：

1. 静态库场景修复

对于静态链接场景，修正FindAom.cmake模块，使其：

• 区分静态库和动态库情况
• 从pkg-config提取依赖库信息
• 确保传递依赖被正确链接

关键实现包括检查库文件后缀判断链接类型，并使用target_link_libraries正确传递依赖。

2. 动态库场景处理

对于动态链接场景：

• 确保libvmaf.so在运行时链接器搜索路径中
• 通过设置LD_LIBRARY_PATH环境变量解决
• 考虑在安装时自动处理rpath

3. 构建系统改进

长期来看，构建系统需要：

• 更健壮地处理第三方库的传递依赖
• 提供清晰的错误提示
• 支持更多构建场景的自动化配置

验证方法

技术团队提供了详细的验证脚本，包括：

1. 静态库验证脚本：

   • 构建静态libvmaf和libaom
   • 配置CONFIG_TUNE_VMAF选项
   • 验证libavif静态链接构建

2. 动态库验证脚本：

   • 构建动态libvmaf和libaom
   • 确保LD_LIBRARY_PATH正确设置
   • 验证libavif链接和运行时行为

经验总结

这一问题的解决过程为开源多媒体项目集成提供了宝贵经验：

1. 传递依赖处理：当项目引入可选依赖时，构建系统需要全面考虑各种链接场景。

2. ABI稳定性：接口变更需要评估对下游项目的影响，特别是当涉及基础编码库时。

3. 构建系统设计：现代CMake的最佳实践（如目标属性）需要与传统的pkg-config机制良好协同。

4. 测试覆盖：需要增加对可选依赖组合的自动化测试，防止回归问题。

通过这次问题的分析和解决，libavif项目在复杂依赖管理方面又向前迈进了一步，为开发者提供了更可靠的构建体验。