语音视频社交背后技术深度解析

伴随智能硬件设备快速发展和网络条件提升，实时语音视频的应用越来越广泛，从互动直播、到休闲游戏、再到陌生人社交，而如何保障实时互动过程流畅不卡顿、如何消除回声以及全球网络节点部署调度成为了关键。即构科技联合创始人蒋宁波在LiveVideoStack Meet上以语音视频社交为例，深度解析实时语音视频互动技术，本文为分享的整理。

大家好，我是即构科技的联合创始人蒋宁波，今天分享的题目《实时语音视频技术的深度解析》，希望和大家交流实时音视频互动的一些技术点。首先简单自我介绍下，我从2005年到2015年在腾讯工作，前期负责QQ Hummer部分重构项目，后期负责腾讯QQ安全的工作，包括把QQ的安全能力开放给其他企业使用。2015年联合创立即构科技，即构科技是提供实时音视频的云服务商，致力于提供全球最稳定最高质量的实时语音视频云服务，主要产品针对多人实时语音，多人实时视频，和互动直播。现有的客户包括映客、花椒、一直播，喜马拉雅FM，六间房、酷狗直播、自由之战2和好未来等。

今天主要分四块内容跟大家一起交流，首先是通过两年大量实时音视频客户的合作，看到了行业应用的一些发展趋势，其次就是实时音视频互动的技术难点，以及即构科技解决这些问题的思路，最后会分享如何选择实时语音视频云服务商。

行业趋势

近几年，伴随手机等智能硬件设备以及网络情况的提升，实时音视频得到越来越广泛的应用，在娱乐化方面，从互动直播，到集成音视频SDK、带有社交属性的休闲小游戏，再到现在音视频的陌生人社交应用。从15年下半年到16年的千播大战，基本上,一二线的直播平台都标配了连麦直播，允许多个主播做实时互动；16年底到17年初，集成了音视频的社交属性的休闲小游戏异军突起，最典型的就是狼人杀，还有一些棋牌类游戏；现在最火爆的则是陌生人视频社交应用，像多人群聊社交产品Houseparty和青少年社交网络Monkey等等，而且伴随美颜、挂件这些图像处理技术越来越成熟，更多的90后、00后等一批互联网原住民将视频社交融入到日常生活中。

实时音视频互动难点

对于一个实时互动的音视频系统而言，存在很多技术难点，我从中摘取几个比较重要的点：首先是低延迟，如果要满足比较流畅地进行实时互动，那么单向的端到端的迟延大概要在400毫秒以下才能保证流畅沟通；第二点就是流畅性，你也很难想象在视频过程中频繁卡顿会有良好的互动；第三点是回声消除，回声的产生是扬声器播放的声音经过环境反射被麦克风重新采集并传输给对方，这样对方就会一直听到自己的回声，整个互动过程会非常难受；第四点是国内外互通，随着现在国内同质化产品越来越多，国内的竞争也异常激烈，很多厂商纷纷选择出海，这时就需要做好海内外的互通；第五点是海量并发，当然这不仅仅指实时音视频了，基本对于任何一款互联网产品而言都是必须要考虑的难点。

难点解决方案

接下来我将针对上面几个技术难点，跟大家分享一下我们即构团队的解决思路和实践经验。

低延迟

首先，如果实时音视频要保证低延迟，那么前端和后端的整个链条一定要做到极致的，比如前端的一些编码算法、流控，甚至丢帧、追帧策略等等都要做到足够好。另外，不同的业务场景下，编码器的选择也会有所区别，从而会带来不同的编码延迟，因此不同的业务场景能达到的延迟程度也是不一样的。

其次，就是对推拉流网络的选择，通常的方案是让需要实时互动的用户通过核心语音视频网络——像BGP这样的优质节点来做语音视频传输，而对于一些特定场景来说，比如互动游戏会直播给一些围观用户看，那么这里就需要做转码、转协议、甚至混流，再通过内容分发网络去分发。像 内容分发网络本身天然就有做就近接入，但对于接入核心语音视频网络就需要有智能的调度策略来完成就近接入，以及跨运营商、跨区域的接入，比如可以采用上次登录IP、常用IP和区域调度，甚至可以测速再去连接，当然网络调度的策略也需要根据业务群的分布仔细规划，甚至采用多个策略配置权重的方式。

流畅性

要实现流畅性也会有很多的技术难点和策略，我主要会介绍其中几种。第一个是可以做动态伸缩的JitterBuffer，在网络较差或者网络抖动比较剧烈的情况下，可以适当增大JitterBuffer，从而降低一点点延迟来对抗抖动。

第二个是快播和慢播技术，在网络较差的环境，可以在用户无感知的条件下稍微降低播放速度，来应对短暂网络抖动引起的立即卡顿，当网络恢复可以加快速度追回来，但这种方式并非适合所有场景，比如对于节奏要求非常准确的唱歌场景，当播放速度稍微放慢就可以被感知。

第三个是码率自适应，也就是以比较合适的码率做动态传输，为了保证流畅度甚至可以调整帧率和分辨率。语音视频引擎会根据当前网络测速的结果和应用所期望的码率，动态地调整码率、帧率和分辨率，最终达到流畅观看的用户体验。

第四个是分层编码、传输控制，在推流端做一些分层的编码，这样在拉流端可以动态根据侦测到的网络带宽情况来拉取不同的数据去做渲染。分层编码允许拉流端取选择不同层次的视频编码数据，网络情况好的时候，就拉取较多层次的数据；网络情况差的情况下，就拉取基础层次的数据。

第五个是动态调度，当在推拉流端监测当前推拉流质量比较差，而且即使通过降低码率、帧率和分辨率等策略已经无法保证质量，这时就可以选择放弃这条链路，直接重新做选入、建立连接，当然在这个过程中可能会出现短暂的停顿。

回声消除

首先介绍下回声消除的原理：对端发送的信号会先给到回声消除的模块，作为将来消除的参考信号，再把信号给到扬声器播放，扬声器播放后由于周围环境反射形成回声，与真实的音频输入一同被麦克风采集，这时采集到的输入信号是带有回声的，回声消除模块会根据前面的参考信号生成滤波抵消掉回声消后再发送出去。

原理听起来会比较简单，但在实际过程中却蕴藏着很多的难点，比如回声消除模块接收的参考信号与最终被环境反射后的回声本身就是存在差异的，此外设备也会极大的影响回声消除，尤其是国内的安卓机型特别多，比如国内某手机厂商，从麦克风采集音频数据到提交中间有将近一百毫秒的延迟，这时回声消除算法如何适应这么长回声延迟的手机就很关键；再比如很多用户在直播中都会用外置声卡，甚至是模拟器，这无形中也会带来回声的延迟。除了设备，场地同样存在很大的相关性，对于普通会议室，设置 40米的回声延迟可能已经足够了，但一些大会场这种回声延迟能达到将近上百米，这也是一种挑战。

关于回声消除，其实谷歌开源的WebRTC提供了回声消除模块，但WebRTC的设计本身是为了在PC端实时音视频互动的场景，在移动端的适应性上就会差一些，尤其体现在安卓的一些低端机上。而相对来说，苹果因为整体硬件、软件全是自己实现的，麦克风、扬声器也都有声学模型设计，因此回声消除的效果会比安卓好很多。即构科技的音视频引擎都是采用自研，在真机和模拟器等1000多的机型上测试过，都可以做到很好的回声消除。

国内外互通

前面提到很多产品都会选择出海，包括主打国内市场的产品也会有一些海外用户，因此流媒体数据和控制信令就要做好跨国的互通，这就需要考虑在全球合理布置一些中继节点。

这张图就是一个典型的中继续传，北京用户和迪拜用户之间要做视频沟通，根据就近接入原则他们会分别连接当地的节点，而这两个节点间如果互拉，效果会非常差，这时就需要布置适合的中继节点，比如香港、新加坡、日本等等，数据路径的选择是需要根据业务侧决定的，也就是说在物理链路路由之上还要再有一条业务的路由表，需要根据用户场景制定，包括用户分布、用户访问频率、高频段峰值等等，可能每次的路由都会有所不同。

海量并发

海量并发是所有互联网产品都会遇到的问题，这里就不再展开，主要要考虑负载均衡，如何平滑扩容，对于无法覆盖的地方要做代理调度，甚至需要考虑容灾、接入层的设计等等。

如何选择实时语音视频云服务商

实时语音视频的技术门槛相对比较高，如果依靠自己研发，可能即使会投入很多开发成本也无法与匹配市场快速发展的节奏。现在实时音视频云服务已经十分成熟，其实不妨“让专业的人去做专业的事”。而对于实时语音视频云服务商的选择也大致可以归为几点：

第一点，肯定是技术过硬。测试产品质量是很好的选型方法，测试的指标包括延迟时间、回声消除的效果以及多机型兼容性等等。

第二点，是否被顶级厂商地大规模验证过。很多系统在小规模并发时看起来质量很好而且非常稳定，但在真实现网环境下一旦大规模并发上来的时候就会出现各种各样的问题。因此选择的产品必须得能在真实的复杂网络中支持大规模并发。

第三点，系统接口要足够简单、灵活，可以保证基础功能的厂商快速集成，同时也要能满足高端客户定制化能力的接入。从采集、前处理、编码、推流、拉流、解码和渲染一整套流程中每个环节都是要完全解耦的，这样就可以集成第三方、甚至客户自身的技术模块。

第四点是技术服务足够好，对需求的响应足够快，而且要有完善的运营支撑体系，能快速定位问题，因此对于监控告警、日志的上报采集就显得非常重要。

图：秒级原始数据