4.2 音频编码与 NetEQ

4.2 音频编码与 NetEQ

前处理把声音收拾干净之后，本节管它的"运输形态"：怎么压缩、怎么补丢。编码器决定同样的音质花多少带宽，接收侧的净缓冲决定线路抖动与丢包时听感如何兜底——这对搭档的配合质量，就是弱网通话体验的下限。

编码侧：带宽都花在哪

引擎缺省选用 Opus 这套现代语音编码，它的价值不在压缩率本身，而在"可调"：帧长可调、码率可调、抗丢包冗余可调，全部可以在通话中动态改变。三个参数构成了调优的主轴。帧长决定打包效率与延时的平衡——短帧延时低但包头开销占比高，长帧反过来；缺省的二十毫秒是多数场景的甜点。目标码率决定音质上限，语音场景数十千比特每秒就足够透明，音乐场景则需要上百千比特每秒。冗余策略最值得展开：编码器可以把前一帧的副本随当前帧一起发送，丢包时接收方用副本顶上，代价是带宽近乎翻倍——所以引擎只在网络变差时逐步打开冗余，恢复后又逐步关闭，整个调整随拥塞控制的带宽估计联动，全自动完成。

还有一招省带宽的利器叫不连续传输：检测到说话人静默时，只发极小的描述帧而不发正常帧，带宽骤降一个数量级。它的代价是静默结束后的首帧恢复需要平滑处理，且会话两端的状态机要严格同步，否则会出现"开口半秒没声"。工程上评估语音带宽预算，必须把静默占比算进去——会议场景实际带宽常常只有按满帧估算的一半，这不是意外而是特性。

图：音频发送与接收管线全景

接收侧：净缓冲这台"节拍矫正器"

网络送来的帧节奏是抖的——早的早到、晚的迟到，而播放必须恒速。接收侧的净缓冲就是两者的仲裁器：帧到手先攒一小段（目标延迟通常数十毫秒），按估计的播放时刻出队。它真正的精妙在动态调节：缓冲偏多时加速播放把存量磨掉，缺帧时放慢节奏或请求隐藏，全程以人耳不易察觉的幅度微调。这就是通话刚接通时声音略微加快或放慢一瞬的来源——那是节拍矫正器在找位。

丢帧时的处置分三档。轻度缺失，用丢包隐藏技术合成过渡音：解码器根据历史帧的频谱特征补一段"像话"的噪声轮廓，听感是轻微的沙沙而非断裂。中度缺失，净缓冲自动拉长目标延迟，宁可多攒一点换取后续的容错空间。持续恶化，编码冗余在发送侧已经加码的前提下，接收侧仍缺帧才会出现可感知的断续。三档策略全由统计驱动，不依赖应用干预。

发送侧统计的读数指南

编码侧的统计也是弱网分析的上游证据，把三个最有解读价值的读数讲清。实际发送码率与目标码率的差值：稳态下两者应贴近，实际持续低于目标说明静默期占比高（属正常省钱）或编码器跟不上节奏（查机器负载）。冗余开启比例的时间曲线：它与丢包率曲线的相对位置直接回答"冗余策略灵不灵"——丢包抬升后冗余应当几乎同步爬坡，滞后明显说明联动参数迟钝。编码耗时占比：占比升高会挤占音频线程的处理余量，是移动端"降复杂度"决策的触发依据，与 4.1 的恒定耗时纪律同源。

把这三条读数与第四章开篇的"节拍器"视角合起来，发送侧音频的健康画像就完整了：节奏稳（耗时占比平）、账目清（码率贴合目标）、保险足（冗余随丢包联动）。这三条全部可以自动化巡检，建议纳入例行质量报表而非等投诉才看。

编码参数速查与高频问答

把 Opus 相关的常用参数与典型取值收成速查表，调参时先查表再实验，能少走弯路。

围绕这组参数的工单也高度重复，挑三条最常见的问答沉淀在此。**问：静默期为什么还有微小流量？**答：不连续传输并非零发送，仍要发极小的描述帧维持序号与时戳连续，否则恢复期两端的同步状态会断档。**问：调低复杂度为什么音质几乎没变？**答：复杂度影响的是编码搜索的精细度，中档以上边际收益递减；把它当作省电旋钮比当作音质旋钮更准确。**问：接收端目标延迟可以强制调小吗？**答：可以设下限，但小于到达抖动的物理水平只会增加缺帧，抖动大的线路里宁深勿浅。

接通瞬间为什么有轻微的快放感

净缓冲的初始目标比实际到达抖动略高，接通后估计器发现抖动小，逐步把缓冲磨薄——磨薄过程表现为轻微加速，持续一两秒自愈。这是测量在收敛，不是故障；若快放感持续存在，说明抖动估计被什么长期带偏，查采集时戳。

双向通话时对方声音突然变厚

八成是回声消除与净缓冲变速在互相拉扯：本端加速播放让参考信号与回声路径错位，消除输出出现抽吸感。引擎对两者的协同做过大量工程处理，遇到顽固案例优先核对参考链路，其次才考虑降缓冲目标。

能否为音乐场景单独配置一套参数

可以且应该。音乐场景关闭不连续传输、放开码率上限、帧长取短，与语音档位并存按内容切换。引擎允许运行时改参，切换点最好选在静默或音乐间隙，避免可闻的过渡毛刺。

案例：从弱网日志读出三档策略的接力

背景。实验室弱网模拟环境把丢包率推到两成，测试反馈"前几分钟听感尚可，随后出现明显断续"，希望搞清引擎各阶段都在做什么。

操作。打开事件记录跑一轮完整弱网通话，导出后按时间轴排列四类事件：丢包计数、冗余开关变化、净缓冲目标延迟变化、隐藏帧生成计数。逐段解读：丢包从零爬升到两成的过程中，冗余在丢包约百分之三时开始介入，带宽占用随之上行；目标延迟在丢包约一成时从六十毫秒抬到一百二十毫秒，此后隐藏帧计数保持低位——说明冗余加缓冲已把绝大多数缺口补掉。几分钟后的断续段里，隐藏帧计数陡增，对应模拟器进一步压带宽、冗余因带宽不足被拥塞控制削减的区间。

结果。结论清晰：前期是冗余与缓冲的功劳，后期是带宽天花板下所有手段同时见底，断续不可避免。

解读。这个案例给出一条重要的工程判断：断续不一定是引擎失灵，可能是物理预算耗尽。区分"机制没工作"与"机制工作到头了"必须看事件序列而不是听感。对应到产品，弱网提示、自动降级到纯语音、引导用户换网络，都应当以事件证据为触发依据。

变式。把模拟器的丢包模型从随机丢包换成突发丢包再跑一轮，会发现冗余的效果大幅缩水——副本与正主常常一起丢。这解释了为什么第七章要把重传与前向纠错并用：随机丢包冗余最划算，突发丢包要靠跨时间的重传或交错打包。不同丢包形态选不同武器，这个判断贯穿整个抗弱网体系。

要点回顾

本节要点：Opus 的帧长、码率、冗余三参数构成调优主轴，冗余随网络动态开关；不连续传输让会议语音实际带宽只有满帧估算的一半；净缓冲以恒速播放为目标做毫秒级变速调节，丢帧处置分隐藏、扩容、断续三档；弱网问题先看事件序列，区分机制失灵与预算耗尽。至此音频走完，下一章进入复杂度高一个量级的视频引擎。