应逐字节扫描同步字0xFF并校验后续字节，手动位提取ADTS头字段；frame_length用于分帧，时间戳须由外部协议提供而非ADTS头推算。
怎么从AAC裸流里定位并读取ADTS头
ADTS头固定7或9字节，但必须从字节流中准确找到起始位置——不能假设第一个字节就是0xFF，也不能跳过同步字（syncword）校验。真实AAC流常夹杂填充、误码或非对齐数据，直接按偏移硬读会崩溃或解析错。
- 逐字节扫描，找连续两个字节为
0xFF且后续第3字节高4位为0xF（即(b3 & 0xF0) == 0xF0） - 确认后读取7字节，检查
adts_fixed_header中profile、sampling_frequency_index是否在有效范围内（如sampling_frequency_index> 12 是非法值） - 若
adts_header_length == 9（由copyright_identification_bit和copyright_identification_start决定），需多读2字节，但多数裸流不含版权字段，优先按7字节解析，失败再试9字节
如何用C++结构体映射ADTS头字段
别手写位域结构体去reinterpret_cast——大小端、内存对齐、编译器填充都会导致字段错位。正确做法是手动位提取，控制每个字段的起始位和长度。
-
syncword：前12位，必须等于0x0FFF -
ID：第13位（bit 12），0=ISO/IEC 13818-7，1=MPEG-4；实际AAC流几乎全为1，但需校验 -
profile：第14–15位（bits 11–10），对应AAC_LC、HE_AAC等，影响解码器初始化 -
sampling_frequency_index：第16–19位（bits 9–6），查表得采样率，常见值4→44.1kHz，5→48kHz -
frame_length：第29–40位（bits 13–2），共14位，表示整个ADTS帧字节数（含头），这是关键字段，用于跳到下一帧
示例提取frame_length：
uint16_t frame_length = ((buf[3] & 0x03) << 11) |
(buf[4] << 3) |
((buf[5] & 0xE0) >> 5);
为什么解析后解码仍失败：常见字段陷阱
字段值合法 ≠ 可解码。几个高频坑点：
立即学习“C++免费学习笔记（深入）”；
-
buffer_fullness（bits 25–36）为0x7FF时代表VBR流的“可变比特率”，但某些解码器要求该值 0x7FF 才接受，需做截断处理 -
number_of_frames（bit 41）为0表示“单帧”，为1表示“多帧流”，但很多编码器乱填，建议忽略此字段，只依赖frame_length跳帧 -
private_bit（bit 24）若为1，部分硬件解码器会拒绝，但软件解码器通常忽略；若遇到播放卡顿，可尝试强制清零 - 采样率与声道数不匹配：如
sampling_frequency_index == 3（32kHz）但channel_configuration == 0（隐式声道），解码器可能fallback失败
如何安全地循环解析一整段AAC裸流
不能简单用frame_length累加偏移——ADTS头后紧跟AAC原始数据，但某些封装（如RTMP AAC）会在ADTS头前插入4字节FLV音频tag header，或在帧间插入空包。必须边解析边校验。
- 每次解析完一帧，用
frame_length推进指针，然后立即验证下一个位置是否还能找到有效syncword；若失败，最多向后滑动3–5字节重试（防单字节错位） - 设置最大重试次数（如10次），超限则判定流损坏，终止解析
- 记录已解析帧数和累计字节数，用于对比原始buffer长度，差值>10字节时警告存在未解析残留
- 对实时流（如WebRTC接收的AAC），必须支持“从任意位置入流”，因此syncword扫描逻辑不能依赖上一帧结束位置，每次都要独立执行
最易被忽略的是：ADTS头本身不携带时间戳，所有PTS/DTS需由外部协议（如RTP、FLV）提供，解析器只负责分帧和提取基础参数。混用ADTS头里的buffer_fullness推算时间戳，一定会出音画不同步。
