另外也要归功于腾讯会议的海量用户群体，10 亿微信用户、8 亿 QQ 用户，还有 250 万企业微信用户，基本上覆盖了所有的中国用户。我记得张小龙有一句话，七个价值观，其中之一就是说：“让需求自然生长”。在疫情期间，“腾讯会议”的极速扩张就是一个自然生长的过程。为了助力疫情期间人与人减少接触，全免费让大家使用体验，这件事情符合实际需求，就是它短期内爆发的又一个原因。
腾讯云做 ToB 业务之后，它给腾讯内外部的各种产品提供了强大的支撑力，遍布全球 130 多个国家，1300 多个的加速节点，专网接入，音视频会议最低延时达到 80 毫秒，而且动态扩容能力非常强。值得一提的是，疫情期间我们发现有“腾讯会议”用户量高峰的规律变化，许多人从早上六点开始工作，然后 6 点半一拨，7 点一拨高峰，后来发现是各地的医生护士在线沟通进度，向大家说一声辛苦了。
QA
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 中的音频流控、音频网络抗性、网络拥塞控制、以及相关功能设计和开发工作。
,
