直播平台多人连麦技术介绍

前言
随着直播行业的发展&＃xff0c;平台玩法越来越多。其中秀场连麦直播玩法人气较高&＃xff0c;一方面改变了主播与观众对立的体验&＃xff0c;另一方面拉近了主播与观众的距离&＃xff0c;对于拉动主播收入平台营收起到了十分重要的作用。在此衍生出来的如PK&＃xff0c;付费问答&＃xff0c;语音连麦等玩法成为各大直播平台的标配。

本篇文章将分享直播移动端直播连麦的技术实现架构&＃xff0c;仅为抛砖引玉&＃xff0c;为各位在技术选型时提供一定的思路。欢迎交流。

技术架构
传统直播形式如图所示&＃xff0c;是一个主播推流&＃xff0c;广播给直播间所有的观众。而所有的观众进入直播间时&＃xff0c;去拉去当前直播间主播的流。这里的特征是&＃xff0c;一个直播间对应一个主播&＃xff0c;并且仅有一路推拉流。

连麦的直播形式如图所示&＃xff0c;是两个主播&＃xff08;另一个主播可能是观众&＃xff09;推流&＃xff0c;广播给直播间所有观众。从技术架构的角度来说&＃xff0c;直播连麦的实现方案大体可以分为三种。

1. 基于RTMP协议优化方案

此方案是在原有直播基础上衍生出来的实现方案。主播A和主播B之间通过原有的推拉流路径去拉取对方的流内容。也就是说&＃xff0c;主播A在推流同时&＃xff0c;拉取主播B的流&＃xff0c;主播B推流的同时拉取主播A的流。对于两个主播来说互为对方的观众。此时对于直播间内的其他观众而言&＃xff0c;是分别拉取主播A和主播B的流&＃xff0c;并展示出来。

可以看出&＃xff0c;主播A和主播B之间并无直接连接&＃xff0c;而是通过拉取对方流来实现连麦。此方案优点是技术实现相对简单&＃xff0c;服务端和客户端可在原有的直播基础上开发&＃xff0c;兼容性好。但是缺点也是明显的&＃xff1a;理想情况RTMP下的直播延迟大概需要3秒&＃xff0c;主播AB之间的互动可能超过6秒&＃xff0c;这在实际连麦体验中是相当差的&＃xff0c;另外观众需要同时拉取两路流&＃xff0c;对于网络要求&＃xff0c;流量消耗&＃xff0c;性能消耗&＃xff0c;时间对齐都是不小的问题。有人提出优化CDN连接方式&＃xff0c;优化主播间的节点&＃xff0c;增加BGP&＃xff0c;在一定程度上可以降低延迟。

在方案1的基础上&＃xff0c;我们可以总结出连麦的技术关键点&＃xff1a;连麦的主播之间如何保证较低的延迟&＃xff0c;提高实时性&＃xff1b;主播之间的画面如何进行对齐&＃xff0c;合成再统一广播给观众。 在此之上我们需要准备的是两套系统&＃xff1a;多人视频交互系统和标准CDN直播系统。

2. 基于P2P协议方案

此方案的实现方式是&＃xff0c;主播A和主播B之间通过P2P协议进行音视频连接&＃xff0c;正常情况下能够保证较低的延迟&＃xff0c;保证主播A和主播B之间的互动。主播A在自己的流内容基础上加入主播B的流内容&＃xff0c;统一推向服务端。此时直播间内仅有一路流&＃xff0c;并且其他观众也只需要拉取这一路流内容。

此方案的优点是显而易见的&＃xff0c;主播AB之间的延迟降低&＃xff0c;交互体验好&＃xff0c;观众保持原有逻辑不变&＃xff0c;拉取直播间固定流地址。 但是缺点是&＃xff1a;主播A在连麦过程中需要承担两路推流一路拉流的压力&＃xff0c;即拉取主播B的流内容&＃xff0c;将自己的流内容推给主播B&＃xff0c;将主播A和主播B的流内容推给服务端&＃xff1b;主播A的网速压力和性能压力将会巨大&＃xff0c;同时主播AB之间一对一的连接也导致扩展性较差&＃xff0c;无法满足2人以上的业务场景需求。

3. 基于多人视频通话系统方案

此方案的实现方式是将主播A和主播B的视频交互交由第三方处理&＃xff0c;目前比较成熟的技术有视频会议系统和Google开源的WebRTC系统。在此架构下&＃xff0c;主播A与主播B的流合成处理上传都是由这个交互系统完成。此方案对于方案2来说减轻了主播端的压力&＃xff0c;并且采用UDP协议传输方式降低延迟。同时也兼容多人连接交互。 此方案缺点是对服务端开发量大&＃xff0c;要求高。

总结
目前主流实现方案多是基于方案3实现。同时有人提出SD-RTN的实现方案&＃xff0c;在我看来此方案是方案3的优化升级版本&＃xff0c;采用此方案确实能够降低开发量&＃xff0c;但同时也需要付出运营成本&＃xff0c;收费与开源选择哪一个还是要看具体的业务场景具体例子具体分析。

多人连麦技术还有许多需要改善的地方。随着技术的发展&＃xff0c;未来会出现更优的实现方式&＃xff0c;我们拭目以待。