有奖捉虫:行业应用 & 管理与支持文档专题 HOT

场景描述

秀场直播场景为社交娱乐模式下的视频互动场景,场景支持多人视频连麦互动,更容易吸引用户参与连麦互动,提升用户的消费意愿及粘性。此外,秀场直播还支持不同房间的主播跨房 PK,进一步增强了直播的趣味性。跨房连麦 PK 时延低于300ms,同时支持观众与主播连麦互动,上下麦平滑切换,满足秀场直播场景下的高频互动需求。秀场直播的智能美颜能力也能够满足主播的个性化需求,让直播更加风采动人。
?
?
?

实现方案

通常实现一个完整的秀场直播场景,需要涉及到多个功能模块:房间管理麦位管理媒体流管理录制与审核 等。每个功能模块下的关键动作及功能点如下表所示。接下来会逐个介绍各个功能模块,通过介绍对搭建秀场直播所需的功能有比较完整的认识。
功能模块
关键动作及功能点
房间管理
房间列表、创建房间、加入房间、退出房间、销毁房间
麦位管理
申请上麦、主动下麦、邀请上麦、强制下麦、麦位禁言
媒体流管理
RTC 实时互动方案
录制与审核
TRTC 云端录制、天御内容安全审核
秀场直播场景整体业务架构如下图所示。房主创建房间,用户可以选择对应感兴趣的房间加入。进入房间后的用户可以上麦跟麦上主播进行音视频互动。通常出于合规要求,房间内的音视频内容需要录制下来并提交审核。
?
?
?
说明:
旁路转推、录制审核环节都可以根据实际业务需求,选择目标单流或者混流。
录制与审核环节可以根据实际业务需求,选择 RTC 录制审核或旁路录制审核。

房间管理

房间管理模块主要负责对房间列表的维护,主要包含以下功能:
创建房间:用户登录业务系统后,可以创建房间,创建房间后房间列表要做新增操作。
加入房间:用户可以选择加入现有房间,加入房间后当前房间人员列表要做新增操作。
退出房间:用户可以选择退出当前房间,退出房间后当前房间人员列表要做删除操作。
销毁房间:所有用户退出房间后,需要销毁房间,销毁房间后房间列表要做删除操作。
说明:
房间管理是实现秀场直播的必要模块,但并非主要功能模块,具体可以结合业务系统以及 IM&TRTC SDK 实现,详见 语聊房-房间管理

麦位管理

直播间内的麦位一般都是有序且有限的。麦位管理主要负责根据业务场景定义房间内的麦位数量,以及对当前房间所有麦位状态的管理。麦位管理主要包含:申请上麦、主动下麦、邀请上麦、强制下麦、麦位禁言等。
用户进入房间后,只有空闲状态的麦位才可以申请上麦。
房主同意用户上麦后,需要修改麦位状态为非空闲状态。
用户停止推流下麦后,需要重置麦位状态。
房主有权锁定麦位、邀请上麦、强制下麦、麦上禁言等。
说明:
麦位管理是实现秀场直播的必要模块,但并非主要功能模块,具体可以结合业务系统以及 IM&TRTC SDK 实现,详见 语聊房-麦位管理

媒体流管理

普通秀场直播场景,我们推荐 RTC 实时互动方案:主播和观众推拉流都使用 RTC 协议,这种方案的端到端延时最低,同时观众上下麦体验更加平滑,无画面快进/回推等突变现象。以多人连麦直播互动为例,秀场直播纯 RTC 推拉流场景的主要架构如下图所示:
?
?
?
该方案的整体流程如下:
1. 主播、观众均通过信令模块进行连接,信令模块主要负责控制直播流程、同步直播状态。
2. 无论是否有连麦观众,主播和观众均通过 TRTC 音视频云服务进行推拉流。
3. 观众请求与主播连麦后,信令模块会通知主播,并同步连麦者的个人信息。
4. 主播接收连麦申请后,连麦观众开始推流,房间内所有成员将会接收到流更新通知,并拉取连麦观众的音视频流。
5. 当连麦观众发起下麦请求后,其停止推流,房间内所有成员将会接收到流更新通知,并停止拉取该观众音视频流。
说明:
信令模块可以是业务自研的信令通道,同时也推荐使用腾讯云 即时通信 IM 进行信令交互。

录制与审核

由于国内对直播行业的监管政策日渐趋严,很多情况下需要云端录制及存储直播内容,以便备案与审查。同时还有对直播内容进行实时安全审核的需求,以便及时打击违法违规的直播间,从而使得直播平台更加规范化。

TRTC 云端录制

TRTC 最新升级的云端录制,不依赖云直播的能力,无需旁路转推云直播,使用 TRTC 内部的实时录制集群进行音视频录制,拥有更完整统一的录制体验。
单流录制:通过 TRTC 的云端录制功能,您可以将房间中的每一个用户的音视频流都录制成独立的文件。
?
?
?
混流录制:将同一个房间的音视频媒体流混流录制成一个文件。
?
?
?
注意:
TRTC 云端录制的具体介绍及开通指引详见 实时音视频 实现云端录制与回放
秀场直播场景常见混流录制方案,如果有对主播或连麦观众的单流审核需求则可选择单流录制方案。

天御内容安全审核

TRTC 联合 T-Sec 天御,提供了实时的音视频内容识别与告警服务,使用实时音视频服务时,支持全局自动或手动发起策略进行音视频内容的识别和告警:
全局自动审核
客户可以指定审核策略和审核流类型,TRTC 云端自动完成应用下所有房间内的音视频内容审核,并通过回调把违规信息发送到客户指定的回调 URL,无需手动发起审核。该方式简单易用,省去了代码接入的工作量,但灵活性欠佳。
TRTC 与天御内容安全审核平台结合的实现原理如下图所示:直播内容安全通过“哑终端”的形式进入指定的 TRTC 房间,作为“观众”拉取音视频流,并针对拉取到音视频流进行内容审核,然后通过回调把违规信息发送到用户指定的 HTTP/HTTPS 服务上。
?
?
?
手动自定义审核
客户只需要调用天御音视频流接口即可实时检测音视频流中是否出现违规内容,音视频安全审核服务会通过回调把违规信息发送给客户指定的回调 URL;该方式更灵活、可定制化更强,但需要调用 REST API 发起审核任务,具有一定的接入复杂度。
?
?
?
说明:
全局自动审核接入指引详见 自动审核接入;手动审核接入指引详见 手动审核接入

关键业务逻辑

礼物与点赞消息

秀场直播场景中,送礼和点赞是一种常见的互动方式,观众可以通过赠送礼物和点赞来表达对主播的喜爱和支持,主播也能从中获取收益。下面我们将分别介绍基于腾讯云 即时通信 IM 的礼物消息及点赞消息的实现方式。

礼物消息

?
?
?
1. 客户端短连接请求到自己的业务服务器,涉及到礼物计费逻辑。
2. 计费后,发送人直接看到 XXX 送了 XXX 礼物(以确保发送人自己看到自己发的礼物,消息量大的时候,可能会触发抛弃策略)。
3. 计费结算后,调用服务端接口 在群组中发送自定义消息(礼物)。
4. 如果遇到连刷礼物的场景需要进行消息合并:
如果直接选择礼物数量的刷礼物,如:直接选择 99 个礼物,1 条消息发送,参数带入礼物数量 99。
如果是连击的礼物,不确定停留在多少个,可以合并每 20 个(数量自行调整)或者连击超过 1 秒,发送一个。按照上述逻辑,例如连击 99 个礼物,优化后仅需要发送 5 条。
服务端接口 在群组中发送自定义消息 请求包示例如下,其中 MsgBody 支持 自定义消息元素
{
"GroupId": "@TGS#12DEVUDHQ",
"Random": 2784275388,
"MsgPriority": "High", // 消息的优先级,礼物消息应设置为高优先级
"MsgBody": [
{
"MsgType": "TIMCustomElem",
"MsgContent": {
// type: 礼物类型; giftUrl: 礼物资源地址; giftName: 礼物名称; giftCount: 礼物数量
"Data": "{\\"cmd\\": \\"gift_msg\\", \\"msg\\": {\\"type\\": 1, \\"giftUrl\\": \\"xxx\\", \\"giftName\\": \\"xxx\\", \\"giftCount\\": 1}}"
}
}
]
}

点赞消息

?
?
?
1. 点赞不涉及计费,一般采用端上直接 发送群自定义消息 的方式。
2. 针对于有需要服务端计数的点赞消息,在客户端节流之后,统计客户端点赞次数,将短时间内多次点赞消息合并,仅发送一次消息。业务方服务端在 发群消息后回调 中拿到点赞次数进行统计。
3. 针对于不需要计数的点赞消息,与步骤2中的逻辑一致,业务要在客户端对点赞消息节流后发送,不需要在发群消息后回调中计数。
注意:
请将重要消息设置为高优先级(例如礼物消息),高频且不重要的消息设置为低优先级(例如点赞消息)。
直播互动功能(点赞、送礼、弹幕收发)的具体实现步骤详见 快速接入指引-直播互动消息

美颜特效接入

秀场直播场景中,美颜是一个被高频使用的功能。美颜不但能提升主播的颜值,也能通过一些贴纸特效增加直播互动的趣味性。TRTC 支持 腾讯美颜特效 的集成,同时也支持市面上主流第三方美颜产品的接入,例如火山美颜、相芯美颜等。

美颜接入流程

?
?
?

API 调用时序

?
?
?

美颜产品对比

美颜类型
美颜效果
接入成本
费用成本
虚拟数字人
支持终端
基础效果好,高级效果大眼/瘦脸等效果显著
较低
适中
支持
Android/iOS/PC/Flutter/Web/小程序
基础效果好,高级效果大眼/瘦脸等效果一般
较高
适中
支持
Android/iOS/PC/Untiy
基础效果好,高级效果大眼/瘦脸等效果较好
较高
偏高
支持
Android/iOS/PC/Linux

跨房连麦 PK

主播与主播之间进行跨房互动连麦 PK 是秀场直播场景下很常见的一种玩法,能够增强互动直播的趣味性,激发观众刷榜送礼物的欲望。TRTC 支持多个房间、多个主播之间跨房连麦 PK,下面介绍具体的实现方式。
1. 实现原理
默认情况下,只有同一个房间中的用户之间可以进行音视频通话,不同的房间之间的音视频流是相互隔离的。通过跨房连麦,可以将另一个房间中某个主播音视频流发布到自己所在的房间中,与此同时也会将自己的音视频流发布到目标主播的房间中。让身处两个不同房间中的主播进行跨房间的音视频流分享,从而让每个房间中的观众都能观看到这两个主播的音视频。
?
?
?
上图展示了跨房连麦 PK 的主要流程,例如:当房间“101”中的主播 A 通过 ConnectOtherRoom() 跟房间“102”中的主播 B 建立跨房通话后:
房间“101”中的用户都会收到主播 B 的 onRemoteUserEnterRoom(B)onUserVideoAvailable(B,true) 这两个事件回调,即房间“101”中的用户都可以订阅主播 B 的音视频。
房间“102”中的用户都会收到主播 A 的 onRemoteUserEnterRoom(A)onUserVideoAvailable(A,true) 这两个事件回调,即房间“102”中的用户都可以订阅主播 A 的音视频。
注意:
跨房连麦 PK 的本地用户和对端用户必须都为主播角色,且必须都有音频/视频上行。
可通过多次调用 ConnectOtherRoom() 来实现与多个房间主播跨房连麦,目前限制一个房间最多可以和其他三个房间的主播跨房连麦,一个房间中最多10个主播可与其他房间的主播跨房连麦。
TRTC 跨房连麦 PK 还可以通过 createSubCloud() 创建子实例加入对方房间推拉流的方式实现,目前子实例的数量没有限制,便于后期多个房间 PK 或者多个主播 PK 的业务扩展。
2. 实时互动跨房连麦流程
纯 RTC 场景下的跨房连麦 PK 流程整体简单,主播和跨房连麦主播互相拉取 RTC 单流,观众同时拉取主播和跨房连麦主播的 RTC 单流,观众可独立控制主播和跨房连麦主播媒体流订阅逻辑。实时互动场景跨房连麦流程如下图所示。
?
?
?
注意:
实时互动跨房连麦场景下,房间内观众可独立控制跨房连麦主播媒体流的订阅逻辑,或者由房主统一下发房间内信令指挥观众控制订阅逻辑。

场景玩法

单主播直播

直播间只有一个主播的场景称为单主播直播。这种场景下,直播间的房主就是唯一的主播。观众可以加入直播间观看直播,并向房主发消息、送礼物。

多人连麦直播

多人连麦直播是指直播间内有多位主播进行实时音视频互动的场景。房主可以邀请观众上麦、进行麦位控制;观众也可以申请上麦和主播互动。

跨房 PK 直播

直播间里,为增进直播气氛、快速吸粉,房主可以邀请另一个直播间的房主进行连麦互动或在线 PK。连麦直播间内的观众可以同时观看两个房主互动,并根据房主表现实时赠送礼物,或快速切换直播间给不同的房主投票。这就是一个典型的视频 PK 连麦场景。

电商带货直播

电商直播是电子商务与视频互动直播相结合的场景。在直播间里,房主向观众介绍商品,提供商品列表和链接;观众看到心仪的商品,可点击链接快速下单。直播过程中,观众可以上麦,和房主实时互动,如询问商品详情,商议价格,分享使用心得等;房主还可以和另一个直播间的房主进行 PK 连麦,展示各自的商品,激发观众的购买热情,增加直播的趣味性。

备选方案

除了上述推荐的 RTC 实时互动方案,秀场直播场景通常还有一种备选方案:RTC 旁路直播方案。

RTC 旁路直播方案

主播全程使用 RTC 协议推流并旁路转推到腾讯云直播或第三方直播,普通观众拉取 CDN 流观看,连麦观众通过切换至 RTC 协议推拉流从而实现互动连麦。此方案是一种常用的折衷方案,观众端观看和连麦的延迟较高,但同时兼具费用成本和观看规模的优势,其推拉流架构如下图所示:
?
?
?
该方案的整体流程如下:
1. 主播进入 TRTC 房间,通过 RTC 协议进行推流并旁路到云直播。
2. 麦下普通观众通过 V2TXLivePlayer 拉取 CDN 加速流进行观看。
3. 观众上麦变为连麦观众,停止 CDN 拉流并切换至 RTC 协议进行推拉流。
4. 观众下麦变为普通观众,停止 RTC 协议推拉流并切换至 CDN 拉流观看。
CDN 播放地址有 RTMP/FLV/HLS/WebRTC 等多种协议,拼接规则详见 拼装播放 URL
不同直播播放协议的适用平台、播放延迟、计费规则不尽相同,详见下表:
直播协议
优点
缺点
播放延迟
FLV
成熟度高、高并发无压力
需集成 SDK 才能播放
2s - 3s
RTMP
延迟较低
高并发情况下表现不佳
1s - 3s
HLS(M3U8)
手机浏览器支持度高
延迟非常高
10s - 30s
WebRTC
延迟最低
需集成 SDK 才能播放
< 1s
注意:
腾讯云直播支持多种拉流协议,您可根据业务需求选择合适的拉流方案,例如针对延迟敏感业务,推荐快直播 WebRTC 拉流方案。
如果您想实现类似“多清晰度播放”的功能,可在 RTC 旁路转推时设置转码输出参数,同时发布多路不同分辨率/码率的媒体流供播放端选择。

平滑上下麦处理

在单主播低频连麦直播场景中,通常出于成本考虑,可能会采用 RTC 旁路直播方案,或第三方直播推拉流方案。在单主播直播情况下,主播通过 RTC 或第三方直播推流,观众通过 CDN 拉流;在互动连麦情况下,主播和观众均通过 RTC 推拉流。这里就涉及到推拉流器的切换,需要尽可能地保持对用户是无感的。下面将具体介绍 RTC 旁路直播和第三方直播推拉流两种方案的平滑上下麦处理方式。
1. RTC 旁路直播方案
RTC 旁路直播方案下,主播始终使用 TRTC SDK 进行推拉流,连麦互动时只需要连麦观众切换推拉流器即可,同时渲染控件可以复用。
?
?
?
2. 第三方直播推拉流方案
第三方直播推拉流方案下,连麦互动时需要主播和连麦观众同时切换推拉流控件,推荐使用 TRTC 的自定义采集与渲染功能实现。
?
?
?
注意:
平滑上麦:为避免在切换拉流器时画面中断,建议等待收到 TRTC 首帧回调 onFirstVideoFrame 后再停止 CDN 拉流。
平滑下麦:为避免在切换拉流器时画面中断,建议等待收到播放器视频播放事件 onVideoPlaying 后再停止 RTC 拉流。

旁路直播跨房连麦

RTC 旁路直播场景下的跨房连麦 PK 流程相对复杂,主播和跨房连麦主播互相拉取 RTC 单流,CDN 观众拉取主播和跨房连麦主播的旁路混流,观众无法独立控制主播和跨房连麦主播媒体流订阅逻辑。旁路直播场景跨房连麦流程如下图所示:
?
?
?
注意:
旁路直播跨房连麦场景下,CDN 观众无法独立控制跨房连麦主播媒体流的订阅逻辑,需由房主通过更新混流任务(指定输入音视频流)实现。

方案配套产品

系统层级
产品名称
场景用途
接入层
提供低延时、高品质的多人音视频实时互动直播解决方案,是秀场直播场景的基础底座能力。
接入层
提供基于群组功能的房间管理、麦位管理能力,实现直播间全员消息、公屏消息等富媒体消息收发,以及自定义信令等通信需要。
接入层
提供美颜、滤镜、美妆、趣味贴纸、Moji 表情、虚拟形象等实时特效处理能力。
接入层
提供直播、点播场景的视频播放能力。
云端服务
提供实时音视频的旁路转推,以及加速媒体流的分发服务,此外还具备录制、鉴黄等附加能力。
云端服务
面向音视频、图片等媒体,提供制作上传、存储、转码、媒体处理、媒体 AI、加速分发播放、版权保护等一体化的高品质媒体服务。
安全服务
针对多种形式的视频文件/视频流进行多样化的场景检测和内容识别,精准识别视频中出现可能令人反感、不安全或不适宜内容。
数据存储
提供音视频录制文件、音视频切片文件的存储服务。
?


http://www.vxiaotou.com