webrtc QOS方法二.2（ulpfec rfc5109简介）

一、RTP报文结构

1）概览

2）RTP Header for FEC Packets（RFC 3550）

3）FEC Header for FEC Packets

FEC头部为10字节，包含内容如下：
E flag：扩展位，供将来使用，当前设置为0。
L flag：指示长偏移掩码是否使用，0表示偏移掩码为16位，1表示为48位。
P/X/CC/M/PT recovery field：由本FEC包所保护的所有媒体数据包的RTP头部的P/X/CC/M/PT flag位经XOR操作后得到。
SN base：本FEC包所保护的媒体数据包的RTP报文的序列号最小值。
TS recovery field: 由本FEC包所保护的所有媒体数据包的RTP头部中的Timestamp字段经XOR操作后得到。
Length recovery field: 由本FEC包所保护的所有媒体数据包的负载长度(包括CSRC、RTP头部扩展、负载和padding的长度之和，以16位无符号网络序表示)经XOR操作后得到。

4）FEC Level Header for FEC Packets

根据FEC Header for FEC Packets中L bit，确定FEC level header长度为4字节或8字节。
Protection length：2字节，表示本级别所保护的媒体数据的长度
mask：2字节(若L flag设置则为6字节)表示偏移掩码，指示本级别所保护的媒体数据包的分布情况。如果偏移掩码的第i位置为1，则表示第N＋i个媒体数据包在本级别中受保护，其中N为FEC Header for FEC Packets中的媒体数据基准序列号（SN base）。

二、保护规则

a）媒体数据包在高于0级别的等级中只能被保护一次，但是可以在0级别中被多个FEC包保护，只要这些FEC包在0级别的保护长度相等。
b）如果媒体数据包在p级别被保护，那么它也必须在p-1级别被保护。注意保护p级别的FEC包和保护p-1级别的FEC包可能不是同一个。
c）如果FEC包包含p级别保护，那么它也必须包含p-1级别保护。注意p级别保护的数据包可能和p-1级别保护的数据包不是同一个。

规则a)把多重保护限定在0级别，高于0级别的多重保护会减小保护效果并且增大接收端恢复数据的复杂度。规则b)限定媒体数据包受保护的连续性，即不存在中间某段数据不受保护的媒体数据包。规则c)限定FEC数据包保护级别的连续性，即不存在中间某个级别不保护数据的FEC数据包。

 

三、实现简介

1）数据保护实现简介

FEC包1在0级别保护了数据包A、B，

FEC包2在0级别保护了数据包C、D，同时在1级别保护了数据包A、B、C、D。

2）FEC Level Header for FEC之mask

FEC Level Header里面的mask

根据RFC5109定义，一个媒体数据包可以被多个FEC包保护，一个FEC包可以多保护多个媒体数据包。

假设m个媒体数据包需要n个FEC数据包保护，则可以定义一个如下图所示的二维的m * n零一矩阵来描述媒体数据包在fec包中的保护分布情况：

1）矩阵中元素m[i, j]置1表示第j个媒体数据包需要第i个FEC包保护。

2）从行角度来看，第i行元素表示第i个FEC包保护的媒体数据包的集合；

3）从列角度讲，第j列元素表示保护第j个媒体数据包的FEC包的集合。

由于该矩阵是零一矩阵，因此在存储上可以采用掩码来存储。这个掩码也就是FEC Level Header中所定义的mask掩码。

那么掩码中的0、1如何分布？现实世界中网络丢包分为随机丢包、突发丢包两种情况，FEC包需要能够针对这两种情况对媒体数据包进行保护。WebRTC预先构造两个掩码表kPacketMaskRandomTbl和kPacketMaskBurstyTbl，以模拟在随机情况和突发情况下媒体数据包在FEC包中的保护分配情况。

假设在随机丢包场景下，对于m * n的情况，我们只需要从kPacketMaskRandomTbl[m][n]就可以获取FEC包所需要的全部掩码，然后该掩码为基础，构造FEC数据包。

3）备注

UlpfecGenerator::AddRtpPacketAndGenerateFec函数中可以看到，webrtc仅使用了MaskRandomTbl和MaskBurstyTbl两个掩码表，进行冗余。

void GeneratePacketMasks：

但是里面还保留了一套UnequalProtectionMask接口，这套接口里面有三种掩码模式：NoOverlap、Overlap、BiasFirstPacket

非对称保护思想是，FEC包对媒体数据包集合中的不同数据包实施不同的保护力度。某些场景下，一帧视频数据编码后生成的一系列RTP数据包，重要性不一样，比如开始几个RTP包包含PPS、SPS等信息，重要性会大一些。因此，在构造FEC包的掩码时，有均匀保护和非均匀保护两种策略。

均匀保护：所有RTP包重要性一样，FEC包对他们进行平等均匀保护。对于m * n，FEC包使用掩码MaskRandomTbl[m][n]。

非均匀保护：RTP包集合分重要数据包集合S1、普通数据包集合S2，分配较多个FEC包保护S1，较少个FEC包保护S2。WebRTC定义三种模式针对实现非均匀保护：

1）kModeNoOverlap：非叠加保护，保护S1的掩码和S2的掩码相互分离。
2）kModeOverlap：叠加保护，保护S1的掩码和S2的掩码叠加在一起。
3）kModeBiasFirstPacket：在均匀保护的基础上，所有FEC包都保护第一个包。

假设保护场景为(m, n)，其中重要数据包为前k个，分配给重要数据包的FEC包个数为t，掩码表为mask_table。则三种场景下最终掩码的确定如下：

1）kModeNoOverlap：mask_table[k][t]和mask_table[m-k][n-t]的移位组合。
2）kModeOverlap： mask_table[k][t]和mask_table[m][n-t]的拼接。
3）kModeBiasFirstPacket：mask_table[m][n]，再第一列全部置1。

不过目前webrtc的编码器使用单Slice编码，视频RTP报文重要程度无大差别，所以就没有使用这个功能。

四、参考

《 rfc5109》

《ULPFEC在WebRTC中的实现》