RTX（Retransmission，重传）在音视频QoS中的作用
RTX（Retransmission） 是音视频传输中用于 丢包恢复 的QoS（服务质量）技术，属于 基于重传的纠错机制。其核心思想是：当接收端检测到数据包丢失时，通过请求发送端重新传输丢失的包，从而保证数据的完整性。RTX通常用于对延迟有一定容忍度的实时场景（如WebRTC、视频会议），但需平衡 延迟 和 可靠性。
1. RTX 的工作原理
（1）基本流程
-
发送端：
- 发送原始音视频数据包（如RTP包），并为每个包分配唯一的序列号（Sequence Number）。
- 可选：在发送原始包的同时，缓存这些包一段时间（用于后续重传）。
-
接收端：
- 检测到丢包（如序列号不连续）。
- 通过 RTCP NACK（Negative Acknowledgement） 反馈丢失的包序号（如RFC 4585）。
-
发送端：
- 收到NACK后，从缓存中提取丢失的包，并通过 RTX（重传通道） 重新发送。
- RTX通常使用单独的SSRC（同步源）或Payload Type（负载类型）区分原始包和重传包。
（2）RTX vs 普通重传
| 特性 | 普通重传 | RTX（优化后的重传） |
|---|---|---|
| 协议支持 | 直接重传原始RTP包（相同SSRC）。 | 使用独立SSRC或Payload Type发送。 |
| 带宽效率 | 可能浪费带宽（重复相同包头）。 | 可压缩包头（如RFC 4588）。 |
| 适用场景 | 简单场景（如UDP+简单NACK）。 | 标准化的WebRTC、视频会议。 |
2. RTX 的应用场景
（1）WebRTC 中的 RTX
-
NACK + RTX 组合：
- WebRTC默认使用 RTCP NACK 反馈丢包，并通过 RTX 重传丢失的RTP包。
- 例如：视频关键帧（I帧）丢失时，优先重传以避免花屏。
-
缓存策略：
- 发送端会缓存最近的RTP包（如200ms~1s），以便快速响应NACK请求。
（2）视频会议（如Zoom、腾讯会议）
-
动态调整RTX策略：
- 在网络较差时增加RTX重传次数，网络较好时减少冗余。
-
与FEC结合使用：
- 对关键帧（I帧）使用FEC，普通帧（P/B帧）使用RTX，平衡延迟和可靠性。
（3）直播与低延迟流媒体
-
选择性重传：
- 只重传影响解码的关键包（如H.264的SPS/PPS/NALU分片）。
3. RTX 的优缺点
| 优点 | 缺点 |
|---|---|
| ✅ 高可靠性：确保数据完整。 | ❌ 增加延迟：依赖RTT（往返时间）。 |
| ✅ 灵活控制：可动态调整重传策略。 | ❌ 带宽占用：重传消耗额外带宽。 |
| ✅ 标准化：兼容WebRTC/RFC。 | ❌ 不适用超低延迟：如云游戏（<100ms）。 |
4. RTX 与 FEC 的对比
| 技术 | 原理 | 延迟影响 | 带宽开销 | 适用场景 |
|---|---|---|---|---|
| RTX | 丢包后重传（需反馈）。 | 较高（依赖RTT） | 中等 | 视频会议、WebRTC。 |
| FEC | 发送冗余包（无需反馈）。 | 低 | 较高（5%~20%） | 直播、强实时场景（如VoIP）。 |
最佳实践：
- 网络较好时：优先使用RTX（减少冗余带宽）。
- 网络较差时：结合FEC + RTX（抗丢包+补包）。
5. RTX 的技术实现（以WebRTC为例）
（1）RTX 封包格式
-
原始RTP包：
[RTP Header(12B)] + [Payload] -
RTX重传包（RFC 4588）：
[RTP Header(12B)] + [RTX Header(2B)] + [Original Payload]- RTX Header 包含原始RTP包的序列号（避免重复解析）。
（2）NACK 反馈机制
-
接收端通过 RTCP NACK 报文请求重传，格式示例：
PID (Packet ID) + BLP (Bitmask of Lost Packets)- 例如：请求重传序列号
100, 101, 103。
- 例如：请求重传序列号
（3）代码示例（C++伪代码）
// 发送端：检测NACK并重传
void OnNackReceived(const std::vector<uint16_t>& lost_packets) {
for (uint16_t seq : lost_packets) {
if (RtpPacket* cached_packet = cache_.GetPacket(seq)) {
SendRtxPacket(cached_packet); // 通过RTX通道重传
}
}
}
6. 总结
-
RTX 是音视频QoS中基于重传的丢包恢复技术，核心依赖NACK反馈和缓存机制。
-
适用场景：WebRTC、视频会议等对可靠性要求较高，且能容忍一定延迟的场景。
-
优化方向：
- 动态调整重传策略（如Google Congestion Control + RTX）。
- 与FEC结合使用，提升抗丢包能力。
