当前位置: 首页 > news >正文

音视频入门基础:AAC专题(3)——AAC的ADTS格式简介

=================================================================

音视频入门基础:AAC专题系列文章:

音视频入门基础:AAC专题(1)——AAC官方文档下载

音视频入门基础:AAC专题(2)——使用FFmpeg命令生成AAC裸流文件

音视频入门基础:AAC专题(3)——AAC的ADTS格式简介

音视频入门基础:AAC专题(4)——ADTS格式的AAC裸流实例分析

音视频入门基础:AAC专题(5)——FFmpeg源码中,判断某文件是否为AAC裸流文件的实现

音视频入门基础:AAC专题(6)——FFmpeg源码中解码ADTS格式的AAC的Header的实现

音视频入门基础:AAC专题(7)——FFmpeg源码中计算AAC裸流每个packet的size值的实现

音视频入门基础:AAC专题(8)——FFmpeg源码中计算AAC裸流AVStream的time_base的实现

音视频入门基础:AAC专题(9)——FFmpeg源码中计算AAC裸流每个packet的duration和duration_time的实现

音视频入门基础:AAC专题(10)——FFmpeg源码中计算AAC裸流每个packet的pts、dts、pts_time、dts_time的实现

=================================================================

一、引言

AAC(Advanced Audio Coding)有两种格式:

1.ADIF(Audio Data Interchange Format,音频数据交换格式):整个流中只包含一个Header(文件头),不能在任意处读取。这种格式基本用不到。

2.ADTS(Audio Data Transport Stream,音频数据传输流):每一帧的音频压缩数据包中都有一个Header,记录音频的采样率、通道数等参数,使得解码可以在流的任何位置开始。所以一般都是用ADTS包装的AAC。

这两种格式的Header不一样,本系列主要针对ADTS格式的AAC进行讲解。首先我们从《音视频入门基础:AAC专题(1)——AAC官方文档下载》下载AAC的标准文档《ISO_IEC_13818-7_2006(E).pdf》和《ISO14496-3-2009.pdf》,以及MP3的标准文档《ISO11172-3.pdf》。现在一般都是用MPEG-4的AAC,所以我们主要阅读《ISO14496-3-2009.pdf》,但是对于从MPEG-2中继承下来的属性,我们需要翻阅《ISO_IEC_13818-7_2006(E).pdf》,对于从MP3中继承下来的属性,我们需要翻阅《ISO11172-3.pdf》。

注:《ISO_IEC_13818-7_2006(E).pdf》总共有202页,《ISO14496-3-2009.pdf》总共有1416页,下面的页数是指在pdf阅读器中显示的页数:

二、ADTS格式的Header

(一)ADTS Header的基本概念

根据《ISO14496-3-2009.pdf》第121页,ADTS序列(ADTS流)由一个个adts音频帧(adts音频压缩数据包)组成。使用syncword分割各个adts音频帧:

根据《ISO14496-3-2009.pdf》第29页,syncword为嵌入在ADTS流中的一种编码,用于标识ADTS音频帧的起始位置:

根据《ISO14496-3-2009.pdf》第122页,adts_variable_header中的number_of_raw_data_blocks_in_frame属性的值为0的情况下,每个adts帧由adts_fixed_header(固定头)、adts_variable_header(可变头)、adts_error_check(错误校验)、raw_data_block(原始数据块)组成:

其中,ADTS Header由adts_fixed_header、adts_variable_header和adts_error_check组成。根据《ISO14496-3-2009.pdf》第123页,adts_fixed_header中的protection_absent属性的值为0时,adts_error_check才会存在CRC校验。所以当protection_absent为0时,adts_error_check占16位(2字节),当protection_absent不为0时,adts_error_check占0位(0字节):

adts_fixed_header固定占28位,adts_variable_header也占28位。所以当protection_absent为0时,ADTS Header占9字节;protection_absent不为0时,ADTS Header占7字节。

(二)adts_fixed_header

根据《ISO14496-3-2009.pdf》第122页,adts_fixed_header包含的属性如下。从下表中可以看到每个属性占的位数,这些属性加起来总共占28位,所以adts_fixed_header固定占28位:

根据《ISO14496-3-2009.pdf》第32页,bslbf(bit string,left bit first)表示比特串,左位在先。

uimsbf(unsigned integer,most significant bit first)表示无符号整数,高位在先。具体可以参考:《uimsbf和 bslbf的含义》:

syncword:占12位。关于syncword属性的值的描述,在《ISO14496-3-2009.pdf》中并没有提到,但是在《ISO_IEC_13818-7_2006(E).pdf》可以找到关于它的说明。从上文我们可以知道,syncword为嵌入在ADTS流中的一种编码,用于标识ADTS帧的起始位置。根据《ISO_IEC_13818-7_2006(E).pdf》第45页,,syncword的每个位都必须被设置为1,也就是0b111111111111:

ID:占1位。根据《ISO14496-3-2009.pdf》第124页,ID为MPEG版本的标识符。如果ADTS流中的音频数据是MPEG-2 AAC,ID被设置为1,如果音频数据是MPEG-4 AAC,其被设置为0:

layer:占2位。根据《ISO_IEC_13818-7_2006(E).pdf》第45页,layer总被设置为00:

protection_absent:占1位。根据《ISO_IEC_13818-7_2006(E).pdf》第45页,protection_absent表示CRC校验是否存在。从上文可以知道,当protection_absent为0时,CRC校验存在,当protection_absent为1时,CRC校验不存在:

profile_ObjectType:占2位。根据《ISO14496-3-2009.pdf》第124页,MPEG版本为MPEG-4时,如果profile_ObjectType为0,AAC的规格为AAC Main;如果profile_ObjectType为1,规格为AAC LC;如果profile_ObjectType为2,规格为AAC SSR;如果profile_ObjectType为3,规格为AAC LTP:

samplingFrequencyIndex:占4位。根据《ISO14496-3-2009.pdf》第59页,samplingFrequencyIndex表示音频的采样频率:

private_bit:占1位。《ISO_IEC_13818-7_2006(E).pdf》和《ISO14496-3-2009.pdf》里面没有对其进行任何说明。在《ISO_IEC_13818-7_2006(E).pdf》第46页,写了想要了解private_bit属性得查阅标准文档《ISO/IEC 11172-3》:

所以我们从https://csclub.uwaterloo.ca/~pbarfuss/ISO11172-3.pdf 下载《ISO11172-3.pdf》,在其第23页终于找到关于private_bit属性的说明了,意思就是private_bit没用:

channel_configuration:占3位。根据《ISO14496-3-2009.pdf》第60页。channel_configuration表示音频声道数。比如channel_configuration值为1表示是单声道(center front speaker);值为2表示是双声道(left, right front speakers);值为3:三声道(center, left, right front speakers);值为4:四声道(center, left, right front speakers, rear surround speakers);值为5:五声道(center, left, right front speakers, left surround, right surround rear speakers);值为6: 5.1声道(center, left, right front speakers, left surround, right surround rear speakers, front low frequency effects speaker);值为7:7.1声道(center, left, right center front speakers, left, right outside front speakers, left surround, right surround rear speakers, front low frequency effects speaker);值为8到15:保留:

original_copy:占1位。该属性继承自mp3里的copyright属性。根据《ISO11172-3.pdf》第24页,如果这个比特位等于0,则表示编码的比特流没有版权,1表示版权受保护:

home:占1位。该属性继承自mp3里的original/home属性。根据《ISO11172-3.pdf》第24页,如果比特流是一个拷贝,home的值为0,如果是原始比特流,则值为1:

(三)adts_variable_header

根据《ISO14496-3-2009.pdf》第122页,adts_variable_header包含的属性如下。从下表中可以看到每个属性占的位数,这些属性加起来总共占28位,所以adts_variable_header固定占28位:

copyright_identification_bit:占1位。根据《ISO_IEC_13818-7_2006(E).pdf》第46页,copyright_identification_bit为72位版权标识字段中的一位:

copyright_identification_start:占1位。根据《ISO_IEC_13818-7_2006(E).pdf》第46页,copyright_identification_start表示copyright_identification_bit音频帧是72位版权标识的第一位。如果没有版权标识传输,此位应保留' 0 ':

aac_frame_length:占13位。根据《ISO_IEC_13818-7_2006(E).pdf》第46页,aac_frame_length为整个ADTS音频帧的长度,包含ADTS Header、错误校验和AAC原始数据块,单位为字节:

adts_buffer_fullness:占11位。根据《ISO_IEC_13818-7_2006(E).pdf》第46页至47页,adts_buffer_fullness为在adt编码过程中,比特储存的状态。如果值为0x7FF,表示比特流是可变速率比特流:

number_of_raw_data_blocks_in_frame:占2位。根据《ISO_IEC_13818-7_2006(E).pdf》第47页,一个ADTS音频帧中有number_of_raw_data_blocks_in_frame + 1个AAC原始数据块。number_of_raw_data_blocks_in_frame的值为0表示该ADTS音频帧中只有一个AAC原始数据块:

三、AAC的samples

根据《ISO14496-3-2009.pdf》第9页,对于标准的MPEG-2/4 AAC,其samples(一帧音频数据中采样的次数)为1024或者960次:

根据《ISO14496-3-2009.pdf》第46页,规格为AAC LC和AAC LTP的AAC,一帧音频数据中采样的次数只允许为1024次:

至于AAC的samples啥时候为960次,我浏览了AAC的标准文档,在里面并没有找到相关说明,AAC的Header中也没有属性用来标识samples是1024还是960次。在微软的官方文章《AAC 解码器》中说明了Microsoft Media Foundation AAC 解码器仅支持1024个样本帧,也就是AAC解码器仅支持的samples为1024不支持960:

我浏览了国外论坛的某些文章《Topic: AAC decoding with a free Windows Library?》、《Support of AAC with 960 samples/frame》,里面写到AAC(AAC Main、AAC LC、AAC SSR、AAC LTP)的samples通常是1024,而DAB+(AAC+、HE AAC v2)的samples是960。所以可以认为目前约定俗成是:AAC(AAC Main、AAC LC、AAC SSR、AAC LTP)的samples是1024,而DAB+(AAC+、HE AAC v2)的samples是960。目前市面上的AAC解码器不支持samples为960的AAC。

FFmpeg源码内部会强制默认AAC(AAC Main、AAC LC、AAC SSR、AAC LTP)的samples是1024,具体可以参考:《音视频入门基础:AAC专题(6)——FFmpeg源码中解码ADTS格式的AAC的Header的实现》。

这个samples(一帧音频数据中采样的次数)非常重要,用于计算一个adts音频帧(adts音频压缩数据包)的时长,具体可以参考:《FFmpeg源码:get_audio_frame_duration、av_get_audio_frame_duration2、av_get_audio_frame_duration函数分析》。

四、AAC的Bit depth

Bit depth(又叫位深度、位元深度、采样深度、采样位数、采样格式)是用于编码每个样本的数字信息位数。简单来说,位元深度衡量的是“精度”。Bit depth越高,信号就越能准确地表示实际模拟声源的振幅。使用最低可能的Bit depth,我们只有两种选择来测量声音的精度:0表示完全静音,1表示最高音量。Bit depth越高,对音频编码的精度越高。举个例子:CD质量的音频的Bit depth是标准的16位,有216(或65536)个音量可供选择。

Bit depth对于PCM编码是固定的,但对于有损压缩编解码器(如MP3和AAC),它是在编码期间计算的,并且可以因采样而异。

也就是说Bit depth只对PCM数字信号有意义。非PCM格式,如AAC这种有损压缩格式,Bit depth是没有意义的。所以AAC裸流的Header中没有Bit depth信息,WAV音频文件因为一般存贮的是PCM音频数据,所以WAV Header中才有Bit depth信息,具体可以参考:《音视频入门基础:WAV专题(2)——WAV格式简介》。

五、参考文章

《Audio encoding demystified》


http://www.mrgr.cn/news/31535.html

相关文章:

  • ⚡️如何在 React 和 Next.js 项目里优雅的使用 Zustand
  • 【珠海科技学院主办,暨南大学协办 | IEEE出版 | EI检索稳定 】2024年健康大数据与智能医疗国际会议(ICHIH 2024)
  • 深入理解指针
  • c语言中孤立位(loner)的使用
  • SwiftUI开发教程系列 - 第十二章:本地化与多语言支持
  • Note1: Linux 多进程服务器端
  • python 多边形越界
  • Python | Leetcode Python题解之第420题强密码检验器
  • 煤矿智慧矿井数据集 (1.煤矿采掘工作面智能分析数据集2.煤矿井下钻场智能分析数据集 )
  • zabbix7.0容器化部署测试--(1)准备容器镜像
  • Rust 文件与 IO
  • 【Python】探索 Errbot:多功能聊天机器人框架
  • SOAP 实例
  • C 标准库 - <ctype.h>
  • Python中使用Scikit-learn进行线性回归分析的实用指南
  • 如何在 PHP 中处理 MySQL 的结果集
  • 关于机器学习和深度学习的区别有哪些?
  • 道路坑洞分割数据集/道路裂纹分割数据集
  • golang学习笔记31——golang 怎么实现枚举
  • AI学习指南深度学习篇-Adagrad超参数调优与性能优化
  • Java对象一口气讲完!φ(* ̄0 ̄)
  • 详细分析分布式事务场景、理论基础以及解决方法
  • 松材线虫目标检测数据集,12522张图-纯手工标注
  • python软体使用Matplotlib设计一个数据可视化工具
  • AI学习指南深度学习篇-Adagrad的Python实践
  • WEB 编程:富文本编辑器 Quill 配合 Pico.css 样式被影响的问题