现在直播连麦功能有哪些解决方案？

这里所说的连麦指的是主播和部分观众之间可以进行实时互动，然后将互动结果实时播放给其他观众观看，有以下三种方

第一种方式就是通过两路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、使用抖动缓存(jitter buffer)来消除网络包的抖动特性，以一个稳定的速率将数据包交给后续模块处理;音频和视频需要有各自的抖动缓存，然后再实现同步; 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(Multi Control Unit)来实现媒体数据转发。然后通过MCU对多路数据进行混合，再把混合流发送给CDN，其原理图如下： 1、主播端加入视频会议系统;此处注意，主播端不再直接推视频给CDN; 2、视频会议系统把主播的视频流推向CDN，观众通过CDN 观看主播视频; 3、参与连麦的观众登录到与主播端同一个视频会议频道中，此时主播端和连麦者通过实时的4,视频会议进行交互;主播与连麦者的视频，经过服务端混合后输出给CDN; 其他用户通过CDN 观看主播与连麦者的交互; 这种方式的优势在于： 1、主播和连麦者交互延迟很小; 由于使用视频会议系统，通过服务端做了一次转发，基本延迟都在一秒以下; 2、主播端只承担视频会议交互的流量，而不需要再承担直播的上传流量，对网路要求比P2P 方式要低; 3、支持多人交互; 缺点在于： 1、服务端相比于一般的直播系统，还多增加了视频会议系统，开发复杂性高; 2、音视频混合在服务端完成，对服务器性能要求高;

第四种方式webrtc直播

WebRTC 全称为：Web Real-Time Communication。它是为了解决 Web 端无法捕获音视频的能力，并且提供了 peer-to-peer（就是浏览器间）的视频交互。实际上，细分看来，它包含三个部分： MediaStream:捕获音视频流

RTCPeerConnection:传输音视频流（一般用在 peer-to-peer 的场景） RTCDataChannel: 用来上传音视频二进制数据（一般用到流的上传） 但通常，peer-to-peer 的场景实际上应用不大。对比与去年火起来的直播业务，这应该才是 WebRTC 常常应用到的地方。那么对应于 Web 直播来说，我们通常需要两个端： 主播端：录制并上传视频 观众端：下载并观看视频

anyRTC一直主推WebRTC技术方案对原有的直播系统进行升级改造。anyRTC采用的是微服务分离架构，流媒体服务只对信令和媒体包进行转发，这些我们定义为轻任务；而类似媒体处理、编解码等重任务由单独的业务服务进行处理。