从方案架构分析秀场直播的四种实现方式

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

基础方案

这是一种最常见的实现方式,标准直播使用推流 SDK,切换成 PK 模式的话,走的是连麦及合流转码服务。其他方案的优缺点主要都基于与这一方案进行比较。

可能风险

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

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

双流方案

所谓双流,指的是观众端会拉两个主播的流,而非其他方案的一个流。除了双流以外,该方案还没有使用连麦服务中的合流转码功能。

方案优点

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

可能风险

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

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

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

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

客户端合流方案

客户端合流方案的主要特点就是主播pk画面的合流由客户端完成。

方案优点

成本低:把合流放到客户端做,那就完全节省了这部分消费,因此,这是个成本最低的方案。

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

可能风险

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

七牛方案

七牛秀场直播解决方案结合了七牛云 QRTC 和 Pili。从技术上说,我们可以称该方案为纯 RTC 秀场直播方案,他抛弃了相对落后的 RTMP 推流模块,在技术上具备一定先进性。这一方案相比标准方案,唯一存在的风险是在标准直播模式下,会增加一个单路转推的费用风险,但由于该服务单价极低,因此新增费用相对可控。

方案优点

包体小:客户端只用了一个 RTC SDK,客户接入成本相对较低,且因为少个SDK,最终APP的包体会略有下降。

体验好:标准直播模式,使用的是先进的 RTC 推流,相比 RTMP推流,RTC 推流抗弱网的表现更好,经测试,RTMP 推流在丢包 10% 情况下卡顿、延时往往就比较显著了,而 RTC 往往可以到 30% 丢包甚至更大的情况下,依然能有比较流畅的声画体验,这是因为从技术上说,RTC 是比 RTMP 更先进的音视频传输技术,是当前人类在音视频传输领域进步的典型成果展示。

抗弱网:推流抗弱网对绝大多数的秀场直播而言,其实意义不是很大,因为专业的主播往往网络条件比较好,但在户外等场景,RTC 推流的意义还是非常显著的。

切换好:由于使用的是一个 RTC SDK,模式切换时,不存在SDK资源申请和释放的问题,模式切换的体验优化相对更容易些。

多兼容:该方案除了实时音视频云和直播云,七牛秀场直播方案在RTC SDK上还深度融合了商汤和字节跳动的美颜滤镜SDK,这一方面帮助客户规避了产品间兼容性问题,另一方面又可以让客户享受到完整的闭环服务,且整个方案代码已全部开源。

在秀场直播这一场景的七牛解决方案中,实时音视频云 QRTC 实现实时连麦互动,主播间连麦、主播与观众的音视频实时互动。通过直播云 Pili 的直播流分发,以及融合了行业 TOP 美颜滤镜 SDK,观众观看到经过美颜、滤镜以及妆容修饰的主播直播间画面。通过 IM 聊天、点赞、打赏等功能实现了更好的互动。同时,借助七牛对象存储 Kodo 实现直播内容的录制,以及 Dora 实现内容审核。