音视频学习（九十五）：FEC

FEC 的核心思想

FEC（Forward Error Correction） 的本质是：发送端主动增加冗余数据，使接收端在发生丢包时无需重传即可恢复原始数据。

与 ARQ 的对比如下：

技术	特点	适用场景
ARQ（重传）	丢了再要	文件下载、HTTP
FEC（前向纠错）	预先冗余	实时音视频

简单来说：

FEC 用"带宽换时延"，避免等待重传带来的卡顿。

音视频场景中的丢包问题

在 UDP 传输（如 RTP）中，常见问题包括：

• 随机丢包（Random Loss）
• 突发丢包（Burst Loss）
• 网络抖动（Jitter）

对于音视频：

• 音频：对丢包敏感（声音断裂明显）
• 视频：关键帧丢失影响极大（画面卡死）

因此：

音频通常 FEC 强度更高

视频通常结合关键帧策略 + FEC

FEC 基本模型

典型 FEC 编码过程：

原始数据包：D1 D2 D3 D4
生成冗余包：R1 R2

发送：D1 D2 D3 D4 R1 R2

恢复能力：

• 丢 ≤ 2 个包 → 可恢复
• 丢 > 2 个包 → 无法恢复

常见 FEC 算法

1. XOR FEC（简单异或）

最基础的 FEC：

R = D1 ⊕ D2 ⊕ D3

如果丢了 D2：

D2 = R ⊕ D1 ⊕ D3

优点：

• 实现简单
• 计算开销低

缺点：

• 只能恢复单个丢包
• 抗突发丢包能力差

常用于：低复杂度音频场景

2. Reed-Solomon（RS码）

一种经典纠删码（Erasure Code）：

• 支持从 N+M 中恢复任意 N 个
• 广泛用于音视频、存储系统

优点：

• 恢复能力强
• 抗突发丢包能力优秀

缺点：

• 编解码复杂度高
• CPU 开销较大

常用于：直播、CDN、大规模分发

3. Raptor / Fountain Codes

喷泉码（Fountain Code）特点：

• 可生成无限冗余包
• 接收端只需"足够多"即可恢复

优点：

• 灵活性强
• 适合高丢包网络

缺点：

• 实现复杂
• 延迟较高

常用于：卫星通信、大规模广播

4. WebRTC 中的 FEC（ULPFEC / FlexFEC）

在 WebRTC 中，常见两种：

• ULPFEC（RFC 5109）

  • 基于 XOR

  • 与 RTP 结合

  • 实现简单

• FlexFEC（RFC 8627）

  • 更灵活的保护范围

  • 支持跨帧保护

  • 可保护多个 RTP 流

当前趋势：FlexFEC 替代 ULPFEC

音频 FEC vs 视频 FEC

1. 音频 FEC

常见方案：

• Opus 内置 FEC（in-band FEC）
• 小包 + 高频发送

特点：

• 延迟敏感
• 丢包容忍度低

一般直接在编码器层解决

2. 视频 FEC

视频更复杂：

• 帧大（MTU 分片）
• 依赖关键帧（IDR）

常见策略：

• 关键帧加强保护（FEC比例更高）
• 非关键帧降低冗余

典型组合：

FEC + NACK + Keyframe Request

FEC 与其他抗丢包机制对比

1. FEC vs NACK（重传）

对比	FEC	NACK
延迟	低	高
带宽	高	低
可靠性	中	高

实际工程中：FEC + NACK 混合使用

2. FEC vs PLC（Packet Loss Concealment）

PLC 是"掩盖丢包"，不是恢复：

• 音频：插值、重复
• 视频：帧复制

FEC 是"恢复"，PLC 是"掩盖"

FEC 的局限性

尽管 FEC 很重要，但也有明显局限：

1. 带宽开销大
2. 无法应对极端丢包（>50%）
3. 增加编码延迟
4. 实现复杂（尤其 RS / Raptor）

因此不能单独使用，必须结合：

• 自适应码率（ABR）
• 重传（NACK）
• 缓冲（Jitter Buffer）

总结

FEC 是实时音视频系统中不可或缺的一环，其核心价值在于：

通过增加冗余数据，在不依赖重传的情况下提升抗丢包能力，从而保障实时性和连续性。

在实际工程中，没有"万能"的 FEC 方案，通常需要结合：

• FEC（前向纠错）
• NACK（重传）
• PLC（掩盖）
• ABR（码率控制）

形成一套完整的抗丢包体系。