音视频学习（九十六）：PLC

PLC 的核心思想

PLC （Packet Loss Concealment，丢包隐藏）的本质不是"恢复丢失数据"，而是：

在数据丢失时，通过算法生成"近似合理"的替代内容，使用户感知尽量平滑。

与 FEC、NACK 等机制不同：

• FEC：通过冗余恢复数据
• NACK：通过重传获取数据
• PLC：不恢复，只掩盖

换句话说，PLC 是一种"感知优化技术"，目标是：

• 减少卡顿
• 避免突变
• 提升主观体验（QoE）

音视频场景中的丢包影响

在实时传输中，丢包带来的影响不同：

1. 音频丢包

• 声音断裂、卡顿
• 出现"啪""咔"等突变
• 连续丢包会导致完全静音

用户对音频异常非常敏感

2. 视频丢包

• 画面马赛克
• 局部块错误
• 帧冻结或跳帧

视频更"容忍短时错误"，但关键帧丢失影响极大

PLC 的基本策略

PLC 的实现思路通常分为三类：

1. 插值（Interpolation）

通过已有数据推测缺失部分：

已知：Frame N, Frame N+2
推测：Frame N+1

适用于：

• 音频连续波形
• 视频轻微运动

2. 重复（Frame Repeat）

直接使用前一帧替代：

丢失 Frame N → 使用 Frame N-1

特点：

• 实现简单
• 适用于短时丢包

3. 预测（Prediction）

基于历史数据进行建模预测：

• 音频：基于周期性（如语音基音）
• 视频：基于运动估计

是当前主流方案

音频 PLC 技术

音频 PLC 是应用最广泛、也是最成熟的部分。

1. 基于波形复制（Waveform Substitution）

直接复制上一段音频：

• 简单高效
• 适用于短时丢包（<20ms）

但缺点是：

• 长时间重复会产生"机械感"

2. 基于周期检测（Pitch-based PLC）

语音具有周期性（声带振动），可以：

• 检测基音周期
• 重复一个或多个周期

效果：

• 比简单复制更自然
• 特别适用于语音

3. 噪声填充（Noise Filling）

对于非语音（背景噪声）：

• 生成类似噪声填充
• 避免"突然静音"

4. Opus 编码器中的 PLC

在实时通信中，Opus 是主流音频编码器，其内置 PLC：

• 自动检测丢包
• 使用历史帧进行预测
• 支持 FEC + PLC 联合

工程上常见做法：

优先使用 FEC 恢复
失败后使用 PLC 掩盖

视频 PLC 技术

相比音频，视频 PLC 更复杂，因为：

• 数据量大
• 空间结构复杂
• 运动变化多

1. 帧冻结（Freeze Frame）

最常见方式：

丢帧 → 显示上一帧

优点：

• 简单稳定
• 不引入错误

缺点：

• 明显卡顿（尤其运动场景）

2. 空间插值（Spatial Interpolation）

在同一帧内：

• 利用周围像素填补缺失区域
• 常见于块丢失（如宏块错误）

3. 时间插值（Temporal Interpolation）

利用前后帧：

Frame N 和 Frame N+2 → 推测 Frame N+1

需要：

• 运动估计（Motion Estimation）
• 光流（Optical Flow）

4. 运动补偿（Motion Compensation）

高级视频 PLC 方法：

• 分析物体运动轨迹
• 预测缺失区域

类似视频编码中的预测机制

5. AI/深度学习 PLC（新趋势）

近年来开始使用：

• GAN / CNN
• 视频修复模型

特点：

• 效果更自然
• 计算开销较大

PLC 与 FEC/NACK 的关系

PLC 通常不是单独使用，而是作为"最后一道防线"。

协同关系：

接收端处理流程：
1. 尝试 FEC 恢复
2. 失败 → 请求 NACK
3. 超时 → 使用 PLC

对比总结：

技术	是否恢复真实数据	延迟	效果
FEC	是	低	中
NACK	是	高	高
PLC	否	极低	取决算法

PLC 的局限性

尽管 PLC 很重要，但它并不是万能的：

1. 无法恢复真实信息
2. 连续丢包效果急剧下降
3. 视频场景效果有限
4. 复杂算法带来计算开销

本质上：

PLC 是"补救措施"，不是"解决方案"

总结

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

在无法恢复数据的情况下，通过算法"掩盖丢失"，保证播放的连续性和用户体验。

在实际系统中，PLC 通常与以下机制协同工作：

• FEC（前向纠错）
• NACK（重传）
• Jitter Buffer（抗抖动）
• 自适应码率（ABR）