Multiview
Multiview monitors RTSP, SRT, RTMP, or NDI inputs together in one browser-based multiviewer. Add a camera or media-server RTSP URL directly; an SRT or RTMP conversion stage is not required just to show it on the board.
Choose this whenOperators need one browser wall for multiple SRT, RTMP, or NDI feeds.
Use another module whenUse Web Players for audience playback; Multiview is the operator monitoring surface.
/api/multiview/createBefore you start
Use x-access-token to configure, start, stop, and create authenticated viewer sessions. If visibility is PUBLIC, anyone with the multiview ID can use its public view, statistics, and join methods, so share the ID only as widely as intended.
What you can do
createstores the multiview, layout, visibility, and initial inputs; an empty input list is valid.updateapplies the complete desired input list and layout.getAll,getCount, andgetByIdinspect saved multiviews.startandstopcontrol the monitoring runtime.joinreturns the browser session details for an authorized viewer.removedeletes the multiview.
Example workflow
- Create a private multiview with the required layout; the input list can initially be empty.
- Update it with the full set of RTSP, SRT, RTMP, or NDI inputs.
- Start the multiview and call the authenticated join method.
- Open the returned viewer session and confirm each input's live status.
- Send the full desired list on later updates; omitted inputs are detached.
Common use cases
- Monitor RTSP cameras directly without building a separate SRT/RTMP bridge.
- Monitor primary and backup contribution feeds in a control room.
- Give a remote producer one view of cameras, program output, and return feeds.
- Compare regional or language outputs before distribution.
Limits and troubleshooting
Correct missing or invalid names, RTSP URLs, input IDs, visibility, or participant data before retrying. A multiview can remain available while one of its inputs is offline, so check each input's live status separately. Add a processing pipeline only when a source needs transcoding, resizing, audio changes or a separate delivery protocol.
Next steps
Connect the intended feeds, validate the join experience, and expose public access only when the multiview is meant to be shared.
Create and manage an operator multiview
Create the wall with reviewed input tiles, update the layout without replacing its identity, start it, and inspect the saved resource before sharing a public room.
- Create the video wallDefine source tiles, layout, visibility, and operator settings.
POST /api/multiview/create - Update tiles and layoutSend the existing id with the complete desired room, source, visibility, and layout state.
POST /api/multiview/update - Start the wallStart the saved multiview only after its input resources are available.
POST /api/multiview/start - Read the managed wallConfirm the saved source and visibility state through the authenticated resource before exposing a public id.
POST /api/multiview/getById - Read room statusUse the public status call only for an intentionally public room.
POST /api/multiview-public/getStat
Treat a public multiview id as shareable access material. Keep private operator walls behind the authenticated management methods.
Ingest one contribution feed, monitor it in Multiview, and record it
Provision SRT ingest first, attach its returned resource id to a private Multiview tile, then reuse the same healthy source in a recording job.
- Create contribution ingestConfigure the listener, access policy, latency, and routing; retain the returned SRT server id.
POST /api/srt-servers/create - Start the ingestStart the listener and confirm the contribution source is connected before building downstream resources.
POST /api/srt-servers/start - Create the private wallCreate the Multiview shell with its layout, visibility, and overlay settings.
POST /api/multiview/create - Attach the SRT tileSet the tile source_id to the SRT server id and use the documented SRT software source kind.
POST /api/multiview/update - Start operator monitoringStart the updated wall and join it through the authenticated operator path.
POST /api/multiview/start - Create the archive jobSelect the same SRT server through the recording module's SRT input preset and choose the archive format and mode.
POST /api/recording/create - Start captureStart recording only after ingest and the operator wall are stable.
POST /api/recording/start - Verify capture healthMonitor bitrate, frame cadence, output time, speed, and progress independently from the wall.
POST /api/recording/getStat
Create Multiview currently starts with an empty inputs list. Add the SRT tile with update, using source_kind INPUT_TYPE_SRT_SOFTWARE and the SRT server id as source_id. The recording create call needs its own SRT input preset; the Multiview id is not a recording source id.
Create a multiview and, unless active is false, start its inputs and conference. The user scope comes from the API token; do not send user_id.
Next call: use getById to read the saved inputs, then join for an operator token.
A 400 response uses { success: false, status, code, message, details }.
Required operator-facing name, 1–120 characters.
Optional layout identifier. The Engine defaults to 4-tiles.
Optional overlay configuration stored with the wall.
Optional input definitions. Supported runtime source kinds include direct RTSP plus SRT, RTMP, and NDI variants; start with an empty array when you want to provision the wall before attaching feeds.
Optional PRIVATE or PUBLIC. The default is PRIVATE.
Optional initial runtime state. Defaults to active unless explicitly set to false.
Stable multiview identifier.
Operator-facing name.
Selected tile layout, for example 4-tiles.
Normalized video inputs and their runtime bindings.
PRIVATE or PUBLIC.
Conference backing the operator viewing surface.
Whether the multiview runtime should be active.