干货 | 奇秀直播连麦技术探索

前言

2020上半年，直播再次成为中文互联网世界的新风口，甚至到了无达人不直播，无名人不带货的地步；从2016年直播元年开始，直播的内容越来越多元，从秀场直播，游戏直播，到短视频直播普济众生，再到电商直播的“带货”，“眼球经济”成长为互联网上的主流。本文介绍爱奇艺在奇秀直播的技术探索。

奇秀直播的两种直播场景简介

第一、普通直播：有一个主播和很多观众，该场景下主播一个人表演，其他观众通过平台IM系统跟主播进行文字互动，类似于单口相声；这种场景大部分使用RTMP协议，然后通过CDN的方式去做分发，从而实现大规模高并发的数据分发。

第二、连麦直播：该模式下主播跟观众除了基于IM系统沟通外，还可以进行和其他一个，或者多个主播实时音视频互动，普通观众可以同时观看多个主播的画面，效果直观，更能有效吸引用户，类似于对口相声和群口相声。

在连麦直播有很多有价值的业务场景，比如PK场景，此时每个主播头像上面会显示一个血条，当观众给某个主播送礼时，她的血条则会增长，结束时哪方观众送的礼物多就会胜利，失败了会被惩罚，这样一来，就能让观众更多地参与到直播的过程中，而且是通过送礼物。

直播场景使用的技术介绍

在技术上，普通主播一般是基于TCP的RTMP协议来推流的，而连麦直播一般是使用基于UDP的RTP协议来推流的。由于连麦直播是基于UDP的，还需要考虑应用层的丢包重传问题。在实现复杂度上，普通主播是相对较低的，而连麦直播实现复杂度相对较高。

对于连麦直播可以使用多种技术实现，比如对RTMP改进，传统的视频会议系统，WebRTC改进等。奇秀直播采用的woogeen，一种WebRTC改进实现的,对客户端SDK和后台MCU服务器进行重新设计,专门针对直播推流，直播连麦等应用场景，整体架构如下：

主要模块及功能：

第一、客户端SDK：主要包含信令功能和将WebRTC流推送到MCU；

第二、MCU节点：socketio信令接入，WebRTC流接入，音视频转码和混流，并负责把RTMP流推送出去；

第三、MCU_DNS：为用户提供最佳MCU节点。MCU_DNS负责节点管理，包括MCU单点负载收集，MCU申请调度，黑名单机制， MCU集群上线/下线处理；

第四、MCU_API：提供业务操作API，比如HTTP信令接入，控制推流和混流等复杂操作，简化业务方的接入工作量；

第五、业务后台：负责推流所需的资源（例如，MCU房间号，RTMP地址）和收集MCU_API的反馈信息，控制整个直播和连麦的过程；

系统架构拓扑

这里介绍一下奇秀直播系统的拓扑结构，从上图可以看出，主播是把音视频流通过RTP推流到MCU服务器；在普通直播时，MCU服务器只需要把收到的音视频流转发到RTMP，当前切换到连麦直播场景时，MCU服务器会在不中断流的情况下进行合成，然后把合成流再转发到RTMP，连麦开始和结束画面实现平滑切换；

从观众端来看，都是使用HTTP-FLV/RTMP来进行拉流播放，且都是基于TCP的，并且普通和连麦场景切换时不会断流或卡顿；其次，每台MCU服务器都是一个独立的服务提供者，各台服务器可独立上线和升级，服务器之间无相互依赖，如服务器异常，只影响当前服务器，做到去中心化;

连麦问题和优化

一、WebRTC的优化

奇秀连麦基于WebRTC，但由于WebRTC一个针对面向通话的解决方案，所以需要对WebRTC进行调整和优化。

WebRTC采集的音频是8K或16K的，因为人在通话过程中信号的频率是不超过4KHz的，而直播主要是主播唱歌等一些音乐场景，所以必须要求是高采样率的，现在使用是48K的采样率。
为了延时更低，WebRTC使用10~32Kbps的低码率音频编码，这样音质很差，而音视频直播里要用到64~320Kbps的高码率的音频编码，但还要考虑设备和网络情况，现在通过界面选择编码码率，默认128Kbps的音频编码；
视频编码采用的是VP8和VP9，但VP8和VP9不适合在CDN上进行分发，现在使用的是H.264这种比较通用的视频编码；
在传输方式上，WebRTC使用P2P方式来进行媒体中转，它只是解决端到端的问题，而对于连麦直播来说，并不仅仅解决主播端的音视频互通问题，还要把主播的数据推送到连麦服务器、CDN，且要保证到达我们的观众端，所以在连麦系统上是Relay的方式，很好处理推流和混流的问题。

二、连麦问题解决

另外和普通直播相比，连麦直播还需要重点解决下面几个问题：

1、混流问题：

在连麦直播里有两个或多个主播的音视频流，首先要解决的就是进行混流。对于混流的技术，可以选择在服务器合流、多流播放和在客户端合流播放等，奇秀连麦采用的服务器合流技术，可以减少下行网络带宽和播放设备的压力等；在服务器上有一个单独服务进程处理拉流、混流、和推流，它维护所有有关的信息，外部只需要通过API和它交互，避免了上层处理这些事务。

2、推流延时问题：

试想一下，如果连麦过程中主播说一句话，对方要等三四秒才能听到，连麦的体验就会非常差，而普通直播无这个要求，这个问题从以下几个个方面进行解决：

开播前的网络优选。当主播在发起直播时会根据她所在地理位置，网络运营商以及服务器的负载等条件，然后从所有的节点里面选出一个比较好的节点和MCU服务器进行推流。
是码率动态调整。在连麦直播里，必须保障音视频的实时性，另外不花屏、不卡顿，所以在传输的过程中，采用了码率自适应策略。由于主播的网络是非常复杂，所以采用根据网络情况动态调整码率的情况，并不是实时地随着网络去变化，而是有一个快降慢升的逻辑，如果码率上调太快，则会导致网络出现一个很不稳定的状态。快降慢升的方式就是当出现丢包的时候，马上下调码率，并且只有当保持了几秒以上的稳定状态后，才允许码率上调。码率动态调整使用了WebRTC的拥塞控制算法，共有两种：

（1）、基于延迟（delay-based）的拥塞控制算法，由收端进行带宽估算，接收方需要每个数据包到达的时间和大小，并计算每个数据分组之间（inter-group）的延迟的变化，由此判断当前网络的拥塞情况，并最终输出码率估计值由RTCP feedback（TMMBR或 REMB）反馈给发送方；在估算时，利用卡尔曼滤波，对每一帧的发送时间和接收时间进行分析，修正估出的带宽。

（2）、基于丢包（loss-based）的拥塞控制算法，发端带宽控制，发送方通过从接收方周期性发来的RTCP RR（Receiver Report）中获取丢包信息以及计算RTT，进行丢包统计，并结合TMMBR或REMB中携带的码率信息算得最终的码率值，来动态的增加或减少带宽，在减少带宽时使用TFRC算法来增加平滑度。然后由媒体引擎根据码率来配置编码器，从而实现码率的自适应调整。

是性能优化。在直播过程中经常遇到设备发热的问题，设备发热会导致系统降频，以及对摄像头的采集掉帧严重。
首先，美颜和特效的功能是可开关的，如果发现性能不行，可以选择不开；其次，特效在不同的机型都有不同的展示。再者，除了个别机型不能支持音视频硬编解外，实现了音视频的硬编硬解。

3、房间管理问题：

房间管理会涉及到一些业务层面的逻辑，比如说房间的状态、房间里有多少人、大小主播之间怎么沟通，这些都需要通过房间管理来做好的。为了保持独立，在服务器上有一个单独服务进程进行房间的管理，它维护了所有的的信息。另外为了同时支持普通和连麦直播，现在为每个主播端单独创建一个房间；当连麦时，会相互拉取对方房间的流进行合成，而不是加入同一个房间。

4、回声问题：

普通直播里面回声基本上不会存在，因为它是单向的，但是在连麦里面回声是必须要解决的。一般产生回声的原因是近端的声音被自己的麦克风采集后通过网络传到远端，而远端扬声器播放出来的声音被麦克风采集后通过网络又重新发回近端，使得近端通话者能够从扬声器中听到自己的刚才说的话，产生回声。

采取回音分端进行优化：

在PC端，一般通过机架软件和兼容的声卡，配置不同的通道，比如伴奏，系统，麦克风，混响等，避免连麦声音被采集再次推流进行回音处理；
在移动端，通过动态切换混音消除进行回音消除，连麦时开启回音消除，不连麦时不进行回音消除，提高声音质量。采用的是webRTC的混音消除算法(AEC,AECM)，采用自适应滤波算法实现回声消除。该算法以输出到扬声器的音频数据为依据,根据现场的回声路径特征,模拟出回声信号。以模拟回声信号为依据,从麦克风采集到的音频数据中滤除模拟回声信号，使用的算法包括 a.回声时延估计 b.NLMS(归一化最小均方自适应算法) c.NLP（非线性滤波） d.CNG(舒适噪声产生等；

继续优化的方向

第一、是连麦服务器是允许实时切换,前文提到当主播在发起直播时，会根据她所在地理位置，网络运营商，以及服务器的负载等条件，然后从所有的节点里面选出一个比较好的节点进行主播推流网络的优选，但是如果在推流过程中发生问题，只能重新开播；如果这时主播在PK，会影响主播的榜单和成绩，所以在推流过程中发生问题可以实时切换服务器，是一个值得优化的方向。

第二，在移动开播过程中，如果发生网络切换时，在推流过程响应网络的实时切换是一个值得优化的方向。

第三，移动端现在回音消除通过webRTC的混音消除算法进行处理，但是处理后音质一般，需要进一步根据娱乐场景进行优化。

参考资料: