Tech
Publish and play live streams with ultra-low latency using WebRTC. The Media Server handles stream delivery to your viewers.
Live Streaming means that video is captured from a camera or another source and transmitted to viewers in real time.
Unlike on-demand video, a live stream has no future content to skip ahead to. Viewers typically join at the most recent point of the stream to see what's happening right now.
But here's the catch: not every live stream is truly live.
There's always some delay between capturing a video frame and displaying it on the viewer's screen. This delay, known as latency, can vary dramatically depending on the streaming technology.
Some live streams achieve sub-second latency, while others can lag more than 30 seconds behind the actual event.
So what makes the difference? Let's take a closer look.
WebRTC offers exceptionally broad browser support and some of the lowest latency available for live streaming. We're talking about that sub-second latency everyone wants.
But how does WebRTC achieve it?
Two key mechanisms make this possible:
In other words, WebRTC isn't just sending video in one direction. It's an intensive, two-way exchange of media packets and feedback. Depending on network conditions and the implementation, RTCP feedback and other return traffic can become substantial.
And this low latency comes at a price: additional network overhead and server-side processing to continuously estimate available bandwidth, adjust transmission rates, and manage packet delivery in real time.
Imagine traditional HLS delivery as a freight train traveling steadily from point A to point B. Each carriage carries a chunk of video. The train isn't particularly fast, but it moves large amounts of content efficiently and predictably.
WebRTC is more like a high-speed highway.
Instead of waiting for entire video chunks, small pieces of video travel in fast-moving cars. They leave frequently, adapt to traffic conditions, and aim to reach their destination as quickly as possible.
Some cars never make it to point B. Those are the lost UDP packets that couldn't be recovered in time.
And that's part of the design: for real-time streaming, receiving the next video frame on time can be more important than recovering every missing piece of the previous one.
WebRTC publishing works the same way on every platform. The publisher's application uses an SDK to open a session with the Media Server, captures the camera and microphone, and publishes them as a stream with a unique name.
The SDK handles session negotiation, media transport and congestion control, adjusting the bitrate to the network as it changes. The application only decides what to capture and under which name to publish it.
The Media Server receives that single stream and keeps it ready for viewers: however many of them play it, the publisher sends it only once.
Publisher App
SDK
Media Server
Viewers
Now let's see how to publish a live stream with each of the four SDKs.
The code looks a little different on each platform, but the idea is the same: capture the camera and microphone, establish a streaming session, and publish the stream to the Media Server.
In a browser, publishing is handled by the Web SDK. It captures the camera and microphone itself, so a few lines are enough:
session
.createStream({
name: 'alice-live',
display: localPreview,
constraints: {
video: { width: 1280, height: 720 },
audio: true,
},
})
.publish();The stream name is set by name: 'alice-live': viewers play the stream by this name.
On Android the app asks for the camera and microphone permissions, then publishes the stream. The SDK captures the camera by default:
StreamOptions options = new StreamOptions("alice-live");
VideoConstraints video = new VideoConstraints();
video.setResolution(1280, 720);
options.getConstraints().setVideoConstraints(video);
Stream stream = session.createStream(options);
stream.publish();The stream name is set by new StreamOptions("alice-live"): viewers play the stream by this name.
On iOS the SDK captures the camera and microphone and shows the local preview in the view you pass to it:
let options = FPWCSApi2StreamOptions()
options.name = "alice-live"
options.display = localView
let stream = try session.createStream(options)
try stream.publish()The stream name is set by options.name = "alice-live": viewers play the stream by this name.
In a video room the camera and microphone are tracks of the participant's connection. The SFU SDK publishes them to the room and tells it what each track carries:
const stream = await navigator.mediaDevices.getUserMedia({
audio: true,
video: { width: 1280, height: 720 },
});
const config = {};
stream.getTracks().forEach((track) => {
config[track.id] =
track.kind === 'audio' ? 'mic' : 'camera';
pc.addTransceiver(track, {
direction: 'sendonly',
streams: [stream],
});
});
await room.updateState(config);Each track is described by its id in config[track.id]: the room knows which track is the camera and which is the microphone.
Publishing starts with a simple stream.publish() call, available in the Web SDK, Android SDK, and iOS SDK. But starting a stream is only the beginning.
What if you want more control over the stream you're sending?
You can choose the camera and microphone, set the resolution, frame rate and bitrate, adjust the microphone gain, turn on stereo and error correction for audio, tell the browser whether to keep the frame rate or the resolution, mute either track without stopping the stream, and choose the transport and codecs to negotiate.
Let's take a closer look at the available controls.
WHIP is a way to publish WebRTC streams without using an SDK.
Let's see how it works with OBS Studio.
OBS sends an HTTP request containing an SDP offer to the Media Server. The server responds with an SDP answer, allowing both sides to negotiate codecs and connection parameters.
Once the WebRTC connection is established, OBS starts publishing the stream, and the Media Server takes care of delivering it to viewers.
Here is what it looks like in practice. In OBS Studio, choose the WHIP service, enter the Media Server URL with the stream name and, if publishing is protected, a Bearer token. Press Start Streaming, and the stream can be played back from the Media Server like any other.
Playback is the other half of live streaming. Each viewer's application uses the same SDKs to open its own session with the Media Server and plays the stream by the name it was published with. A new viewer does not touch the publisher: the Media Server adds one more WebRTC connection and sends a copy of the same stream to it.
The SDK negotiates the connection, receives the media and renders it, while RTCP feedback keeps each viewer's delivery tuned to their own network. The result is the same sub-second latency for every viewer, whether they watch in a browser, in a mobile app or in a video room.
Publisher App
Media Server
Viewer App
SDK
Now let's see how a viewer plays the live stream with each of the four SDKs.
Again, the code differs from platform to platform, but the idea is the same: establish a streaming session, request the stream by its name, and show it on the screen.
In a browser, the Web SDK plays the stream into the element you pass to it:
session
.createStream({
name: 'alice-live',
display: remoteVideo,
})
.play();The viewer plays the stream by the name it was published with: name: 'alice-live'.
On Android the SDK renders the stream into the view you pass to it:
StreamOptions options = new StreamOptions("alice-live");
options.setRenderer(remoteRenderer);
Stream stream = session.createStream(options);
stream.play();The viewer plays the stream by the name it was published with: new StreamOptions("alice-live").
On iOS the SDK shows the stream in the view you pass to it:
let options = FPWCSApi2StreamOptions()
options.name = "alice-live"
options.display = remoteView
let stream = try session.createStream(options)
try stream.play()The viewer plays the stream by the name it was published with: options.name = "alice-live".
In a video room a viewer joins the room and receives the tracks of the other participants. The SFU SDK announces each new track, and the app requests the ones it shows:
remoteVideo.srcObject = new MediaStream();
room.on(SFU_ROOM_EVENT.ADD_TRACKS, async (e) => {
for (const info of e.info.info) {
const remote = await room.getRemoteTrack(info.type);
await remote.demandTrack(info.id);
remoteVideo.srcObject.addTrack(remote.track);
}
});
await room.join(pc);Each track is requested by its id in demandTrack(info.id): the viewer receives only the tracks it shows.
Playback starts with a simple stream.play() call, available in the Web SDK, Android SDK, and iOS SDK. But starting playback is only the beginning.
What if you want more control over the stream you're watching?
You can enable or disable video, request a specific resolution, bitrate, or quality level, choose which codecs to negotiate, and control how audio is played.
Let's take a closer look at the available controls.
Not every viewer has the same network. One watches over fiber, another over a crowded mobile connection. Send everyone the same high-bitrate stream, and the weakest connections start to stall.
WebRTC ABR (Adaptive Bitrate) solves this on the server side. The Media Server transcodes the incoming stream into several qualities, for example 720p, 480p and 240p, and keeps all of them ready for playback.
The viewer starts with one quality while the player keeps an eye on the playback statistics. When bandwidth drops or packets get lost, it switches to a lower quality; when the network recovers, it switches back up. The publisher still sends a single stream.
Why the SFU SDK? On the Media Server, WebRTC ABR is built on the SFU: the server creates an SFU room named after the stream and offers the qualities as the qualities of its video track. So the ABR player joins that room with the SFU SDK, which already knows how to receive several qualities of one track and request the one that fits the network.
In a browser, WebRTC ABR is played with the SFU SDK. The player receives the qualities of the stream and switches between them on its own, watching the playback statistics:
const display = initRemoteDisplay(
state.room,
document.getElementById('remoteVideo'),
{ quality: true, autoAbr: true },
{
thresholds: [
{ parameter: 'nackCount', maxLeap: 10 },
{ parameter: 'freezeCount', maxLeap: 10 },
{ parameter: 'packetsLost', maxLeap: 10 },
],
abrKeepOnGoodQuality: ABR_KEEP_ON_QUALITY,
abrTryForUpperQuality: ABR_TRY_UPPER_QUALITY,
interval: ABR_QUALITY_CHECK_PERIOD,
},
// ...the meeting controller, model, view and participant factory
);
await state.room.join(state.pc, null, null, 1);autoAbr: true turns automatic switching on; the thresholds list the statistics the player watches: NACKs, freezes and lost packets.
No setup, no installation. Press Live, allow the camera and microphone, and watch your stream come back from the Media Server over WebRTC with sub-second latency.
The stream could not be played.
LLcast will deploy a dedicated Media Server just for you, ready to receive your live streams. Publish from a browser or a mobile app and experiment with different settings.
