本方案为C++开发，提供PC、Android（JNI）、IOS跨平台的支持，为了方便测试，在PC下开发了一个简易测试DEMO如下图1所示，该DEMO主要用于验证功能，能直观的展示所有收发包数据。

图1  FEC/QOS 数据测试型DEMO界面

测试工具为点对点工作模式，可在两台PC上各自运行（同时也支持单机模式，只需将收发IP地址均设置为本地IP即可），以实现双方之间RTP（FEC+QOS）通讯。软件收发自定义的测试包数据，提供了模拟丢包功能，支持按固定间隔丢包或者按随机比率丢包；支持设置FEC冗余度或者选择冗余度自适应，支持设置QOS丢包等待时延等参数。

测试工具内部默认使用10个媒体包外加冗余度（数量由选择的冗余度决定）作为一个GROUP，当选择冗余度20%时，一个GROUP由10个媒体包附加2个冗余包组成。下图是Wireshark的观察情况，10个媒体包后面紧接着2个冗余包。

图2  Wireshark截包观察GROUP组成

需要说明的是：程序主动丢包是在UDP发送层进行，所以即可能丢媒体包也可能丢

冗余包。下面我们以20%冗余度为例说明系统对各类丢包率的抵抗能力。

当选择每10个包丢1个包时（丢包率10%），一个GROUP中最多只会丢弃1个包，20%的冗余度足够抵抗这一丢包率，测试结果也验证了这一结论，接收到的所有媒体包序号均保持连续，丢包率从10%降为0%，实验情况如上图1所示。

当选择每5个包丢弃1个包时（丢包率20%），丢包情况如下所示：

图3  每5个包丢弃1包时的情况

对于第一个GROUP，一共丢弃了三个包，包括0号媒体包、5号媒体包、0号冗余包。因为接收的媒体包数为8个加接收的冗余包数1个，总数小于总媒体包数（10个），因此接收端FEC无法恢复。对于第二个GROUP，只丢失了两个媒体包，可以正常恢复。下图4的实验结果也说明了推断的正确性，0号媒体包、5号媒体包丢失，13号、18号媒体包被成功恢复，系统丢包率从20%降低到10%左右。

图4  经过FEC恢复后的数据包情况

当选择每4个包丢弃1个包时（丢包率25%），一个GROUP中将丢弃3个数据包，必然不满足FEC恢复条件，无法恢复，此时将原样输出收到的数据包，入下图5所示：

图5  丢包率过高无法恢复的情况

需要说明的是：丢包是针对传输层数据包（媒体包和冗余包）进行的，DEMO软件中只显示媒体包部分，没有显示冗余包。“下行丢包率”参数是统计的传输层数据包的丢失率，而“下行丢包率（经过丢包恢复）”是统计的应用层媒体包的丢失率，所以会出现后者比前者还高的情况。

当系统丢包率达到FEC特定冗余度的理论极限时，丢包将无法恢复，此时唯有加大冗余度才能实现恢复功能。实际应用时，应该对线路的网络丢包情况做一定统计分析，以确定最佳的冗余度方案，这个往往是比较困难和繁琐的，为此我们推出的自动冗余度方案，从一定程度上解决了这个问题。

若定义“无失真抗丢包能力”为可百分百无失真恢复丢失的媒体包的能力。下表是各冗余度下，传输层“无失真抗丢包能力”的估算情况：

是不是10个冗余包配2个冗余包时，信道丢包率只要低于16.67%就肯定可以无失真恢复呢？这个不一定，因为丢包的分布情况是随机的，比如100个包里丢10个包，10个包是连续丢还是随机均匀丢对FEC恢复来说是完全不同的。FEC并不能解决所有丢包问题，但可以显著提升系统的抗丢包能力。