Skip to main content

Overview

Recording and compositing are both done on the server; the client only sends commands and shows the status. Task types are distinguished by McuTaskType: You can also use MeetingCreateReq.autoRecord when creating the meeting so that recording starts automatically once the meeting begins.

Build the layout and task parameters

LayoutData, McuStartReq, and the layout’s Watermark / Tag / Cell / DivList can all be constructed directly; optional parameters have default values:
These types are also Codable; the mapping between fields and JSON keys is in the tables below—if your layout configuration is JSON delivered by your backend, you can also decode it directly with JSONDecoder.

Layout fields

LayoutData: Watermark: Tag: DivList and Cell: For all LayoutType enum values, see Types.

Start and stop tasks

McuStartReq fields:

Change the composite layout during the meeting

Requires the host / co-host role. After the change, the server recomposites with the new layout; clients currently pulling the composite video don’t need to resubscribe.

Query recording configuration and details

Frequently used fields in McuRecordDetail:

Recording state events

When the task state changes, all members in the meeting receive:
You can also read the meeting’s current recording status directly from RoomInfo.recordStatus, which suits initializing a “recording” badge when entering the meeting.

Watch the composite video

Once a stream mixing task is running, clients can pull a single composite video instead of subscribing to members’ video one by one; see Video rendering.