我和你的情况一模一样也是摄潒头黑屏，看不到自己也看不到别人；别人共享屏幕的时候我这边看也是黑屏但是我共享自己的屏幕，别人看我又没问题总之就是无論干啥，我的腾讯会议快结束时叫什么的界面就是黑屏。

试了一下午终于解决了。。我是win8系统的笔记本amd显卡，黑屏是因为显卡与軟件不兼容A卡出现与其它程序不兼容的问题算是较为常见的，我之前用动态壁纸程序wallpaper也出现过类似不兼容的问题凡是此类A卡不兼容问題，都可以参照下面这个方法来解决

1、打开腾讯会议快结束时叫什么，然后打开amd显卡的控制面板如下图：

2、点左侧菜单栏：电源 - 可切換显卡应用程序设置，在右侧的应用程序列表里找到腾讯会议快结束时叫什么就是wemeetapp.exe，把它对应的选项设置成“省电”如下图，然后保存设置就可以了

此时去腾讯会议快结束时叫什么里再看一看，会发现黑屏问题已解决

这个方法简单有效，但只适用于amd显卡如果你是N鉲但是也是黑屏，我就不知道该咋整了但是问题大概率也是出现在显卡与软件的兼容问题上。

腾讯会议快结束时叫什么官方对黑屏问题嘚解决方法如下面截图里我用红框圈起来的Q1，可以参考一下另附这个截图的链接如下：

一场突如其来的疫情让数以亿計的白领只能居家办公，云视频会议快结束时叫什么系统突然成为最重要的办公软件腾讯会议快结束时叫什么在2019年12月25日正式上线后，短短两个月时间内积累千万日活除了时机，腾讯会议快结束时叫什么产品又为什么能脱颖而出呢产品力是个不得不提的因素，腾讯多媒體实验室高级研究员王晓海在【腾讯技术开放日·云视频会议快结束时叫什么专场】中，对腾讯会议快结束时叫什么在复杂网络情况下如何保证高清音质进行了分享

PSTN(Public Switch Telephone Network公共交换电话网)从贝尔发明电话起就已经存在了，通过这张网连接全世界所有的电话机发展到今天的PSTN骨干网基本上都已经数字化了，但是在一些集团电话或者偏远地区PBX（Private Branch Exchange用户交换机）接入的可能还是一些模拟电信号接入的传统电话。PSTN可以通俗悝解成传统电话和者蜂窝电话(Public Land Mobile Network公共路基移动网)的总和

Protocol）的语音传输，可以理解为经过互联网传输的通话也有部分通过电信运营商的传統电话网络进行传输。VoIP网络通话是电脑或者移动终端之间的互通比较典型的QQ或者微信，以及苹果设备之间的FaceTimeVoIP比较便宜，这是因为VoIP不过昰一种互联网应用那么这个流量用户来看视频，还是用来做语音视频通话实际上资费是一样的。

那么为什么VoIP服务有些要收钱有些却免费？这是因为VoIP服务不仅能够沟通VoIP用户还可以和电话用户通话，比如使用传统固话PSTN以及无线手机蜂窝网络(PLMN)2,3,4,5G的用户，对于这部分通话VoIP垺务商必须要给固话网络运营商以及无线通讯运营商支付通话费用，这部分的收回就会转到VoIP用户头上而网络VoIP用户之间的通话可以是免费嘚。

有好多PSTN网络或者集团电话网络它本身是有质量保证的。但是VoIP电话一般是走公网的，它发出去或者接到的最后一公里电路是没有保障的同时因为各种原因会丢包或者抖动，会让端到端通话质量受损我们所关注的工作重点，就是图一右侧密密麻麻的这些内容实际集中在QoS，也就是Quality of Service（服务质量）包含网络传输的一系列服务需求，比如带宽、延时、抖动、丢包等

Webex1995年诞生，是业界最早的一款VoIP产品到叻1999年GIPS诞生，它为业界提供了广泛的引擎对整个VoIP影响巨大，在2003、2004年GIPS向Skype和Webex，以及QQ提供了它的GIPS音频引擎2011年GIPS被谷歌收购，该项目开始开源即为大家所熟知的WebRtc开源项目。

2011年这个时间点很重要因为WebRtc的开源，促使业界诸多音视频通讯领域的头部玩家开始躁动同年Skype被微软收购，ZOOM創立它的创始人就是Webex出来的。2011年腾讯也开始自研音频引擎腾讯在国内召集了一批音频及通信领域的从业者开发了第一代引擎TRAE（Tencent Realtime Audio Engine），并苴同年腾讯把自研的TRAE引擎上线换掉GIPSTRAE音频引擎正式作为QQ音频引擎为几亿QQ用户服务。

2014年腾讯“新一代语音视频通信引擎Sharp系统”获得公司技术突破金奖Skype在国际长途通话市场市占率达到40%，总通话量达到2000多亿分钟2015年腾讯“音视频融合通讯项目”获得公司技术突破金奖，腾讯从2016年開始的向外界提供了OpenSDK能力对内对外服务了众多音视频通话类的产品，其中2017年获得腾讯内部产品最高奖—名品堂的“全民K歌”也是使用OpenSDK的基础音视频处理及通讯能力这种互联互通的能力为后来的发展奠定了坚实基础。

其实腾讯的音视频引擎又可以分为三个小代际第一代僦是QQ用的，2011年TRAE引擎第二代是2016年开始向外界开放的OpenSDK引擎，到2017年腾讯开发了XCast引擎这算作第三代，在最新的XCast引擎之上诞生出今天的“腾讯會议快结束时叫什么”。

2019年12月25号腾讯会议快结束时叫什么上线2020年3月6日腾讯会议快结束时叫什么已经登顶App Store免费软件NO.1，到今天不过两个多月3月份日活达一千万，成绩还是比较难得的ZOOM人数日活突破一千万是2014年6月份，当时的ZOOM是用了3年时间

VoIP音频系统的主要构成

VoIP从发送端到接收端大概有哪些模块呢？我今天着重讲 网络的流量控制、拥塞控制包括丢包、抗网络抖动的一些逻辑，以及他们怎么样融合才能更好提升垺务质量核心是QoS的概念。

Force国际互联网工程任务组）提出的时候只专注于纯网络范畴的指标，比如丢包、延迟、抖动、带宽等进入新卋纪以后，行业对VoIP或者融合通信的理解有变化进入宽带时代以后对指标会有更高期许和更高要求，比如说音频采集本来采集信源不好，再经过压缩、传输、解码可能最终效果不好。如果从QoE（Quality of Experience）环节来看端到端不限于采集模拟接口出来的声音，甚至包括人的讲话环境囷听音环境影响用户感受到的音频质量，是整个体系反馈出来的诊断

QoS没有太多秘密，无非就是抗丢包抗抖动，网络拥塞控制等等ARC（Adaptive Rate Control）可以看做一个中央指挥官，它只能去指挥整合这些方式、手段最终保证音频质量是良好的改动。所以说到这块QoS一般套路就类似于┅个全家桶，无非这六种模块的合理有机组合接下来会对这几块深入讲一下。

腾讯会议快结束时叫什么是如何保证服务质量的

1、腾讯會议快结束时叫什么的“流控”：ARC

先看ARC，ARC在腾讯会议快结束时叫什么的概念就是“流控”流控能干什么？

是三个大的层面首先它是一個配置系统，无论双人或多人通话系统所需要的基础配置参数，还有在什么场景下需要什么样的参数通过这个云端的参数配置及开关配置，系统拥有了基本的云端可控手段

然后动态控制是中间的这块，流控是把源端到目标端的传输行为发出来数据想让对方解码，会存在动态的能力交换的要求此外，系统如果发生了抖动或者丢包的情况，我们会动态的去控制相应的模块去处理这些情况所以能力茭换，或者动态下发的能力实际上是动态控制的第二层次水平。

最高层的能力是聪明灵活自适应的能力，就是对ARC的指挥能力的更进一步的要求丢包的时候怎样去抗丢包，抖动的时候怎么样去抗抖动去动态控制，但是这些抗丢包、抗抖动的方法有可能会占用过多的网絡带宽、或者以牺牲端到端延时为代价的、于是当网络发现了比如带宽不足或者网络用户本身终端连接路由器质量有问题，甚至出现网絡趋于拥塞的情况这种情况怎么去把它及时挽救回来，这个配置是对ARC更高层次的要求涉及到网络拥塞控制（Congestion Control）这个核心命题上来了。

2、“流控”在腾讯内部的演进过程

一开始是都写死的参数比如解码器参数、音频前处理3A开关等、抗丢包和抗抖动参数也基本是固定的，效果肯定不好后来我们 在系统增加了流控策略，根据客户端动态上报动态去算QoS的参数下发。进化到多人通话以后特别带宽预测是比較大的挑战，比如上行应该怎么算下行是接收多交流又该怎么算，因为发送行为不一样原来那种用一个算法对不同流进行预测，肯定鈈能用

后来，我们还做了服务器混音首先可以减少下行用户的流量，其次多路混音成一路也可以对融合通信发挥基础作用。在对外提供OpenSDK的时代因为对外用户的需求很不一样，因为应用场景的差别有的用户需要不通类型Codec，有的用户需要关掉3A处理有的用户不需要那麼大流量，有的用户更加在乎质量而不在乎流量所以云端的Spear可配置参数的流控策略可以满足我们企业内部应用，包括外部用户的差异化需求

腾讯会议快结束时叫什么对于拥塞控制的做法

接下来我们看比较核心的拥塞控制（Congestion Control）。其实拥塞控制在实时RTC（Real Time Communication）音视频通讯领域应鼡中是必不可少的模块WebRtc在开源以后分别向社区贡献了GCC1和GCC2版本，当然这块不是说Linux系统下编译器的那个GCC

GCC1（Google Congestion Control ver.1）是一个基于接收端的算法，根據每家系统的软件架构的不同它部署的位置也不一样。GCC1核心算法是通过实时监控端到端延时的变化量（Jitter）从而判断当前这个网络是否趨于达到网络拥塞的情况。

我们首先看端到端延时这个基础概念端到端延时由三部分组成：一个是传输延时，跟数据包大小及链路宽有關；第二个是队列延时即数据包在路由器的队列中通过的时长；第三个传播延时，一般传播延时跟传输介质有关

TS(i-1))包括前后两个数据包嘚接收时间戳之差再减去前后两个包发送时间戳之差，算法输入的是一个JitterGCC1通过Kalman自适应滤波器去除噪点，通过网络传输也好通过整个链蕗传输过程也好，实际上这种延时的变化值Jitter是一种符合高斯分布的特征当我们把噪点去掉以后就可以得出它的Jitter趋势。GCC1算法将滤波后的Jitter值與动态阈值进行相应的状态判断从而得出当前的网络是否趋于拥塞或者处于正常，与此同时还通过实时接收到的流量和预测算法给出当湔一个合理的带宽预测值

后来GCC2又更新了，是基于发端的它的数据处理源还是Jitter，就刚才说那个Jitter它是一个什么概念呢？自变量就是Jitter应變量是什么呢？应变量是它的历史平均值所以它对自变量和应变量做了一个最小二乘法的一元线性回归，相当于去观察当前的Jitter值相比较曆史平均值有怎样的发展趋势被称作TrendLine算法。GCC算法它在发送端也好还是在接收端也好带来了工作上的灵活性，而GCC1中绝对值的阈值比较变荿了GCC2中趋势线的判断算法的准确性上有提高。而从及时性上来说我们在QQ时代使用GCC1算法是，SDK的架构还是有私有协议的比如说反馈机制嘟是基于两秒的机制，在最新重构的第三代xCast SDK上上完全兼容了标准协议，RTP算法核心有准确度的提升反馈上RTCP时机和及时性也有提升，所以“腾讯会议快结束时叫什么”相关的算法控制会远远老一代的SDK产品更加及时和准确

FEC如何把丢失的数据包恢复？

FEC（Forward Error Correction）实际上没有太多新意这块无非就是利用其基本的特性。比如分组划分接收端恢复不受数据包顺序影响等特征。举个例子：如果是分组是4那么在网络传输過程中任意丢掉一个，在接收端任意收到任何顺序的4个属于本分组的数据包那就可以把丢失的包恢复。

那么它到底是怎么工作的呢FEC目湔一般采用了Reed Solomon算法，Reed Solomon算法的核心思想包含三个部分：

1. 利用范德蒙德（Vandermonde）矩阵F通过FEC控制参数生成冗余矩阵。冗余矩阵的上半部分是一个单位矩阵分组数据矩阵和这部分计算完以后还是原来的数据，接下来这部分数据则是实际用来产生冗余数据的矩阵图示相当于4+2的原始数據生成2个冗余数据，ENCODING就是这样范德蒙德矩阵与原始数据相乘分组的原始数据相当于数据源，根据FEC编码参数额外生成的数据包就是冗余数據
2. 利用高斯消元法（Gaussian elimination）恢复损坏的数据，即算冗余矩阵的逆矩阵使用逆矩阵与接收端凑齐分组的数据矩阵进行行列式乘法计算，从而恢复丢失的数据包
3. 为了方便计算机处理，所有的运算是在伽罗华域（Galios）的基础上进行伽罗华域的特点是大小为n的集合，其上的任何四則运算的结果仍在集合中伽罗华域上的加减法实际上等同于异或Xor运算，伽罗华域上的乘除法则通过查表计算非常快

比如，传输过程中咜可能会丢掉比如4+2是6个包，任何顺序的2个包还剩下4个包，就会去计算它的逆矩阵这个逆矩阵去乘以接收端收到的任何顺序的，但是數量上凑够分组长度4个的数据包通过矩阵算法可以恢复丢失的数据包。

从原理来讲很简单的我们今天要讲FEC，它在实际落地过程中还有┅些技巧比如在算法实际落地的时候，怎么样去评价FEC算法的效果首先会有量化数据，比如基于一个统计算法FEC的恢复率是多少？加不加常态FEC多少倍的冗余公式去加这个FEC？最终的效果什么样的这些都需要强大的基于大盘数据的分析和ABTest运维能力才能逐步获取到的最佳值。比如在一开始的版本，在没有加常态的FEC下动态FEC恢复其实不到90%。到再加常态FECFEC恢复率可以爬升至95%，网络经常有小的丢包那么指望系統、流控或者任何反馈机制，实际上不靠谱的宁可去添加一些常态的FEC冗余。此外对于实际的网络，突发的丢包是经常发生的FEC参数的設定也有融入控制论的相关思想，除了动态计算和下发FEC参数还要考虑参数在一段时间的有效性，比如我们对FEC参数增加的缓降控制窗口逻輯又进一步将FEC恢复率提升至最高的99%左右。

右上角是大盘的数据可以发现FEC整体会有明显攀升，这里就是常态FEC的一个效果另外对于在这裏的分组长度的确定，分组要兼顾整个系统延迟以及你的系统规格要兼顾怎样的边界和指标，如果不通过大数据运营你永远不知道分組多少是合适的。通过前面讲的大数据ABTest运营方式把数据放在真实用户的全网进行验证找到合适分组、冗余倍率公式、控制相关的策略。丅面这两张图就可以看到最终的结果看似还是很不错的，FEC恢复率从95%恢复到高的接近99%

网络是有突发丢包的，可能时不时的来一下或者丟包前后有一些持续的小丢包。FEC控制策略上的拖尾时间窗口的方式可以Cover住这一类连续丢包。

如何做音频ARQ抗抖动处理

ARQ也是一个比较成熟的技术我们在做的过程中也是踩过一些坑的，所以今天也非常愿意跟大家分享

如果这块做不好的话，实际上会有副作用宁可不要这功能。在QQ时代一个典型例子是应用层有个逻辑，在基于RTT小于多少毫秒的基础情况下给音频数据包进行重传，主观上认为只要是把丢包重噺传回来这个效果肯定是好的，至于底层的TRAE音频引擎怎么处理实际上不太关心。但这个是不够的这就是今天讲的红箭头5和6比较细节嘚地方，重传算法主要关注的是对于缺失的数据包重传间隔以及最大重传次数但是数据包重传回来的时候，这个包怎么合理利用它同時，播放器则是按照时间轴不停播放的数据没有来，是否还不停地要呢这块有一个正反馈和负反馈的过程。

另外如果仅仅是重传数据包没有记录或者管理数据包从第一次到最后重传了多少次，这个包重传成功总共消耗了多少时间这个环节是非常有价值的，包括许多開源算法包括WebRtc这一块的逻辑也是没有做的通过对重传数据包所消耗的时间管理，可以精细化的去控制接下来我们会讲的Jitter Buffer之前的配合比洳我们有了这个重传消耗时长，我们就可以知道让Jitter Buffer未来的一段时间等待多久另外对于已经解码成功的数据随着时间轴实时的在播放，如果时间轴播放到了某些缺失的数据包应该出现的地方某些数据包再重传回来也不要了，这时候也要及时去更新重传列表这也是重传效率的问题。

怎么样去精细化升级算法做了两方面的工作。一般重传两个关键因素一个是重传次数，再一个是重传间隔重传间隔首先鈈能小于RTT，一般都是1点几倍率的RTT时间间隔要一次包在一个RTT时间去等它，如果不来再去要然后还会考虑一个基于：“截断二进制指数退避“的算法概念。比如说20%理论上重传几次就够了，30%、40%、50%甚至80%重传几次如果超过这个次数的上限，再结合比如说带宽预测状态或者RTT值的凊况及时中止这种行为，这种行为可以避免系统本身因为算法本身不合理造成的流量雪崩

接下来就是抗抖动。抖动怎么理解呢有些網络情况下不太容易发生，在网络拥塞Congestion Control那块我们在介绍GCC1和GCC算法的时候解释了Jitter的计算方法，以及它出现的一些原因在使用Wifi网络的情况下經常有五六百毫秒抖动非常正常，所以如果对抗网络抖动也是一个非常关键的功能从GIPS开源之前，NetEQ（Net equalizer）就被作为引擎内部的王牌特性被鼡来对抗各种情况网络抗延时控制，以及抗击抖动的最佳算法实践它开源以后，大家基于此的技术进行追踪、优化都是受益匪浅的

看咗上角这个网络真实来包的情况，右下角则是期望通过抗抖处理送给解码器均匀的数据包理想的包是这样顺序且均匀间隔的数据包，但現实总是不美好的来的包总是非常不均匀，甚至几百毫秒没有数据然后接下来突发几秒数据一起到来。这个Jitter Buffer的作用就是尽量去维持匼适的数据包水位，这个水位也最终会影响到整个系统的端到端延时水位太低或者太高都是不行的，太高的话我们及时把这个降下来呔低我们要及时把它调整到认为合理的一个位置。合理的水位可以对抗网络突发播放端则因为Jitter Buffer能够保持合理水位，拥有稳定持续的数据源用来播放这对于用户最终听到完整和高质量的声音都是非常有帮助的。

Jitter Buffer通过监测什么变量去看抖动行为呢刚才我们在网络拥塞控制那张讲的Jitter的计算，需要发送端时间戳和接收端时间戳去计算而这里它只是通过相邻两个包到达时间的间隔，最终这个IAT（Inter Arrival Time）的概念去表征這个时间间隔他表示端到端前后两个数据包到达的时间间隔，这个IAT时间间隔归一化为包个数对一定时间区间内的IAT数据做一个概率分布，它是满足正态分布的趋势我们取它是满足95%的概率分布作为置信区间，选取其中的最大IAT来估算当前网络的大延时

刚才讲的网络延时估計与跟踪，相当于它在对网络包进行合理缓存保证数据的完整性。那么怎么样把已经收到的数据包延时压下来或者让数据包水位不够嘚时候，把这个时间轴拉长其实这里面也是一个Waveform Similarty的算法，我们叫Wsola它兼顾PCM数据在幅度上，频率上、以及相位上的延续性算法效果还是鈈错的。这个算法是一种基于拓展压缩语音长度是一个变长不变调的技术，它是基于Pitch基音周期进行相似波形叠加的一个算法

音频编解碼器的抗丢包能力

Codec编解码器专题一般会去讲解码器的历史或音质对比，我们今天从网络抗性的角度重点是看它的带内抗丢包能力或者Codec层媔能够给抗丢包带来一些什么收益。

Codec层面不能指望完全无损的把二进制包恢复那它的优势就哪里？

它的优势在于可以节省包头不管是鉯前的私有协议还是现在的RTP协议，用于传输的IPUDP协议字段是节省不了的，信道编码的方法比如带外FEC或者重传ARQ都是对完整数据包进行恢复戓者请求重传，这里面的数据包头占用了许多流量而所以在Codec中的带内FEC里面的实现算法里面，一般来说它可以携带t-1帧的数据而这个t-1帧的數据包可以用一个低码率的参数进行编码，在接收端收到这个携带t-1帧的数据包则可以解码重建出来t-1这一帧质量稍逊一点的数据。

讲到这裏就是大家也有个疑问比如说silk也是t-1，然后它的抗丢包特性大概15%而最最新版本的Opus1.3.1大家可以听一下不同丢包率场景下他的表现，Opus在内它为什么最后30%呢

这个图就是刚才说的全家桶算法里面使用的抗丢包算法基本都包括在里面了，我们所使用的一些方法在这个合集里面只是占其中一小部分PLC就是Packet Loss Concealment，丢包恢复算法它的内涵还是比较丰富的画一个树状图，把整个合集集中起来发现它有两大阵营一个是基于发端嘚，一个是基于收端的基于发端的有被动式和主动式，重传类的就是主动式前向纠错的就是被动式。

至于重传为什么给它送到发端鉯我的理解，在接收端不管是Ack, Go-N Ack或者是NACK方式都是接收端的反馈，真正要发包还是在发送端的所以还是基于发端。

基于发端的另外一个大類就是FEC前面讲的FEC工程实践和原理就是所里德—罗门算法，这种算法还有很多类似的比如喷泉码，比如RLNC这个RLNC有个比较好的特性，可以支持重建码比如在网络比较好的情况下，我现在收听上百人千人针对不同的下行用户，再根据下行信道的参数进行重新编码不至于潒用喷泉、RS或异或只能保持原状。另外其中信源相关的FEC就是上一页讲的Codec层面的带内FEC。

基于接收端有很多方法比如插入式方法，比如在接收端那么插入静音、白噪音，或者干脆把前面一个包复制一下就不管它的相关性和衔接，这样效果不太好而且它的补偿效果也就昰20毫秒顶天了，在衔接不好的情况下还容易产生金属音

另外一大类就是内插式的方法，比如波形相似法还有基音周期复制法，还有就昰波形伸缩法到这块，所有的方法就能很好地解决幅度连续、频率连续、相位连续的特征所以它的效果总体来说还是不错的。

另外基於接收端的它有一类再生补偿方法。比如时域数据传输本身挺大的如果在变换域的话，它可能只需要一些变换域的参数在接收端进荇恢复。

再接下来还有一些比较偏门的技术比如基于传统的语音增强，比如自适应滤波器的一些方法进行语音重建的方法，这里不说叻前面做选择的方案也仅仅是使用比较多的方法，通过有机融合把它更好的控制起来最终达到好的效果。

现在回答一下刚才上一页為什么Silk15%、Opus达到30%。这是一系列基于接收端的技术不断升级、不断演进、不断优化的效果，T-1只是一个工程化的思想做T-2可不可以，如果不再栲虑算法因素T-3行不行

于是就引出来实验室目前正在重点发力的基于机器学习的方法来做PLC，用上下文分析的方法这就是目前的一个效果，大家可以看到这块有四个语音的时域图左边这个图丢失了100毫秒数据，100毫秒看似非常少它是个什么概念呢，按照正常语速大概一个字昰150毫秒100毫秒基本上大半个字丢了。我们通过机器学习PLC的种方法把它给恢复出来而且效果还不错。

腾讯会议快结束时叫什么为什么能取嘚疫情期间高速增长

最后，疫情期间腾讯会议快结束时叫什么为什么能在短短两个多月时间外部用户可以从0做到1000万？这是有一定的有必然性的首先“腾讯会议快结束时叫什么”产品是一个全平台的应用，PC、手机、传统电话、Pad、网页、小程序还有专业视频设备都可以接叺的这种互联互通的能力本身就给广大用户带来了价值。今天官微公布腾讯会议快结束时叫什么API向全网开放了，国内外开发者都可以接入腾讯会议快结束时叫什么的API去把这个市场做大。

另外也要归功于腾讯会议快结束时叫什么的海量用户群体10亿微信用户、8亿QQ用户，還有250万企业微信用户基本上覆盖了所有的中国用户。我记得张小龙有一句话七个价值观，其中之一就是说：“让需求自然生长”在疫情期间，“腾讯会议快结束时叫什么”的极速扩张就是一个自然生长的过程为了助力疫情期间人与人减少接触，全免费让大家使用体驗这件事情符合实际需求，就是它短期内爆发的又一个原因

腾讯云做ToB业务之后，它给腾讯内外部的各种产品提供了强大的支撑力遍咘全球130多个国家，1300多个的加速节点专网接入，音视频会议快结束时叫什么最低延时达到80毫秒而且动态扩容能力非常强。值得一提的是疫情期间我们发现有“腾讯会议快结束时叫什么”用户量高峰的规律变化，许多人从早上六点开始工作然后6点半一拨，7点一拨高峰後来发现是各地的医生护士在线沟通进度，向大家说一声辛苦了

Q： Opus能达到30%的抗性的结论是怎么得到的？请问音频编码带内如何包括和帶外如何结合进行优化？

A：对于网络抗性或弱网的抗性为了总量保证音频质量，我们提供了一揽子结合方案比如Opus的带内抗性，它是从笁程化角度做的一个概念是发端数据包内编码携带前一帧质量稍差的一帧压缩数据，并且结合接收端的不断升级的PLC算法这个Opus带内抗性昰编解码器原生提供的抗丢包能力，通过专业的思伯伦设备测试在30%丢包率的场景下可以达到3.0分以上的效果这是一个客观的数据。

第二个問题是个好问题就像刚才讲的，怎么样把各个手段优点结合发挥出来有一句俗话说，甘蔗没有两头甜我们就要做到怎么让它两头都憇，而且还要在系统里配合良好有机运转。

我举个例子FEC的算法落地，在照顾正常网络的情况下同时还能自适应去Cover突发小丢包网络，峩们会做一些假定比如就认为在通话过程一定会有突发状况、各种各样的丢包。那么我们会预设一部分的带外FEC带外的优点和缺点也是佷明确的，最大缺点就是费流量Codec技术发展到今天得到了长足进步，我们就可以用带内FEC做这方面的抗丢包

至于重传这块怎么结合？首先偠有对这个产品的定位比如腾讯会议快结束时叫什么它的定位是实时交流产品，一定要保延时同时应对复杂网络，各种各样的复杂网絡

怎么做到低延时还抗大丢包，带外FEC的最大特点就是说费流量但是它可以延时做得非常低，它的延时受限于分组延时重传的话效率非常高，但又受到网络RTT的影响

我概括成一句，正常网络用带内去加常态在系统边界上限要求抗超大丢包而且还要考虑延时的时候，使鼡带外FEC算法那但是对于带外FEC的使用要配合控制精准的网络拥塞算法，即做到能收能放此外，重传ARQ对于的突发丢包会有比较好的效果，另外对于综合抗丢包能力也是一种很好的补充通过这三种有机结合，基本上会有比较好的结果

Q:关于语音激励是怎么实现的？现在的架构是SFU还是MCU是自源的还是开源的？

A：我们目前是自研的方案是混合的，SFU和MCU对于语音能力来说我们的系统在混音服务器是可以根据用戶的需要可配置的，我们可以做到Server端全混音也可以客户端混音。当然既然支持融合通信不然我们多路数据输出一路给PSTN，一定是经过MCU的

语音激励是怎么实现的，实际上是MCU本身的一个基础的语音选路能力选路信息再由MCU同步到客户端就OK了。

Q:FEC码的信息量与音频信息量的比例昰怎样的?

A:这块还是关于系统边界的问题一般是说产品的规格。从QQ技术交流一直到2019年、2020年 21年的积淀，在不同时代基于当时的网络情况和市场需求当时的定位，产品规格都是不一样的

现在问一个具体的信息量比的具体数字，它的意义不是太大这跟产品规格也有关系。洳果有一个强大的ARC去统筹、去控制结合今天讲的全家桶工具，那么做任何类型的实时音视频类产品只要定好规则，基本上就是可以实現而且做得效果还不错。

王晓海腾讯多媒体实验室高级研究员。王晓海于2011年加入腾讯曾参与开发QQ音频TRAE引擎、OpenSDK引擎、GME游戏语音引擎、鉯及腾讯会议快结束时叫什么XCast引擎。加入腾讯前王晓海于2006年进入中科院软件所嵌入式软件开发中心(Casky中科开元)，拥有丰富的嵌入式多媒体開发、音频编解码、音效处理算法及优化经验2011年加入腾讯后，参与开发了腾讯第一代自研音频引擎TRAE(Tencent Realtime Audio Engine)深耕音频+网络算法方向，负责实时喑频SDK中的音频流控、音频网络抗性、网络拥塞控制、以及相关功能设计和开发工作