江苏龙网

  1. 首页 > 人文 > >

【腾讯】一文读懂腾讯会议在复杂网络下如何保证高清音频( 二 )


其实腾讯的音视频引擎又可以分为三个小代际 。 第一代就是 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 的概念 。
【腾讯】一文读懂腾讯会议在复杂网络下如何保证高清音频
本文插图
QoS（Quality of Services）概念当时在 IETF（The Internet Engineering Task Force 国际互联网工程任务组）提出的时候 ， 只专注于纯网络范畴的指标 ， 比如丢包、延迟、抖动、带宽等 。 进入新世纪以后 ， 行业对 VoIP 或者融合通信的理解有变化 ， 进入宽带时代以后对指标会有更高期许和更高要求 ， 比如说音频采集 ， 本来采集信源不好 ， 再经过压缩、传输、解码 ， 可能最终效果不好 。 如果从 QoE（Quality of Experience）环节来看 ， 端到端不限于采集模拟接口出来的声音 ， 甚至包括人的讲话环境和听音环境影响 ， 用户感受到的音频质量 ， 是整个体系反馈出来的诊断 。
QoS 没有太多秘密 ， 无非就是抗丢包 ， 抗抖动 ， 网络拥塞控制等等 ， ARC（Adaptive Rate Control）可以看做一个中央指挥官 ， 它只能去指挥整合这些方式、手段 ， 最终保证音频质量是良好的改动 。 所以说到这块 ， QoS 一般套路就类似于一个全家桶 ， 无非这六种模块的合理有机组合 ， 接下来会对这几块深入讲一下 。
【腾讯】一文读懂腾讯会议在复杂网络下如何保证高清音频
本文插图
腾讯会议是如何保证服务质量的？1、腾讯会议的“流控”：ARC
先看 ARC ， ARC 在腾讯会议的概念就是“流控” ， 流控能干什么？
是三个大的层面 ， 首先它是一个配置系统 ， 无论双人或多人通话 ， 系统所需要的基础配置参数 ， 还有在什么场景下需要什么样的参数 。 通过这个云端的参数配置及开关配置 ， 系统拥有了基本的云端可控手段 。
然后动态控制是中间的这块 ， 流控是把源端到目标端的传输行为 ， 发出来数据想让对方解码 ， 会存在动态的能力交换的要求 。 此外 ， 系统如果发生了抖动 ， 或者丢包的情况 ， 我们会动态的去控制相应的模块去处理这些情况 。 所以能力交换 ， 或者动态下发的能力 ， 实际上是动态控制的第二层次水平 。
最高层的能力 ， 是聪明灵活自适应的能力 ， 就是对 ARC 的指挥能力的更进一步的要求 ， 丢包的时候怎样去抗丢包 ， 抖动的时候怎么样去抗抖动 ， 去动态控制 ， 但是这些抗丢包、抗抖动的方法有可能会占用过多的网络带宽、或者以牺牲端到端延时为代价的、于是当网络发现了比如带宽不足 ， 或者网络用户本身终端连接路由器质量有问题 ， 甚至出现网络趋于拥塞的情况 ， 这种情况怎么去把它及时挽救回来 ， 这个配置是对 ARC 更高层次的要求 ， 涉及到网络拥塞控制（Congestion Control）这个核心命题上来了 。
2、“流控”在腾讯内部的演进过程
一开始是都写死的参数 ， 比如解码器参数、音频前处理 3A 开关等、抗丢包和抗抖动参数也基本是固定的 ， 效果肯定不好 。 后来我们 在系统增加了流控策略 ， 根据客户端动态上报 ， 动态去算 QoS 的参数下发 。 进化到多人通话以后 ， 特别带宽预测是比较大的挑战 ， 比如上行应该怎么算 ， 下行是接收多交流又该怎么算 ， 因为发送行为不一样 ， 原来那种用一个算法对不同流进行预测 ， 肯定不能用 。


推荐阅读


上一篇：『走心不愚人』只是玩笑？愚人节手机厂商或有深意

下一篇：「阿里巴巴」阿里正面刚腾讯：收入1615亿对1094亿，净利润522亿对216亿