场景描述
概述
大班课是指课堂中一名教师教学，成千上万学生观看的教学模式。大班课方案覆盖绝大多数直播教学场景，方便教师快速开课使用，适用于 K12 教育、留学语言培训、职业技能培训、公考求职，兴趣培养等多种大型直播课程。
?
需要特别提及的是，狭义上大班课为上图这种典型应用，但出于运营方的需要，大班课实际还分为真直播课和伪直播课。真直播课指的授课老师在直播时段内真实进行直播，而伪直播课则是将提前录制好的上课视频以不能加速，不能快进跳转的方式加载进入播放器给学生观看。
真直播课有实时性、互动性，老师可以通过弹幕、评论、与学生连麦提高上课的正反馈，缺点是上课有可能会发生意外，考验老师的功底和备课情况。而伪直播课则是无法互动，其本质是点播视频，无风险，也不会用到 TRTC ，因而伪直播课的大班课，不在本章节的介绍范围内。
除这种分类外，还有一种特殊的直播公开课，即把小班课的上课内容混流转推给观众，是与前者小班课业务结合的复合型。
选型
大班课需要用到通话与直播功能，目前腾讯云上使用直播的方式主流有两种，一种是云直播（Cloud Streaming Services，CSS），另一种是 TRTC 实时音视频。其中 TRTC 实时音视频的直播功能实际也是借用了云直播的部分底层能力，转推为直播流，他们的特点优劣势大致如下表格，请读者根据自己需要的业务场景进行选择。
类别 | 云直播 | 实时音视频 |
协议类型 | RTMP/HLS/HTTP-FLV | UDP 私有协议 |
延时 | 根据协议 1~30s 不等 | 低至 100ms |
SDK类型 | iOS、Android、Web、小程序 | iOS、Android、Web、小程序、C++、C#、Flutter、Electron、uniapp |
CDN | 本身即 CDN 播放 | 可旁路转推为云直播 CDN |
互动性 | 没有互动性，需使用其他产品实现 | 1v1/1vN 的连麦与视频通话 |
播放方式 | 可使用支持直播链接的播放器直接播放 | 需要接入 SDK 拉流播放 |
使用限制 | 推流播放域名须已在工信部备案 | 无 |
费用 | 按流量/带宽收费 | TRTC 按使用时长收费，转推按云直播收费 |
简而言之，单纯的云直播适合无互动、单向内容输出的场景，而实时音视频适合需要和学生连麦通话等场景。至于 SDK 和协议的差异则是硬性条件，请读者根据自己期望上线的平台做选择。价格上实时音视频收费更高，并且如果转推还需要再收取一份云直播的费用。
实现方案
整体大班课 App 分为四个角色：老师、教务平台、助教、学生。每个角色在小班课中均有各自负责的功能。老师主要负责课程的内容与上课；教务平台在大班课中更多是承担管理直播间、后台管控直播流、审核直播内容、发放讲义以及一些后台技术行为；学生观看上课直播与通过弹幕和聊天窗与老师互动；助教负责管控直播间。大班课场景整体的参考业务流程如图所示，具体情况可根据自身业务情况与需求调整。
?
以下是大班课场景通常涉及的功能模块：直播管理、角色管理、账号管理、录像管理、流管理、教材管理、课程管理。如图所示，本章节将会对这几个业务层的方向进行介绍，下一章节将会对核心功能进行介绍。
?
直播管理
不同于小班课，小班课的房间是教室的抽象化，而大班课的房间是直播间的抽象。直播间最重要的两个功能：并将直播内容推送出去；邀请他人进入直播间互动。
需要注意的是，如果学生量级较小（一般指千级以下），则可以等价于小班课 + 学生不推流的模式，这里不再重复赘述，下面的讲解都将围绕与小班课差异较大的万人及以上的直播大班课模式讲解。
大班课中，直播间的管理一般不在老师端，而是由后台管理系统（教务系统）负责，类似于直播中的导播间。可以开启直播，关闭直播，切换直播流等。老师只决定直播内容和邀请他人进入直播间。
该直播间的本质依然是一个 TRTC ROOM，只是对于学生端来说，他们所看到的是该房间旁路转推出去的直播流，换句话说，学生并没有实际进入TRTC ROOM，仅仅只是使用播放器来观看直播，仅当学生与老师需要连麦时，学生才需要进入 TRTC ROOM。
?
1. 推流侧
直播间则是一个 TRTC 的房间，老师并不关心在 TRTC 房间内的各种流是如何被教务后台操作转码推流出去的，TRTC Room 即是教师端的推流器。所以教务管理平台根据这种差异，需要实现对应不同直播的功能：
?创建直播间
?开始直播（后台执行混流转推）
?切换直播流
?停止直播流
?关闭直播间
而对于教师而言，只需要进入房间之后开启相关设备即可，无需做其他复杂操作。
2. 播放侧
直播间是观众（学生）所能感知到的实际房间，在这个房间中，则是包含了各种各样的业务功能：实时音视频通话、播放器观看直播、聊天互动等，对应技术构成如下：
?连麦 —— TRTC
?聊天互动 —— IM
?生成直播间二维码，学生连麦
?播放器、弹幕 —— TCPlayer
角色管理
对于整个业务系统来说，我们有授课老师、学生（观众）、助教身份，以及可能存在试听人员。
?老师从直播开始时就一直在 TRTC 房间内，拥有麦克风、摄像头、屏幕分享、白板推流、请人上麦等一系列房间内权限。
?助教只能拉流，但拥有禁言和踢人的权利。
?学生没有与老师连麦前，只有拉流观看权限。一旦上麦后，学生只有开启或关闭自己的麦克风，和结束连麦的权限。
?教务系统不算角色，但确实存在与其他角色不同的权限，拥有直接关闭直播间的能力（关闭后直播链接会失效，直播流停止推送）。如果遇到需要紧急关闭直播间的情况，则需要教务系统进行管控，也可以兼任封号。
?机构有临时让游客或者待成交的学生、家长进入直播间体验试听的需求，可以支持试听人员进入直播间试听体验，试听学员不能使用摄像头、麦克风、不能参与试卷互动、也无法进行打字聊天等操作，相当于一个旁观者。
功能 | 授课老师 | 学生 | 助教 | 教务平台 | 试听人员 |
推流 | Y | 可选 | N | N | N |
拉流 | Y | Y | Y | Y | Y |
打字发言 | Y | Y | Y | N | N |
禁言踢人 | Y | N | Y | Y | N |
封号 | N | N | N | Y | N |
直播间管理 | N | N | N | Y | N |
账号管理
和教室与房间一样，整个业务系统需要有一个自身的账号体系，同时进入 TRTC Room 也需要有 userId，IM 也需要。账号一般分为：老师账号、学生账号、助教账号、游客账号。游客账号通常只有试看的权限。
可以用业务自己的 userId，如果为了保密，可以自己做一层哈希的映射，把 userId 映射为唯一对应的 TRTC 和 IM 的 userId，且 userId 需要唯一。在 Web 端的场景下，如果用到屏幕分享，则一个用户角色需要两个 TRTC userId，一个 userId 用来推视频流，一个 userId 用来推屏幕分享流。而在原生 Native 端环境下，则是在同一个 userId 下，则可以用主流推摄像头流，辅流推屏幕分享流。
同时，如果业务的账号系统本身不允许多端登录，那么自建账号系统还需要检测是否已登录或顶替下线的功能。
?
为管理不同学生的上课权限，可以给学员划分同样场景的组别，这样在创建课程的时候，可以将同一组别的学员账号批量设置进一个课程中，便于机构统一管理，创建课程的时候将预设的分组信息直接设置进课程里。
录像管理
在远程教育应用场景中，考虑复盘、质检、审核、存档和回放等需求，常需要将整个视频通话以及各自的视频流录制和存储下来。而实时音视频流本身无法录制，需要将其转推为可录制的直播流格式。
?基于云点播，能将录制的内容在播放器中播放。
?在大班课场景中，录像一般直接录制混流后的视频即可，无需录制单流。
?大班课的录像时常需要做限时回放（公开课、试听课等），限时回放可以通过设置 Key 防盗链来设置过期时间，也可以通过自己的业务逻辑管控。
?助教可根据上课内容，或方便后续视频运营，可以对录像做以下操作：
在混流时， 在
LayoutParams下填写 WaterMarkParams实现水印；使用录制 API，可填写
DynamicWatermark实现水印；截图视频一帧为视频封面（ iOS 与 Android 支持，使用 snapshot 方法 ）；
视频拆条、剪辑、生成多个新的点播视频；
其他播放器常见功能可见腾讯云 播放器 SDK，您可根据该列表判断自己的相关点播、直播附加功能能否基于该 SDK 本身的接口实现。
?
一般从老师点击“开始上课后”，才开始调用录像接口，这样可以防止过早录像，前面一段时间后台要二次处理剪辑。混流录制，把白板、多个学生、老师的视频做混流后再录像，这样是一个完整的录像文件，课程回放不需要做多路视频和白板的时间戳对齐。
教材管理
教材管理主要分为两部分：
给白板使用的上课素材。
教材库/文库，可供学生课前/课后下载反复查阅。
?
提前把绑定课程的教材上传到白板后台，可节约动态 PPT、静态文件的转码时间。如果有大的视频文件，需提前上传到后台，如果放在上课过程中临时上传会占用老师带宽导致网络卡顿。
教材展示
?
方案架构
在大班课中观众不需要进入 TRTC Room，因此只需要将白板流在混流时加入即可。
?
具体实现
开发者需要将需要展示的教材加载到白板上，这里需要用到互动白板提供的转码功能，将其加载进白板的流中推送出去。
教材类型 | 转码类型 | 输出格式 | 动画效果 |
ppt、pptx、doc、docx、pdf | 静态转码 | jpg | 不保留 |
ppt、pptx | 动态转码 | h5 | 保留 |
视频文件 | 无需转码，使用 addVideoFile | \\ | \\ |
?
API 调用时序
?
教材共享下载
当文件成功上传至 COS 时，COS 会提供下载链接。
业务方可通过 COS 的 API 拉取存储桶及对应的文件列表。
可在 COS 的控制台设置权限管控，只允许特定用户或特定链接下载文件。
存储在腾讯云对象存储（Cloud Object Storage，COS）中的内容，需要符合相关法律法规。
流管理
大班课的流从推流端（老师端）和小班课并没有很大差异，主要区别在于学生不会使用到摄像头，只是连麦，因而不需要考虑分辨率等问题，重点讲述从混流到观众播放器这一条链路。
音视频流
在大班课场景中，音视频流主要为老师端推流，学生连麦时推送音频流即可。
屏幕分享流
在 TRTC 中，提供了专门的 API 或参数打开屏幕分享。屏幕分享默认有视频流与音频，视频流为选择的窗口，音频流为系统音量。
注意：
如您在 Web 端上使用屏幕分享，采集系统声音只支持 Chrome M74+；在 Windows 和 Chrome OS 上，可以捕获整个系统的音频；在 Linux 和 Mac 上，只能捕获选项卡的音频。其它 Chrome 版本、其它系统、其它浏览器均不支持。
在 Web 端，屏幕分享与音视频流，甚至第三条第四条其他流，均是独立平级的。但在原生端默认情况下，屏幕分享使用辅路画面。如果使用主路做屏幕分享，您需要提前停止摄像头采集 stopLocalPreview 以避免相互冲突。且同一个房间中同时只能有一个用户使用辅路做屏幕分享，也就是说，同一个房间中同时只允许一个用户开启辅路。
白板流
除去推流相关问题，在大班课的场景中，由于媒体流走的是直播链路，其延时是远于 TRTC 的。常见的白板使用方法有两种：把白板可以作为媒体流合并其他流一起推流；或者在观看端也集成白板 SDK，通过信令的方式同步并还原白板涂鸦。但如果是后者，由于信令的传输速度远大于媒体流，这样会导致白板的轨迹动作先于视频声音发生，就出现了音画不同步。
为解决这种情况，可以将白板作为一路流和其他媒体流推送（即方法一）。但该方法只适用于腾讯云互动白板，只有腾讯云互动白板可以将其白板内容传输到云直播后台用于混流，如果是第三方的白板软件 SDK 则无法走到云直播后台，这种情况下就需要使用信令发送时间戳做业务对齐，或者把整个白板放在屏幕分享里发出去（但这样白板效果没那么好）。因而如果条件允许，不建议自实现或接入第三方白板，强烈建议使用腾讯云互动白板保证良好的生态。
合成流
合成流指的是，TRTC Room 内的白板、屏幕分享、摄像头麦克风等媒体流通过混流的形式合成为一路流进行推送，在之前的 录像管理 模块中我们已经介绍过了，录像就是这个合成流的备份文件，存储在云点播后台。而对于整个业务系统而言，仅有 TRTC Room 内不会用到合成流，管理后端、观看端、助教端都是在合成流的基础上进行处理。合成流有以下重要概念：
CDN 推流拉流
合成流将以 CDN 的形式推送出去，观看端将会获得一个直播链接，将其放入支持直播观看的播放器即可观看拉流。
该直播的清晰度，由混流决定，大班课有且推荐服务端混流，由于客户端混流只能混出一路流，而直播的观众端常有切换不同清晰度的需求，这就需要通过服务端混流混出多条分辨率不同的合成流，而且服务端混流也方便后台教务系统进行查看和管控。
观看端切换线路一、线路二，以及切换清晰度的本质是切换不同的播放地址。
在 TRTC 和云直播的合作下，不需要推流域名，会自动生成，腾讯云会默认在您的云直播控制台中增加一个格式为?
xxxxx.livepush.myqcloud.com 的推流域名，该域名为腾讯云直播服务和 TRTC 服务之间约定的一个默认推流域名，暂时不支持修改。播放域名需要由用户自行填写已备案过的域名，域名添加成功后，系统会为您自动分配一个 CNAME 域名（以 .liveplay.myqcloud.com 为后缀）。CNAME 域名不能直接访问，您需要在域名服务提供商处完成 CNAME 配置，配置生效后，即可享受云直播服务。具体操作请参见?CNAME 配置。
视频安全
直播链接需要进行防盗或加密，混流输出后直播流的费用，是和拉流次数（观看者人数）相关的，如果没有加密，有人利用程序大量的播放视频地址，就会产生大量的费用。以下是目前行业内实现视频安全的几种方案：
设置防盗链：防盗链计算。
筛选观众：直播内容不允许让观众随意观看，希望满足某些条件的人群才能观看，例如会员、已登录过的用户、完成购买的用户、发送一次性邀请码等。
版权限制：直播内容的版权方有明确的限制，必须在可信的安全环境下播放。例如迪斯尼电影、中国的电视台直播等。
更多视频安全方案及实现细节请参考 直播播放安全。
直播 License
在移动端开发中，播放器需要 License 才可以播放直播流。
在 Android 和 iOS 端播放直播流，需购买指定规格直播/点播流量资源包赠送视频播放 License 一年使用授权或购买独立视频播放 License 一年使用授权。
在 Web 端播放直播流，可以直接使用 video 标签播放，但具体支持哪些协议，需要看浏览器的支持情况。
直播审核
基于网络内容质量审查的需求，内容产出方对直播内容负有监管责任，人工审核压力太大，并不适合所有规模的公司，TRTC 提供了如下审核方式。
手动自定义审核：客户需要调用天御音视频流接口即可实时检测音视频流中是否出现违规内容，音视频安全审核服务会通过回调把违规信息发送给客户指定的回调 URL。
全局自动审核：客户可指定审核策略和审核流类型，TRTC 云端自动帮忙完成应用下所有房间内的音视频内容审核，并通过回调把违规信息发送给客户指定的回调 URL，无需手动发起审核。
水印
无论是录像还是直播，出于对知识产权的维护，除了通过防盗链保证其不在程序层面被盗用之外，录屏等操作也是需要杜绝的，一般来讲水印由两部分组成。
内容产出方水印，例如在课程会打品牌水印。
用户水印，画面页面上也会合入观看者用户的 id 或昵称作为水印，该水印往往会在视频上按一定速度线性移动，防止有人通过视频加工的方式掩盖它。一旦发现有人采用录屏或其他的方式将视频泄露，可以通过该水印判断泄露者，方便进行维权。
课程管理
课程管理模块是大班课和小班课的差异点，由于大班课并不确定有多少人会来上课，会上多久的课，也不会有人监课，因此对于上课情况的数据监控是必须有的环节。以下是对大班课的课程管理中，常用的一些课程逻辑进行介绍。
直播数据统计
1. 上课时长：一般指学生在直播页面里停留的时长，停留时长 ÷ 课程总时长 = 课程存留率，可以用该指标判断课程对学生的吸引程度，便于运营方对课程内容和相关策略做出优化双开页面不能加倍统计上课时长，常用的方案为：
一个账号 uid 在同一时间只能计算一次时长不能累计。
不允许一个账号多页面同时登录，登录一方时自动踢掉另一方。
2. 直播并发统计：指的同时间在直播间内的人数峰值，可用于宣传、评估流量消耗和服务器荷载。
3. 地域分布：根据播放端的 IP 地址来源，收集观众的地域分布，根据用户的地域分布可以更有效率更有针对性的开展线下活动，进行推广。
4. 弹幕数、聊天区发言数：衡量上课效果的维度之一。
5. 问答数据：教师使用答题器时，可通过该数据查看问题的回答分布情况，决定讲解时长。
课程设计
由于大班课观众的流动性，用户并不能保证自己除去直播上课之外，课后观看回放也是用户会选择的学习方式，而无论是直播还是看录像，往往都需要上课时长达到某个时长时才可以签到，签到一定次数后才可以获得某些福利。其次，除了签到之外，课程本身还有很多数据需要统计，下面将介绍与课程相关的逻辑。
1. 直播自动签到：根据 直播数据统计 - 上课时长，当在直播间内的时长达到某个阈值时自动触发后台逻辑签到。
2. 回放自动签到：根据点播课程的播放时长判断，当播放时长达到某个阈值自动签到。
倍速播放不会翻倍计算时长。
阈值一般设计为课程时长 ÷ 最高倍率的播放速度，如最高为2倍速，直播时长为2h，则阈值设计为1h，阈值设置过高会导致倍速看完整节课都无法达成打卡条件。
3. 上课总时长：指以账号为维度，该账号总共观看直播课与课程回放的时长，可用于判断课程价值和回头率。
4. 课程播放量：分别记录每一场课程录像的播放量，该数据可用于统计当前的学员对某项课程讲解内容的感兴趣程度，方便运营方做相似课程的衍生设计。
5. 课程最高留存率片段：4的升级版，运营方可根据 播放器 SDK 中的切片功能，将老师上课的录像根据教学大纲进行切片或在完整的录像中打上标签断点，由后台统计学员对于哪个片段更感兴趣。
6. 试看：出于运营的需要，除了购买了课程的学员，运营方可能会将播放量较高视频公开，但限制观看时长，这就需要用到试看功能。
关键业务逻辑
本章节将会对核心功能层的业务逻辑进行讲解，提供流程图、调用时序图以及相关 API 的关键参数。
对于大班课，老师端使用桌面端（ Windows/Mac ）比较多，学生端则是移动端（ Android/iOS/小程序）、iPad、Web 较多。对于桌面端，可以使用原生语言集成，也可以使用跨平台 QT 框架集成。由于涉及的终端较多，通用模块将会使用伪代码的方式带过，具体接口用法可参考官网对应的语言的 API 文档。常见各端对应语言如下表所示：
教师端语言推荐
终端 | 原生 SDK 方案 | 跨平台方案 |
Windows | C# 、C++ | Electron、QT |
? | Mac | Swift、OC |
学生端语言推荐
终端 | 原生 SDK 方案 | 跨平台方案 | ||
Android | Java | QT | Flutter React Native | uniapp Taro(React) |
? | ? | ? | iOS | Swift、OC |
? | ? | ? | iPad | Swift、OC |
? | ? | Web | html css js | - |
? | 微信小程序 | wxml wxss js | - | - |
注意：
QT 是目前唯一可以覆盖所有移动端和桌面端的语言，但需要注意兼容性，尤其是在 Mac M1 及以上 CPU 版本的电脑中，兼容性尚不能完全保证，据官网的说法，QT6.2 的预览版才刚支持 M1 芯片，使用前需谨慎调研当时 QT 版本的支持情况。
uniapp 广义上虽然跨所有平台，但由于 TRTC 微信小程序 SDK 、Web SDK 本质上并不是用同一套，因此如果需要实现跨五端则需要使用大量的条件编译进行实现，开发效率并没有想象中的高，Taro 同理。如果只需要使用 uniapp 跨 Android 与 iOS，则可以直接使用原生的 uniapp SDK，Web 端需要使用 Web SDK，小程序的实现可参考该文档 uniapp - WXMini，因而实际上是用多套 npm 进行开发，并不能一个 SDK 完成所有场景。
Taro 大部分问题同 uniapp，需要注意的是，虽然 Taro 对小程序的支持更好，但腾讯云并没有对 Taro 做相关 SDK，同时 Taro 对原生的支持实则依赖打包工具将 Taro 打包成 React Native 实现，兼容性并不乐观。
如果不需要小程序，最为推荐的跨平台实现方案为 Flutter。
大班课群组管理
在大班课场景中，需要有对应的讨论区，以便课堂内的互动交流。
实现流程
1. 由教务系统来创建直播间，通过调用 即时通信 IM 的 REST API 接口 进行 创建群组，创建群组时即可同时设置相应的群资料；
3. 可以通过即时通信IM的 SDK 接口 即可获取在线人户，也可以通过 REST API 接口，获取该群组实时的在线人数；
?
?
注意：
即时通信 IM 群组类型有多种，针对大型直播课，推荐使用 直播群 AVChatRoom，该群组无人数上限要求，其它群组均有群组人数限制。
时序图
?
文本安全审核
课堂中进行互动交流，需要对交流的内容进行过滤处理，避免出现敏感内容，以免对业务带来影响。
实现流程
当学生发送了一条消息后，这个消息会请求到 即时通信 IM 的后台，会通过 群内发言之前回调 请求到客户的业务后台，客户业务后台需要在 2s 以内做出响应，如：修改消息内容、拦截消息、允许下发等，按照相应的返回格式，返回给 即时通信 IM 后台，IM 后台接收到响应后，根据相应内容做出是否下发消息等操作。
?
?
时序图
?
禁言踢人
禁言就是让其无法进行发言，禁言时长，根据业务需要进行设定；踢人就是将其踢出房间。在课堂中，如果遇到捣乱的学生，需要对指定的学生进行禁言、踢人操作，避免扰乱课堂的开展。
实现流程
助教和老师，都可以对直播间的学生进行禁言、踢人操作。
对于踢人操作，这里相对复杂。当为直播群时，直播群不保存群成员列表，无法进行踢人操作，这里要进行“踢人”，可以变换一种方式进行达到效果，即当发起踢人操作时，请求会先到教务后台，然后教务系统通过 即时通信 IM 服务端接口，发送一条自定义消息给指定人，当他收到时，主动去调用退群接口，即退出群组，达到踢人的效果。
?
注意：
好友工作群（Work）、陌生人社交群（Public）和临时会议群（Meeting）成员人数上限最高支持付费拓展到6000人；社群（Community）最高支持10万人；直播群（AVChatRoom）成员人数无上限。
即时通信 IM 群组类型为 直播群 AVChatRoom ，该类型为大型直播时特别适用，人数众多，人数量级达到千万，不提供拉取全量成员列表的功能，不支持踢人操作。
如果业务场景中，直播间人数不会超过一定量级，可以直接调用 服务端接口 踢人，
时序图
?
白板轨迹和音视频同步
这里适用于自研白板的情况，建议使用腾讯云互动白板，不需要自己处理以下场景遇到的问题。
大班课场景，除了房间内的学生，还可能会存在直播观众。一般百人-千人的大班课，可以全部走房间通道。达到万人，则建议一部分走直播通道观看。当需要走直播通道时，因为视频时延比信令时延大，则会出现白板轨迹与音视频不同步的情况。以下会分三个场景：
场景一：千人以内大班课，老师学生都在同一个房间，视频和信令延时可以忽略。
?
场景二：千人以上，一部分学生进房间，一部分房间外的学生通过拉混合流观看。
进房的这部分逻辑同场景一，不存在时延差。
房间外的学生，使用 TRTC 后台接口混流，把白板流和视频流混合，通过直播的方式给房间外的学生观看。该场景适用于使用腾讯云互通白板的情况。
如果是自建的白板，可以使用屏幕分享的方式把白板区域推流到 TRTC，使用 TRTC 后台接口混流。但如果本身有屏幕分享功能的话，屏幕分享流会被占用，也就是同一个进程不适合同时进行2个屏幕分享。此时可以用方案三。
?
场景三：千人以上，一部分学生进房间，一部分房间外的学生通过拉单流对齐白板信令的方式。
以本地时间线作为参考，在视频流和白板信令中实时插入时间戳。
播放端，播放老师视频时，通过播放器获取到插入到视频中的时间戳，加载相近时间戳的白板轨迹。
?
实现流程
场景一和场景二的实现流程比较简单，这里主要列举场景三的实现流程。
?
自建白板的信令，可以用 IM 的自定义消息封装，在自定义消息中增加一个自定义 timestamp 字段，用于记录当时发送的时间。
如果有自己的信令通道，或者第三方 IM，也是类似的方式，在数据结构中增加自定义时间戳字段。
时序图
?
注意：
H264 视频流默认的 SEI 帧类型是 0x0605，TRTC SEI 类型是 0x06F3，在播放 TRTC 旁路直播流时，可以加上判断；
如果想把 SEI 类型改为默认类型的话，TRTC 提供有实验性接口，可以把 SEI 类型改为 0x0605，这样播放器就不用做类型判断了。
SEI 信息发送频率和大小都有限制，所以我们要尽量精简 SEI 信息的大小，可以控制在1s 插入一次 SEI 即可。
SEI 信息的发送限制：
发送消息到房间内所有用户，每秒最多能发送30条消息（与
sendCustomCmdMsg 共享限制）。每个包最大为1KB，若发送大量数据，会导致视频码率增大，可能导致视频画质下降甚至卡顿（与
sendCustomCmdMsg 共享限制）。每个客户端每秒最多能发送总计8KB数据（与
sendCustomCmdMsg共享限制）。方案配套产品
系统层级 | 产品名称 | 场景用途 |
接入层 | 提供低延时、高品质的多人音视频实时互动直播解决方案。在此场景下，老师和学生之间可以低延时地视频互动。 | |
接入层 | 提供基于群组功能的房间管理、消息的收发，以及自定义信令等通信需要。在此场景下，可以用 IM 的文本消息聊天，用自定义消息封装教室状态、控制状态。 | |
接入层 | 提供整套完备的多人实时白板互动服务，打破线上教学中师生信息传递障碍，拥有比面授教学板书更丰富、直观和多样的功能。在此场景下，可以用各种 PPT、Word、PDF 教材的同步操作，在教材上同步涂鸦、批注等。 | |
云端服务 | 提供实时音视频的旁路转推，以及加速媒体流的分发服务，此外还具备录制、鉴黄等附加能力。在此场景下，可以做后台监控、视频录制、旁路拉流做 AI 表情专注度分析等功能。 | |
云端服务 | 面向音视频、图片等媒体，提供制作上传、存储、转码、媒体处理、媒体 AI、加速分发播放、版权保护等一体化的高品质媒体服务。在此场景下，可以做视频录制文件的二次转码和加工。 | |
数据存储 | 提供音视频录制文件、音视频切片文件的存储服务。在此场景下，可以把录制文件转移到 COS 作为长期存储。 |
?
