秀场直播主播pk实现的四种技术架构

秀场互动直播是 RTC 技术应用的常见场景，虽然主播PK 的业务逻辑不算复杂，但由于在标准直播模式和主播PK 模式的切换过程中容易产生卡顿、黑屏等现象，为了在优雅实现业务逻辑的同时，最大程度缓解类似的音视频体验问题，工程师们八仙过海各显神通，提出了很多种秀场直播的实现架构，下面我们介绍其中最典型的四种架构

 

方案A：

 

概要说明：

1. 最常见的实现方式，标准直播使用推流SDK，切换成PK模式的话，走的是连麦及合流转码服务；
2. 算是个基准方案，其他方案的优缺点主要都基于跟方案A进行比较

方案风险：

1. 客户端会集成两个SDK，现实中，采用该方案的客户多会有两个供应商，一个提供连麦，一个负责直播，这会存在产生产品间兼容性问题的隐患
2. 由于推流SDK和RTC SDK 是分开的两个SDK，由于涉及到资源的申请和释放，因此，在模式切换时，是比较容易产生卡顿、黑屏等现象的，优化难度较大
    

方案B：

概要说明：

1. 该方案也可以称之为双流方案，所谓双流，指的是观众端会拉两个主播的流，而非其他方案的一个流；
2. 除了双流以外，该方案还没有使用连麦服务中的合流转码功能

方案优点：

1. 使用单路转推功能，替代掉合流转码功能，由于合流转码一般的单价较高，因此，连麦的消费费用会有较明显的降低

方案风险：

1. 虽然连麦的消费会显著下降，但由于观众端直播流需要拉两路，因此直播云消费可能会显著上升，如果观众主播比较大的话，连麦+直播的总消费会较明显增大
2. 跟标准直播一样，客户端集成了两个SDK，导致模式间切换的体验优化比较困难，产品间的兼容性隐患依旧存在
3. 双流方案，观众端的体验比单流方案是可能有所下滑的，一方面对观众端的带宽要求更高(*2)，另一方面，还存在一定概率的两个主播的rtmp流时间不太同步的隐患
4. 方案的扩展性相对也差些，比如如果未来要做主播观众连麦的玩法，终究还是会回到合流转码的方式上去

 

方案C：

概要说明：

1. 该方案我们也称之为客户端合流方案，他的主要特点就是主播pk画面的合流由客户端完成；

方案优点：

1. 把合流放到客户端做，那就完全节省了这部分消费，因此，这是个成本最低的方案；
2. 由于始终保持着客户端跟直播云的上行推流线路，在模式切换时不存在所谓进入抢流模式（两个不同的上行推流设备，同时往一个直播通道推流，后推的设备会顶掉前面的上行设备，该模式称之为直播抢流模式），所以理论上模式间切换的体验优化会稍稍好做些

方案风险：

1. 这个方案缺点也比较显著，把合流放到客户端，对主播的网络和手机性能要求都明显提高，尤其是网络，现在多了一路推流，等于上行带宽*2，对直播而言，主播端的推流情况对观众体验的影响是最重要的，主播带宽要求*2，直播体验下降的风险必然增加很大；

 

方案D：

概要说明：

1. 该方案我们称之为七牛方案，方案中的实时音视频云即为七牛QRTC产品，直播云即为七牛PILI产品
2. 技术上说，我们可以称该方案为 纯RTC 秀场直播方案，他抛弃了相对落后的RTMP推流模块，在技术上具备一定先进性

方案优点：

1. 客户端只用了一个 RTC SDK，客户接入成本相对较低，且因为少个SDK，最终APP的包体会略有下降
2. 标准直播模式，使用的是先进的 RTC 推流，相比 RTMP推流，RTC 推流抗弱网的表现更好，我们自己的测试，RTMP 推流在丢包10%情况下卡顿、延时往往就比较显著了，而RTC 往往可以到30%丢包甚至更大的情况下，依然能有比较流畅的声画体验，这是因为从技术上说，RTC 是比 RTMP 更先进的音视频传输技术，是当前人类在音视频传输领域进步的典型成果展示
   1. 推流抗弱网对绝大多数的秀场直播而言，其实意义不是很大，因为专业的主播往往网络条件比较好，但在户外等场景，RTC推流的意义还是非常显著的
3. 由于使用的是一个RTC SDK，模式切换时，不存在SDK资源申请和释放的问题，模式切换的体验优化相对更容易些
4. 该方案除了实时音视频云和直播云，七牛秀场直播方案在RTC SDK上还深度融合了商汤和字节跳动的美颜滤镜SDK，这一方面帮助客户规避了产品间兼容性问题，另一方面又可以让客户享受到完整的闭环服务，且整个方案代码已全部开源

方案风险：

1. 方案相比标准方案，唯一的隐患在于在标准直播模式下，会增加一个单路转推的费用风险，但由于该服务单价极低，因此新增费用相对可控