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

1 篇文章 0 订阅
1 篇文章 0 订阅

秀场互动直播是 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. 方案相比标准方案,唯一的隐患在于在标准直播模式下,会增加一个单路转推的费用风险,但由于该服务单价极低,因此新增费用相对可控
  • 1
    点赞
  • 3
    收藏
    觉得还不错? 一键收藏
  • 1
    评论
评论 1
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值