在实时音视频处理中，G.711到AAC的编码转换是一个常见但技术复杂的需求。今天，我将分享自己在项目中积累的实战经验，从原理到代码实现，再到性能调优，希望能帮助大家少走弯路。

1. 背景介绍：为什么需要G.711转AAC？

G.711作为传统的PCM编码格式，虽然音质不错，但码率高达64kbps（8kHz采样率）。而AAC作为新一代音频编码标准，在同等音质下只需一半的带宽（32kbps）。这种转换在VoIP转直播、会议系统录制等场景特别常见。

• G.711特点：无压缩/低压缩、算法简单、延迟极低
• AAC优势：高压缩比、更好的频响范围、支持多声道

2. 技术方案对比

常见的转换方案主要有三种：

1. 纯软件方案（FFmpeg）：灵活度高，适合各种平台
2. 硬件加速方案：如Intel Media SDK，性能好但依赖特定硬件
3. 云端转码服务：简单但成本高，不适合实时场景

我们选择FFmpeg方案，因为：

• 跨平台支持完善
• 社区资源丰富
• 可以精细控制转换参数

3. 核心实现：FFmpeg代码详解

以下是关键代码片段（C++实现）：

// 初始化输入输出上下文
AVFormatContext *in_ctx = nullptr;
avformat_open_input(&in_ctx, "input.g711", nullptr, nullptr);

// 创建输出上下文
AVFormatContext *out_ctx = nullptr;
avformat_alloc_output_context2(&out_ctx, nullptr, "aac", "output.aac");

// 查找音频流
AVCodecParameters *in_params = in_ctx->streams[0]->codecpar;
AVCodec *decoder = avcodec_find_decoder(in_params->codec_id);

// 关键参数设置
AVCodecContext *dec_ctx = avcodec_alloc_context3(decoder);
avcodec_parameters_to_context(dec_ctx, in_params);
dec_ctx->request_sample_fmt = AV_SAMPLE_FMT_FLTP; // AAC需要浮点采样

4. 性能优化关键点

通过项目实践，我发现这几个参数对性能影响最大：

1. 采样率转换：
2. 保持原始采样率（8kHz）会丢失高频信息

3. 推荐升频到44.1kHz或48kHz

4. 比特率选择：

5. 语音场景：32kbps足够

6. 音乐场景：建议64kbps以上

7. 缓冲区设置：

8. 太小会增加CPU负载
9. 太大会引入延迟
10. 推荐20-50ms的缓冲窗口

5. 避坑指南

遇到过的典型问题及解决方案：

• 时间戳异常：
• 问题表现：音频视频不同步

• 解决：手动计算PTS，避免依赖输入时间戳

• 内存泄漏：

• 关键点：每次循环必须释放AVPacket和AVFrame

• 检查工具：Valgrind或AddressSanitizer

• 杂音问题：

• 原因：采样格式转换未做dither处理
• 方案：启用swresample的dither算法

6. 总结与思考

经过优化后，我们的转码延迟从最初的200ms降低到了80ms。但在超低延迟场景（<50ms）下，仍有提升空间。几个值得探索的方向：

1. 使用NEON指令集优化重采样
2. 尝试Opus编码作为中间格式
3. 实现零拷贝的DMA传输

最后留个思考题：在RTC场景中，当网络抖动导致G.711数据包乱序到达时，如何保证转码后的AAC音频仍然连贯？欢迎在评论区分享你的方案。

希望这篇实战总结能帮到正在处理音频转码的开发者们。记住，好的音频处理既要懂技术原理，也要有耐心调试的精神！