音视频通讯能力作为标配渗透到了各个行业，腾讯音视频实验室音频技术负责人郭亮在LiveVideoStackCon 2017上分享了腾讯音视频实验在流畅无卡顿、回声消除等音频前处理、网络部署与覆盖等各个技术上的深度解析，以及前沿技术创新在音视频场景中的实践，本文为分享的整理。
演讲 / 郭亮
整理 / LiveVideoStack
一、行业背景与趋势
感谢主办方LiveVideoStack给予这次分享机会来介绍我们整体的技术方案，以及互相探讨学习。首先，做下自我介绍，我是来自腾讯音视频实验室的郭亮，主要负责腾讯视频云的整体解决方案，以及互动直播、点播的解决方案。
众所周知在前年下半年和去年移动直播非常火，虽然今年整体直播行业略有降温，但并不代表音视频也降温了，同时音视频的应用场景变得越来越多，我们作为一家视频云服务平台，更能深刻地感受到这种变化，像上图中聚美、蘑菇街、大智慧以及全民K歌、唱吧等等，这类自带粉丝特性以及自带行业特性的App越来越火。
1.直播行业的细分
教育是非常火的音视频应用场景之一，比如像VIPKID在线课堂的用户群体数量就非常大；电商也是比较大的应用场景，由于它自带流量的属性，因此变现能力较强；游戏赛事，近年来如王者荣耀等游戏推动了直播的发展；再有就是旅游的、秀场的、社交等等应用都不约而同的用起了音视频技术。前两年更火的是以观看为主的单向直播，而近一两年趋势则转变为以教育、电商、K歌这一类互动性更强的直播方式。
2.优秀直播产品的特性
我们可以看到一个优秀的直播产品所需的特性很多，虽然现在使用WebRTC可以快速搭建起直播产品，但同时也会发现存在各种问题：延时、回声、动效等等，因此对于一个初创的团队而言，从头到尾搭建音视频是非常耗人力以及时间成本，而且一旦错过窗口期也意味着错过了一些非常重要的资源。因此我们也认为“让专业的人去做专业的事”。
3.主流直播方案
在现如今的行业中，很多公司都在推基于音视频服务的平台，那么又该如何去做技术选型呢？又有哪些方案可供选择？上图中的直播方案其实也都是比较传统的方案：RTMP、FLV、HLS、RTP等等，在几年前PC端比较火时，RTMP和FLV因为无需安装额外的东西而具有非常广泛的应用，移动端的火爆则让具有手机浏览器支持特性的HLS得到了大范围的应用。上图列了一些优缺点，可以看到它们各有千秋，如RTMP和HLS适应性较强，但延时和可控制性上都是有一定的缺陷。
4.腾讯云互动直播方案
我们在做视频云时分析了各个方案的优缺点，最终推出了一套方案（上图），其实目前主流服务平台的方案都大同小异：以UDP的实时传输作为主要的实时沟通的方案，在小范围追求低延迟、高质量的情况下，我们建立一个UDP小范围的传输网络，同时支持旁路推流，以及点播录制，支持CDN分发。这样我们既支持了一个高互动的网络，同时也支持大范围分发、录制、后处理、可接入机房这样的服务后台体系。下面的方案中使用CDN做分发的主要原因还是出于成本控制，因为一旦用户量很大，使用上面的方案所带来的成本就会成为企业沉重的负担。
二、音视频质量
上面简单的介绍了一下我们的方案，接下来是今天主要分享的三部分内容：
- 音视频的质量
- 可扩展的功能
- 技术创新
音视频的质量我将它分为两类：
- 网络传输以及抗性方面的质量
- 音视频内核的质量
之所以这样分类，主要是自身使用场景和服务客户的过程中，经常会反映出两个问题：一个是卡顿、延时大，另一个是回声、画质不清晰等问题，由此分为了两个方面。
1.网络传输与抗性
- 服务器部署覆盖全球
我们会在全球各个主流国家进行布点，这也是很多大公司集中采购的优势之一，同时我们这些资源也可以进行很好的复用。举个例子，如上图我们在北京进行一个现场或者互动的直播，美国的朋友想观看，那么此时我们可以提供多条链路：从加拿大获取、从北京拉专线直连、从上海或者香港转中转等等，这样我们就能实时从多条链路中择优选择质量最好的链路传输。当然并不是所有时间都必须使用最优的网络，这里我们还会有所控制，比如上面的例子中从北京到上海再到美国这条链路是最好的，但同时上海的用户量也非常大，那么怎么合理的在后台进行用户分布的控制，同样是很重要的。
仅仅通过主观评定还远远不够，很多时候需要用数据说话，我们在全球用户量比较大的主流国家之间的网络链路质量进行了量化，我们根据延时、丢包等相应指标综合考核评分，实时监控网络链路的质量。如图上所示，我们定义红色为网络质量相对比较差的地区，可以看到从非洲和澳大利亚出来的网络很差，如果接入自动监控的机制就可以看到这个地方网络一定是有问题的。这样我们就可以提前发现问题，进行监控。同时可以很好的给用户做排查。
做网络有几个要点：
- 部署要好，若部署不好，后面的东西做的再好都会产生问题
- 部署好之后抗性也要强，这样即使在部署较好，但网络质量下降时，也可以很好应对
- 影响秒开的因素
如何做秒开？为了更好的定位问题，我们把它定义为两个阶段：进房速度和出画速度。首先进房速度要快，一旦耗时很长，用户的产品体验就会非常差，你也很难想象用户滑屏之后出现两秒的黑屏，因此进房速度一定要快，这就需要对并行和设备有一定深刻的理解。第二，出画速度要快，直播中有人进来时会向服务器请求数据，而只有收到第一个GOP I帧，后面的数据才能出来，但同样有可能出现当请求时GOP的I帧刚过去，这就要花费一定时间等待，如此是无法满足用户体验的。
- 双GOP缓存机制
针对上面GOP I帧的问题，我们在Server缓冲一个GOP，这样就可以拉到最近的一个I帧，从而保证用户能尽快的看到画面。同时也做了一些优化，缓存一个GOP是否能保证用户在最快的时间内就看到画面？能否保证在最快的时间就把这个延时降下来？答案其实其不行的。比如现在多拉了一个GOP，但哪怕GOP设的很小，它也会多拉一些数据，所以我们会对它做对齐的处理，包括音视频对齐，以及一些时间戳的操作。
其实或者无论音频还是视频，都会有快进慢放的操作。对于普通场景来说快进慢放的感受可能不明显，但对音乐等这类节奏感很强的应用，就会非常明显。因此我们按照串并联方案，缓存两个GOP，根据它合适的时机来推最合适的GOP，从而减少快进慢放对体验的影响。
不过在实践过程中我们发现，虽然它大部分情况下都能保证出画或进房时间很快，但不稳定性非常强。这主要是由于当推了一个GOP，在几十毫秒或者几百毫秒内，同时下来的数据量会非常大，从而造成网络拥塞，那么假如这时刚好把I帧丢掉了，首屏加载一样会有问题。我们针对这个问题做了推流速度的微控制，比如20毫秒推500K，但仅靠控制还是不够的，还需要做一些如QoS保障机制、FEC、关键帧的重发等等机制将质量保证到最好。
- 网络三级自适应调控机制
上图是我们网络控制的架构——三级自适应的调控机制，它分别对应了不同的网络在几百毫秒级别微小的丢包、一两秒网络抖动情况下、以及长时间的网络带宽已经有了明显变化的情况下，采用不同的机制来对整个编解码流控进行调整。在网络抖动很小时，会首先调整码率，接下来是对帧率的细微调整，当确认长时间网络较差时，我们会对整体编码的策略和编码参数进行调整，通过这样的方式来实现良好的网络抗性。
- 快速网络探测专利技术
前面介绍的都是事后处理，也就是在我监控到出现丢包、网络的延时比较大之后，再对发送码流、发送码率进行调整，其实此时已经晚了，因为网络已经变坏了，而当作出调整时，它可能又已经恢复了，那这就是无效的调整。因此我们结合了国外的一些前沿技术做了一套快速的网络探测技术，大家可能用过RTC的知道它有一个卡尔曼滤波带宽预测，我们设计了一套更为优秀的算法，总结来说，我们可以在网络达到临界点之前，提前感知到网络的变化，从而作出调整保证用户观看体验。
2.音视频内核质量
- 优异的回声抵消技术方案
前面重点讲解了网络质量，下面我们继续介绍音视频内核的质量。虽然现在iPhone和很多安卓机型都自带回声抵消，而且WebRTC中也有AECM模块，即使对于没有音视频基础的人，也可以做到Run起来没有回声，但这只是比较初级的体验。虽然苹果回声抵消做得比较好，但对于像全民K歌这类专业级的音乐应用来说，它对回声抵消要求还是无法满足的。比如使用iOS的回声抵消后声音的频谱一定会下到12K，但是对于音乐应用最少要保证16K的频谱，也就是32位采样才能比较真实的还原声音的质量。
在安卓上，使用AECM则存在适配能力以及偶尔出现回声的问题，最重要的是ACEM的双讲剪切会非常的厉害。除此以外还存在另一个比较大的问题：手机一般至少会有三种音量的类型——通话音量、铃声音量和媒体音量，我们在放歌或直播时一般使用的是媒体音量，但如果你想使用系统的回声抵消能力，则必须切换为通话音量，但对于iOS来说，切换为通话音量类型会对音质有一定损伤。
因此回声抵消也一直是我们自研的核心技术。回声抵消有两个技术：首先是自适应滤波、残余噪音消除是否干净，但在此之前更重要的是信号对齐，如果信号对齐不好，即便算法再优秀也是没有办法将声音消除干净的。因此我们在信号对齐方面也是有多套对齐方案同时上，这主要是为了满足不同的场景间的特性区别：比如安卓的碎片化，包括PC端XP、Win7、Win8，Win10的特性也都不一样，某些系统上时间戳非常准、而有些则使用线谱非常准的。我们自研的一套指纹对齐，它更加精准，会在系统特性、性能消耗以及最终效果之间做平衡。
第二点就是适应滤波器、残留回声的抑制以及一些细分场景的调优。上图是Skype（上）和我们自研（下）的效果对比，红框部分中可以看到，下面的回声抵消很快就将回声收敛了，虽然上面也做了很好的收敛，但时间比较长。在我们日常使用时可能会有这种体验：正常沟通时没有问题，但在有人突然说话时会出现漏回声的情况，这就是由于收敛慢造成的，因此这也是考核回声抵消比较重要的因素之一。
- 领先的视频编解码引擎
其实在视频编解码这部分大家的做法基本差不多，就是软硬结合的方式，对软件的性能以及在X264或者其他的编解码器在代码基础上进行视频编码优化，以及在部分硬件上提供硬件编解码。而我们的优势在于使用QQ的产品做运营和测试，因为QQ每天有几千万次双语音呼叫，基本上可以遍布所有的机型，所以在硬件编解码的机型适配上有一套很好的流程：比如我们给全网1%的用户下发一个配置，当他登陆时，会选择合适时机进行一个Test，然后上报结果，我们通过这个结果得知硬件编解码的质量如何，若效果没问题，就可以把这个配置再通过后台系统重新下发，如此就可以形成一个良好的闭环系统，让很多安卓手机都能享受到硬件编解码的好处。
三、可扩展的功能框架
可扩展功能重点还是依托于我们的架构，在服务几百家客户的过程中，我们也发现每家客户的需求是不一样的，体现在几个层次：
1.SDK层
有些人喜欢用音频，有些人可能音视频都需要，有些人可能需要插件服务，为什会把这个单独列出来做插件化呢？其实大家对安装包的要求是非常高的，尤其是在一些游戏上，众所周知在iOS上是有一条红线的，当超过一百兆之后就不能用移动网络来下载，另外代码段是不能超过一百兆的，但是很多大型的游戏代码量非常大，而它对安装包的要求也非常高，这时我们就可以灵活的定制，按需出包。
2.采集层
对于接入多个服务一起操作的情况而言，音视频的采集可能是不需要我们来做的，这时我们需要帮他来做处理和其他操作，比如在手机直播时实现伴奏等功能。
3.处理层
这部分我们也是开放的，比如提供给用户美颜、变声、滤镜等体验：我们的实时美颜技术会设置一个域值，根据它来控制美颜的程度；同时提供趣味音效等多种功能。之所以在这部分做可扩展，主要考虑到人主观看法是不一样的，使用者本身诉求的差异化可能会很大，比如大家对于美白的需求就会有所差别，甚至对于欧洲人来说美白功能是完全不需要的，因此我们这部分做了自适应。除了以上功能，我们还做了动效与背景的替换，比如动态贴纸等等。这部分需要着重关注的是性能的消耗和贴服性。
四、技术创新
最后分享我们的一些技术创新，可能大家首先会想到AI，不过从我的角度来看AI是一个工具，可以用它来做很多东西。而我们的技术创新也是一样的，并非一定要做很高深的技术，而将技术真正的用到产品中，为产品创造更多更好的玩法，以及更好的用户体验。
1.跨房间连麦
房间对于传统音视频互动是不可回避的一个方面，我们实现了一套跨房间连麦的机制，这套连麦机制不仅支持主播间的连麦，同时支持粉丝上麦，将两个房间的粉丝聚合起来，这样无形中增强了这种PK体验和互动性，也创造了更多的玩法，而在实际用户活跃度的统计中确实可以看到明显的提升。
2.歌房合唱
除了网络抗性和部署方面以外，音视频不同步也是非常重要的问题。我们在7月全民K歌中实现了多人合唱的功能，甚至有按字出歌词的功能，但大家都知道每个人的网络延迟都不一样，几十毫秒的网络延迟是无法实现这种效果的，坦诚来讲，这其实是产品体验上看到的效果，实际的技术实现是一个领唱、一合唱、最后放给观众端，在这个过程中我们做了很多音画同步以及对齐的处理，这里的同步除了演唱者以外还包括了歌词的对齐，从而让观众感觉和KTV唱的体验是一致的。
3.低照度处理
除了上面的介绍，我们在音视频内核做了很多技术上的优化。比如在暗的场景下拍照、拍摄会有问题，因此我们做了低照度的处理，上图从左到右是处理过的图，可以看到清晰度有了非常大的提升，而在这里着重介绍是因为我们已经实现视频的低照度增强，而不单单是图像级的，但其中会有几个难点：
- 性能上会有比较大的优化诉求
- 在视频时不同帧之间的衔接要做的非常的精细
- 如何在极亮的场景处理的不模糊，没有很多的噪点
4.手势识别
手势识别，目前借助机器学习已经可以很好的实现，它的核心主要在于识别准确和性能损耗的降低。我们是基于现在一些成熟的框架，目前对一帧的识别大概可以在20毫秒以内返回结果，这样就可以很好的满足实时性的要求，给用户一个更好的玩法体验。
5.无参考评估
音视频的主观评估一直是难点，因此我们建立了一个无参考评估的体系，上图浅的地方代表质量比较差，深的地方代表质量比较好，这样我们就在全国给音视频做无参考的评估，这也是我们一个比较核心的体验，关于这部分内容大家可以详见《直面音视频质量评估之痛——走进腾讯音视频质量体系》。
WebRTCon 2018 7折火热报名
WebRTCon希望与行业专家一同分享、探讨当下技术热点、行业最佳应用实践。如果你拥有音视频领域独当一面的能力，欢迎申请成为讲师，分享你的实践和洞察，请联系 speaker@livevideostack.com。
