非常感谢大家利用自己宝贵的时间来阅读我的文章 , 这篇文章主要写一个iOS系统直播连麦功能的实现 ，如果你正好需要 , 希望你看完后能够对你的提升有所帮助 , 当然，阅读中如果发现什么错误和可优化的地方 , 希望可以得到你的指点 , 有任何不妥的地方 欢迎指正。喜欢的可以关注下我的简书、我的博客
连麦在现在的直播APP算是常见的需求了，这里所说的连麦指的是主播和部分观众之间可以进行实时互动，然后将互动结果实时播放给其他观众观看，搜集了一些资料，现在向大家介绍几种实现方法
这段引用亲加通讯云郝飞：探讨直播低延迟低流量的粉丝连麦技术中的内容
第一种方式就是通过两路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 和直播技术基础上可以实现，对这方面比较熟悉的团队可以尝试整合一下。
刚开始的时候我的思路就是上面说的第一种方式，写了demo发现这种方法根本不可取，然后开始从后面两种方法入手，后面两种方法其实大部分实现思路是一致的，首先主播和连麦者建立p2p视频通讯，区别在于主播端合流和服务器合流，那就先来看看怎么实现p2p视频通信，对方不想多说并甩给了你几篇文章做参考（主要是webrtc）
我选择使用的是webrtc来实现的视频通信，主播和连麦者建立视频通信之后就是合流的问题了，你可以选择在主播端进行合流，也可以选择在服务器合流，当然我们最喜欢的就是在服务器做了，这样我们就可以省去很多工作，做完这些连麦功能基本就实现了，当然有连麦就少不了聊天室系统和礼物系统了，信令服务什么的就不在多说了，网上的资料很多，总结来说就是使用webrtc+rtmp 来实现连麦功能。我这里只是提供一个思路，具体的实现还是要靠你自己了，demo暂时先不传了，等什么时候有空整理整理再说吧😎
