Video Transport
概述
视频传输负责将编码后的视频数据通过网络传输到接收端。
传输协议
RTP/RTCP（Real-time Transport Protocol）
- RTP：实时传输协议，用于传输音视频数据
- RTCP：RTP控制协议，用于传输控制信息（丢包率、延迟等）
- 特点：低延迟、支持多播、UDP传输
- 应用场景：视频会议、VoIP、实时流媒体
RTMP（Real-Time Messaging Protocol）
- Adobe开发的协议，基于TCP
- 特点：延迟较低、支持推流和拉流
- 应用场景：直播推流、CDN分发
WebRTC（Web Real-Time Communication）
- W3C标准，用于浏览器实时通信
- 特点：低延迟、P2P传输、内置拥塞控制
- 应用场景：视频会议、在线教育、实时通信
HLS（HTTP Live Streaming）
- Apple开发的HTTP流媒体协议
- 特点：基于HTTP、支持自适应码率、延迟较高
- 应用场景：点播、直播（延迟要求不高的场景）
DASH（Dynamic Adaptive Streaming over HTTP）
- MPEG标准，基于HTTP的自适应流媒体
- 特点：标准化、支持多厂商、自适应码率
- 应用场景：点播、直播
传输机制
分包与重组
- 将视频帧分割为适合网络传输的包
- 添加序列号、时间戳等元数据
- 接收端根据序列号重组数据
丢包重传
丢包是网络传输中的常见问题，特别是在UDP传输中。业界有多种方案来处理丢包，主要分为两大类：ARQ（自动重传请求）和FEC（前向纠错）。
ARQ（Automatic Repeat Request，自动重传请求）
ARQ通过检测丢包并请求重传来恢复丢失的数据。
工作原理：
– 发送端：发送数据包，维护发送窗口，等待确认
– 接收端：检测丢包（通过序列号间隙），发送重传请求
– 发送端：收到重传请求后，重新发送丢失的数据包
ARQ类型
Stop-and-Wait ARQ（停等ARQ）
– 原理：发送一个包后等待确认，收到确认后再发送下一个包
– 特点：
– 实现简单，但效率低
– 每个包都需要往返时间（RTT）等待确认
– 效率 = 传输时间 / (RTT + 传输时间)，吞吐量低
– 延迟高，不适合实时应用
– 适用场景：低带宽、可容忍高延迟的场景，或作为其他ARQ的基础和教学示例
Go-Back-N ARQ（回退N步ARQ）
– 原理：发送端维护一个发送窗口（大小为N），可以连续发送多个包；接收端按序接收，发现丢包后丢弃后续所有包并发送NACK，发送端收到NACK后从丢包处开始重传窗口内的所有包
– 特点：
– 效率高于停等ARQ，可以连续发送
– 接收端需要缓存窗口大小的数据
– 丢包会导致后续包也被丢弃（即使已收到），需要重传
– 相比Selective Repeat，实现简单但效率较低
– 适用场景：网络质量较好、丢包率低的场景
Selective Repeat ARQ（选择重传ARQ）
– 原理：发送端和接收端都维护窗口，接收端可以乱序接收并缓存，只请求重传丢失的包，已收到的包可以继续处理，发送端只重传丢失的包
– 特点：
– 效率最高，只重传丢失的包，不浪费带宽
– 接收端需要更大的缓冲区来缓存乱序包
– 实现复杂度较高，需要维护发送和接收窗口状态
– 适用场景：网络质量不稳定、丢包率较高的场景，或对效率要求高的应用
业界ARQ实现方案
RTP NACK（Negative Acknowledgment）
– 协议：基于RTP/RTCP协议
– 原理：
– 接收端通过RTCP反馈包（RTCP NACK）通知发送端丢包
– 发送端收到NACK后重传丢失的RTP包
– 支持批量NACK（一次请求多个丢失的包）
– 特点：
– 标准RTP协议支持
– 延迟 = RTT + 重传时间
– 适合低延迟场景（< 200ms）
– 应用场景：WebRTC、视频会议、实时通信
RTX（RTP Retransmission）
– 协议：RFC 4588定义的RTP重传扩展
– 原理：
– 使用独立的RTP流（RTX流）传输重传包
– 原始流和重传流使用不同的SSRC
– 重传包使用原始序列号的映射（Original Sequence Number）
– 特点：
– 标准化方案，兼容性好
– 可以区分原始包和重传包
– 支持统计和监控
– 应用场景：WebRTC、SIP视频通话
RED（Redundancy Encoding）
– 协议：RFC 2198定义的冗余编码
– 原理：
– 在RTP包中携带前一个或多个包的冗余数据
– 如果当前包丢失，可以从后续包的冗余数据中恢复
– 如果后续包丢失，可以从当前包的冗余数据中恢复
– 特点：
– 无需往返延迟，恢复速度快
– 增加带宽开销（通常20-50%）
– 适合连续丢包较少的场景
– 应用场景：VoIP、音频通话
FEC（Forward Error Correction，前向纠错）
FEC通过发送冗余数据，接收端可以在不请求重传的情况下恢复丢失的数据。
工作原理：
– 发送端：对原始数据包进行编码，生成冗余包（FEC包）
– 接收端：如果部分原始包丢失，可以使用收到的原始包和FEC包进行解码恢复
– 优势：无需往返延迟，恢复速度快
FEC类型
块FEC（Block FEC）
– 原理：
– 将数据包分成块（Block），每块包含K个原始包
– 对每块进行编码，生成N个FEC包（N > K）
– 接收端只要收到K个包（原始包+FEC包），就可以恢复所有K个原始包
– 特点：
– 实现简单，计算开销小
– 需要等待整个块才能解码
– 适合批量传输场景
– 应用场景：文件传输、批量数据发送
卷积FEC（Convolutional FEC）
– 原理：
– 使用滑动窗口，对连续的多个包进行编码
– 每个FEC包可以保护多个原始包
– 可以连续解码，无需等待整个块
– 特点：
– 延迟更低，适合实时传输
– 实现复杂度较高
– 保护范围可配置
– 应用场景：实时流媒体、直播
业界FEC实现方案
ULPFEC（Uneven Level Protection FEC）
– 协议：RFC 5109定义的RTP FEC扩展
– 原理：
– 基于XOR运算的简单FEC
– 可以对多个RTP包进行XOR生成FEC包
– 支持多级保护（不同重要性的包使用不同的FEC保护）
– 特点：
– 计算开销小，延迟低
– 可以保护多个包（通常2-8个）
– 标准RTP协议支持
– 应用场景：WebRTC、RTP流媒体
Reed-Solomon FEC
– 原理：
– 基于Reed-Solomon纠错码
– 可以恢复任意K个包中的M个丢失包（K+M = N）
– 数学上最优的纠错码
– 特点：
– 纠错能力强，可以恢复多个丢失包
– 计算开销较大（特别是大块时）
– 需要等待足够的包才能解码
– 应用场景：文件传输、存储系统、卫星通信
RaptorQ FEC
– 原理：
– 基于喷泉码（Fountain Code）的FEC
– 可以生成任意数量的FEC包
– 接收端收到足够数量的包（略多于原始包数）即可解码
– 特点：
– 灵活性高，可以动态调整冗余度
– 计算开销适中
– 适合大规模分发场景
– 应用场景：CDN分发、广播场景
FlexFEC
– 协议：RFC 8627定义的灵活FEC方案
– 原理：
– 支持多种FEC编码方式（XOR、Reed-Solomon等）
– 可以灵活配置保护参数
– 支持1D和2D保护模式
– 特点：
– 灵活性高，可配置性强
– 标准协议，兼容性好
– 适合不同场景的需求
– 应用场景：WebRTC、自适应流媒体
混合方案
ARQ + FEC 组合
– 原理：
– 首先使用FEC尝试恢复丢包
– 如果FEC无法恢复，再使用ARQ请求重传
– 根据网络状况动态调整FEC冗余度和ARQ策略
– 优势：
– 结合两种方案的优点
– FEC处理小范围丢包，ARQ处理大范围丢包
– 适应不同网络条件
– 应用场景：WebRTC、自适应流媒体
分层FEC（Layered FEC）
– 原理：
– 对不同重要性的数据使用不同级别的FEC保护
– 关键帧使用更强的FEC保护
– 非关键帧使用较弱的FEC保护
– 优势：
– 在带宽和可靠性之间取得平衡
– 优先保证关键数据的可靠性
– 应用场景：分层编码、可扩展编码
方案对比与选择
ARQ vs FEC 对比
| 特性 | ARQ | FEC |
|---|---|---|
| 恢复延迟 | RTT + 重传时间（通常100-500ms） | 无需往返，延迟低（通常<50ms） |
| 带宽开销 | 仅重传丢失的包（通常5-20%） | 持续发送冗余数据（通常20-50%） |
| 计算开销 | 低（主要是网络传输） | 中等（需要编解码计算） |
| 延迟特性 | 需要RTT，延迟较高，适合可容忍较高延迟的场景 | 无需往返，延迟低，适合超低延迟场景（<100ms） |
| 适用丢包率 | 低到中等丢包率（<10%） | 中等丢包率（5-20%） |
| 实现复杂度 | 中等 | 中等（FEC编码）到高（复杂FEC） |
业界方案对比
| 方案 | 类型 | 延迟 | 带宽开销 | 实现复杂度 | 主要应用 |
|---|---|---|---|---|---|
| RTP NACK | ARQ | 中等（RTT） | 低（仅重传） | 低 | WebRTC、视频会议 |
| RTX | ARQ | 中等（RTT） | 低（仅重传） | 中等 | WebRTC、SIP |
| RED | 冗余编码/FEC | 低（无需往返） | 中（20-30%） | 低 | VoIP、音频 |
| ULPFEC | FEC | 低（无需往返） | 中（20-40%） | 低 | WebRTC、RTP |
| Reed-Solomon | FEC | 中等（需等待块） | 中高（30-50%） | 高 | 文件传输、存储 |
| FlexFEC | FEC | 低到中等 | 可配置 | 中等 | WebRTC、自适应 |
选择策略
根据延迟要求选择：
– 超低延迟（<100ms）：优先使用FEC（ULPFEC、RED）或ARQ+FEC组合，避免ARQ的RTT延迟
– 低延迟（100-200ms）：优先使用FEC，如果网络RTT较小（<50ms）也可使用ARQ（NACK、RTX）
– 中等延迟（200-500ms）：可以使用ARQ或FEC，ARQ带宽效率更高
– 高延迟（>500ms）：优先使用ARQ，带宽效率更高，延迟影响可接受
根据丢包率选择：
– 低丢包率（<5%）：使用ARQ（NACK、RTX），带宽开销小
– 中等丢包率（5-15%）：使用FEC（ULPFEC）或ARQ+FEC组合
– 高丢包率（>15%）：使用强FEC（Reed-Solomon）或分层FEC
根据应用场景选择：
– 实时视频通话/会议：WebRTC方案（NACK + ULPFEC + RTX），综合使用ARQ和FEC
– 直播推流：RTMP（TCP自动重传，延迟较高）或UDP + FEC（延迟低但需实现FEC）
– 点播：HTTP/TCP（利用TCP自动重传）或DASH/HLS（自适应码率，延迟较高但体验好）
– VoIP音频：RED（冗余编码，延迟低）或NACK（ARQ，延迟较高但带宽效率高）
– 文件传输：TCP（自动重传，可靠）或Reed-Solomon FEC（批量传输场景）
WebRTC的丢包恢复方案（业界最佳实践）
WebRTC综合使用多种方案，实现最佳的性能和可靠性：
1. NACK：检测丢包并请求重传（ARQ机制）
2. RTX：使用独立RTP流进行重传，区分原始包和重传包
3. ULPFEC：发送FEC包进行前向纠错，无需往返延迟
4. RED：在音频中使用冗余编码，携带前序包的冗余数据
5. 自适应策略：根据网络状况（丢包率、延迟、带宽）动态调整FEC冗余度和ARQ策略
实现建议
– 实时通信：优先使用WebRTC方案（NACK + ULPFEC + RTX），综合ARQ和FEC的优势
– 直播场景：根据延迟要求选择TCP（可靠但延迟高）或UDP+FEC（延迟低但需实现FEC）
– 点播场景：使用HTTP/TCP，利用TCP的自动重传机制，延迟要求不严格
– 自定义协议：根据延迟要求、丢包率和带宽限制选择合适的ARQ或FEC方案
拥塞控制
- 检测网络拥塞（丢包率、延迟增加）
- 动态调整发送速率
- 算法：TCP拥塞控制、BBR、WebRTC的GCC等
QoS保障
- 优先级队列：关键帧优先传输
- 带宽预留：为音视频预留带宽
- 流量整形：平滑发送速率
传输优化
自适应码率（ABR）
- 根据网络状况动态调整编码码率
- 网络好时提高码率，网络差时降低码率
- 保证流畅播放的同时尽可能提高质量
网络状态检测
- 监控丢包率、延迟、带宽
- 使用RTCP反馈或自定义机制
- 实时调整传输策略
缓冲策略
- 接收端缓冲一定数据再开始播放
- 平衡延迟和流畅度
- 动态调整缓冲大小