跳转到主要内容
录制建在 MCU 合流之上 —— 服务端把多路画面合成一路,既可以下发给客户端订阅, 也可以录成文件。

任务类型

McuTaskType 决定服务端做什么: McuTaskType.unknown(-1)是 1.1.0 新增的解码兜底,只出现在事件和详情里,不要拿来发请求。

启动与停止

mcuStop 要传同一个 taskType —— 服务端按类型区分任务。 启的是 mixAndRecord 就不能用 record 去停。服务端的 task_type 是按位组合的(1 录像、2 合流、4 录音、8 直播流),自动录制起的任务可能是 9 这类组合值。 1.4.0 起 mcuStop 接受原始数字,停这类任务直接传 onRoomMcuTask 里的 taskTypeRaw;不传 taskType 则停掉全部。
需要会议开始时自动录制的,在创建会议时设 MeetingCreateReq.autoRecord = true。

布局

LayoutType 有 20 种预置: Cell.bindShare = true 可以把某个格位绑定到共享画面。
adminUpdateLayout 影响的是服务端合流的布局,不是客户端本地的排版。 本地宫格怎么摆是你自己的 UI 事。

监听任务状态

McuTaskStatus 的完整取值:
1.1.0 起 McuTaskStatus 的数值与服务端对齐:1.0.0 及以前是 exception = 2、normal = 3,与服务端错位, 会把「待结束」报成 exception、把「异常结束」报成 normal,真正的「正常结束」则整条丢弃。 按成员名比较的代码升级后即得正确语义;直接拿数字比较的代码需要自查。
exception 必须提示给用户。录制出问题时用户一定要知道 —— 否则他们会以为整场都录上了, 会后才发现没有。errDesc 里有原因,直接展示。

查询

McuRecordDetail 中比较常用的字段: vodKey / vodSize / mcuAt / mcuDur 自 1.1.0 起废弃并改为可选(新服务端不再返回 vodKey / vodSize),分别改用 records、totalSize、beganAt、totalDuration。完整字段见类型定义。 RoomInfo.recordStatus 也能读到当前录制状态,进会时用它初始化 UI。

客户端订阅合流画面

大型会议不要 N 路各自订阅,改订 MCU 合成的那一路:
客户端解码开销不随人数线性上升 —— 这是人多时的主要方案。 渲染就是把 meeting.mcuTrack 交给 SRTCVideoView:
订了 MCU 就不要再逐路订阅同一批人的画面 —— 那是双份带宽。 两种模式应当是互斥的,切换时先退掉另一种。

录制文件在哪

录制产物走资源体系,用 resourcesList 查、presignedGetObject 换下载地址。 见资源与附件。 另外,1.1.0 起 mcuRecordDetail 返回的 records[].addr 是录制文件分片的预签名播放地址(有效期 2 小时,过期后重新查询详情)。

相关阅读