【原创】FEC/QOS 数据测试型DEMO——–FEC功能验证

本方案为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并不能解决所有丢包问题,但可以显著提升系统的抗丢包能力。

发表评论

电子邮件地址不会被公开。 必填项已用*标注