谢谢各位，谢谢LiveVideoStack给我这个机会做分享。标题是全面解密，但是今天真的做不到全面解密，因为其中任何一个点都可以说一天，今天只能说我们比较全面的过一遍，更深度的内容我们下面再详细交流。首先简单做个自我介绍，我来自于即构科技，我们是做语音视频方面的实时通讯，典型的应用有直播、视频社交和游戏语音，跟前面分享的主题会有一点区别的，在于我们更多的注重实时互动，比如单向直播就是一个妹子唱歌跳舞给你看，实时互动则是几个妹子一起脱口秀也好、合唱也好一起表演给你看，或者说就像Houseparty几个人同时一起在线语音视频互动。

后直播时代的趋势

这是我今天覆盖的一些主题，首先是发展趋势，虽然我不是做行业研究的，我要了解行业的发展趋势，基本是基于平时对一些客户的服务过程中的交流沟通，我从中做了一些总结。

1.互动直播头部客户

第一张图是易观报告里面的，另外一张是我们客户的列表。易观这张图基本总结了整个直播行业头部的客户，如果你不是直播行业的，又想知道直播行业里面主要的Player是谁，那你看这张图就可以了，在右边的图我们可以看到第一行有YY直播、映客、花椒、一直播，还有陌陌的哈你直播、酷狗凡星、来疯，这些都是大名鼎鼎的。然后再看左边这张图，是我们过去两年里深度服务的一些客户列表，我们可以看到这两张图的重合度还是蛮高的，我框出的这四个和易观报告中是一样的，也就是说我们的客户基本覆盖了直播行业超过一大半的头部客户，而且他们有一个显著的特点就是在直播方面对实时互动技术产品上的业务创新玩法十分多样，具体如何多样我们后面再做详细介绍。

2.直播时代创新玩法

这里的前三张图都是花椒直播的，第四张是美播的，他们主要的特点就是能够互动，具体怎么样互动？我们一步一步来说，第一张图里面的美女是关之琳，这个是典型的单向直播，也就是一个美女唱歌表演给你看；第二张图是三个帅哥，他们之间是可以互动的，一个在远端、一个在近端，双方可以听到对方的声音、看到对方的样子，这是两人连麦；接下来三人连麦和六人连麦，我们现在可以做到移动端20个人连麦，PC端32个人连麦，其实还可以继续扩容。

不过你可能会有疑问：手机屏幕那么小为什么需要20个人连麦？PC屏幕也不是很大，为什么需要32人连麦？如果看下美国现在火爆的Houseparty、狼人杀就知道为什么需要那么多，狼人杀最起码需要12个人，手机屏幕虽然小，其实可以用很小的框去做显示，最重要的部分还是语音的实时沟通。像花椒用我们的服务在直播行业就把公众直播玩的十分多样，像他们推出的浴室歌王、中国男生等一系列的K歌玩法，都是采用这套实时互动的连麦技术。

我们可以想象两个人一起合唱，如果延时大一点，基本上一个人肯定把另一个带跑调，我看过一些文献，在工作中也做过总结：一般来说，如果延时超过400毫秒，两个人是无法正常对话的；如果低于100毫秒，两个人就可以很激烈、高频的做脱口秀，就像金星一样；如果低于50毫秒，两个人是可以一起合唱的，不会出现跑调。

3.后直播时代的趋势

我们说2016年是直播的元年，现在基本已经过去了一年多了，就像任何一个互联网时代一样，大浪过来又过去了，肯定会留下一些东西，并且它还会继续蓬勃发展，那直播时代留下什么东西呢？我总结了两个点，第一个点是技术的，第二点是行业的。

技术上面就是语音视频技术逐渐成熟了。以我们为例，延迟可以做到全球范围100毫秒左右，如果是直播的话，围观的观众端我们做到一秒左右，主播之间的互动在100毫秒，相互是可以做到高频吵架、辩论的；第二点是回声消除，如果是单向直播根本不需要回声消除，因为根本没有馈路，但如果是互动就必须要做回声消除；第三点流畅不卡顿是最基础的要求，必须保证。

在行业方面，经过一年多的痛苦踩坑、无限努力之后创业者达成一个共识，就是语音视频方面的技术门槛是蛮高的，而互联网发展又快、产品迭代又快，因此还不如把专业的技术让专业的人来做，他们把精力集中在主营业务上，抢占市场、拿融资、发展业务，也就是用第三方的SDK来做云视频的直播。

经过直播时代，行业慢慢衍生出一些新的趋势，就是除了直播以外，后直播时代视频社交、甚至音频社交大行其道，具体一点说：像狼人杀既有游戏属性又有社交属性，游戏语音同样也是具有社交属性和游戏属性，此外还有陪聊、视频交友等等，特别是陌陌最近上线的8.0把社交玩到极致，社交下面除了文字、图片，更加好玩的是可以通过声音跟视频很快的搭上话，以上是我对后直播时代趋势的简单介绍。

视频互动背后的超低延迟

接下来讲的内容就纯技术了，刚才我提了一个问题，因为我觉得对于直播，甚至社交来说低延迟是十分重要的，接下来我会深度的介绍怎样获得比较低的延时，低到什么程度？全球范围能够达到一百毫秒左右，围观的观众——不需要互动的人能低到一秒左右。

1.RTMP or UDP？

我们了解如果通过RTMP标准协议现在行业普遍的水平应该是三秒左右。我们即构这边通过实时通讯架构，还有实时通讯各个环节上的优化，使用RTMP协议也是可以做到一秒左右的，使用基于UDP的专有协议话我们可以做到一百毫秒。怎么做到的呢？首先你要选择要用哪种协议：是用TCP，还是用UDP——RTMP协议的下层是TCP协议，自己的专有协议是基于UDP协议的。我做下简单的概括：UDP协议让你对端到端全链条有更多的掌控力，如果你足够牛可以全面的掌控ARQ和FEC进行信道保护，可以做到码率自适应。如果你的团队有信心有实力要获得超低延时，那你一定要选择UDP协议。

我并不是说RTMP不好，它也有自身的好处——就是普适性，它普遍被CDN支持，而且也可以获得比较低的延迟，围观的观众端可以达到一秒左右，互动可以达到四百毫秒左右。但是RTMP有它的不足：因为它是基于TCP的，TCP有自己的ARQ，但是它基本是把ARQ包起来——你改不了，而且TCP是一个面向IP网络、面向公平，不是为实时通讯而设计的协议，这是80年代的技术，到了今天已经不太适合做实时语音视频通讯。TCP不允许开发者做FEC，所以你能做的事情并不多。在网络比较好且编解码器一样的情况下，这两者效果是差不多的，但是网络一旦变差的话，高低就分出来了，如果网络比较差，丢包率比较高，延时比较高，特别是跨国的情况下，这时候基于UDP的专有协议会有更多的保障。

2.实时通讯架构

这是实时通讯的架构图，目前大家基本都是用这个架构，刚才我也说的蛮多了，左边是低延迟实时互动的，右边是围观观众的，大家会觉得这个东西应该只在直播行业里面用，其实在狼人杀里面也是这样，像大型的MMORPG游戏也都会用到这样的架构图，为什么这样呢？在MMORPG中少数几个Leader带着一大堆人去攻城，围观的那些小兵应该是只听不说的，只有那些做决策的Leader需要实时的沟通，像狼人杀同样是说话的几个人需要实时沟通，绝大部分人还是在听的，只要围观就好了。那为什么要分两波？主要还是出于成本的考虑，围观的人不需要用到核心的服务器，不需要用到很好的资源，所以它的成本是比较低的，而实时互动相对成本就比较高。

刚刚我们说到要用UDP来实现实时低延迟比较有保障，那UDP它是不做信道保护的，也就是说它会有很多丢包，网络糟糕的话它也是不管的，但好处是自由、有很大的掌控力，如果你要掌控它，你就得在上面做一层信道保护，也就是QoS技术，我们做了三大技术：一个是FEC，第二个是ARQ，第三个是ABC。当然FEC和ARQ是很经典的算法，但每一家都有自己的独门武功，会做一些优化达到低延时。ABC是英文缩写，全称叫做Adaptive Bit-rate Control，就是码率自适应。

3.FEC（前向纠错）

我们先来看FEC，这个在教科书里面都能看到，简单来说，它的好处就是只需要发送一次，你会在有效的数据包里面加入一些语义包一次性发过去，即使丢了一些包也没关系，对方收到后会把它恢复，所以你只需要传送一次就可以达到发送有效信息的目的。它的优势就是在跨国环境，RTT比较大的时候，它只传一次节省时间，但缺点是它要加语义包，这样信道利用率就降低了，还有一个是它的算法相对来说比较复杂，适合做符合泊松分布的随机丢包，但如果是突发性丢包，它就不太适合。举一个简单的例子，如果你要发四个数据包通过Reeds-Solomon经典的算法会增加两个奇偶校验包，那实际上发的是6个包，增加了50%的带宽，这是蛮多的，因为带宽就是钱。对方收到以后如果丢了一个包那怎么办？他可以通过r1去恢复，这基本是FEC的做法，它用股市上面的一句话就是用空间去换时间，你多发送数据，但是你省了时间。

4.ARQ（丢包重传）

ARQ，如果用股市上面的一句话，它是用时间去换空间，它发送多次，但是省了带宽，怎么省呢？就是我给你发个数据包，如果你没收到，我再给你发，一直发到你收到为止，所以就说他多花时间去多次发送，但是它省了空间，因为它只发那些必须要发的数据包，什么是必须要发的？重要的，他有算法决定哪些是重要的，而且这个数据包必须在那个解码的deadline之前送到的，如果它能预测到及时重发也会错过解码的deadline，接下来我就不让你发了，这样既省了带宽，也省了时间的消耗。它的好处就是算法简单，复杂度低，然后占用带宽成本低，对突发性的丢包事件效果比较好，劣势当然是国际环境里面，比如中国到美国那么远RTT那么高，还要重传一次，还有一个劣势就是如果丢包率很高时候，它不断的重传，形成一个重传风暴，这是很可怕的，会加剧拥塞。

5.ABC（码率自适应）

码率自适应是很牛的东西，它基本的做法就是尽量的去发更大的码率，这样更加清晰，但是如果你发更大的码率很可能会碰到天花板，什么叫天花板？就是流拥塞、会丢包，这时候怎么办？碰到墙壁肯定是要退的，退就要降低码率，降低码率成果好了就又升上去，上去碰到天花板以后又下来，它就是不断尝试你的底线，从而去获得最好的效果，如果碰到天花板就下来，这个道理有点像开车。

具体的算法是，首先你得知道带宽有多少，也就是天花板在哪，第一步很重要，Bandwidth Estimation是很核心的一个算法，原先经典的80年代算法是根据丢包率测算网络情况，也就是说我发现丢包了、拥塞了，赶紧降码率，但是这时候已经迟了，这叫事后处理，但是现在的Bandwidth Estimation算法可以预测，比如说我们说地震的时候，最先知道的是那些鸟、兽，因为它们看到一些征兆，而网络情况也是可以看到一些征兆，比如发现延时不是很稳定，有时候延时多一点、有时候延时少一点，而且我的拥塞列表莫名其妙的变长了，那么有拥塞就是个预兆，我就会把这个带宽预测出来，告诉他应该降码率了。

另外你预测了带宽，这个带宽不是全部分给有效数据包的，你要分给我们刚才说的FEC和ARQ，它们是冗余数据包，也要占用带宽的，你要很好的分给他们，具体怎么分配我们一会再介绍。下面这张图是整个架构图，我这里简单的说一下，我们可以看到发送端有引擎、有媒体的编解码器、有ARQ和FEC，它们是保护信道的两大法宝，它通过RTP去发送和接收，带宽分配会给它们两个，同时也会分配给有效的数据包，然后通过RTCP反馈信息，RTCP是基于TCP的，因为比较可靠，再反馈给引擎，不断的反馈时宽，从而可以达到最优。

6.前向纠错和丢包重传混合

我们前面说的FEC和ARQ，你可能会问我，时间换空间好，还是空间换时间好？我以一个中国人的角度告诉你，中庸之道永远是对的，两个都好，两个都要用。所以我们在很多情况在做HARQ，就是ARQ和FEC两者混合的，这样的好处就是在网络不好的时候，可以做到十分好的效果，描述网络好不好用通常是三个因素，一个是Packett Lost Rate丢包率，第二个是RTT往返的延迟时间，第三个是有效的带宽，因为这是一个三维的图，我没办法画出来，所以用两张二维的图来表示，左边这张二维图估计在网上看过一些类似的，像索尼、华为内部讨论都会有。

我们这边也根据自己的经验总结了一个图，可以看到这里面有三种颜色，横坐标是RTT，纵坐标是丢包率，丢包率我分了两个关键的节点：3%、10%，国际环境有时候会达到10%，国内一般是不会超过3%的，然后再看RTT，国内一般来说是一百毫秒以内的，国际的话会超过一百毫秒，网络的环境会有好坏两个极端，特别差跟特别好的，特别差的就是图中最外围淡色的部分，特别好的就是左下角这个部分。

那特别差的情况下，我们一般是不用ARQ的，因为国际环境往返已经那么长了，所以不能反复重传，用FEC传一次就够了；在网络情况比较好的时候会选择用ARQ，ARQ几乎没有多占用额外的带宽，如果通讯距离短（RTT比较小），只要没有到解码deadline可以允许多重传几次。除此以外，在网络情况适中的情况下往往采取中庸之道，也就是FEC和ARQ有机结合使用。PLC在前面没有介绍，它是专门给音频用的，全称Packet Lost Concealment，中文称为丢包错误隐藏，也就是说，假如我丢了一个音频数据包，不使用FEC和ARQ，我也可以根据上个数据包和下个数据包之间的相关性推测出中间的数据包，不需要发送端参与，只需要接收端处理，就完成了错误隐藏处理。以上基本是我们在不同情形、不同的主播里面用到技术模块的组合，是我们一些经验的积累。

右手边的图是通过RTT和PLR两个维度来解释带宽分配的，我们做带宽预测估算出来一个值，你可以把它当作一笔钱，这笔钱要分给三部分，第一个是ARQ，第二个是FEC，第三个是有效的数据包，怎么分？我们看第一个图，第一个图所说的指标是RTT，就是往返的时间，假如往返时间特别短，比如你在同城的朋友进行实时视频通话的话，基本上使用ARQ就够了，ARQ的带宽消耗是不多的；但是如果你是在中国跟美国或者说跟中东的朋友视频通话，这时候就更多的用到FEC。RTT比较低的时候一般用ARQ，带宽也会分配给ARQ和有效数据包；在RTT比较高的时候一般使用FEC，带宽分配给FEC和有效数据包。而我们看另外的指标——丢包率。如果网络特别好，不怎么丢包的话，带宽基本是全部都分配给有效数据包；如果丢包越来越多，那就要逐渐增加分配给FEC和ARQ的带来来增强纠错能力。基本上，要根据RTT和PLR来决定给ARQ、FEC和有效数据包的带宽分配。

这么做有什么结果？即构科技通过这三个技术有机的结合，再加上全球布了超过100个BGP的节点覆盖，有了这么好的硬件基础，即构科技可以做到全球一百毫秒超低的延迟，这是有真实数据支撑的，感兴趣的朋友，我可以把测试报告发给你看。

这张图是我们的一些实时数据，当然这个不是设计同学画的，是通过算法计算出来的，背景是一张世界地图，每个点的位置是通过IP地址定位的，这个点的亮度是由这个IP地址当地用户的数量决定的，人数越多这个点的亮度就越高，人越少就越暗。我们可以看到，中国是最亮的，其次是中东跟北非，美国是第三亮的，其他地方还是比较暗的，特别是荒无人烟的格陵兰岛（哈哈）。

回声消除的解决之道

回声消除，做语音视频的朋友肯定知道它是语音视频技术里面最难的。回声消除是在互动双工通讯的情况下才需要做，单向通讯一般是不需要的。如果你要戴上耳机来切断回路，即使在双工通讯的情况下也不需要做回声消除，但是那样会影响你的体验。

1.AEC的原理

我们先说它的原理，这个其实是老生常谈了，大家都知道我们通常说的近端、远端，近端就是你坐的位置，跟你说话的那个人就是远端了，他说的话通过下行信道把信号送过来，再通过你的扬声器播放，播出来以后他的声音会空间里面传播，而同时你也在说话，这样他的声音跟你的声音在房间里面基本上会经过墙壁、玻璃反弹分成很多路，它们相互之间会产生叠加，叠加以后有一部分被地板吸收，剩下的被麦克风采集进去，所以麦克风采集的是远端信号变化的回声还有你的声音，这个有点像红墨水和蓝墨水合在一起，密不可分。采集进来以后通过AEC——Acoustic Echo Cancellation就可以把红墨水跟蓝墨水分开，也就是消除回音，把有效的声音传到远端，这基本上是整个回音消除的原理。

如果你不做回音消除，结果怎么样呢？那样你在远端的朋友会听到他自己的声音，而且这个声音是有延迟的，他就会觉得很怪，十分扰乱他的心神。右边是我做的一个简单的总结，回音消除的本质其实是对一个回声馈路函数进行求解，什么叫回声馈路？第一个点是扬声器Loudspeaker，第二个点是你的房间Room，第三个是麦克风Microphone，它们连在一起叫做LRM，这是一个回声馈路。如果我们把这个回声馈路当作一个自然的函数，那这个函数要怎样去求解？首先需要用函数对它进行模拟，模拟出来之后再求解，我们将求得的解作为参数传递给滤波器，滤波器可以模拟这个回声的生成，再生成反向波给到滤波器就可以和这个声音叠加把回声消除掉，基本上这是我对回声消除本质的理解。

2.三种语音状态

下面我们再详细说下三种语音状态，你可以仔细回想你跟朋友聊天时候的 状体 无非有三种情况：第一种是你说了一个很郁闷的事情，然后两方都不说话了，这就是静音；第二种情形是你特别能说，让他一句话都说不出来，就是单讲；第三种是你们都很善谈，两个人争着说话，就是双讲，这三种情形从技术的角度来说是十分重要的。

我们可以通过VAD检测哪些是语音段、哪些是非语音段，如果是非语音段就不需要处理，也不需要发送，直接填充一些舒适的噪音就可以。当有人说话时才需要处理。这里又分成两种情形：单讲和双讲。如果是单讲，因为近端采集到的只有回音，只需要把它全部干掉，然后回填一些舒适的噪音就可以发送了；如果是双讲就十分难了，我后面会详细介绍。

3.AEC的实现

这张图是AEC的实现，和刚才看的原理那张图很像，当然还是有区别的，大家可以看到左下这部分我们是把实现的东西加进去了。那实现其实可以分成两步，第一步是自适应线性滤波器——Linear Adaptive Filter，第二步是非线性的处理。非线性的处理又分为两步，第一步是把经过自适应线性滤波器消除后剩下的一些东西补到Error Adjustment中，最后一步是进行非线性的剪切处理，接下来我们具体看下每一步是样处理的。

• 线性自适应滤波

第一步是线性自适应滤波，这张图是我从网上找的，它可以作为我们双人连麦场景的示意图：这两个房间代表你（近端）和你的朋友（远端），就像我刚才说的，大家可以在右边这个房间看到声音的反弹和叠加，声音传播的路径可以简单描述为Loudspeaker—Room—Microphone（LRM），这其实就是一个自然环境生成的函数fe=LRM（fs），fs是远端的信号，fe是生成近端真实的回声。我们要对它建模，怎么模拟呢？ 我门 构造一个函数fe’=f（fs），输入是相同的，都是fs（far-end signal），我通过构造的函数模拟回声，让它跟自然环境真实的回声尽量地逼近，当然肯定是做不到跟它完全相同的，然后在滤波器里面根据模拟的回声生成一个反向的波把真实的回声消除就好了，这就是自适应的滤波器。一般来说，绝大部分的团队把这部分搞定就已经完成80%的工作，所以线性自适应滤波很重要。

但同时它也有两个难点：首先在建立模拟的时候，是要找出远端信号跟回声之间的相关性，所以必须要有个干净的环境找出两者之间的关系，但如果这时候近端说话就会干扰它的收敛，然而又不能不让用户说话，所以只能让你的收敛过程尽量短，短到一个时间片里面近端的人不说话，只有回声存在，只有单讲，这样就可以做到很快收敛、稳定下来，从而建立模型。另外一个难点就是动态自适应，你既需要我稳定，又要反应敏捷，比如说LRM这个回路发生变化，你要我也马上变化，重新进入模拟的过程快速逼近新的回声馈路，这是很难做到的。回声馈路为什么会出现变化？简单举个例子，你打开窗户、打开门，台风一来回声馈路就发生变化了；你拿着手机边走路边玩游戏，周围的墙壁相对你的位置变化了，也会影响回声馈路发生变化，这时候就需要重新收敛。

• 非线性处理

非线性的处理分为两步，第一步是残留回声处理，如果有残留的回声就把它消除掉，这部分这里涉及到很多算法细节就不详细展开讲了，然后根据处理结果判断它是单讲还是双讲：如果回声消除效果很好、回声的衰减幅度很大，说明它是单讲的情形。比如说，回声的抑制幅度达到18dB以上，那么很可能是单讲的情形。有了结果以后我们进入下一步非线性剪切处理，如果是单讲直接消除回声、添加一些舒适的噪音就可以了；如果是双讲又会分为两种情形：一种情形是这个回声很大，比如你的麦克风离扬声器很近，或者对方是说话的声音很大，把你的声音完全盖住了，那这时候无论怎么做回声消除，技术总是无法保证完全消除回声的，这个是自然环境决定的，所以这时候只要直接把它干掉，填充舒适的噪音就好了；另一种情形就是我们既要保护有效的噪音，又要做回声消除，那这时候我们就不再做处理，保护有效的声音。

这里有两种基本的做法，并没有对错之分，实际应用中需要根据用户的需求来决定。第一种是宁肯杀错也不放过——尽量把回声消除干净，第二种是宁愿放过也不错杀——允许保留些许回声也不要对原声造成损伤。

全面而细致的后台管理

在听完我所讲的这两个技术之后你会觉得很不错，不过也会质疑在实际使用中我讲的东西对你来说更像黑盒子一样，并不知道里面的语音视频、码率等等是怎么样的，也不知道如何去处理、解决问题。我们一直认为再好的技术只是基础，一个产品80%还是它的服务，即构的服务是有后台管理系统做支撑，不会出现用了我们的SDK之后出问题没人管、打电话咨询也说不清的情况发生。

1.用户推流质量监控

我们能够让你清楚的看到每路流的码率、帧率、每一毫秒是怎么样的，到底是什么地方出了问题：流推到哪个服务器去了，CDN是什么地方出现问题等等。

这张图是用户推流质量的监控，这里可以看到语音视频的码率、帧率，更细致一点的还可以看到采样点、三秒钟的时长、整体码率以及语音和视频分别的码率，还有推流的连麦支持和CDN。

2.APP管理&秒级原始数据

此外所有的APP我们都可以看到它具体的Feature配置、上线的流程、柔性可用、测试节点，一旦出现问题，我们可以快速的反应。

我们获取到所有原始数据，而且是秒级的，包括质量数据（RTT和丢包率）和带宽数据，比如进来的媒体流的码率和出去的媒体流的码率。同时我们可以做到开发完成之后，当天动态部署上线服务器，保证对用户资源需求变化快速做出反应。

3.监控告警系统

做运维的朋友，最痛苦的事情就是即使在睡觉的时候都要盯着手机，万一老板打电话就得马上处理。我们的监控告警系统可以准确告诉你什么地方出问题了，让你快速解决。举个例子，观众开播首帧延时率，域值大概是50毫秒，这里最新值一般是十几、二十几，我们的监控告警系统还能监测出一些更详细数据：延迟率、发生延时的时间、第几次发生延迟，我们可以通过这些数据告诉客户哪个主播慢了，什么时候慢了，慢了多少等等。

4.深度技术服务能力

最后做下总结，我们以这个强大便捷的后台系统作为基础，技术就不再是黑盒子，服务才是真正的我们要传达的东西，我们通过服务让客户能够清楚地看到后台的细节，在这个基础上我再强调两点：第一个我们全部是人工服务，当然现在大家都是这么说的，但提供人工服务的是非技术背景的客服妹子，我们这边接电话的不是客服妹子，你听到的很可能是一个很厚重的男人声音，他是我们的后台工程师、核心的研发人员，直接为您服务解决问题。第二个就是我们不只是会跟客户讨论方案，还可以讨论在技术过程中遇到的一些难题，这些有可能是你搞不定的问题，我们可以跟你一起去探讨怎么解决、怎么提高、怎么把现有的系统跟我们的结合在一起达到最优。