WebRTC 的前向纠错编码 - XOR FEC
2016-12-11 21:37
495 查看
FEC Format
WebRTC 应用RFC 5109所定义的 XOR 来对RTP 数据进行保护, 以抵抗网络丢包. 协议所定义的包结构如下:+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | RTP Header (12 octets or more) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | FEC Header (10 octets) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | FEC Level 0 Header | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | FEC Level 0 Payload | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | FEC Level 1 Header | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | FEC Level 1 Payload | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Cont. | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
RTP Header 就是 RFC 3550 所定义的RTP 报文结构的头部. 如果这个RTP Packet 是FEC包的话,
M - Marker 必须为0, 对于FEC 而言, Marker 是无意义的.
SSRC - SSRC必须跟这个FEC所要保护的RTP 数据包的 SSRC一致, 表示这两者是同源的。
TimeStamp - Timestamp的时钟频率必须跟这个FEC所要保护的媒体数据的时钟频率一致.
Payload - FEC 包的Payload type 是需要通过SDP协商给定的。
对于不支持这FEC的系统, 简单丢弃其接收到的FEC包即可, 不影响它对数据报的处理.
这里有多个FEC Level Header, 是用来做ULP 保护的, ULP可以产生多种交织的保护方式, 比较复杂。 不过WebRTC不支持ULP, 只能使用FEC Level 0 对数据进行保护.
FEC Header的定义:
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |E|L|P|X| CC |M| PT recovery | SN base | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | TS recovery | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | length recovery | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
E - 1 bit, 保留位, 必须为0
L - 1 bit, 用来标示 FEC Level Header里的MASK 是否为 Long Mask, 普通的MASK 长度为16 bits, 一个FEC 数据包 Group 的包个数最多为16个, Long MASK 长度为 48 bits, 一个FEC 数据包Group的包个数最多为48个.
P - 1 bits, X - 1 bits, CC - 4 bits, M - 1bit, 用来产生RTP Header里相应字段的保护位。
PT recovery - 7 bits 数据包 payload type 的保护位
TS recovery - 32 bits, 数据报Timestamp的保护位
SN base - 数据包里的最小sequence.
Length recovery - 16 bits, 数据长度的保护位, 数据包的长度是 CSRC List, payload, padding 的总长度
ULP Level Header
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Protection Length | mask | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | mask cont. (present only when L = 1) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Protection length - FEC 数据长度
MASK - 如前所述, MASK 可以是16 bits 的 short mask, 或 48 bits 的 long mask, 是用单个bit 位来定义 其对应 sequence 的rtp 数据报是否属于这个FEC包要保护的Data Group. 其对应关系很简单, 就是从SN base 开始的连续的16 or 48个包分别对应于mask 的比特位, 1表示这个数据包被保护, 0 表示这个数据包不被保护。
Red Packet
WebRTC 对相应的数据包Group产生FEC包之后, 数据包和FEC包都被重新编码为Red Packet,然后进行传输. 关于Red Packet, 可以参看 http://blog.csdn.net/volvet/article/details/53573359Reference:
1. rfc2198 - RTP Payload for Redundant Audio Data
2. rfc5109 - RTP Payload Format for Generic Forward Error Correction
相关文章推荐
- WebRTC中的前向纠错编码 - Red Packet
- webRTC的 OPUS编码 在FEC中的应用
- 【WebRTC】视频采集 / 编码 / 发送
- 差错掩盖算法:(1)基于RTP的FEC前向纠错算法简介
- 汉明码编码的纠错原理
- 史上最通俗的海明码编码计算、检错和纠错原理解析
- FEC(向前纠错)
- webrtc视频采集后编码与发送
- webrtc 研究-音频编码
- WebRTC VideoEngine综合应用示例(三)——集成X264编码和ffmpeg解码
- WEBRTC FEC/NACK 前向纠错码
- 计算机组成.其实机器也会出错.错误检验与纠错的数据编码
- 无线通信中FEC 编码原理及评价(1)
- WebRTC 集成X264编码和ffmpeg解码
- Forword Error Correction, FEC前向纠错是什么
- WebRTC中OPUS编码相关设置和分析
- webrtc fec
- 无线通信中FEC 编码原理及评价(4)
- WebRTC中的Opus编码揭秘
- WebRTC::FEC