QOSFECNACK实时⾳视频传输库测试报告（声⽹、腾讯实时 ⾳视频测试）
工业氯化钙⽬录
QOS FEC NACK 实时⾳视频传输库测试报告
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信令、数据处理，对外层⿊盒。
6. JittBuff⾃适应缓存处理，抵抗⽹络抖动，提供流畅输出。
7. 码率/帧率⾃适应建议输出
8. IDR帧请求建议输出
9. 丢帧冻结机制⽀持
10. 提供丢包率、码率、RTT等上下⾏基础统计数据获取
11. 针对嵌⼊式等资源受限平台设计，资源占⽤低，运⾏效率⾼。编码规范、代码精简、注释完善，不依赖于任何第三⽅开源或闭源库。 本⽂档使⽤⼀个点对点投屏DEMO对⽅案进⾏各项弱⽹模拟测试，研究各种弱⽹特征下传输层的表现情况。⽂档最后对⾏业内优秀解决⽅案：腾讯云、声⽹Agora WebRtc等进⾏了研究。
实验环境
为了保证测试环境⼀致性和可重现性，我们将在较好的⽹络环境下借助第三⽅弱⽹模拟⼯具，模拟各类⽹络情况。同时也会使⽤信号较弱的wifi搭建真实的弱⽹环境。
这⾥列举Windows平台上常⽤的两款弱⽹模拟⼯具：
A、Network Emulator for Windows Toolkit
该⼯具是⼀款windows平台弱⽹模拟⼯具，使⽤说明可以参考以下链接：
图1 Network Emulator for Windows Toolkit⼯具
软件提供：丢包、包篡改、延时、带宽限制、乱序、断⽹等功能。
注意事项：
1、我们按照上⾯链接搭建测试⼯程后，发现实际未⽣效。解决办法是加载程序安装包⾃带的样例XML配置
（l），在此配置基础上修改为⾃⼰的测试需求。
2、如上图所⽰，测试项可以作⽤于本机输⼊也可以作⽤于本机输出。⽐如对Outgoing的丢包设置将对本机发出的包进⾏丢包，适合在发送端使⽤。⽽对Incoming的丢包设置将对本机收到的包进⾏丢包，适合在接收端使⽤。对待测应⽤程序⽽⾔，在发送端丢包还是接收端丢包没有差异，本次实验均在发送端进⾏弱⽹测试。 图2 在发送和接收处模拟弱⽹
B、Clumsy
Clumsy是⼀款⼩巧⽽功能强⼤的开源弱⽹模拟⼯具，⽀持windows平台，可⽤于模拟：丢包(Drop)、延时(Lag)、重复(Duplicate)、乱序(Out of order)、篡改(Tamper)、抖动(Throttle)等。其项⽬地址：
图3 Clumsy对所有发送的包按10%进⾏丢包处理⽰意
本次测试主要使⽤Clumsy，相⽐使⽤Network Emulator for Windows Toolkit，⼆者测试结论基本⼀致。
测试DEMO说明
本次测试使⽤windows平台下的桌⾯投屏DEMO，DEMO分为发送端和接收端，发送端采集⾃⾝桌⾯和扬声器⾳频，压缩后通过QOS-FEC-NACK 点对点SDK发往接收端，后者解码并渲染输出，从⽽实现屏幕共享功能。
A、接收端
该组DEMO的功能与投屏类应⽤类似，我们⾸先启动接收端DEMO。进⼊UDP-AVClient-ScreenPlay⽂件夹，双击启动 即可。
图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表⽰是否启动⽇志功能，建议启⽤。
在后⾯的测试过程中，将会对部分配置进⾏调整，查看调整前后的效果对⽐。pe附着力促进剂
B、发送端
发送端为UDP-AVClient-ScreenCap⽬录下的，在启动前我们需要先对其进⾏配置，配置⽂件为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缓存，具体配置⼊下图所⽰：
豫公网安备41160202000603
站长QQ:729038198
关于我们
投诉建议