【原标题】探讨直播低延迟低流量的粉丝连麦技术
【来 源】ArchSummit技术关注【作 者】郝飞
【编者按】本文转自ArchSummit技术关注，本站编辑进行了调整。
到目前为止，直播行业继续如预期的那样如火如荼的发展着，在先后竞争完延迟，高清，美颜，秒开等功能后，最近各大直播平台比拼的一个热点就是连麦。什么是连麦？简单描述就是当主播直播期间，可以与其中某一个粉丝进行互动，并且其他粉丝能够观看到这个互动过程。
这个连麦的操作把主播和粉丝的交互从文字聊天一下升级为音视频互动，这个功能瞬间就提升了粉丝们的参与感；同时，这个互动过程其他粉丝都可以看到，极大满足了连麦粉丝的幸福感，连麦的流程图如下：
1.在主播直播过程中，主播提示进入互动环节，此时用户可以参与互动
2.用户请求参与互动，主持人同意某一个用户的请求；
3.用户参与直播，用户与主播的互动过程直播给其他所有粉丝；
那如何实现连麦这样的功能呢？今天就向大家介绍几种实现方法；
第一种方式就是通过两路RTMP流实现
目前直播的协议普遍采用的是RTMP协议，RTMP是Adobe公司实现的一套为Flash播放器和服务端之间音视频和数据传输的私有协议。此协议基于TCP实现，采用多路服用，信令和媒体都通过一个通道进行传输。
目前国内的直播CDN基本上都使用此协议，其延迟大概在3秒左右；由于此协议的数据是单向流动的，因此如果连麦功能使用此协议实现的话，就需要两路视频流的发布订阅；其原理图如下：
1.主播首先发布视频到流媒体服务器，用户从流媒体服务器拉取视频信息；
2.其中某个用户希望与主播连麦，他通过信令服务器向主播请求连麦，主播同意连麦请求；
3.连麦者发布视频到流媒体服务器；
4.主播端和其他用户获取连麦者发布的视频，在手机端采用画中画形式显示；
在这个方案中，主播和参与连麦的粉丝分别发布了一路视频流，观看的粉丝同时拉取两路视频流。这种连麦方式从技术实现上非常简单，但其体验上也存在很多问题：
首先，主播和参与连麦的粉丝之间的交互延迟太大。大家了解，一路rtmp的延迟大概在3秒左右。如果主播与参与连麦的用户需要进行对话，那么主播从提问到听到对方的答复原则上差不多要6秒左右时间了，这个对于实时交互来说完全没有办法接受。
其次，声音效果不好，会产生回波。一般的直播的音频处理模块都没有进行回波抵消处理，因此主播端在观看到连麦者视频的同时，不能打开连麦者的音频听，否则会通过音频采集设备重新采集，形成回波。
最后，客户端接收两路视频，流量消耗高。一般的用户端需要接收两路视频才能分别看到主播和连麦者，两路视频导致流量消耗比较高，同时两路解码也比较消耗CPU资源。
从上面的分析大家可以看出，上述方案并不是一套可接受的连麦方案；连麦的场景对于延迟要求很高，RTMP协议明显无法满足要求。比较好的方案需要确保连麦者（2个或者多个）之间的交互满足视频会议的标准，也就是延迟在600ms以内，整体的交互过程再进行视频混合，以RTMP的方式进行输出。也就是说，这个方案中其实涉及了两套系统，一套是保证低延迟的多人音视频交互系统，另外一套是标准的CDN直播系统；直播系统大家已经很了解了，下面重点介绍下低延迟的交互系统的特点：
1.直播系统是一个单向的数据通道，而低延迟的视频会议系统是一套双向的通道。这使得这类系统在支持大并发方面没有直播系统那么容易扩展，其网络拓扑结构更加复杂；
2.低延迟系统传输层一般都使用UDP，应用层使用RTP／RTCP协议，从而保证包的即时性；为了保证安全性，更多的系统在使用SRTP协议，它是在RTP基础上多了一层安全和认证措施；客户端的连接建立常使用ICE协议，它结合私有网络中主机所处的环境，通信双方首先从STUN，TURN收集尽可能多的连接地址，然后对地址进行优先级排序，选择最优的方式进行连接；这种方式对于不使用NAT穿透的场景也有好处；它可以保证不同网络客户的联通率，例如有些境外的客户直连境内服务器效果不够好，可以考虑通过TURN服务进行中转，从而保证服务质量；
3.使用UDP就会涉及网络延迟，丢包，因此要考虑QoS，主要策略包括：
a.使用抖动缓存(jitterbuffer)来消除网络包的抖动特性，以一个稳定的速率将数据包交给后续模块处理；音频和视频需要有各自的抖动缓存，然后再实现同步；
b.在音频方面，需要实现丢包隐藏算法；GIPS公司的NETEQ算法应该是业界公认最好的VOIP防抖动算法，目前已经在WebRTC项目中开源；
c.视频方面，需要实现一个自适应反馈模型，能够根据网络拥塞情况调整丢包保护策略；当RTT较大时，可以使用FEC进行数据保护；当RTT较小的时候，选择采用NACK机制；
接下来将基于以上讨论的这种模型，介绍两种连麦实现方式；这两种方式都可以保证连麦效果，他们的主要区别是一种使用P2P技术进行连麦，另外一种使用多人视频会议系统支持连麦，具体如下。
第二种方式是P2P＋直播的连麦方式，其原理图如下
1.主播首先发布视频到流媒体服务器，用户从流媒体服务器拉取视频信息；
2.连麦者请求连麦，此时主播端会弹出连麦请求，主播选择连麦用户，连麦者和主播建立P2P连接；
3.主播端和连麦者之间建立了P2P通道，通过此通道进行音视频数据的交互；
4.主播端从摄像头中采集主播视频，从P2P通道获得连麦者的视频，然后把两张图片进行混合，再发布给主播模块，直播出去；
这种实现方式的优势在于：
1.主播和连麦者之间的交互延迟小，由于这两者之间是P2P连接，因此网络延迟非常小，一般都在几百毫秒的量级。主播与连麦者之间的交互非常顺畅；
2.声音效果好；主播端使用回波抵消模块，连麦者的回声会被消除；同时，主播与连麦者的语音交流也会整体直播出去；
这种方式存在的问题在于：
1.主播端相当于有两路视频上传（直播视频＋连麦者的视频交互），一路视频下载（连麦者的视频），对网络要求会比较高。我们团队在正常的电信，联通等wifi及4G网络下进行测试，主播端带宽完全能够满足要求；
2.不支持多路连麦者同时交流；
第三种方式通过视频会议＋直播的方式实现
为了能够实现多个粉丝同时连麦，可以考虑主播与连麦者之间使用视频会议系统，用一个MCU（MultiControlUnit）来实现媒体数据转发。然后通过MCU对多路数据进行混合，再把混合流发送给CDN，其原理图如下：
1.主播端加入视频会议系统；此处注意，主播端不再直接推视频给CDN；
2.视频会议系统把主播的视频流推向CDN，观众通过CDN观看主播视频；
3.参与连麦的观众登录到与主播端同一个视频会议频道中，此时主播端和连麦者通过实时的视频会议进行交互；主播与连麦者的视频，经过服务端混合后输出给CDN；
4.其他用户通过CDN观看主播与连麦者的交互；
这种方式的优势在于：
1.主播和连麦者交互延迟很小；由于使用视频会议系统，通过服务端做了一次转发，基本延迟都在一秒以下；
2.主播端只承担视频会议交互的流量，而不需要再承担直播的上传流量，对网路要求比P2P方式要低；
3.支持多人交互；
缺点在于：
1.服务端相比于一般的直播系统，还多增加了视频会议系统，开发复杂性高；
2.音视频混合在服务端完成，对服务器性能要求高；
以上就是对连麦实现方式的简单介绍，这三种方式在实际项目中都有被使用到，原则上后两种方法的体验会更好些；特别是第三种方案，他可以支持小范围的多人实时交互，但这种方案的开发量大，同时熟悉视频会议和直播的团队比较缺少，对研发团队要求高；第二种方案可以在webrtc和直播技术基础上可以实现，对这方面比较熟悉的团队可以尝试整合一下。
Q&A
问题1:连麦技术是在客户端实现还是服务器端实现?两种实现方式各有什么优缺点?
刚才介绍的第二种方案就是在客户端实现的，当然服务端也需要做一些工作；而第三种方案主要是在服务端的实现；相关的优缺点上面也做过解答，大家可以参考下；
问题2:连麦技术有开源基础版吗？
P2P的方案可以考虑在webrtc基础上实现；而视频会议＋直播的方案目前还没有看到开源项目，可以考虑在视频会议系统上进行改造，使其输出RTMP直播；
问题3:直播和用户宽带至少需要多少才能流畅连麦？
如果是P2P方案，对主播端带宽要求会高一些；如果是第三种会议模式，要求就不高了，基本上就是一路上传，一路下载；第二种P2P方案，我们在4G，10M的联通，电信等网络下实验都是OK的；
问题4:你们P2P是自己研发的还是基于其他的？
我们是在webrtc基础上改造的，webrtc的视频图像要和摄像头的视频图像合成；并且在带耳机的情况下，音频也需要程序合成；
问题5:你们对防火墙或NAT有没有运用STUN或ICE之类的技术？
ICE是一定要使用的；对于P2P网络，有很多网路不能直连，肯定要使用TURN服务做中转；对于会议模式，也可以通过TURN做中转，从而解决异地网络连接不稳定的情况；
问题6:各方案中如果用户端断线，此时用户重新连麦要重新走连麦流程吗？还是说可以挂着视频系统自动重连？
是可以重新连接的，不需要再走连麦流程；
问题7:第二种方案为什么不支持多路连麦者同时交流？
P2P其实也可以支持多人交互，但多个人同时交流，对于主播端来说CPU压力和网络压力都很大；
问题8:你们的视频和音频分别采用的是什么编码？
通用的编码方案是：视频采用H264，音频采用AAC；如果端到端都可控情况下，建议使用H265，压缩率更高；
问题9:第三种方案中，有什么推荐的视频会议系统？
大家有兴趣的话可以看看licode
问题10:第三种方案的开发团队要多少人，开发周期一般多长
这个不在于人多，主要还是对视频会议系统要比较了解；如果使用licode改造的话，需要服务端实现RTMP推流的改造，如果对ffmpeg等比较熟悉的话，一个月左右能够出来一个基础版本，但真正稳定下来还有很多工作需要完善；
