TRTC 云助手 场景解决方案（小班课）

三、实现方案

整体小班课 App 分为四个角色，老师、教务平台（助教）、学生、家长。每个角色在小班课中均有各自负责的功能。老师主要负责课程的内容与上课；教务平台或助教作为学生家长与教师的桥梁，安排上课、发放讲义以及一些后台技术行为；学生则是完成老师与教务平台的任务；家长负责监督。小班课场景整体的参考业务流程如下，具体情况可根据自身业务情况与需求调整。

以下是小班课场景通常涉及的功能模块：

四、房间管理

房间管理根据业务情况，一般由老师或教务系统负责，主要功能有：创建房间、进入房间、邀请加入、销毁房间、退出房间等。教务系统根据课程表自动创建或由老师手动创建上课的房间。

需要注意的是，业务上的房间和在 TRTC SDK 的房间并非是一个概念。业务上的房间是线下教室的抽象化，音视频通话仅是该房间中的一个功能模块，还有其他房间上课业务的实现也将在该房间内进行。而 TRTC SDK 的房间仅仅只是 TRTC 为用于某一群用户可以互相拉取对方流而设置的技术隔离方案。为方便区分，这里用教室代指业务的房间、TRTC 房间指 TRTC 的 room 这个概念。

与课程表对应，一堂课则对应一个教室 id，教室 id 为唯一值同时也可作为对应 TRTC 房间的 roomId，建议用字符串 strRoomId 作为房间 id，后期可扩展性更好。房间 id 可以作为后续的 TRTC roomId 和 IM groupId。上课结束后 TRTC 房间可以不用手动解散，当最后一个用户退出房间后，TRTC 房间会自己销毁；除了 TRTC 房间，如果教室内有用到即时通讯相关的功能，那么 IM 的 groupId 则需要手动解散群组，防止群组累计过多，触发IM群组创建上限，导致群组创建失败。

五、角色管理

对于整个业务系统来说，我们有老师、学生、助教（教务管理员）、家长这些身份，但对于 TRTC 来说，并不区分这些角色，需要业务侧来管控不同角色的权限。

·一般老师、学生可以推流也可以拉流；

·助教和家长只能拉流；

·不存在角色变换的情况，因此进房应是唯一确定角色身份及权限的时间点；

·老师、教务有权管控学生的推流情况，例如选择上麦的学生，否则学生不可自行开麦。

六、账号管理

和教室与房间一样，整个业务系统需要有一个自身的账号体系，同时进入 TRTC Room 也需要有 userId，IM 也需要。

可以用业务自己的 userId，如果为了保密，可以自己做一层哈希的映射，把 userId 映射为唯一对应的 TRTC 和 IM 的 userId，userId 需要唯一。在 Web 端的场景下，如果用到屏幕分享，则一个用户角色需要两个 TRTC userId，一个 userId 用来推视频流，一个 userId 用来推屏幕分享流。而在原生端环境下，则是在同一个 userId 下，创建子实例进行推流。

同时，如果业务的账号系统本身不允许多端登录，那么自建账号系统还需要检测是否已登录或顶替下线的功能。

七、录像管理

在远程教育应用场景中，考虑复盘、质检、审核、存档和回放等需求，常需要将整个视频通话以及各自的视频流录制和存储下来。而实时音视频流本身无法录制，需要将其转推为可录制的直播流格式。

·基于腾讯云旁路转推能力，能将通话中的实时音视频，推送一路一模一样的直播流到云直播平台。

·基于腾讯云直播能力与 COS 对象存储服务，能快速将直播流内容存储至云平台并进行二次制作和分发。

·基于直播录制服务，能快速将你的直播活动传播到各种应用场景和 App 中。

·基于云点播，能将录制的内容在播放器中播放。

·录制根据划分标准不同有几种区别：

·全局和指定：全局录制是自动检测当前有几路流，并全部录制；指定录制需要使用 SDK 或者 restful API 指定流 ID 进行录制；

·单流和混流：单流录制即每一路流独立成录像文件；混流可以将其中某些或全部流同时展现出来合成一个视频文件。

一般从老师点击“开始上课后”，才开始调用录像接口，这样可以防止过早录像，前面一段时间后台要二次处理剪辑。混流录制，把白板、多个学生、老师的视频做混流后再录像，这样是一个完整的录像文件，课程回放不需要做多路视频和白板的时间戳对齐。

八、教材管理

教材管理主要分为两部分：

·供给白板使用的上课素材。

·教材库/文库，可供学生课前/课后下载反复查阅。

提前把绑定课程的教材上传到白板后台，节约动态 PPT、静态文件的转码时间。如果有大的视频文件，需提前上传到后台，避免在上课过程中临时上传占用老师带宽导致网络卡顿。

九、教材展示

方案架构

腾讯云互动白板提供的白板推流服务支持将白板画面推流到实时音视频房间，观看端不需要集成互动白板也能观看到白板画面，再结合实时音视频旁路推流及云端混流的能力，可以把白板画面与实时音视频房间内的其他音视频流按照指定的布局混到一起推到 CDN，其他客户端通过 CDN 拉流观看，非常适合大部分观看端不需要通过白板进行互动的直播场景。

具体实现

开发者需要将需要展示的教材加载到白板上，这里需要用到互动白板提供的转码功能，将其加载进白板的流中推送出去。

API 调用时序

十、教材共享下载

·当文件成功上传至 COS 时，COS 会提供下载链接。

·业务方可通过 COS 的 API , 拉取存储桶及对应的文件列表。

·可在 COS 的控制台设置权限管控，只允许特定用户或特定链接下载文件。

·存储在腾讯云对象存储（Cloud Object Storage，COS）中的内容，需要符合相关法律法规。

十二、音视频流

在小班课场景中，音视频流分为学生流与老师流，老师端可以管控学生流的推送情况，助教可以监控所有流的推送情况但自身不推流。

·老师端视频分辨率高于学生端视频分辨率，学生端分辨率达到刚好能看见行为的清晰度即可；

·学生端默认应处于闭麦状态，老师主动点名或学生申请连麦通过时，才可以打开麦克风；

·学生端默认应处于打开摄像头状态，当需要有类似考试等场景时，老师应拥有关闭学生间互相推送音视频流的权限；

·在某些需要多角度展示老师视角的场景（如绘画课、书法课，需要额外一个摄像头用来拍摄老师的侧面展示手型），则需要额外创建一个实例并选择对应的摄像头，用于推送一路不含音轨的视频流。

十三、屏幕分享流

在 TRTC 中，提供了专门的 API 或参数打开屏幕分享。屏幕分享默认有视频流与音频，视频流为选择的窗口，音频流为系统音量。

十四、白板流

白板的相关推流，详情请参见 教材管理 – 教材展示 – 方案架构。

这里需要额外补充，如果是类似绘画小班课的场景，并非只有老师端需要使用互动白板，因此 教材管理 – 教材展示 – 方案架构 中学生也需要和教室一样进行白板的推拉流，在架构上需要做出一定调整。

十五、关键业务逻辑

本章节将会对核心功能层的业务逻辑进行讲解，提供流程图、调用时序图以及相关 API 的关键参数。

对于小班课，老师端使用 C++ 与 electron 端的情况最多（跨平台），学生端则是移动端，Web 或小程序，由于涉及的终端较多，通用模块将会使用伪代码的方式带过，具体接口用法可参考页面对应的语言的API文档。

十六、小班课音视频通话方案

在小班课场景中，不论是教师端还是学生端均有较大可能存在需要拉取多路流和推送多路流的场景。以美术培训为例，老师需要推送音视频流、屏幕分享流、白板流，学生推送音视频流和白板流，同时彼此还需拉取其他人的白板流，学生至少需要拉取老师的三路流。因此在实现上有诸多注意要素。

十七、实现流程

首先对于小班课这种多流上行的音视频通话场景，参数上，老师应选择较清晰画面，学生则选择刚好能看清表情和嘴型的画质即可。以下是推荐的分辨率与帧率，及对应的码率，如果已知网络环境较差或学生数量较多，可以适当下调。

教师与学生端推荐视频参数：

其次，在 TRTC Web SDK 中，多流的推送需要使用多实例进行实现，大致思路如下：

注意：如果 1v5 小班课，则每个用户需要推1路，拉5路，共需要6路视频带宽；如果 1v10 小班课，则每个用户需要11路带宽。需要注意的是，在测试环境，测试机器通常连接在同一个路由器下面，11个用户都在一个路由器下面，则该路由器需要 11*11=121 路视频带宽。如果要在测试环境测试10个 user 的压力，实际上只要开3个 user 就能达到类似效果。

不同分辨率与码率下的带宽要求：

十八、时序图

学生端相较于教师端，有以下变化：

·登录时为检查是否为学生账号。

·推摄像头麦克风流时，默认不推麦克风流或默认闭麦。

·不推屏幕分享流。

·视情况不使用白板。

十九、点名与举手

小班课看似和公司小组开会、培训是一样的场景，但由于专门的线上课老师有自己严格的课程节奏安排以及课时要求，学生不能随意开麦发言打断，因此需要交互时，要么由老师点名或学生自己举手，抽象来看这就是一个简易的麦位管理。

20、实现流程

可以使用腾讯云 IM 的信令，信令接口是基于 IM 消息提供的一套邀请流程控制的接口，可以实现多种实时场景，例如：

·直播聊天室中进行上麦、下麦管理。

·聊天场景中实现类似微信中的音视频通话功能。

·教育场景中老师邀请同学们举手、发言的流程控制。

1. 老师调用接口邀请同学们举手，同学们收到回调。

2. 同学们根据回调中的邀请列表和字段判断被邀请者里有自己且是举手操作，决定是否举手。

3. 如果有学生举手，所有人都可以收到有人举手回调，并展示举手学生列表。

4. 老师从举手成员列表中邀请某个同学进行发言。

5. 学生收到邀请连麦的回调，决定是否发言。

6. 如果有学生发言，所有人都可以收到有人发言的回调，展示发言成员列表，并打开该学员的麦克风。

7. 结束连麦时，关闭该学员麦克风。

22、互动白板

多人实时白板互动，支持互动涂鸦、轨迹实时同步、文档共享、媒体共享、文档转码、白板与音视频实时同步录制、回放。支持多用户同时涂鸦、全套画笔标注工具（画笔，直线，矩形，圆形，颜色选择，画笔粗细）、翻页同步。覆盖主流平台，Android、iOS、Windows、Mac、Web、小程序端使用 SDK 接入，集成接入方便简单。支持在云端与教学音视频同步录制，解决白板内容与教学音视频分别录制带来的不同步问题、后期混流成本高等问题。支持多种格式文档转码，支持动态、静态文档转换，可将 PPT、Word、PDF 等文件转换成 HTML5 页面或图片。主要应用于线上语言培训、K12 学科辅导、STEAM 教育等线上课堂场景。

23、实现流程

其中，对于白板推流，在 教材管理 中有详细的流程图，不再赘述。

首先是白板的摆放与大小的计算：

1. 先把老师视频宽高、学生视频宽高、聊天区域宽高确定，剩下的部分都用作白板区，然后根据实际课件与 UI 需要，计算出白板的实际大小。

2. 白板窗口的比例最好与课件的比例一致，否则容易产生显示时出现错位，和背景图片以及课件内容无法对应上，通常有窗口尺寸有三种方式适配。先确定用哪一种方式适配，通过计算窗口的比例。

3. 如果因特殊原因课件比例不固定，必然会出现比例不适配，那么会出现以下三种情况，这里罗列了不同比例下实际内容的展示效果，请开发者自行斟酌是否要动态调整白板的大小。

总结：宽度比 widthScale = W1/W2，高度比 heightScale = H1/H2。

·如果 widthScale < heightScale，则纵向留有空隙。内容缩放的比例以小的值为准 contentScale = widthScale；

·如果 widthScale > heightScale，则横向留有空隙。contentScale = heightScale；

·如果两比例相等，则两个方向没有空隙。contentScale = widthScale = heightScale。

26、实现流程

在 录像管理 中，已经简单介绍了几种录制方式，这里将详细叙述使用流程：

1. 学生、教师单流录制

·全局录制方案

·单流全局录制是默认的方案，在 实时音视频控制台 – 应用管理 页面中，点击目标应用的配置，点击左侧列表的录制管理，在右侧的云端录制配置中开启云端录制，并选择全局自动录制即可实现，自动完成后续录制操作。

·录制的单流，可以为后期做语音识别，专注度识别做大数据沉淀。

·自动停止，即每个主播在停止音视频上行后，该主播的云端录制即会自行停止。如果你在选择文件格式 时设置了续录时间，则需要等待续录时间超时后才能收到录制文件。

·指定用户录制方案

在开启云端录制时，需选择指定用户录制（推荐），使用SDK创建实例/进房时，需设置录制参数。

利用服务端混流接口可混单流的机制，调用 StartMCUMixTranscode 时指定OutputParams.RecordId参数即可开始录制。

2. 整体课堂录制

若需要看到整个课堂的回放录像，则需要使用混流功能将以上需要的单流整合至一个录像文件。

混流是音视频通话应用中的核心技术，通过设定参数，可以将多路不同终端的音视频流、屏幕分享流、特殊渲染流等整合在一路画面并设定各自的视频参数、位置，并以直播协议（rtmp,flv,hls）推送出去，使得不在音视频房间内的观众，可通过播放器的方式播放推送地址进行单方面的观看。

同时旁路转推后为直播协议，依然可被录制服务转码成为 mp4 等视频格式的文件，保存在存储中。

混流的基本使用方法请参见 云端混流转码。

27、时序图

注意：1. 请注意，在客户端混流情况下，若你还在房间中且不再需要混流，请务必再次调用混流接口并将 config 设置为空以进行取消，不及时取消混流可能会引起不必要的计费损失。当你退房时 TRTC 会自动取消混流状态。

注意：2. iOS、Android、Windows、Mac、Electron、Flutter 和 Web 平台的 SDK 有客户端混流的 API，如果你希望在微信小程序上也实现混流功能，请使用服务端混流。

注意：3. 原生端中，TRTCTranscodingConfigMode_Template_ScreenSharing适用于在线教育场景等以屏幕分享为主的应用场景，仅支持 Windows 和 Mac 两个平台的 SDK。 该模式下，SDK 会先根据你通过 videoWidth 和 videoHeight 参数设置的目标分辨率构建一张画布。

28、方案配套产品