3.4 容错设计：FEC、DTX与丢包隐藏

3.4 容错设计：FEC、DTX 与丢包隐藏

本节摘要：实时网络丢包是常态，Opus 用三层机制在码流内部消化它——带内 FEC 把上一帧的低码率副本捎进当前帧、DTX 在静音期停发数据包只留舒适噪声参数、PLC 在丢包后用历史信息合成填补段。本节拆三件工具的触发逻辑、开销与适用边界，并给出丢包测试方法。

第三章收束节：3.1 至 3.3 讲的是"网络正常时怎么干得又快又好"，本节讲"网络不好时怎么活下来"。容错是 Opus 对 AAC 最具代差优势的一块拼图——AAC 的码流里没有任何对等机制。

为什么容错必须做进码流

先算一笔账。通话链路丢 5% 的包，若每包 20 ms 音频，每分钟就有 150 个空洞。靠应用层重传（ARQ）补洞在实时场景基本不可行：一来一回的 RTT 远大于抖动缓冲容忍度；靠加大抖动缓冲硬扛，延迟预算立刻爆掉（端到端 150 ms 是对话体感的分水岭）。剩下的路只有两条：发送端预埋冗余（FEC）、接收端合成填补（PLC）。Opus 把两条路都做进了码流语法，收发两端无需任何带外协议即可协同——这是"交互原生"的最后一处体现。

带内 FEC：把上一帧塞进当前帧

Opus 的 FEC（前向纠错）形态很朴素：编码当前帧时，把上一帧的低码率重构副本（主要是语音的关键参数）附加在包尾。当前帧正常到达时，副本被直接丢弃；当前帧丢了、下一帧到了，解码端从下一帧里取出上一帧的副本，恢复出"降质但完整"的丢失段。

开销与增益的量级：典型配置下 FEC 增加约一至两成码率，把"可懂度崩溃点"从约一成丢包推到三成上下。启用条件也有讲究：编码器需要知道丢包率（WebRTC 通过 RTCP 接收报告回传），libopus 里先开 OPUS_SET_INBAND_FEC(1)，再设 OPUS_SET_PACKET_LOSS_PERC(n) 让编码器按丢包率调节冗余量——丢包越高，副本质量档越高。

一个容易被忽略的细节：FEC 只保护"上一帧"。突发丢两包以上时，中间帧的副本也丢了，恢复链条断裂——这正是突发丢包比均匀丢包更伤的原因。对策是降低包时长（短帧）或在传输层做交织（把相邻帧分散到不同包，用延迟换突发容忍）。

DTX 与舒适噪声：静音不花预算

对话有近半时间是无声的。DTX（不连续传输）让编码器检测到静音后停发数据包，只在参数变化超过阈值时发一个极小的舒适噪声参数帧（CNG 描述噪声的频谱形状与能量）。接收端据此合成背景噪声，听感上"线路还通着"，实际上带宽占用近乎归零。

DTX 与 VAD（语音活动检测）配合工作，但二者不同：VAD 是判断器，DTX 是执行器。工程上的坑在阈值——切得太灵敏，词尾辅音被当静音截断（"吞字"）；切得太迟钝，省流效果打折。libopus 的实现经过大规模通话调校，一般直接信任默认值，出现吞字优先查前端 AGC 与噪声估计，而非关 DTX。

PLC：丢包之后的临场发挥

丢包真的发生且无 FEC 可用时，最后一道防线是 PLC（丢包隐藏）。Opus 的 PLC 不是简单静音或重复上一帧，而是按内容类型分策略：浊音段用历史基音周期做波形外推（声调与节奏得以延续）；清音段按近期频谱包络合成噪声；过渡段用线性预测外推加淡出。合成段的能量随时间衰减，几帧后自然过渡回静音，避免"机器感"的无限延伸。

值得注意的是 PLC 完全在解码端运行——即使发送端毫无 Opus 特定配置（比如经过只做转发的 SFU 服务器），接收端也自动享有这层保护。三种机制的分工时序如下：

图：三层容错的协作时序

怎么验证与调参

libopus 提供了丢包模拟的官方姿势——解码器可以直接被告知"这一帧丢了"：

/* 接收端：正常解码与丢包隐藏各占一路 */
int n = opus_decode(dec, packet, nbytes, pcm, 960, 0);   /* 正常 */
int m = opus_decode(dec, NULL, 0, pcm_lost, 960, 0);     /* PLC 合成 */
​

测试方法：对同一段素材按固定比例随机丢弃编码包（5%/10%/20%/30% 各一轮），分别测"FEC 开/关"两组的听感与可懂度，得到本链路的崩溃曲线。调参要点有三：丢包率估计要真实（RTCP 反馈为准，不要拍脑袋设常数）；突发严重时优先缩短帧长而不是堆 FEC；DTX 场景要确认舒适噪声参数帧有送达（部分 SFU 默认过滤小包，会切成"咔嗒"式断续）。

三件工具的适用边界

一次完整的丢包实验设计

把验证方法展开成可执行的实验设计。目标：测出本链路在 FEC 开与关两种配置下的"可懂度崩溃曲线"。素材：三段各两分钟——纯净朗读、嘈杂环境对话、语音加背景音乐（最后一段最考验 PLC 的合成质量）。变量控制：固定码率 24 kbps、帧长 20 ms、复杂度 6，只动 FEC 开关与丢包率两维。丢包注入：用脚本按均匀分布与突发分布（连续三包为一组）各注入 5%、10%、20%、30% 四档——突发模式是必测项，它是 FEC 保护盲区的探针。评测：每轮产物先跑客观指标（ViSQOL 相似度），再对差距小于 0.1 分的条件做三人 ABX 判别；记录合成段的"机器感"是否可闻（PLC 特有的失真维度，客观指标抓不到）。

预期结果形态：FEC 关闭时可懂度在约 10% 丢包处明显下滑、突发模式下更早；FEC 开启后崩溃点推后到 25 至 30%，且突发劣势收窄但依然存在（单帧保护的边界）。若实测偏离这个形态——比如 FEC 开了没效果——优先查丢包率回传是否真的到了编码器（RTCP 链路断掉时，FEC 冗余度不会随实际丢包调整），这是该实验最常抓出的工程 bug。

这套实验的产出物（崩溃曲线 + 机器感记录）直接服务于 5.1 的契约设计：通话类产品的"最低可用网络门槛"就定在崩溃点之前一档。把实验脚本与曲线存档，网络侧调优（比如传输协议升级）之后重跑对比，容错配置的演进就有了数据轨道。

💡 关键直觉：FEC 是"提前买保险"，PLC 是"事后自救"，DTX 是"没病别挂号"。三者组合的哲学是分层的——先花小钱防单点，再用合成兜底，最后把不存在的语音根本不发。AAC 的世界线里这三层全部缺席，不是没想到，是分发场景假设（可靠信道、可重传）让它们没有存在的必要。

第三章到此完整：起源、引擎、参数、容错四块拼图就位。下一章把 AAC 与 Opus 摆上同一张解剖台——延迟、音质、算力、场景、生态，逐项对质。