音视频学习（九十六）：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 很重要，但它并不是万能的：

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

本质上：

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

总结

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

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

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

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