ADTS头结构与音频帧封装

AAC插件通过ADTS（Audio Data Transport Stream）头封装原始音频数据。每个ADTS头占7字节，其结构可通过Hexdump清晰展示：

00000000: FFF1 5080 0340 0AFC  [音频数据...]

• FFF：同步字（固定值）
• 1：MPEG版本（0=MPEG-4，1=MPEG-2）
• 50：编码配置（含采样率、声道数）

实际封装时，FMLE会根据编码设置动态生成ADTS头。例如48kHz立体声的LC-AAC头通常为FFF150800340。

LC-AAC与HE-AAC模式对比

| 编码模式 | 延迟(ms) | 推荐比特率(kbps) | 适用场景 | |------------|----------|------------------|-------------------| | LC-AAC | 100-200 | 96-256 | 高保真音乐直播 | | HE-AAC v1 | 50-100 | 48-128 | 语音/移动端直播 | | HE-AAC v2 | 30-80 | 32-64 | 超低码率传输 |

关键差异： - HE-AAC采用SBR频带复制技术，相同音质下码率降低40% - HE-AAC v2新增PS立体声参数编码，进一步节约带宽

FMLE配置模板

fmle.exe -i audio="麦克风" -o "rtmp://server/live" \
  -a codec=aac -a bitrate=128 -a profile=aac_he_v2 \
  -a samplerate=44100 -a channels=2 \
  -a bufferlength=200 -a threads=4

重点参数说明： - profile=aac_he_v2：需搭配64kbps以下比特率使用 - bufferlength=200：单位为ms，建议≥2倍帧间隔 - threads=4：超过物理核心数会导致竞争延迟

FFmpeg合规性检测

ffmpeg -i input.aac -c copy -f null - 2>&1 | grep "adts_header"

正常输出应包含：

[aac @ 0x7f8ef4000c00] adts_header missing
[aac @ 0x7f8ef4000c00] Estimating duration from bitrate

性能优化实战

线程模型优化

1. 绑定CPU核心：

   start /affinity 0xF fmle.exe  # 绑定前4个核心

2. 音频采集线程独立：通过WASAPI独占模式减少3-5ms延迟

缓冲区计算公式

理想缓冲区大小 = (网络抖动最大值 + 编码延迟) × 1.5
例如：200ms抖动 + 50ms编码 → 375ms缓冲区

时钟漂移补偿

在WASAPI模式下需添加：

-a audiodriftthreshold=0.2  # 允许20%时钟偏差

常见问题解决方案

采样率转换失真

• 原始采样率必须与编码采样率成整数比（如48kHz→24kHz）
• 建议使用SoX预处理：

  sox input.wav -r 44100 output.wav resample -q

多平台兼容性

• iOS需添加EXT-X-MEDIA-SEQUENCE头
• Android Chrome要求≥64kbps的HE-AAC

声道映射问题

立体声混音时需明确指定：

-a channel_layout=stereo -a pan="stereo|c0=c0|c1=c1"

未来演进思考

1. 向GStreamer迁移：可复用现有AAC编码器参数：

   gst-launch-1.0 pulsesrc ! audio/x-raw,rate=44100 ! faac profile=2 bitrate=64000 ! rtmp2sink

2. Opus对比测试：

3. 64kbps Opus ≈ 128kbps AAC音质
4. 但AAC在48kHz以上高频保留更优

通过本文的深度优化，FMLE+AAC方案仍可在特定场景下实现<100ms的端到端延迟，这对需要兼容传统设备的直播系统尤为重要。