目录

QOS-FEC-NACK传输库简介

实验环境

测试DEMO说明

测试项说明

测试结果

竞品分析

总结

---

                    QOS FEC NACK 实时音视频传输库测试 告

                                                                            www.mediapro.cc

• QOS-FEC-NACK传输库简介

QOS-FEC-NACK是一套集FEC前向纠错、QOS、NACK选择性重传、JitterBuff、码率自适应等技术于一体的实时音视频传输解决方案。方案基于私有的UDP协议，以库或源码的方式提供用户，其接口简洁可快速集成到用户现有音视频系统之中。方案使用C++开发支持Windows、Android（JNI）、Ios、Linux系统，支持X86、ARM  32位、64位平台。

QOS-FEC-NACK库特别适合在需要在弱 （4G、Wifi）下进行可靠、实时音视频传输的领域。它具有以下特点：

1. 自适应FEC冗余度，根据当前 络状况自适应调整冗余度，提高抵抗力同时避免带宽浪费。
2. 自适应FEC Group配置，对不同时刻、不同特征的媒体数据使用不同的FEC Group策略，在不增加抖动的前提下提升连续丢包的抵抗力。
3. 选择性NACK重传，只对预期无法恢复的数据包发起重传，最大限度避免拥塞和抖动。
4. 自适应NACK等待时间选取，内置NACK信令、数据处理，对外层黑盒。
5. 无延时的乱序、重复包处理。
6. JittBuff自适应缓存处理，抵抗 络抖动，提供流畅输出。
7. 码率/帧率自适应建议输出
8. IDR帧请求建议输出
9. 丢帧冻结机制支持
10. 提供丢包率、码率、RTT等上下行基础统计数据获取
11. 针对嵌入式等资源受限平台设计，资源占用低，运行效率高。编码规范、代码精简、注释完善，不依赖于任何第三方开源或闭源库。

 

• 实验环境

       为了保证测试环境一致性和可重现性，我们将在较好的 络环境下借助第三方弱 模拟工具，模拟各类 络情况。同时也会使用信 较弱的wifi搭建真实的弱 环境。

       这里列举Windows平台上常用的两款弱 模拟工具：

       A、Network Emulator for Windows Toolkit

       该工具是一款windows平台弱 模拟工具，使用说明可以参考以下链接：

       https://blog.csdn.net/lluozh2015/article/details/50545159

                           

                                            图1 Network Emulator for Windows Toolkit工具

软件提供：丢包、包篡改、延时、带宽限制、乱序、断 等功能。

注意事项：

    1、我们按照上面链接搭建测试工程后，发现实际未生效。解决办法是加载程序安装包自带的样例XML配置（ConsoleToConsole2PercentPacketloss.xml），在此配置基础上修改为自己的测试需求。

      2、如上图所示，测试项可以作用于本机输入也可以作用于本机输出。比如对Outgoing的丢包设置将对本机发出的包进行丢包，适合在发送端使用。而对Incoming的丢包设置将对本机收到的包进行丢包，适合在接收端使用。对待测应用程序而言，在发送端丢包还是接收端丢包没有差异，本次实验均在发送端进行弱 测试。

                                                      

                                                      

                                                                    图2 在发送和接收处模拟弱

     B、Clumsy

    Clumsy是一款小巧而功能强大的开源弱 模拟工具，支持windows平台，可用于模拟：丢包(Drop)、延时(Lag)、重复(Duplicate)、乱序(Out of order)、篡改(Tamper)、抖动(Throttle)等。其项目地址：

      http://jagt.github.io/clumsy/cn/index.html

                                               

                                                    图3 Clumsy对所有发送的包按10%进行丢包处理示意

    本次测试主要使用Clumsy，相比使用Network Emulator for Windows Toolkit，二者测试结论基本一致。

 

 

• 测试DEMO说明

      本次测试使用windows平台下的桌面投屏DEMO，DEMO分为发送端和接收端，发送端采集自身桌面和扬声器音频，压缩后通过QOS-FEC-NACK 点对点SDK发往接收端，后者解码并渲染输出，从而实现屏幕共享功能。

A、接收端

     该组DEMO的功能与投屏类应用类似，我们首先启动接收端DEMO。进入UDP-AVClient-ScreenPlay文件夹，双击启动AVClient.exe即可。

                                           

                                                               图4 接收端DEMO启动界面

       接收端启动后，将显示其投屏码（图中的4000），发送端可以使用该投屏码进行投屏。当发送端码流到来时，接收端将使用一个新的窗口“Remote Video”显示远端画面，如下图所示：

                                                     

                                                         图5 接收端独立的窗口展示远端画面

      注意：“Remote Video”窗口是一个全屏窗口，用户可以自行在底部任务栏切换。当远端停止音视频传输时，该窗口内容无更新，且不会响应鼠标事件，只能底部切换。

      接收端文件夹下的AVClient.ini文件为其配置文件，对配置文件的修改需要重启客户端方能生效。配置文件包括如下几项：

                                                             

                                                                    图6 接收端配置文件

       UseFreezeFrameWhenLost 表示当出现视频丢包无法恢复时，为了不展现出花屏而将画面冻结，直至完整的关键帧到来再继续送显。该值一般设置为1开启。

       BufferTime表示接收Jitter buff缓存毫秒数，为了抵抗 络传输、FEC恢复、QOS乱序恢复、NACK重传等行为带来的抖动，接收端需要加入缓存以保障视频的流畅性。流畅性和实时性（时延）是一对矛盾的指标，Jitter buff必然将引入一定延时，当前默认为200ms。

       CaptureDownStream表示是否开启录制功能，若开启则将接收到的音视频流录制到TS文件。测试过程中建议关闭。

       FecEnableNack表示本端视频是否开启NACK功能，建议开启以提高视频抗丢包能力。

      Debug组下是日志相关的配置，比如path指定日志文件存放的路径，level表示当前期望输出的日志级别，常用级别有DEBUG, INFO, WARN, ERROR。enable表示是否启动日志功能，建议启用。

       在后面的测试过程中，将会对部分配置进行调整，查看调整前后的效果对比。

B、发送端

发送端为UDP-AVClient-ScreenCap目录下的AVClient.exe，在启动前我们需要先对其进行配置，配置文件为AVClient.ini

                                                            

                                                                      图7 发送端配置文件

VideoBitrate表示发送端使用的视频编码码率，单位kbps，设置为3000即表示3Mbps

VideoTransWidth表示发送端使用的视频编码宽度，VideoTransHeight表示视频编码高度，ViceFrameRate表示视频编码帧率（本程序使用Direct桌面采集，在性能较低的机器上采集帧率无法达到30fps，编码帧率仍然会按30fps配置编码器）

RemoteIpAddr表示接收端的IP地址，请按自己接收端实际情况进行配置。

EncodeQualityLevel0to7表示当采用X264软编码时，使用的preset级别，0表示ultrafast，1表示superfast，2表示veryfast，3表示faster，4表示fast，5表示medium，6表示slow，7表示slower。等级越高同等码率下的图像质量越好，但CPU占用也越高，请根据自身机器配置而定，建议设置为1。

HWEnable表示是否启用硬编码，程序支持Intel QSV硬编码和Nvidia硬编码，相比X264能获得更低的CPU占用。不过硬编码的缺点是灵活性不足，无法支持传输层IDR帧请求机制。

FecRedunRatio表示上行FEC使用的冗余度，比如设置为30时表示使用30%的上行冗余，设置为0时表示使用自动冗余度。

FecGroupSize表示上行FEC使用的group标准分组大小。为了获得最佳效果，分组大小建议与码率想匹配。512Kbps以下建议设置为8，512Kbps~1Mbps建议设置为16，1Mbps~2Mbps建议设置24，2Mbps~4.5Mbp建议设置28，4.5Mbps以上建议34。注：当关闭自动group策略时，每个group大小均为该值设定值。当开启传输层自动group策略时，将产生非均匀大小的group，此时该值用来表示最小的group大小。

FecEnableNack表示是否启用NACK选择性重传机制。收发双方均开启时方能生效，建议双方均开启以提高系统抗丢包能力。

IDR帧间隔：当使用X264编码时，发送端使用5秒一个IDR帧。当使用硬编码时，发送端使用3秒一个IDR帧。

启动发送端后进入如下界面，输入接收端展示的投屏码即可开始连接。注意：收发双方并无TCP连接，这里的连接可以理解为本地UDP资源的创建。

                                                         

                                                                           图8 发送端启动界面

       连接后，客户端将进入下图所示的待共享屏幕状态。可以点击主界面启动按钮或者使用悬浮球来启动桌面共享。启动后，接收端就能看到发送端的桌面并能听到发送端播放的音乐了。

                                                     

                                                                            图9 发送端开始共享桌面

 

 

• 测试项说明

说明：同市面上各大实时视频服务商一样，DEMO也提供丢帧冻结机制，这样用户无法察觉到丢帧带来的花屏，从而获得更好的用户体验。因此本次测试中，丢包最终将体现为画面卡顿。DEMO提供了发送端码率自适应功能，传输层根据当前的 络状况实时调整发送帧率，从而达到间接调整码率的目的。相比直接调整编码码率，调整帧率有如下优点和缺点：

优点：

A、相比直接调整码率，更难察觉质量跳变。

B、无需适配各个平台的硬件编码器，各个平台均可以采用统一的帧率调整方案。

缺点：

A、画面流畅性受到影响

 

评测项：流畅度

关于流畅度，我们将分为以下几个级别：

1. 画面流畅
2. 偶尔微弱卡顿（附加：卡顿时长+频率描述）
3. 明显卡顿（附加：卡顿时长+频率描述）
4. 较长时间卡顿

 

评测项：延时

       延时计算方式：在发送端打开毫秒精度秒表，接收端将看到秒表值，使用手机对二者屏幕拍照，计算二者差值得到总延时。整个系统中，延时主要有非传输层延时和传输层延时两部分组成。非传输层延时包括：采集、编码、解码、渲染引入的延时，本DEMO实际采集帧率无法达到恒定30fps，对整体延时稍有影响。

       传输层延时又分为：相对稳定部分和抖动延时部分。其中接收端Jitter buff程序加入的缓存延时属于相对稳定部分。 络线路传输延时、QOS乱序等待时间、NACK重传等待时间、FEC恢复等待时间、画面冻结等待时间属于抖动延时部分，抖动延时只在该动作发生时引入，且动作完成后消失。QOS乱序发生时才会引入等待，比如收到1、2、4 包，输出1、2后会进入等待，若此期间收到3 包则输出3、4，若超出等待时间仍未收到3 包则直接输出4 包，即便后续收到3 包也将其丢弃。若当前丢包无法恢复时，即会触发NACK重传，接收方进入NACK等待，等待期间收到了重传包则输出，否则等待超时后退出。FEC有group组的概念，冗余包位于组的尾部，前部媒体包的丢失需要等待尾部冗余包的到来方能恢复输出，因此FEC解码在丢包时也会引入抖动，FEC group越大引入的抖动也越大，不过在同等冗余率下抗连续丢包的能力也越强。当NACK、FEC均无法恢复时，将冻结画面并请求远端发送IDR，只有收到完整的IDR帧时才恢复送解码、渲染，这里也将引入抖动延时。编码器Gourp越大，“可能”需要的IDR等待时间越长（当接收端主动请求的IDR帧也出现丢包时，只能依靠编码器自身的周期性IDR帧。当接收端主动请求IDR帧传输成功时，等待时间和编码器自身的周期性IDR间隔无关。）

       需要说明的是延时指标和流畅性指标往往是一对矛盾，播发端缓存的数据越多，流畅性越好，延时也越大，反之若缓存的数据较少或者不缓存，则延时更低，流畅性不足。传输层需要根据实际应用场景选择合适的策略（折中）。SDK提供API供用户配置接收端的Jitter Buff缓存毫秒数。默认情况下使用300ms缓存，这是基于300ms的延时不会对双向音视频实时互动产生影响这一业内经验。

评测项：清晰度

DEMO使用自适应帧率方式来间接实现码率自适应，因此图像质量与传输层无紧密关系，主要由用户指定的编码分辨率、码率、桌面画面内容决定。注：帧率降低时，帧间相关性降低，运动估计残差更大，同等码率下编码质量会稍弱。

 

• 测试结果

测试默认配置：

接收端使用300ms缓存，具体配置入下图所示：

[Config]

UseFreezeFrameWhenLost=1

BufferTime=300

FecEnableNack=1

发送端使用720P  2Mbps  30fps，FEC使用自动冗余，具体配置入下图所示

[Config]
VideoBitrate=2000
VideoTransWidth=1280
VideoTransHeight=720
ViceFrameRate=30
EncodeQualityLevel0to7=1
FecRedunRatio=0
FecGroupSize=28
FecEnableNack=1
HWEnable=0

画面内容：全屏播放影片

 

丢包测试

发送端使用Clumsy 设置发送丢包5%、8%、12%、20%、30%，为了排除遗留影响，每次修改丢包率均在发送端断开连接再重新连接。

5%丢包时，连续观察20分钟，画面流畅，较难感知丢包，延时稳定在300ms左右，冗余率基本维持在自动冗余度的下限30%，码率平均约2.4Mbps。

8%丢包时，连续观察20分钟，画面流畅，较难感知丢包，延时稳定在300ms左右，冗余率基本维持在自动冗余度的下限30%，码率平均约2.4Mbps。

12%丢包时，连续观察20分钟，画面流畅，较难感知丢包，延时稳定在300ms左右，，冗余率基本维持在自动冗余度的下限30%，码率平均约2.4Mbps。

20%丢包时，连续观察20分钟，因码率自适应被触发，画面帧率逐渐下降，总体比较流畅，较低频率偶尔卡顿，卡顿时长约300ms左右（IDR请求）。延时稳定在330ms左右。码率约2.2Mbps。

30%丢包时，连续观察20分钟，因码率自适应被触发，画面帧率逐渐下降，有较明显的卡顿。延时稳定在400ms左右。码率约2.0Mbps。

                                

                                                           图10  20%丢包时的延时情况

 

重复测试

测试配置A，发送端使用Clumsy 设置Duplicate发送重复率5%、12%、20%、30%，每次重复1包（Count设置为2）。

5%重复包时，连续观察20分钟，画面流畅，延时稳定在260ms左右，冗余率基本维持在自动冗余度的下限30%，码率平均约2.4Mbps。

12%重复包时，连续观察20分钟，画面流畅，延时稳定在260ms左右，冗余率基本维持在自动冗余度的下限30%，码率平均约2.4Mbps。

20%重复包时，连续观察20分钟，画面流畅，延时稳定在260ms左右，冗余率基本维持在自动冗余度的下限30%，码率平均约2.4Mbps。

30%重复包时，连续观察20分钟，画面流畅，延时稳定在260ms左右，冗余率基本维持在自动冗余度的下限30%，码率平均约2.4Mbps。

可见单纯的重复包对系统影响很小。

 

乱序测试

测试配置A，发送端使用Clumsy 设置Out of order发送乱序率5%、12%、20%、30%。

5%乱序包时，连续观察20分钟，画面流畅，延时稳定在280ms左右，冗余率基本维持在自动冗余度的下限30%，码率平均约2.4Mbps。

12%乱序包时，连续观察20分钟，画面流畅，延时稳定在280ms左右，冗余率基本维持在自动冗余度的下限30%，码率平均约2.4Mbps。

20%乱序包时，连续观察20分钟，画面流畅，延时稳定在280ms左右，冗余率基本维持在自动冗余度的下限30%，码率平均约2.4Mbps。

30%乱序包时，连续观察20分钟，画面流畅，延时稳定在280ms左右，冗余率基本维持在自动冗余度的下限30%，码率平均约2.4Mbps。

可见单纯的乱序包对系统影响很小。

 

延时测试

测试配置A，发送端使用Clumsy 设置Lag发送延时50、100、200、400、600ms。

50ms时，连续观察20分钟，画面流畅，延时稳定在310ms左右，冗余率基本维持在自动冗余度的下限30%，码率平均约2.4Mbps。

100ms时，连续观察20分钟，画面流畅，延时稳定在340ms左右，冗余率基本维持在自动冗余度的下限30%，码率平均约2.4Mbps。

200ms时，连续观察20分钟，画面流畅，延时稳定在520ms左右，冗余率基本维持在自动冗余度的下限30%，码率平均约2.4Mbps。

400ms时，连续观察20分钟，画面流畅，延时稳定在740ms左右，冗余率基本维持在自动冗余度的下限30%，码率平均约2.4Mbps。

600ms时，连续观察20分钟，画面流畅，延时稳定在920ms左右，冗余率基本维持在自动冗余度的下限30%，码率平均约2.4Mbps。

线路延时最终会叠加到总体延时之上，测试结果符合预期。

 

抖动测试

测试配置A，分别进行以下几项测试

A、发送端使用Clumsy 设置Throttle  分别5%、12%、20%、30%概率抖动30ms。

测试结果：5%~30%概率30ms抖动对流畅性、延时无可感知的影响。

B、发送端使用Clumsy 设置Throttle  分别5%、12%、20%、30%概率抖动100ms。

测试结果：5%~30%概率100ms抖动对流畅性、延时无可感知的影响。

C、发送端使用Clumsy 设置Throttle  分别5%、12%、20%、30%概率抖动150ms。

测试结果：5%~30%概率150ms抖动对流畅性存在一定影响，几十秒一次的可感知微弱顿挫感。

D、发送端使用Clumsy 设置Throttle  分别5%、12%、20%、30%概率抖动200ms。

测试结果：5%~30%概率200ms抖动对流畅性存在较大影响，随着概率的增加，30%概率时一秒一次的可感知明显顿挫感。

       抖动达到一定程度时，超出Jitter Buff抵抗力，将出现画面顿挫。目前版本暂未加入Jitter Buff能力自适应，用户设定Jitter Buff深度后，即根据设定值确定缓存深度，不会跟随媒体流实际抖动自适应调整。这样做有以下优缺点：

       优点：系统延时稳定于用户设定值，不随 络抖动增长而增长。

       缺点： 络抖动超出设定值时，播放器将出现卡顿。当实际抖动小于设定值时，仍然引入了设定值的延时。

抖动优化是后续传输层优化的方向之一。

 

极速测试

       当设定接收端Jitter Buff缓存0ms时，即关闭接收端缓存功能，收到数据第一时间解码、第一时间渲染，此时无程序引入的延时，我们称之为极速模式。

        设置接收端配置文件BufferTime=0，不加入人为弱 措施时：

测试结果：连续观察20分钟，画面总体比较流畅，延时稳定在94ms左右。对于延时要求较高，而对于流畅性没有极高要求的场合可以使用极速模式。

 

断 测试

本DEMO收发双方并无TCP连接，断开一方 络后，另一方只是无法接收或发送媒体数据，待 络恢复后自行恢复。

 

• 竞品分析

       实时音视频传输一直是多媒体通信的核心之一，腾讯云、 易云信以及部分新兴企业如声 、即构均提供了云解决方案。各家方案各有千秋，通过相互对比借鉴，能获得更多灵感。

 

1、腾讯云：https://cloud.tencent.com/product/trtc

站介绍：腾讯实时音视频（Tencent Real-Time Communication，TRTC）是腾讯云基于QQ十多年来在音视频通话技术上积累，提供全平台互通高品质实时视频通话服务的一款产品；抗丢包率超过 40%，抗 络抖动超过 1000ms，即使在弱 环境下仍然能够保证高质量的音视频通信，确保视频通话过程顺畅稳定。

       腾讯实时音视频同样使用私有的UDP协议，目前广泛应用于微信、QQ等产品。腾云实时音视频官 提供了DEMO供用户测试，使用步骤大致如下，具体请参考腾讯文档说明：

       https://cloud.tencent.com/document/product/647

       A、用户需要先在腾讯云上注册实时音视频服务，并在控制台中指定音视频参数。

       B、下载iLive SDK和配套DEMO工程，在DEMO代码中填写注册时生成的APP ID等参数并编译可执行程序。

       用户在腾讯云后台中对音视频互动的详细参数进行设置（注意：腾讯云SDK并不在客户端进行音视频参数设置，而是在管理后台设置，客户端选择后台中的某组设置）。当前可供用户设置的分辨率最大到720P，码率最高到1500kbps，可能更高级别的参数需要人工客服申请。

                                  

                                                                     图11 腾讯云实时音视频控制台

                                                      

                                                               图12 腾讯云实时音视频能力设置

       为了方便演示，我们在附件中提供了腾讯云DEMO的源码以及一个使用我们申请测试账 编译的可执行程序。程序包括一个发送端和一个接收端，发送端将采集系统默认的摄像头编码后发往腾讯云服务器，后者转发给接收端。

注意：为了搭建与我们DEMO类似的环境，我们使用虚拟桌面采集摄像头作为系统默认摄像头（运行我们DEMO后，将自动向系统注册一个名为screen-capture-recorder的虚拟摄像头，拔掉发送端机器的其他摄像头，确保让虚拟摄像头成为默认摄像头）。

注意：腾讯云并不提供P2P服