nack fec心得

webrtc中fec的处理机制:获取一帧数据，拆分成多个rtp包，再封装成fec包（fec只有primay block）,发送到网络；之后根据rtp包生成相应数量的fec包(根据冗余度来生成对应数量的包)，再发送到网络。
需要注意的是:rtp red包和fec red包都是序号连续的。所以判断一个完整帧的依据依然可以使用:获取到首包，获取到尾包，中间包连续。但因为fec的加入，导致所有原始数据的rtp包无法连续（和纯nack不会这样）。
所以针对带有fec包的丢包处理机制是这样的:如果一个完整帧里面丢了原始数据包，一定要在当前帧的所有包到来之前，把此帧数据恢复完整，否则就会导致解码异常问题。如何恢复，两种策略同时使用：1.发现丢包会立即出发nack重传（即使是乱序也会触发）
2.靠后面来的fec包还原丢失的数据包。注意，以上两种策略一定要保证在下一帧数据到来之前把上一帧的数据包恢复完整，否则就会出现解码异常。

nack的处理机制:
与webrtc相比，我在此作了改善。发现丢包后立即触发重传，最多触发5次。
nack如何判断一帧的完整性:因为nack中没有fec的数据包，因此所有的数据包都是原始数据的rtp包。当前帧获取到了首包，尾包，中间包连续后，即可触发解码；之后可立即判断出下一帧的首包序列号是多少，因此比较容易。
fec如何判断一帧的完整性 :当前帧获取到了首包，尾包，中间包连续后，即可触发解码；但是下一帧的首包不一定是下一个序列号对应的数据包，因为有fec包存在。因此一定要保证在下一帧数据到来之前把上一帧的数据包恢复完整，否则就会出现解码异常

 

webrtc追求的是最低的延迟，当收到一个完整帧后立即解码输出。而在有fec数据后，判断一帧完整性变得异常复杂，最终我放弃了webrtc的思路。而是用空间换取了时间：内存中保存5个完整帧，通过mark识别，当大于5个完整帧后，取出首帧来解码 ，并从内存中删除该部分数据。