Tech
Once a stream reaches the Media Server, it can be recorded. It doesn't matter how the stream was published — WebRTC, RTMP, RTSP, SRT, or any other supported protocol.
Recording happens entirely on the server side, so the publisher's device doesn't matter either. Whether the stream comes from a browser, a smartphone, or a professional camera, the Media Server handles the recording.
Once recording is complete, the video is available as an MP4 or MKV file, ready to download, store, or play back.
Recording works the same way on every platform. The publisher's application uses an SDK to open a session with the Media Server and publishes the camera and microphone as a stream with a unique name, plus one option: record it.
The SDK only passes this option on; everything else happens on the server. The Media Server writes the received audio and video to a file while the stream is live and finalizes the file when publishing stops.
Viewers are not affected: they play the same stream as before, and the publisher sends it only once, with no extra upload for the recording.
Publisher App
SDK
Media Server
Recording File
Now let's see how to publish a stream with recording enabled from each SDK.
The code looks a little different on each platform, but in every SDK recording is one option of the published stream.
In a browser, the Web SDK publishes the stream, and one option asks the Media Server to record it:
session
.createStream({
name: 'alice-live',
display: localPreview,
record: true,
})
.publish();record: true enables recording of the published stream: the Media Server writes it to a file from the start of publishing until it stops.
On Android recording is enabled in the stream options before publishing:
StreamOptions options = new StreamOptions("alice-live");
options.setRecord(true);
Stream stream = session.createStream(options);
stream.publish();Recording is enabled by options.setRecord(true); the rest is ordinary publishing.
On iOS recording is one more property of the stream options:
let options = FPWCSApi2StreamOptions()
options.name = "alice-live"
options.display = localView
options.record = true
let stream = try session.createStream(options)
try stream.publish()Recording is enabled by options.record = true; the rest is ordinary publishing.
Recording does not have to be requested by the publisher. Your backend can start recording any stream published on the Media Server through the REST API, whatever protocol it came in with: WebRTC, RTMP, RTSP, SRT or any other supported protocol.
The backend identifies the stream by its mediaSessionId and calls /recorder/startup. Nothing changes for the publisher or the viewers: the application keeps publishing as before, and the Media Server writes the stream to a file while it plays.
A single request from your backend starts recording the stream:
const api = 'https://media.example.com:8444/rest-api/v3';
await fetch(`${api}/recorder/startup`, {
method: 'POST',
headers: { 'Content-Type': 'application/json' },
body: JSON.stringify({
mediaSessionId,
config: {
fileTemplate: '{streamName}-{startTime}-{endTime}',
rotation: '20M',
},
}),
});The stream is identified by its mediaSessionId. The optional config sets the file name template and rotation, here a new file every 20 MB.
In a video conference every participant publishes a stream of their own. The Multi Recorder writes all of these streams into a single file: each stream becomes its own pair of tracks, audio and video, side by side in one MP4 or MKV container.
The Multi Recorder is managed via REST API. Your backend starts a recorder with an identifier like multi-recorder://meeting-42, adds streams to it by their mediaSessionId as participants join, removes them as they leave, and terminates the recorder to finalize the file.
One recorder, a stream added for every participant:
const api = 'https://media.example.com:8444/rest-api/v3';
const post = (method, body) =>
fetch(`${api}/multi_recorder/${method}`, {
method: 'POST',
headers: { 'Content-Type': 'application/json' },
body: JSON.stringify(body),
});
const uri = 'multi-recorder://meeting-42';
await post('startup', { uri });
await post('add', { uri, mediaSessionId: alice });
await post('add', { uri, mediaSessionId: bob });
// when the meeting is over
await post('terminate', { uri });Every add puts one more stream into the same file as its own audio and video tracks; remove takes a stream out when a participant leaves.
The Media Server writes every stream into a container that suits its codecs. By default H.264 streams are recorded to MP4 and VP8 streams to WebM; the container for each codec is set in the server settings, so you can switch to MKV or record H.264 to WebM instead.
Audio-only streams are always recorded to MP4 with AAC audio.
The most compatible format: plays in browsers, on mobile devices and in any media player.
The most flexible container: takes almost any codec, but cannot be played directly in a browser.
The web format: plays in browsers and keeps the Opus audio of a WebRTC stream.
No setup, no installation. Press Record, allow the camera and microphone, and the Media Server records your stream while you see it come back over WebRTC. Stop the stream and download the recording.
The stream could not be played.
LLcast will deploy a dedicated Media Server just for you, ready to record your streams. Publish over WebRTC, RTMP, SRT or RTSP, record single streams or multiple tracks into one file, and try MP4, MKV and WebM.
