产品概述
产品优势
应用场景
场景解决方案
场景描述
直播带货是一种新兴的电子商务模式，通过直播平台让主播与观众实时互动，展示和推广商品，从而实现销售。在这个场景中，主播通常会在直播间展示各种商品，包括服装、化妆品、家居用品等，向观众讲解产品特点、优惠信息和使用方法等。观众可以在直播间内提问、评论和购买商品，实现即时沟通和交易。使用 RTC Engine 搭配 Chat 等产品即可轻松完成电商直播间的搭建。
实现方案
通常实现一个完整的直播带货场景，需要涉及到多个功能模块：房间管理、麦位管理、商品管理、音视频管理、云端录制 等。每个功能模块下的关键动作及功能点如下表所示。接下来会逐个介绍各个功能模块，通过介绍对搭建电商直播所需的功能有较为完整的认知。
功能模块 | 关键动作及功能点 |
房间管理 | 创建房间、加入房间、退出房间、销毁房间 |
麦位管理 | 申请上麦、主动下麦、邀请上麦、强制下麦、麦位禁言 |
商品管理 | 商品列表管理、商品弹窗管理、跳转与支付 |
音视频管理 | 本地推流、远端拉流、观众连麦 |
云端录制 | RTC Engine 云端录制 |
直播带货场景整体业务架构如下图所示。主播创建房间，其他用户可以选择感兴趣的房间加入。进入房间后，麦下用户可以上麦与麦上主播进行音视频互动。主播同时负责维护商品列表，以及商品的讲解与上架等。通常出于合规要求，直播间内的音视频内容需要进行录制和审核。
房间管理
房间管理模块主要负责对房间列表的维护，主要包含以下功能：
创建房间：用户登录业务系统后，可以创建房间，创建房间后房间列表要做新增操作。
加入房间：用户可以选择加入现有房间，加入房间后当前房间人员列表要做新增操作。
退出房间：用户可以选择退出当前房间，退出房间后当前房间人员列表要做删除操作。
销毁房间：所有用户退出房间后，需要销毁房间，销毁房间后房间列表要做删除操作。
说明：
麦位管理
直播间内的麦位一般都是有序且有限的。麦位管理主要负责根据业务场景定义房间内的麦位数量，以及对当前房间所有麦位状态的管理。麦位管理主要包含：申请上麦、主动下麦、邀请上麦、强制下麦、麦位禁言等。
用户进入房间后，只有空闲状态的麦位才可以申请上麦。
主播同意用户上麦后，需要修改麦位状态为非空闲状态。
连麦用户下麦后，需要停止本地推流，并重置麦位状态。
主播有权锁定麦位、邀请上麦、强制下麦、麦位禁言等。
说明：
商品管理
商品管理模块是电商直播场景特有的，一般包含商品列表管理、商品弹窗管理、商品链接跳转与支付等。下图展示了商品管理的基础流程：
商品列表管理
商品列表管理是商品管理的基础功能，主要包括商品的添加、删除、修改和查询等功能。通常，我们会在后台数据库中存储商品的各种信息，如商品名称、描述、价格、库存、图片等。在前端，我们可以通过 API 接口获取这些信息，并以列表的形式展示给用户。
商品弹窗管理
在直播带货过程中，伴随着主播对商品的讲解与上架，通常需要在观众端弹出对应的商品信息，以便提示观众浏览和购买。商品信息弹窗功能可以通过以下两种方式实现，您可根据业务需求选择使用：
自定义消息
一般情况下，商品信息弹窗可以通过向直播间发送自定义消息的方式实现，直播间观众收到自定义消息后进行解析和展示。自定义消息收发可以由业务侧自行实现，也可以使用 Chat 群组消息 实现。具体实现详见 商品信息弹窗-自定义消息。
SEI 信息
SEI（Supplemental Enhancement Information）即补充增强信息，提供了一种向视频流中加入额外信息的方法。您可以借助 RTC Engine 发送 SEI 信息 将指定商品信息插入到主播视频流中，直播间观众拉流观看便可接收 SEI 消息，然后进行消息的解析和展示。基于 SEI 的特性，此方式能够实现商品信息弹窗和主播直播画面的精准同步。具体实现详见 商品信息弹窗-SEI 信息。
商品跳转与支付
直播间内的观众完成商品挑选后，需要通过点击商品链接，跳转到具体的电商店铺进行订单的确认及支付。这里的电商店铺可以是平台内店铺，或是集成的第三方平台店铺。待用户支付完成后，我们还需要获取支付结果，以便更新商品的销售状态和库存信息等。
说明：
上述商品管理模块仅供参考，实际应用中您需要结合业务需求自行设计并部署。
音视频管理
对于常规的电商直播场景（观众规模不超过10万人），我们推荐 RTC 实时互动方案：主播和观众推拉流都使用 RTC 协议，这种方案的端到端延时最低，同时观众上下麦体验更加平滑，无画面快进/回推等突变现象。以多人连麦互动直播为例，电商直播场景下纯 RTC 推拉流主要架构如下图所示：
该方案架构的整体流程如下：
1. 主播、观众均通过信令模块进行连接，信令模块主要负责控制直播流程、同步直播状态。
2. 无论是否有连麦观众，主播和观众均通过 RTC Engine 音视频云服务进行推拉流。
3. 观众请求与主播连麦后，信令模块会通知主播，并同步连麦者的个人信息。
4. 主播同意连麦申请后，连麦观众开始推流，房间内所有成员将会接收到流更新通知，并拉取连麦观众的音视频流。
5. 当连麦观众发起下麦请求后，其停止推流，房间内所有成员将会接收到流更新通知，并停止拉取该观众的音视频流。
说明：
云端录制
RTC Engine 最新升级的云端录制，使用 RTC Engine 内部的实时录制集群进行音视频录制，拥有更完整统一的录制体验。
单流录制：通过 RTC Engine 的云端录制功能，您可以将房间中的每一个用户的音视频流都录制成独立的文件。
混流录制：将同一个房间的音视频媒体流混流录制成一个文件。
说明：
关键业务逻辑
商品讲解回放
商品讲解回放是电商直播场景的必备功能，一般可以分为直播中回放和直播后回放。商品讲解回放能够帮助一些后进房，以及错过直播的用户自助回看主播直播时的商品讲解，从而增加销售量、提高转化率。商品讲解回放功能可以通过以下两种方式实现。
录制回放
录制回放是一种比较常用的商品讲解回放功能的实现方式，其实现简单且不限制回放时机。以下是使用录制回放实现商品讲解回放的基本流程。
1. 录制讲解素材
指定录制模式（RecordMode）
单流录制：将房间内每个主播的音视频流都单录成独立的音视频文件上传到云存储平台。
合流录制：将房间内您所订阅所有主播的音视频流混录成一个音视频文件上传到云存储平台。
指定存储位置和录制格式（StorageParams）
存储位置：支持存储至 云点播 VOD 或 对象存储 COS，也支持 AWS storage，可通过 StorageParams 参数指定 CloudStorage（COS 存储参数）或 CloudVod（VOD 存储参数），不支持同时设置点播和对象存储。
录制格式：存储至 COS 时默认录制格式为 HLS，可通过 RecordParams 下的 OutputFormat 参数修改录制文件格式；存储至 VOD 时默认录制格式为 MP4，可通过 TencentVod 下的 MediaType 参数修改录制文件格式。
启动录制任务（CreateCloudRecording）
通过您的后台服务调用 REST API （CreateCloudRecording）来启动云端录制，需要重点关注参数任务 ID（TaskId）；这个参数是本次录制任务的唯一标识，您需要保存下这个任务 ID 作为后续针对这个录制任务接口操作的输入参数。
注意：
发起云端录制任务的接口 CreateCloudRecording 中需要您指定分配录制机器人的进房参数 UserId 和 UserSig（如何获取 UserSig），请不要与您房间内的正常主播或观众使用的 UserId 重复且不可与正在录制中的房间内指定的录制机器人 UserId 一致，否则会导致录制任务失败。
停止录制任务（DeleteCloudRecording）
2. 获取播放地址
方式一：手动查找
结束录制任务后，RTC Engine 录制系统中录制下来的文件会上传至您指定的云存储平台（云点播 VOD 或对象存储 COS或AWS storage）。您可以直接前往 云点播控制台 或 对象存储 COS 控制台 查找目标录制媒体文件，并手动获取播放地址。
方式二：回调接收
您还可以通过在控制台 配置录制回调地址，让腾讯云主动把新录制文件的消息推送给您的服务器。当录制文件转存完成后，RTC Engine 会通过您在 控制台 中设置的回调地址（HTTP/HTTPS）向您的服务器发送通知。RTC Engine 会将录制和录制相关的事件都通过您设置的回调地址推送给您的服务器，您可以通过接收事件类型为311的上传成功回调来获取录制文件的播放地址 VideoUrl，回调示例信息如下所示：
{"EventGroupId": 3,"EventType": 311,"CallbackTs": 1622191965320,"EventInfo": {"RoomId": "20015","EventTs": 1622191965,"UserId": "xx","TaskId": "xx","Payload": {"Status": 0,"TencentVod": {"UserId": "xx","TrackType": "audio_video","MediaId": "main","FileId": "xxxx","VideoUrl": "http://xxxx","CacheFile": "xxxx.mp4","StartTimeStamp": xxxx,"EndTimeStamp": xxxx}}}}
3. 播放录制视频
完成前置准备工作后，您可以调用 TXVodPlayer 的
startVodPlay 来播放录制好的商品讲解视频。TXVodPlayer 内部会自动识别播放协议，您只需要将播放 URL 传给 startVodPlay 函数即可。更多代码示例详见 快速接入指引-商品讲解回放。// 播放 URL 视频资源String url = "http://1252463788.vod2.myqcloud.com/xxxxx/v.f20.mp4";mVodPlayer.startVodPlay(url);
// 播放 URL 视频资源NSString* url = @"http://1252463788.vod2.myqcloud.com/xxxxx/v.f20.mp4";[_txVodPlayer startVodPlay:url];
说明：
美颜特效接入
电商直播场景中，美颜也是一个被高频使用的功能。美颜不但能提升主播的颜值，也能通过一些贴纸特效增加直播互动的趣味性。RTC Engine 支持 美颜 AR SDK 的集成，同时也支持市面上主流第三方美颜产品的接入，例如火山美颜、相芯美颜等。
美颜接入流程
API 调用时序
美颜产品对比
跨房 PK 连麦
主播与主播之间进行跨房 PK 连麦是电商直播场景下比较新颖的一种玩法，互动 PK 能够增强直播的趣味性，也能一定程度激发观众购物的欲望。RTC Engine 支持多个房间、多个主播之间跨房 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个主播可与其他房间的主播跨房连麦。RTC Engine 跨房连麦 PK 还可以通过
createSubCloud() 创建子实例加入对方房间推拉流的方式实现，目前子实例的数量没有限制，便于后期多个房间 PK 或者多个主播 PK 的业务扩展。2. 实时互动跨房连麦流程
RTC 实时互动方案 跨房 PK 连麦流程整体简单，主播和跨房连麦主播互相拉取 RTC 单流，观众同时拉取主播和跨房连麦主播的 RTC 单流，观众可独立控制主播和跨房连麦主播媒体流订阅逻辑。RTC 实时互动跨房连麦流程如下图所示：
注意：
场景玩法
单主播直播带货
单主播直播带货是电商直播场景最常见，也是最基础的一种玩法。这种场景下，直播间只有唯一的主播端，不存在连麦主播等角色。观众可以进入直播间观看直播，以及在直播间进行互动和购物等。
多人连麦互动直播带货
多人连麦互动直播带货是在单主播直播带货场景的基础上，增加了观众上麦和主播进行互动的玩法。主播可以邀请观众上麦，并对麦位进行控制；观众也可以主动申请上麦和主播互动。多人连麦互动直播带货能够提升观众的参与感，调动观众的积极性。
跨房 PK 连麦直播带货
除了传统的单房间主播直播带货外，主播还可以和另一个直播间的主播进行跨房 PK 连麦，展示各自售卖的商品，激发观众的购买热情，增加直播的趣味性。
方案配套产品
系统层级 | 产品名称 | 场景用途 |
接入层 | 提供低延时、高品质的多人音视频实时互动直播解决方案，是电商直播场景的基础底座能力。 | |
接入层 | 提供基于群组功能的房间管理、麦位管理能力，实现直播间全员消息、公屏消息等富媒体消息收发，以及自定义信令等通信需要。 | |
接入层 | 提供美颜、滤镜、美妆、趣味贴纸、Moji 表情、虚拟形象等实时特效处理能力。 | |
云端服务 | 面向音视频、图片等媒体，提供制作上传、存储、转码、媒体处理、媒体 AI、加速分发播放、版权保护等一体化的高品质媒体服务。 | |
数据存储 | 提供音视频录制文件、音视频切片文件的存储服务。 |
文档反馈