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）下进行可靠、实时音视频传输的领域。它具有以下特点：

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

本文档使用一个点对点投屏DEMO对方案进行各项弱网模拟测试，研究各种弱网特征下传输层的表现情况。文档最后对行业内优秀解决方案：腾讯云、声网Agora WebRtc等进行了研究。

实验环境

为了保证测试环境一致性和可重现性，我们将在较好的网络环境下借助第三方弱网模拟工具，模拟各类网络情况。同时也会使用信号较弱的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、画面流畅性受到影响

评测项：流畅度

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

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

评测项：延时

延时计算方式：在发送端打开毫秒精度秒表，接收端将看到秒表值，使用手机对二者屏幕拍照，计算二者差值得到总延时。整个系统中，延时主要有非传输层延时和传输层延时两部分组成。非传输层延时包括：采集、编码、解码、渲染引入的延时，本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，即使在弱网环境下仍然能够保证高质量的音视频通信，确保视频通话过程顺畅稳定。

注意：腾讯云、阿里云等也提供基于RTMP\HLS的直播服务，这类基于TCP协议的直播并非本文所描述的音视频实时互动范畴，它们往往用于对延时要求不高的单向的音视频传输服务，其对弱网的抵抗力较差，在网络恶化时服务质量衰减迅速。本报告中，我们将以大牛直播RTMP传输为例，测试基于TCP的RTMP协议在弱网下的表现。

腾讯实时音视频同样使用私有的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服务，所有音视频均走服务器转发，这可能是由其收费方式决定的，对于所有用户按使用分辨率、时长收费，一个发送端、一个接收端使用1小时，则按2*1小时计费。若提供P2P服务，并对用户之间的P2P传输收取费用则于情于理说不过去。

注意：腾讯云SDK将视频编解码和传输层一起封装。

正常情况下，使用720P 1.5Mbps码率，在无弱网模拟的情况下，连续观察20分钟，画面流畅，延时稳定在140ms左右，码率平均约1.5Mbps。

丢包测试结果：

5%丢包时，连续观察20分钟，画面流畅性有一定下降（帧率下降导致，均匀丢帧，无长时间卡顿）延时稳定在150ms左右，码率平均约1.6Mbps。

12%丢包时，连续观察20分钟，画面流畅性进一步下降（帧率下降导致，均匀丢帧）偶尔（几分钟）出现明显卡顿，延时稳定在140ms左右，码率平均约1.6Mbps。

20%丢包时，连续观察20分钟，画面几秒一次频繁卡顿（卡住约500ms左右），帧率较低，延时稳定在200ms左右，码率平均约1.6Mbps。

通过画质对比，腾讯云应该也是采用帧率自适应，并未降低码率，图像质量相对恒定。码率控制和用户购买的非常接近，毕竟这个涉及到自身成本。延时总体较低，接收端缓存较小，在丢包时因NACK引入的瞬间抖动导致画面易出现卡顿。IDR帧间隔约为1秒。

抖动测试结果：

使用720P 1.5Mbps码率，30%概率引入100ms抖动，无丢包，此时画面流畅，延时扩大到240ms左右，说明腾讯检测到网络持续抖动后自适应的增加了接收端缓存时间。当关闭抖动模拟时，延时恢复到140ms。观察到开启抖动模拟时，画面会持续1~2秒的卡顿期，然后延时加大，流畅性提升，说明在此期间进行了缓存的重新初始化动作。腾讯的接收缓存自适应调整的策略值得我们学习。

重复测试结果：

30%重复包时，连续观察20分钟，画面流畅性与未开启时基本一致，延时稳定在140ms左右，码率平均约1.5Mbps。

乱序测试结果：

30%重复包时，连续观察20分钟，画面流畅性与未开启时基本一致，延时稳定在140ms左右，码率平均约1.4Mbps。

计费标准：https://cloud.tencent.com/document/product/647/17157

2、声网：https://www.agora.io/cn

网站介绍：SD-RTN是专为实时传输设计的虚拟通信网络，基于UDP，延时可控。专利算法，极大幅提升可靠性。全球部署近 100 个数据中心，国内数十家中小运营商全面覆盖， 99.99% 高可用，连通率 99.9%。

声网实时音视频同样使用私有的UDP协议，基于Webrtc技术优化开发，SDK将音视频编解码和传输层封装在一起。

图13 声网DEMO下载

注意：我们选择多人音视频通话DEMO，Wireshark截包发现该DEMO在同一网段内走的是P2P（虽然走的P2P，但仍然按量收费）。附件中已经包括了测试DEMO执行程序。

图14 声网DEMO启动界面

在启动DEMO后，选择720P 30fps分辨率（这个分辨率为摄像头通讯时的分辨率，本次测试我们使用屏幕共享，后者将默认使用桌面的分辨率进行通讯，帧率最高只能设置15fps），并填写一个房间号，收发双方使用相同的房间号即可进行互通。

图15 使用屏幕共享功能

我们将桌面分辨率设置为720P，DEMO将自动使用720P 约800Kbps码率（DEMO未提供对桌面共享分辨率、码率的设置功能），在无弱网模拟的情况下，连续观察20分钟，画面因帧率15fps的缘故流畅性一般，延时稳定在240ms左右。

丢包测试结果：

5%丢包时，连续观察20分钟，画面流畅性有一定下降（帧率动态变化，最低到8fps，丢帧不够均匀，无长时间卡顿）延时稳定在400ms左右，码率平均约800Kbps。

12%丢包时，连续观察20分钟，画面不流畅（帧率下降导致，非均匀丢帧），延时稳定在550ms左右，码率平均约800Kbps。

20%丢包时，连续观察20分钟，画面很不流畅（非均匀丢帧，帧率在8~13fps），延时稳定在400ms左右，码率平均约800Kbps。

抖动测试结果：

使用720P 800kbps码率，30%概率引入100ms抖动，无丢包，此时画面流畅性基本不受影响（受15fps缘故，流畅性一般），延时扩大到450ms左右，码率基本不变。说明声网检测到网络持续抖动后增加了接收端缓存时间。当关闭抖动模拟较长时间后，延时仍然维持在400ms左右。这点与腾讯的处理策略不同。

重复测试结果：

30%重复包时，连续观察20分钟，画面流畅性与未开启时基本一致，延时稳定在220ms左右，码率平均约800kbps。

乱序测试结果：

30%重复包时，连续观察20分钟，画面流畅性与未开启时基本一致，延时稳定在220ms左右，码率平均约800kbps。

计费标准：https://www.agora.io/cn/price/

3、附加：QOS-FEC-NACK 15fps 720P 800Kbps版本测试

因为声网DEMO限制，只能达到15fps，为此我们将QOS-FEC-NACK DEMO也使用同等环境。发送端配置如下：

[Config]
VideoBitrate=800
VideoTransWidth=1280
VideoTransHeight=720
ViceFrameRate=15
EncodeQualityLevel0to7=1
FecRedunRatio=10
FecGroupSize=28
FecEnableNack=1
HWEnable=0

我们使用720P 15fps 800Kbps编码，使用固定10%的冗余度。

接收端配置如下：

[Config]

UseFreezeFrameWhenLost=1

BufferTime=300

FecEnableNack=1

丢包测试结果：

在无弱网模拟的情况下，连续观察20分钟，画面因帧率15fps的缘故流畅性一般，延时稳定在320ms左右。

5%丢包时，连续观察20分钟，画面流畅性基本不受影响（帧率稳定于15fps，无长时间卡顿）延时稳定在330ms左右，码率平均约900Kbps。

12%丢包时，连续观察20分钟，画面流畅性基本不变，偶尔有短暂顿挫感（帧率稳定于15fps，无长时间卡顿）延时稳定在400ms左右，码率平均约900Kbps。

20%丢包时，连续观察20分钟，画面很不流畅（均匀丢帧，帧率最低降到8fps）。延时稳定在400ms左右，码率平均约900Kbps。

总结

QOS-FEC-NACK方案可以在保障实时性前提下，有效提升音视频在弱网下的传输效果，相比业内领先的解决方案，传输效果在某些指标上已经较为接近。相比业内以云服务方式提供服务，QOS-FEC-NACK提供开放的接口，可以方便的加入到私有网络中。方案以库或源码方式提供，相比昂贵的按时收费成本更低。