盘点目前常见的几种直播连麦方案

在前文《到处都在说直播连麦技术，它们真的能连吗？》中，我们以CDN架构的特点为切入点，比较了各种基于CDN方案而延伸出的“直播连麦方案”和一种新的基于UDP的方案，总共介绍了以下四种“连麦方案”：

• 多路RTMP流实现

• 主播端与连麦者P2P

• 服务器端合图

• 基于SD-RTN的解决方案

半年过去了，各大CDN都纷纷上了直播连麦的功能。我们这次就将现在已经商用的“连麦方案”做一个盘点，以此为基础寻找更大的技术变革，再次推动一次直播热潮！

连麦场景的应用

连麦技术经过1年的发展，已经成为直播平台的标配。并且已经在一些垂直场景有了具体应用。

• 最常见的，秀场直播，多主播连线

• 在线教育中，直播大课，学生可以举手与老师连麦互动提问。

• 手游狼人杀，玩家以连麦的方式进行游戏，整场游戏可以直播。

连麦不但成为丰富应用场景、活跃用户的手段，更是成为了很多平台变现的手段。比如，在秀场直播中，观众只有达到了一定的等级，才有与主播连麦的权限。在手游狼人杀中，连麦直播成为吸引铁杆玩家，开展直播创造现金流的必备技术。

目前已有连麦方案&架构

目前，有很多连麦方案。虽然从功能上来说是类似的，但是由于其背后的架构及技术的不同，最终会造成体验、质量上有很大差异。接下来就总结一下，目前已有的连麦方案的技术架构。

架构一：RTMP改进

RTMP改进，就是在原有CDN分发的直播系统上，针对延迟问题，进行服务器架构的改进，尽可能的减小延迟，达到互动的目的。

架构上来说，可以实现如下：

首先，主播和嘉宾，分别就近接入CDN的边缘节点；

这时，为了减小由于主播和连麦嘉宾由于地域、运营商等不同造成的延迟增大的问题，使主播和嘉宾接入边缘节点，接入BGP三线机房，进行音视频数据的转发。这样，可以很好的解决连麦延迟过大问题，主播就可以和嘉宾较好的进行交互；

最后，观众端需要看到主播和嘉宾连麦的视频，目前有两种方案比较成熟：

1. 主播接收嘉宾的视频，并在本地进行重新编码，将合成的图像，再次推送到CDN边缘节点，CDN将此视频转发给观众端；

2. 增加转码服务器，将主播和嘉宾的视频，在服务端进行解码、编码，然后将合成的音视频流发送给观众端；

优点：

1. 在原RTMP基础上进行优化，比较稳定，解决了一部分原连麦上的延时问题；

2. 架构较成熟，实现较简单；

缺点：

1. 在原RTMP基础上进行优化，比较稳定，解决了一部分原连麦上的延时问题；

2. 架构较成熟，实现较简单；

架构二：视频会议服务器

视频会议系统，在90年代就已经比较普遍，随着软硬件技术的发展，到现在已经非常普遍。由于视频会议系统一般需要依赖专线、特殊硬件设备等，所以有比较好的效果。

那么在视频会议系统的基础之上，来进行连麦也是可以的，因为对于会议来说，一般要求实时性比较高，这样对于直播连麦来说，也是满足要求的。

针对这种场景来说，比较常见的架构如下：

其中，关于合图，在这个架构中主要分为两种情况：

1. 视频会议服务器合图，即在视频会议服务器上，进行合图后推到CDN上做分发，但是很多视频会议系统，服务器并不直接接收用户音视频数据，所以一般更多使用第2种方式；

2. 主播端合图，即主播端将各个连麦端的视频，合成一路视频，推到CDN上去分发；

优点：

1. 使用已有系统，快速解决连麦问题，连麦上延时问题解决较好；

2. 方案成熟，实现上线快；

缺点：

1. 会议系统很大程度上依赖专线服务，成本过高；

2. 会议系统很多不能在服务器做转码合成视频，对主播设备依赖过大。因为合图视频主要是由主播端编码、推送到CDN，一部分需要主播设备比较高端，另外需要主播网络比较好，否则依然解决不了连麦问题；

架构三：WebRTC改进

WebRTC是Google的一个开源项目，是一个支持网页浏览器进行实时语音对话或视频对话的技术，并且WebRTC提供了视频会议的核心技术，包括音视频的采集、编解码、网络传输、显示等功能，这样开发者就可以很方便的基于这个项目开发音视频通信应用。

所以，很多在WebRTC的基础上，进行二次开发。这样，上面的基于软件、硬件的视频会议服务器，就可以变成一个基于纯软件的视频会议系统。

所以基于WebRTC改进的整体架构，与上面视频会议服务器架构基本类似，区别点在于视频会议服务器，在这里是WebRTC服务器，架构如下：

优点：

1. 方案是开源的，可以自己进行定制化；

2. 可以较好的解决连麦问题，并且可以自己部署服务；

缺点：

1. 目前WebRTC主要是一个比较全面的方案，但是很难解决一些比较高深度的问题；

2. 代码量非常大，开发部署上线比较慢，并且问题较难解决；

3. 做到与直播无缝对接，比较困难；

架构四：SD-RTN™

SD-RTN™(Software Defined Real-time Network)，是专为实时传输设计的虚拟通信网络，对于直播这种要求低延时，强互动的情况来说，是最佳解决方案。这是声网Agora.io的专利方案（读者自行判断，非软文）。

对于连麦来说，SD-RTN™可以满足各种需求的环境，相对来说架构更加轻量且易于扩展，用户体验也更好一些。

优点：

1. 底层使用UDP协议实现，延时可控；

2. 支持平台、协议多，用户使用方便简单；

缺点

1. SD-RTN是新概念，架构新颖；

2. 对接CDN时，有一定开发量；

连麦方案的基本点

说了这么多目前直播连麦相关的方案和架构，是不是对直播连麦有了一定的了解？那么针对直播连麦这种场景，如何去考察、评估、并制定相应的测试方案来选择供应商？

下面提供一些考察的基本点，供大家参考。

直播相关的评估点

首先，先说一下直播的考察基本点，这里先不涉及到连麦，但从直播来说，需要具备哪些功能点，才能做到一个比较高的水平。

 1. 音质、画质

音质和画质不但是直播中的首要元素，在其他音视频场景中，也是首要元素。正是因为用户对于音质和画质的强烈需求，才会推动着音视频的发展。例如说不断提高的视频分辨率，用户对立体声的强烈需求等等，都是这方面的需求点。

音频的质量主要体现方面有：电流声消除、回声消除、降噪、变声、立体声等等方面。

视频的质量主要体现方面有：分辨率、帧率、码率、卡顿率、美颜等等方面。

 2. 美颜、贴纸、表情

直播中，主要是用户的体验为主，一些个性化的美颜、贴纸、表情等，都让直播变得趣味十足，也可以吸引较多的用户，有更多的玩法。美颜、贴纸等，可能会由于GPU、CPU占用问题导致发热、耗电量升高，这是要值得注意的。

 3. 秒开

直播中秒开，即首帧时间，也是考量的一个重要因素。秒开就是说从用户去请求音视频开始，到收到第一帧音视频数据展示出来的时间，达到一个较低的水平，也就是说首帧时间越小，给用户带来的体验也越好。

 4. 与CDN融合

另外一个主要的方面，是与CDN的融合。直播的各个方面，都需要CDN的参与：转发、录制、存储、点播、截图等等方面，都需要CDN的参与，才能给用户更好的体验。

连麦独有的评估点

然后，我们再来分析一下连麦中，一些独有的考察基本点。

 1. 低延时

连麦中，最重要的元素，就是低延时。只有低延时，主播和连麦嘉宾之间，才可以较好的互动、交流。根据ITU-TG.114标准，单向通话延时大于150ms就可受到通话连续性受到影响，最大可容忍时延为400ms。

 2. 音画同步

由于音频和视频不同采集、传输处理，会有很大程度上存在音画不同步的问题出现，这是一个比较严重的问题，观众端看到主播的动作，在听到声音；或者先听到声音，才看到动作，或者说话口型对不上，会感到很奇怪。

 3. 回声消除

回声是一个很有意思的问题，经常容易发生在连麦过程中，刚开始时，会听到同样的话说两边，然后频率不断加快，最后会变成严重的蜂鸣声，就是一个严重的问题了，所以回声消除也是一个必须要解决的问题。

 4. 信令，申请/邀请连麦的成功率

信令，是一个很庞大的系统，在很多场景下可以使用，例如说电信中，用户发起呼叫，到对方响铃，可以用信令。它是区分与音视频这种用于数据传输的另外一套网络，主要用于传输控制信息、用户信息等。所以无论是直播，还是其他业务中，都会用到信令系统。例如说直播中，用户发起申请/邀请连麦请求，可以通过信令；用户购买礼物，送礼物，可以通过信令；用户发送弹幕，送鲜花，点赞，也可以通过信令。在直播场景下，也是不可缺少的一部分。

 5. 延展性

另外直播还需要更好的延展性，行业在不断的发生变化，需要快速的去应对发展潮流，引入更多的用户。所以需要一个延展性、扩展性更好的系统，快速应对这些场景。

 6. 其他

还有很多很多细节上的场景，例如说大频道、用户自定义绘制、卡顿检测与优化等等，都是直播中不可缺少的部分，这里就不一一列举了。

原文来自:聊聊架构

声明：所有来源为“聚合数据”的内容信息，未经本网许可，不得转载！如对内容有异议或投诉，请与我们联系。邮箱：marketing@think-land.com