带货直播系统,实现主播pk三种技术架构

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

方案A:

带货直播系统,实现主播pk三种技术架构_第1张图片

概要说明:

最常见的带货直播系统实现方式,标准直播使用推流SDK,切换成PK模式的话,走的是连麦及合流转码服务;

算是个基准方案,其他方案的优缺点主要都基于跟方案A进行比较

方案风险:

客户端会集成两个SDK,现实中,采用该方案的客户多会有两个供应商,一个提供连麦,一个负责直播,这会存在产生产品间兼容性问题的隐患

由于带货直播系统推流SDK和RTC SDK 是分开的两个SDK,由于涉及到资源的申请和释放,因此,在带货直播系统模式切换时,是比较容易产生卡顿、黑屏等现象的,优化难度较大

方案B:

带货直播系统,实现主播pk三种技术架构_第2张图片

概要说明:

该方案也可以称之为双流方案,所谓双流,指的是带货直播系统观众端会拉两个主播的流,而非其他方案的一个流;

除了双流以外,该方案还没有使用连麦服务中的合流转码功能

方案优点:

带货直播系统使用单路转推功能,替代掉合流转码功能,由于合流转码一般的单价较高,因此,连麦的消费费用会有较明显的降低

方案风险:

虽然带货直播系统连麦的消费会显著下降,但由于带货直播系统观众端直播流需要拉两路,因此直播云消费可能会显著上升,如果观众主播比较大的话,连麦+直播的总消费会较明显增大

跟标准直播一样,客户端集成了两个SDK,导致模式间切换的体验优化比较困难,产品间的兼容性隐患依旧存在

双流方案,带货直播系统观众端的体验比单流方案是可能有所下滑的,一方面对观众端的带宽要求更高(*2),另一方面,还存在一定概率的两个主播的rtmp流时间不太同步的隐患

方案的扩展性相对也差些,比如如果未来要做主播观众连麦的玩法,终究还是会回到合流转码的方式上去

方案C:

带货直播系统,实现主播pk三种技术架构_第3张图片

概要说明:

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

方案优点:

把合流放到带货直播系统客户端做,那就完全节省了这部分消费,因此,这是个成本最低的方案;

由于始终保持着带货直播系统客户端跟直播云的上行推流线路,在模式切换时不存在所谓进入抢流模式(两个不同的上行推流设备,同时往一个直播通道推流,后推的设备会顶掉前面的上行设备,该模式称之为直播抢流模式),所以理论上带货直播系统模式间切换的体验优化会稍稍好做些

方案风险:

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

————————————————

声明:本文由云豹科技转发自csdn,如有侵权请联系作者删除

原文链接:https://blog.csdn.net/heliang1108/article/details/109228615

你可能感兴趣的:(直播平台源码,后端)