一、冗余报文和媒体报文组织结构优化点

以单帧10个媒体报文，冗余度20%为例。这里webrtc输出要有10个媒体包2个冗余包。webrtc输出的报文序列如下：

代码实现如下：

UlpfecGenerator::AddPacketAndGenerateFec：攒够足够的帧

ForwardErrorCorrection::EncodeFec：根据媒体报文个数和冗余度，计算要生成的冗余报文个数。

ForwardErrorCorrection::GenerateFecPayloads：通过这组媒体报文数据，连续生成num_fec_packets个冗余报文。

EnqueuePackets函数，一口气把num_fec_packets个冗余报文全部发送出去。

可以看出这种打包方式，会增加FEC解码端的解码时间。 建议优化改成FEC和媒体报文交织打包发送。如下：

二、冗余报文的保护个数限制

UlpfecGenerator::AddPacketAndGenerateFec函数限制如下：

目前webrtc限制，仅支持48bit的掩码，若是单帧视频报文数大于48的话，后续报文不会push到media_packets_队列，也就不会参与冗余。降低了FEC的保护能力。实际根据rfc8627协议格式，flexfec可以保护108个媒体包。这里的限制不合理。

flexfec_header_reader_writer.h文件报文格式定义：

 三、仅支持1D列冗余模式

 可以引入2D行列冗余模式，对抗连续丢包和随机丢包两种丢包模型。

 但是这种打包方式冗余度偏高，对于延时要求不是特别严苛的场景下，可以考虑多帧冗余打包。