背景痛点

实时音视频系统中，音频编码面临三大核心挑战：

• 带宽限制：移动网络下需平衡音质与流量消耗
• 延迟敏感：200ms内的端到端延迟是实时通信的生命线
• 设备兼容：不同操作系统/硬件对编码器的支持差异显著

技术参数对比

| 特性 | G.711(PCMU/PCMA) | AAC-LC | |-------------|------------------|--------------| | 采样率 | 8kHz | 8-48kHz | | 码率 | 64kbps | 16-128kbps | | 算法延迟 | <1ms | 20-100ms | | 压缩方式 | 无损(μ-law/A-law)| 有损 | | CPU占用 | 极低 | 中等 |

实现细节

WebRTC中的G.711协商

// SDP协商示例
m=audio 9 UDP/TLS/RTP/SAVPF 0 8
// 0代表PCMU(G.711 μ-law), 8代表PCMA(G.711 A-law)
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000

FFmpeg转码AAC

# 带ADTS头的AAC转码命令
ffmpeg -i input.wav \
       -c:a aac -b:a 64k -ar 44100 \
       -profile:a aac_low -f adts output.aac
# 参数说明：
# -profile:a 指定编码复杂度等级
# -f adts 添加音频数据流头

性能数据

测试环境：骁龙865设备，128kbps码率 | 编码格式 | CPU占用率(单核) | 内存消耗 | |----------|-----------------|----------| | G.711 | 2% | 15MB | | AAC | 12% | 32MB |

常见问题解决

1. Android AAC硬编兼容性问题

2. 解决方案：检测MediaCodec支持的profile，降级使用AAC-LC

3. WebRTC默认禁用G.711

4. 修改peerconnection_constraints.cc启用payload type 0/8

5. AAC编码出现杂音

6. 检查ADTS头是否缺失，确保采样率与声道数配置正确

进阶思考

如何根据网络抖动动态切换编码格式？考虑以下因素：

1. 通过RTCP报告获取当前网络丢包率
2. 高抖动时切换至抗丢包更强的G.711
3. 稳定环境下启用高压缩率的AAC

测试表明：当丢包率>5%时，G.711的主观听感优于AAC。