一、概述
连麦：是指直播带货app源码中，由观众向主播发起连线请求，在主播和该观众之间建立低延迟的通讯链路，而其他观众可以看到“主播+连麦观众”的合成音视频内容。
PK：是指直播过程中，由主播发起，选择与其他主播进行PK，主播间建立低延迟的通讯链路，在所有观众方可以看到两个主播的合成音视频内容。
二、产品形态及流程
2.1 连麦
¬ 主播端根据等级，确定发起的直播间是否可以接收观众的连麦请求；
¬ 播放端根据等级，确定观看直播时是否可以发起连麦请求；
¬ 播放端发起连麦请求后，需排队等待麦序，及等待主播响应后才能开始连麦；
¬ 主播端或连麦观众主动结束连麦，主播结束直播或连麦观众退出直播间，结束连麦。
2.2主播PK
¬ 主播创建直播，选择PK模式；
¬ 挑选PK对象（好友或系统随机匹配）；
¬ 开始PK；
¬ 任一主播退出PK，结束。
三、方案选择
实际上，直播带货app源码连麦与PK在即时通讯部分的基础技术基本一致。但如何实现即时通讯，则有不同的方案。其差别主要体现在使用何种协议，是否对采集到的不同音视频进行混流，以及如何混流。
3.1 协议选择
a) RTMP,商业CDN广泛支持的一种协议，延迟相对较大。
b) RTP，WebRTC基于该协议通讯，延迟较小，但商业CDN不支持，业内使用较多。
c) 私有协议，延迟小，整套协议规范及传输方式、部署都需自己实现。
| 协议名称 | 传输层 | 延迟 | CDN支持 | 开发难度 |
|---|---|---|---|---|
| RTMP | TCP | 大，1-3s | 广泛 | 易 |
| RTP | UDP | 小，<1s | 需自己部署 | 中 |
| 私有协议 | UDP | 小，<1s | 需自己部署 | 难 |
总结：直播带货app源码移动端保证较小延迟，应尽可能采用UDP传输，但由于商业CDN一般仅支持RTMP，所以推送到CDN需使用RTMP。
3.2 混流技术
a) 不混流，是指主播或连麦用户的直播流，直接推送到CDN。播放端拉取多路直播流，分屏同时渲染。
b) 主播端混流，是指在主播端拉取另一主播/连麦观众的直播流后，本地进行音视频合成，然后封装成RTMP格式推送，播放端可以兼容旧播放器。
c) 服务端混流，是指在直播带货app源码服务端将直播流解码，进行音视频混流后，再次编码，以RTMP流格式推送到CDN，播放端兼容旧播放器。
| 方案 | 瓶颈 | 播放端 | 延迟 | 下行带宽 | 体验问题 |
|---|---|---|---|---|---|
| 不混流 | 带宽 | 需重新开发 | 小 | 成本翻倍 | 可能两路流不同步 |
| 主播端混流 | 主播端性能 | 兼容性强 | 很大 | 不变 | 主播端手机发烫，上行带宽不够，延迟过大 |
| 服务端混流 | 服务端资源 | 兼容性强 | 大 | 不变 | 中等 |
总结：
1).混流的过程中，由于要同步多路流的进度，考虑到网络抖动，相较于不混流的情况，延迟会增大，但下行带宽减半；
2).不同混流方案中，主播端混流不适用移动直播场景（将性能瓶颈分布到各个主播设备上，系统资源消耗少，但延迟很大，主播设备不稳定），服务端混流可能会消耗大量计算资源（由于服务端解码为冗余工作，且集中混流）。
3).整体而言，播放量较少场景下，直播带货app源码可采用不混流方案，播放量较大可采用服务端混流方案。
声明：本文由云豹科技转发自littleRabbit博客，如有侵权请联系作者删除
