移动直播连麦实现思路：整体篇

导语：本文专为介绍移动直播连麦实现架构和思路而写，介绍了移动直播连麦的整体情况、各种实现架构和优劣比较等，包括连麦介绍、角色定义、连麦特点要求，合成思路介绍、各种合成方式比较等几个小节。

移动直播连麦是主播在直播期间，与一位或多位粉丝进行实时音视频互动，同时其他观众能观看到该互动过程。移动直播连麦功能的推出让直播的传播方式由文字互动转变成媒体互动模式，主播和观众的身份也转换为发起者和参与者，相比传统的单向直播，观众能更直接地参与，满足与主播音视频实时互动，对提升移动直播应用的活跃度和粘性都有明显作用，故连麦已成为移动直播的必备功能。

连麦简述

了解移动直播连麦实现架构，需要定义以下参与角色，首先介绍客户端（如图1），按用户在连麦直播中的角色差异分别定义为A端（A主播）、B端（B主播）、C端（用户）。

移动直播连麦客户端角色定义

图1 移动直播连麦客户端角色定义

A端，指当前正在直播的主播，相当于主持人，可以主动邀请用户连麦或批准当前观众的连麦请求，也可以关闭某个B主播的连麦；A端视频一般都是全屏显示，A端直播主播（以下简称A主播）一般都要经过平台授权，具有直播权限。

B端，指参与当前连麦的观众，可以向A主播申请连麦，或接受A主播的连麦邀请，进行音视频连麦，当不想连麦后，B端可以主动断开；B端的视频一般只在右侧的某个区域显示，视频尺寸较小，以不影响A主播视频显示为好。B端用户在经过平台授权方面一般不做要求，其合规性要求由A主播代管，由于其也参与了直播，我们称其为B主播。同时，受移动直播视频显示区域的限制，最多可以支持3个B主播同时连麦。

C端，是移动直播的观众，从用户操作角度说，并没有太大差异；数量上C端用户没有数量限制，故使用从1到n标示。

总结，A主播在直播时仅有1个，而B主播则可以有多个；A主播一旦停止直播，则整个直播也就随之结束了；而B主播可以随时断开或切换，即行为具有非常大的随意性，这也是A主播和B主播在移动直播连麦中最显见的差异。

下面介绍下移动直播视频云平台的结构，为简化模型不考虑数据存储及各类型服务器集群的情况，仅描述移动直播连麦所需要的最简单服务器类型，如图2所示。

图2 移动直播连麦服务器角色定义

ControlServer，控制服务器，用于控制和授权，如判断A主播是否有直播权限，保存各项音视频参数配置，提供服务器接入查询等，还可以实现UpServer服务器的负载均衡和故障转移等管理功能。

UpServer，直播主播上传媒体数据服务器，主要包括两个功能，一是负责A主播、B主播之间媒体数据的交互，二是按指定协议把媒体数据转发给DeliveryServer。至于音视频合成等扩展功能，取决于实现合成的模式选择，将在后续小节中进行说明。

DeliveryServer，媒体数据分发服务器，接收UpServer服务器发送过来的媒体数据，并分发给直播观众；由于观众数量庞大，一般都需要使用集群实现，通用方式是使用各大CDN的视频云平台分发媒体数据，需要考虑跨网、就近、网络速度、带宽等指标。

下面介绍其特点，与主播的直播相比，连麦实现的技术难点增大很多，具体如下：

低延迟互动，要保证A主播和B主播之间能够实时音视频互动，两者之间好比电话沟通，能在秒级以内听到对方的声音、看到对方的视频；否则连麦后延迟过大，将导致互动体验很差。

音视频实时合成，其他观众需要实时收听连麦声音和观看视频，对音视频的实时合成要求也很高，不能让合成的算法复杂增加耗时，从而影响观众听、看的体验。

音画同步，移动直播连麦后对音画同步的要求与单向直播中差异较大，不仅要求A主播自身的音画同步，也要求A主播和每个B主播都要音画同步，对音视频的合成要求是高效和及时，对网络延迟的精度控制也有比较高的要求。

合成思路

参与移动直播连麦的架构中共涉及4个角色，分别是A主播、B主播、C用户和服务器，理论上来说，这4个角色都可以负责音频视频的合成，即实现连麦的合成功能，从而确保每个C用户看到连麦后的视频和听到音频（注：负责合成的服务器类型仅限UpServer，而不包括其他类型的服务器）。

下面分别对这4个角色实现的思路进行初步介绍和比较。本节将介绍B主播合成和C用户合成两种思路。后续两节分别描述使用服务器（UpServer）合成和A主播合成，个人认为这两种实现思路更具有优势。

B主播合成

从参与角色上来说，使用B主播合成音频视频是可行的，可是为什么说该思路不靠谱呢，具体有以下3点。

不唯一，从角色介绍中可知最多有3个B主播参与到连麦中，故选择一个最佳的B主播存在一定困难。如果选择了B1主播，之后发现B3主播合成更有优势，是否切换呢？不切换则用户的连麦体验效果会差一点，而切换则导致连麦的过程中出现卡顿。相比之下，由A主播负责合成不存在不唯一的问题。
参与随机性，任意B主播可以随时开始或停止连麦。当多个B主播参与连麦时，根据性能最优选中B2负责合成，但B2掉线或主动停止连麦了，则是切换到A主播或是其他B主播，还是等待B2主播再开始连麦呢？无论如何处理，都会造成一些卡顿。而使用A主播负责合成，则不存在该问题，能够完全实现B主播连麦和断开的自由切换；更近一步，如果A主播掉线则整个直播都将停止。
手机性能和网络性能无法保证，B主播一般都是由粉丝转化而来，其直播手机和网络性能，是否符合直播要求无法在短时间内验证。从使用资源说，参与直播且进行音视频的合成将比个人直播消耗更多，故使用B主播合成性能方面存在较大风险。相应的使用A主播合成则性能风险较小，原因是A主播都是经过平台授权和验证，且通过了较长直播时间考验，对于直播手机和网络的掌控可靠得多。

基于以上三方面的分析，排除了使用B主播负责整体直播连麦音视频合成的工作。但B主播仍然要负责其本地的音视频合成，目的是供B主播自己观看视频和收听其他主播的声音。

C用户合成

由C端用户负责合成音视频，需要A主播、B主播把所有媒体数据，通过服务器发送给C端的用户，具体结构图如图3所示，图中为区分A主播、B主播的媒体数据流，在服务器之间传递时使用独立的两条线进行标示。

图3 移动直播连麦C端合成结构图

该实现思路有两个特点：一是C端用户需要兼容能力好的播放器，要支持A主播、多个B主播的音视频解码，时间戳同步，视频同步绘制和声音播放等。二是A主播、B主播之间的媒体数据也要通过UpServer服务器进行分发，为了各自的音视频呈现，A主播、B主播也要执行相应的合成工作。为简化结构图，A、B主播之间的媒体数据分发未在图3中绘制。

由C端用户侧负责合成，比使用B主播合成还更靠谱一点，但也存在一些显而易见的问题。

成本高，该模式需要的成本高主要体现在服务器带宽消耗上，A主播、B主播（多个）音视频数据流都要推送到每个用户手机上，比仅推送合成后的数据流，为每个用户要增加约40%以上网络带宽。如用户量较少则成本增加不明显，若观看用户非常多，相对于仅推送一路数据流，成本大幅度攀升了，毕竟服务器带宽是公司需要掏真金白银的。
播放器实现复杂度高，C端需要接收多路音视频数据流，并在多路数据流播放时做到音视频同步，且网络抖动的控制、播放的时间戳同步、音频视频合成的复杂度都会明显提高。在控制层面，B主播的任意切换也将需要C端播放器实时调整，故对播放器的开发维护要求很高。
互动效果差，当使用多路数据流推送给C端用户时，由于网络延迟、丢包等不稳定因素，可能造成A、B主播媒体数据到达时间差异大，此时合成很可能导致用户观看A、B主播视频之间有较大延迟，即A、B主播之间没有构成同一个舞台的效果，失去了互动性。若采用A端合成或UpServer合成，A、B主播的媒体数据是同时到达C用户端的，具有比较好的互动性。
主播端实现不简单，当C用户负责合成时，A主播和B主播不再负责整体的音频、视频合成，但仍然要负责本地的音视频合成，供自己使用，否则自己无法观看视频和收听声音。本地的合成任务大部分可以和整体合成任务重复，此时就不能复用了。

总结，基于以上原因分析故也不建议选择C端合成媒体的思路实现移动直播连麦。

UpServer合成

Server端合成与C端合成的结构略有不同，结构如图4所示，其媒体流的合成功能由UpServer服务器实现，具体的工作流程介绍如下。

图4 移动直播连麦Server端合成结构图

A主播和B主播都要把自己采集到的音频、视频数据，在编码打包后发给UpServer服务器。
UpServer执行合成功能，把合成好的音视频数据流推送给DeliveryServer，并由该服务器分发给众多的移动直播观众。
为满足A主播收看其他主播视频、收听其他主播音频的需要，UpServer还需要进行特殊处理，把未合成的视频，合成好的音频发送给A主播。
类似的，为满足B主播收看其他主播视频、收听其他主播音频的需要，UpServer也需要进行相应的特殊处理。
为简化该实现思路结构图，针对第3步、第4步的特殊处理数据流并未在图4中画出。
UpServer给A主播或是B主播特殊处理的方式差异，造成推送的数据流是不同的；此时A主播或是B主播需要完成的功能也是不尽相同的，关于该部分的处理细节，将在后续的文章中详尽描述。

说完由UpServer端合成的基本工作流程，下面介绍下该思路的优缺点。

及时性最高，由UpServer负责合成A主播和B主播的媒体数据，音视频数据经历的网络延迟最小，UpServer合成后直接发送给移动视频直播云平台，网络带宽和丢包方面也不必担心，毕竟服务器的网络质量还是放心的。
音画同步好，在主播接入的第一级服务器UpServer上进行媒体数据合成，由于媒体数据接收不完整或网络抖动延迟增大，造成音画不同步的可能性大幅降低了；相比其他模式，多个主播的音画同步得到良好的保证。
服务器资源消耗高，与其他思路相比，服务器除了必须的媒体数据传输和缓存功能外，还增加了音视频的合成工作，顺序上首先要把主播编码后的媒体数据解码，接着再根据配置方案进行合成，最后再次进行编码和打包。众所周知，视频编码消耗CPU资源还是很厉害的，即使是高性能服务器硬件，与不执行合成任务相比，其处理的移动直播上传数量会明显下降。
服务器复杂度高，服务器实现复杂度高包括两个方面：一是解码、合成、编码需要大幅增加服务器的复杂度，如果使用很好的模块化设计，且每个模块都非常稳定，则这块影响不大。二是A、B主播，与普通观众所需要的数据流是不尽相同的，为满足每个终端都可以正常观看视频和收听音频都需要特殊处理，且音频和视频的处理逻辑可能完全不同，需要梳理流程和详尽设计。
质量下降，视频、音频的编码算法为了保证高压缩率，它们都采用了有损压缩的编码方式。由UpServer负责音视频合成任务，合成后需要再次编码，如果选择视频质量非常高的视码参数，虽说质量降低很小，但码率升高以致得不偿失，如果与主播端使用的相同的编码参数，则会造成音视频质量下降。

总结，该思路完成连麦功能是完全可以实现的，但也存在一些争议，如服务器硬件资源和服务器程序编码质量要求高，故需要具有相当开发经验的服务器工程师进行开发。后期UpServer服务器的维护也同样重要，务必实时监控服务器资源占用情况，如消耗资源达到瓶颈，用户端观看时会卡得很厉害，体验差，需高度重视。

A主播合成

该实现思路要求A主播分别把自己的音频、视频数据与B主播的数据合成，然后把合成好的媒体流发给服务器，并由服务器集群广播给所有用户。故A主播手机负担的任务更重，对手机性能和网络性能要求也比普通直播时更高一些。A主播合成实现结构如图5所示，下面描述下该实现方式的一些基本流程。

A、B主播通过UpServer服务器建立媒体数据传输通道，使每个主播都可以获得其他主播的媒体数据。
B1主播拿到A主播和其他B主播的视频、音频，也要做相应的合成工作，用于自己的视频显示和声音播放。
A主播拿到所有B主播的媒体数据后，也进行合成，一方面用于自己的显示和播放，另一方面要发给UpServer服务器，用于C端用户观看。
UpServer服务器要负责两方面内容，一是A、B主播之间的媒体数据分发，二是把A主播合成好的数据发送给DeliveryServer服务器。

图5 移动直播连麦A端合成结构图

为简化图5的结构图，A、B主播之间的媒体数据传输，仅绘制了B主播到A主播的一条线路，以表示数据是由A主播负责合成的；实际上它们之间的数据传递如上面的流程描述所说，仍然是通过UpServer服务器双向传输的。

基于上面的流程，总结下该实现方式的优劣。

低成本，与使用Server端合成相比，由于UpServer端不用视频、音频的重新解码、编码工作，也不需要执行合成任务，可以极大降低该服务器的CPU消耗；即把媒体合成资源从占用服务器转换为占用主播手机了，该方式也符合互联网分布式计算的特点。由服务器负责合成音视频，使用高性能服务器硬件若可以支持50个移动直播连麦，则在相同硬件条件下，不使用服务器端合成至少可以支持200个以上。

与使用C端用户侧合成相比，媒体数据的视频云分发网络仅需要推送一路数据流，当用户量很大时可以显著降低带宽成本。互动效果不错，A主播和B主播之间的沟通仅需要跨越UpServer服务器，类似电话的直接沟通，网络延迟和视频质量可以控制的很好，互动效果满意。A主播合成后通过视频云平台分发给观看用户，A、B主播之间的音画同步问题得到很好的解决，不会向使用多个数据流发送时，用户侧出现的多个主播之间音画不同步现象。

音视频质量，相对于UpServer端合成导致的二次编码损失，A主播的音视频在采集后先进行合成，后进行编码，故A主播的音视频没有二次编码造成质量损失的问题。在该实现思路下，B主播的音视频质量损失与UpServer合成相同，考虑到视频显示上以A主播为主，故影响不大。

缺点也有两条，一是对A主播的手机性能、网络性能要求更高一点，毕竟执行的任务增加了；考虑到即使不进行整体的合成工作，为满足本地观看和收听需要，也要执行相关的合成工作，故增加的任务量并不太多，整体在可控范围内。

二是与Server端合成相比要耽搁一些时间，增加一次A主播到UpServer服务器之间的往返网络时延（RTT），但也仅限B主播音视频增加该时延，A主播的音视频是在合成后编码打包直接发送的，故不增加该网络时延。

总结，使用A主播进行连麦的音频视频合成还是非常有价值的，既可以保证A、B主播之间的及时互动，也可以降低UpServer资源消耗，是我推荐的一种实现方式。

后记

这篇文字是移动直播连麦实现思路的整体介绍，主要包括音频视频合成的几种实现思路：A主播合成、B主播合成、C用户端合成和Server端合成媒体数据，比较了它们之间的一些优劣等。基于比较结果，笔者反对使用B主播合成和C用户端合成两种实现方式，赞同A主播合成或是Server端负责媒体数据流的合成。

至于是使用A主播合成，还是Server端负责合成，个人理解是看公司的运营成本，如果公司、为该功能实现投入不计成本，那么建议选择由Server端合成媒体数据；如果公司精打细算、依靠低成本高技术手段推进业务，那么建议选择A主播合成模式。

后续将分别介绍A主播合成、UpServer合成音视频数据流的实现细节。