OpenAPV编码器API输出格式优化：从raw_bitstream_access_unit到access_unit

OpenAPV编码器API输出格式优化：从raw_bitstream_access_unit到access_unit

openapv OpenAPV 项目地址: https://gitcode.com/gh_mirrors/op/openapv

背景介绍

OpenAPV项目是一个开源的视频编解码器实现，专注于提供高效的视频压缩解决方案。在视频编码过程中，编码器输出的数据格式直接影响后续存储和传输的效率。

问题发现

在OpenAPV的编码器API(oapve_encode)实现中，当前输出的是raw_bitstream_access_unit格式数据。这种格式会在每个访问单元(Access Unit)前添加4字节的au_size字段，表示该访问单元的大小。然而，这种设计在实际应用中存在一些不便：

1. 当用户需要将编码输出存储为ISOBMFF(MP4)格式的样本(Sample)时，需要手动去除这4字节的au_size字段
2. 增加了额外的处理步骤，影响编码到封装的工作流程效率

技术分析

raw_bitstream_access_unit格式

raw_bitstream_access_unit格式定义在APV规范中，其结构为：

au_size(4字节) + access_unit数据

其中au_size字段表示后续access_unit数据的大小。

ISOBMFF样本格式

在ISOBMFF(MP4)容器格式中，视频样本通常直接存储编码后的数据。虽然APV的ISOBMFF样本格式规范后来更新为也包含au_length字段(语义与au_size相同)，但这种设计存在争议：

1. ISOBMFF本身通过stsz盒已经记录了每个样本的大小
2. 重复存储大小信息造成冗余
3. 增加了数据解析的复杂性

解决方案

OpenAPV项目组经过讨论后决定：

1. 保持对raw_bitstream_access_unit格式的兼容支持
2. 新增选项允许编码器直接输出不包含au_size字段的纯access_unit数据
3. 该选项应在编码器创建时进行配置

这种设计既满足了需要原始access_unit数据的用户需求，又保持了与现有规范的兼容性。

技术决策考量

项目维护者解释了采用当前设计的原因：

1. 与AVC(H.264)的length+NALU格式保持一致，便于现有解析器的复用
2. 允许一个样本盒中包含多个访问单元，为未来扩展留下空间
3. 已被多家操作系统和芯片厂商实现，保持兼容性很重要

实际应用建议

对于不同使用场景的开发人员：

1. 如果目标输出是ISOBMFF文件且不需要au_size字段，应在编码器创建时配置相应选项
2. 如果需要与其他APV系统交互，建议保留au_size字段以确保兼容性
3. 在处理现有APV流时，应注意检查au_size/au_length字段的存在

总结

OpenAPV对编码器输出格式的优化体现了在标准兼容性和实际应用便利性之间的平衡。开发人员应根据具体应用场景选择合适的输出格式，理解不同格式的设计考量可以更好地集成APV编码器到多媒体处理流程中。

openapv OpenAPV 项目地址: https://gitcode.com/gh_mirrors/op/openapv