《QOSFECNACK实时音视频传输库测试报告（声网、腾讯实时音视频测试）.docx》由会员分享，可在线阅读，更多相关《QOSFECNACK实时音视频传输库测试报告（声网、腾讯实时音视频测试）.docx（12页珍藏版）》请在taowenge.com淘文阁网|工程机械CAD图纸|机械工程制图|CAD装配图下载|SolidWorks_CaTia_CAD_UG_PROE_设计图分享下载上搜索。
1、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
2、. 适应FEC冗余度，根据当前络状况适应调整冗余度，提抵抗同时避免带宽浪费。2. 适应FEC Group配置，对不同时刻、不同特征的媒体数据使不同的FEC Group策略，在不增加抖动的前提下提升连续丢包的抵抗。3. 选择性NACK重传，只对预期法恢复的数据包发起重传，最限度避免拥塞和抖动。4. 适应NACK等待时间选取，内置NACK信令、数据处理，对外层盒。5. 延时的乱序、重复包处理。6. JittBuff适应缓存处理，抵抗络抖动，提供流畅输出。7. 码率/帧率适应建议输出8. IDR帧请求建议输出9. 丢帧冻结机制持10. 提供丢包率、码率、RTT等上下基础统计数据获取11. 针对嵌式等
3、资源受限平台设计，资源占低，运效率。编码规范、代码精简、注释完善，不依赖于任何第三开源或闭源库。本档使个点对点投屏DEMO对案进各项弱模拟测试，研究各种弱特征下传输层的表现情况。档最后对业内优秀解 决案：腾讯云、声Agora WebRtc等进了研究。实验环境为了保证测试环境致性和可重现性，我们将在较好的络环境下借助第三弱模拟具，模拟各类络情况。同时也会使信号较 弱的wifi搭建真实的弱环境。这列举Windows平台上常的两款弱模拟具： A 、 Network Emulator for Windows Toolkit该具是款windows平台弱模拟具，使说明可以参考以下链接：图 1 Networ
4、k Emulator for Windows Toolkit 具软件提供：丢包、包篡改、延时、带宽限制、乱序、断等功能。注意事项：1、我们按照上链接搭建测试程后，发现实际未效。解决办法是加载程序安装包带的样例XML配置（ConsoleToConsole2PercentPacketloss.xml），在此配置基础上修改为的测试需求。2、如上图所，测试项可以作于本机输也可以作于本机输出。如对Outgoing的丢包设置将对本机发出的包进丢包，适合在 发送端使。对Incoming的丢包设置将对本机收到的包进丢包，适合在接收端使。对待测应程序，在发送端丢包还是接收端 丢包没有差异，本次实验均在发送端进弱
5、测试。图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- FE
6、C-NACK 点对点SDK发往接收端，后者解码并渲染输出，从实现屏幕共享功能。A、接收端该组DEMO的功能与投屏类应类似，我们先启动接收端DEMO。进UDP-AVClient-ScreenPlay件夹，双击启动AVClient.exe 即可。图4 接收端DEMO启动界接收端启动后，将显其投屏码（图中的4000），发送端可以使该投屏码进投屏。当发送端码流到来时，接收端将使个新的 窗“Remote Video”显远端画，如下图所：图5 接收端独的窗展远端画注意：“Remote Video”窗是个全屏窗，户可以在底部任务栏切换。当远端停视频传输时，该窗内容更新，且不会响应标事件，只能底部切换。接收端
7、件夹下的AVClient.ini件为其配置件，对配置件的修改需要重启客户端能效。配置件包括如下项：图6 接收端配置件UseFreezeFrameWhenLost 表当出现视频丢包法恢复时，为了不展现出花屏将画冻结，直完整的关键帧到来再继续送显。该值般设置为1开启。BufferTime表接收Jitter buff缓存毫秒数，为了抵抗络传输、FEC恢复、QOS乱序恢复、NACK重传等为带来的抖动，接收端需要加缓存以保障视频的流畅性。流畅性和实时性（时延）是对盾的指标，Jitter buff必然将引定延时，当前默认为200ms。CaptureDownStream表是否开启录制功能，若开启则将接收到的
8、视频流录制到TS件。测试过程中建议关闭。FecEnableNack表本端视频是否开启NACK功能，建议开启以提视频抗丢包能。 Debug组下是志相关的配置，如path指定志件存放的路径，level表当前期望输出的志级别，常级别有DEBUG, INFO,WARN, ERROR。enable表是否启动志功能，建议启。在后的测试过程中，将会对部分配置进调整，查看调整前后的效果对。 B、发送端发送端为UDP-AVClient-ScreenCap录下的AVClient.exe，在启动前我们需要先对其进配置，配置件为AVClient.ini图7 发送端配置件VideoBitrate表发送端使的视频编码码率
9、，单位kbps，设置为3000即表3MbpsVideoTransWidth表发送端使的视频编码宽度，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表sl
10、ower。等级越同等码率下的图像质量越好，但CPU占也越，请根据机器配置定，建议设置为1。HWEnable表是否启硬编码，程序持Intel QSV硬编码和Nvidia硬编码，相X264能获得更低的CPU占。不过硬编码的缺点是灵活性不，法持传输层IDR帧请求机制。FecRedunRatio表上FEC使的冗余度，如设置为30时表使30%的上冗余，设置为0时表使动冗余度。FecGroupSize表上FEC使的group标准分组。为了获得最佳效果，分组建议与码率想匹配。512Kbps以下建议设置为8，512Kbps1Mbps建议设置为16，1Mbps2Mbps建议设置24，2Mbps4.5Mbp建议设
11、置28，4.5Mbps以上建议34。注：当关 闭动group策略时，每个group均为该值设定值。当开启传输层动group策略时，将产均匀的group，此时该值来表 最的group。FecEnableNack表是否启NACK选择性重传机制。收发双均开启时能效，建议双均开启以提系统抗丢包能。IDR帧间隔：当使X264编码时，发送端使5秒个IDR帧。当使硬编码时，发送端使3秒个IDR帧。启动发送端后进如下界，输接收端展的投屏码即可开始连接。注意：收发双并TCP连接，这的连接可以理解为本地UDP资源 的创建。图8 发送端启动界连接后，客户端将进下图所的待共享屏幕状态。可以点击主界启动按钮或者使悬浮球
12、来启动桌共享。启动后，接收端就能看 到发送端的桌并能听到发送端播放的乐了。图9 发送端开始共享桌测试项说明说明：同市上各实时视频服务商样，DEMO也提供丢帧冻结机制，这样户法察觉到丢帧带来的花屏，从获得更好的户体验。 因此本次测试中，丢包最终将体现为画卡顿。DEMO提供了发送端码率适应功能，传输层根据当前的络状况实时调整发送帧率，从 达到间接调整码率的的。相直接调整编码码率，调整帧率有如下优点和缺点：优 点 ： A、相直接调整码率，更难察觉质量跳变。B、需适配各个平台的硬件编码器，各个平台均可以采统的帧率调整案。 缺点：A、画流畅性受到影响评测项：流畅度关于流畅度，我们将分为以下个级别：1.
13、画流畅2. 偶尔微弱卡顿（附加：卡顿时长+频率描述）3. 明显卡顿（附加：卡顿时长+频率描述）4. 较长时间卡顿评测项：延时延时计算式：在发送端打开毫秒精度秒表，接收端将看到秒表值，使机对者屏幕拍照，计算者差值得到总延时。整个系统 中，延时主要有传输层延时和传输层延时两部分组成。传输层延时包括：采集、编码、解码、渲染引的延时，本DEMO实际采集帧率法达到恒定30fps，对整体延时稍有影响。传输层延时分为：相对稳定部分和抖动延时部分。其中接收端Jitter buff程序加的缓存延时属于相对稳定部分。络线路传输延时、QOS乱序等待时间、NACK重传等待时间、FEC恢复等待时间、画冻结等待时间属于抖
14、动延时部分，抖动延时只在该动作发时引，且动作完成后消失。QOS乱序发时才会引等待，如收到1、2、4号包，输出1、2后会进等待，若此期间收到3号包则输出3、4，若超出等待时间仍未收到3号包则直接输出4号包，即便后续收到3号包也将其丢弃。若当前丢包法恢复时，即会触发NACK重传，接收进NACK等待，等待期间收到了重传包则输出，否则等待超时后退出。FEC有group组的概念，冗余包位于组的尾部，前部媒体包的丢失需要等待尾部冗余包的到来能恢复输出，因此FEC解码在丢包时也会引抖动，FEC group越引的抖动也越，不过在同等冗余率下抗连续丢包的能也越强。当NACK、FEC均法恢复时，将冻结画并请求远端
15、发送IDR，只有收到完整的IDR帧时才恢复送解码、渲染，这也将引抖动延时。编码器Gourp越，“可能”需要的IDR等待时间越长（当接收端主动请求的IDR帧也出现丢包时，只能依 靠编码器的周期性IDR帧。当接收端主动请求IDR帧传输成功时，等待时间和编码器的周期性IDR间隔关。）需要说明的是延时指标和流畅性指标往往是对盾，播发端缓存的数据越多，流畅性越好，延时也越，反之若缓存的数据较少或者 不缓存，则延时更低，流畅性不。传输层需要根据实际应场景选择合适的策略（折中）。SDK提供API供户配置接收端的Jitter Buff 缓存毫秒数。默认情况下使300ms缓存，这是基于300ms的延时不会对双向
16、视频实时互动产影响这业内经验。评测项：清晰度DEMO使适应帧率式来间接实现码率适应，因此图像质量与传输层紧密关系，主要由户指定的编码分辨率、码率、桌画内 容决定。注：帧率降低时，帧间相关性降低，运动估计残差更，同等码率下编码质量会稍弱。测试结果测试默认配置：接收端使300ms缓存，具体配置下图所：Config UseFreezeFrameWhenLost=1 BufferTime=300 FecEnableNack=1发送端使720P 2Mbps 30fps，FEC使动冗余，具体配置下图所Config VideoBitrate=2000 VideoTransWidth=1280 VideoTr
17、ansHeight=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
18、左右，冗余率基本维持在动冗余度的下限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
19、设置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%，码
20、率平均约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分钟，画流畅
21、，延时稳定在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左右，
22、冗余率基本维持在动冗余度的下限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
23、设置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抵抗，将出现画顿挫。
24、前版本暂未加Jitter Buff能适应，户设定Jitter Buff深度后，即根据设定值确定缓存深度，不会跟随媒体流实际抖动适应调整。这样做有以下优缺点：优点：系统延时稳定于户设定值，不随络抖动增长增长。缺点：络抖动超出设定值时，播放器将出现卡顿。当实际抖动于设定值时，仍然引了设定值的延时。 抖动优化是后续传输层优化的向之。极速测试当设定接收端Jitter Buff缓存0ms时，即关闭接收端缓存功能，收到数据第时间解码、第时间渲染，此时程序引的延时，我们称之为极速模式。设置接收端配置件BufferTime=0，不加为弱措施时：测试结果：连续观察20分钟，画总体较流畅，延时稳定在94ms左右。
25、对于延时要求较，对于流畅性没有极要求的场合可以使 极速模式。断测试本DEMO收发双并TCP连接，断开络后，另只是法接收或发送媒体数据，待络恢复后恢复。竞品分析实时视频传输直是多媒体通信的核之，腾讯云、易云信以及部分新兴企业如声、即构均提供了云解决案。各家案各有 千秋，通过相互对借鉴，能获得更多灵感。站介绍：腾讯实时视频（Tencent Real-Time Communication，TRTC）是腾讯云基于QQ多年来在视频通话技术上积累，提供全平台互通品质实时视频通话服务的款产品；抗丢包率超过 40%，抗络抖动超过 1000ms，即使在弱环境下仍然能够保证质量的视频通信，确保视频通话过程顺畅稳定
26、。注意：腾讯云、阿云等也提供基于RTMPHLS的直播服务，这类基于TCP协议的直播并本所描述的视频实时互动范畴，它们往往于对延时要求不的单向的视频传输服务，其对弱的抵抗较差，在络恶化时服务质量衰减迅速。本报告中，我们将以直播RTMP传输为例，测试基于TCP的RTMP协议在弱下的表现。腾讯实时视频同样使私有的UDP协议，前泛应于微信、QQ等产品。腾云实时视频官提供了DEMO供户测试，使步 骤致如下，具体请参考腾讯档说明：A、户需要先在腾讯云上注册实时视频服务，并在控制台中指定视频参数。B、下载iLive SDK和配套DEMO程，在DEMO代码中填写注册时成的APP ID等参数并编译可执程序。户在
27、腾讯云后台中对视频互动的详细参数进设置（注意：腾讯云SDK并不在客户端进视频参数设置，是在管理后台设置，客户端选择后台中的某组设置）。当前可供户设置的分辨率最到720P，码率最到1500kbps，可能更级别的参数需要客服申请。图11 腾讯云实时视频控制台图12 腾讯云实时视频能设置为了便演，我们在附件中提供了腾讯云DEMO的源码以及个使我们申请测试账号编译的可执程序。程序包括个发送端和个接收端，发送端将采集系统默认的摄像头编码后发往腾讯云服务器，后者转发给接收端。注意：为了搭建与我们DEMO类似的环境，我们使虚拟桌采集摄像头作为系统默认摄像头（运我们DEMO后，将动向系统注册个 名为scree
28、n-capture-recorder的虚拟摄像头，拔掉发送端机器的其他摄像头，确保让虚拟摄像头成为默认摄像头）。注意：腾讯云并不提供P2P服务，所有视频均服务器转发，这可能是由其收费式决定的，对于所有户按使分辨率、时长收费， 个发送端、个接收端使1时，则按2*1时计费。若提供P2P服务，并对户之间的P2P传输收取费则于情于理说不过去。注意：腾讯云SDK将视频编解码和传输层起封装。正常情况下，使720P 1.5Mbps码率，在弱模拟的情况下，连续观察20分钟，画流畅，延时稳定在140ms左右，码率平均约1.5Mbps。丢包测试结果：5%丢包时，连续观察20分钟，画流畅性有定下降（帧率下降导致，均
29、匀丢帧，长时间卡顿）延时稳定在150ms左右，码率平均约1.6Mbps。12%丢包时，连续观察20分钟，画流畅性进步下降（帧率下降导致，均匀丢帧）偶尔（分钟）出现明显卡顿，延时稳定在140ms左右，码率平均约1.6Mbps。20%丢包时，连续观察20分钟，画秒次频繁卡顿（卡住约500ms左右），帧率较低，延时稳定在200ms左右，码率平均约1.6Mbps。通过画质对，腾讯云应该也是采帧率适应，并未降低码率，图像质量相对恒定。码率控制和户购买的常接近，毕竟这个涉及到成本。延时总体较低，接收端缓存较，在丢包时因NACK引的瞬间抖动导致画易出现卡顿。IDR帧间隔约为1秒。抖动测试结果：使720P 1
30、.5Mbps码率，30%概率引100ms抖动，丢包，此时画流畅，延时扩到240ms左右，说明腾讯检测到络持续抖动后适应的增加了接收端缓存时间。当关闭抖动模拟时，延时恢复到140ms。观察到开启抖动模拟时，画会持续12秒的卡顿期，然后 延时加，流畅性提升，说明在此期间进了缓存的重新初始化动作。腾讯的接收缓存适应调整的策略值得我们学习。重 复 测 试 结 果 ： 30%重复包时，连续观察20分钟，画流畅性与未开启时基本致，延时稳定在140ms左右，码率平均约1.5Mbps。乱 序 测 试 结 果 ： 30%重复包时，连续观察20分钟，画流畅性与未开启时基本致，延时稳定在140ms左右，码率平均约1
31、.4Mbps。站介绍：SD-RTN是专为实时传输设计的虚拟通信络，基于UDP，延时可控。 专利算法，极幅提升可靠性。全球部署近 100 个数据中， 国内数家中运营商全覆盖， 99.99% 可，连通率 99.9%。声实时视频同样使私有的UDP协议，基于Webrtc技术优化开发，SDK将视频编解码和传输层封装在起。图13 声DEMO下载注意：我们选择多视频通话DEMO，Wireshark截包发现该DEMO在同段内的是P2P（虽然的P2P，但仍然按量收费）。附件中已经包括了测试DEMO执程序。图14 声DEMO启动界在启动DEMO后，选择720P 30fps分辨率（这个分辨率为摄像头通讯时的分辨率，
32、本次测试我们使屏幕共享，后者将默认使桌的分辨率进通讯，帧率最只能设置15fps），并填写个房间号，收发双使相同的房间号即可进互通。图15 使屏幕共享功能我们将桌分辨率设置为720P，DEMO将动使720P 约800Kbps码率（DEMO未提供对桌共享分辨率、码率的设置功能）， 在弱模拟的情况下，连续观察20分钟，画因帧率15fps的缘故流畅性般，延时稳定在240ms左右。丢包测试结果：5%丢包时，连续观察20分钟，画流畅性有定下降（帧率动态变化，最低到8fps，丢帧不够均匀，长时间卡顿）延时稳定在400ms 左右，码率平均约800Kbps。12%丢包时，连续观察20分钟，画不流畅（帧率下降导致
33、，均匀丢帧），延时稳定在550ms左右，码率平均约800Kbps。20%丢包时，连续观察20分钟，画很不流畅（均匀丢帧，帧率在813fps），延时稳定在400ms左右，码率平均约800Kbps。抖动测试结果：使720P 800kbps码率，30%概率引100ms抖动，丢包，此时画流畅性基本不受影响（受15fps缘故，流畅性般），延时扩到450ms左右，码率基本不变。说明声检测到络持续抖动后增加了接收端缓存时间。当关闭抖动模拟较长时间后，延时仍然维持在400ms左右。这点与腾讯的处理策略不同。重 复 测 试 结 果 ： 30%重复包时，连续观察20分钟，画流畅性与未开启时基本致，延时稳定在220
34、ms左右，码率平均约800kbps。乱 序 测 试 结 果 ： 30%重复包时，连续观察20分钟，画流畅性与未开启时基本致，延时稳定在220ms左右，码率平均约800kbps。3、附加：QOS-FEC-NACK 15fps 720P 800Kbps版本测试因为声DEMO限制，只能达到15fps，为此我们将QOS-FEC-NACK DEMO也使同等环境。发送端配置如下： ConfigVideoBitrate=800 VideoTransWidth=1280 VideoTransHeight=720 ViceFrameRate=15 EncodeQualityLevel0to7=1 FecRedu
35、nRatio=10 FecGroupSize=28 FecEnableNack=1 HWEnable=0我们使720P 15fps 800Kbps编码，使固定10%的冗余度。接收端配置如下： ConfigUseFreezeFrameWhenLost=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提供开放的接，可以便的加到私有络中。案以库或源码式提供，相昂贵的按时收费成本更低。