WebRTC live streaming
Low-latency live streaming with WebRTC for moments that cannot wait
When the audience bids, votes or asks a question, a stream that arrives several seconds late is a different event. DynTube’s new live system can deliver your stream over WebRTC, typically in under a second, and falls back to HLS automatically for any viewer whose connection cannot hold it. WebRTC playback is enabled per account on the new live system — talk to us to switch it on.
One moment, two arrival times
IllustrativeOn stage
Sub-second lane
typically under 1 sStandard lane
typically 6–15 s
Typical ranges, not DynTube measurements
Bid accepted happens at 0 seconds. WebRTC (WHEP): typically under 1 s. HLS: typically 6–15 s.
When a viewer sees the same moment, by delivery lane
Illustration using typical industry ranges, not measured DynTube figures. Actual delay depends on the encoder, network and viewer.
The basics
What is WebRTC live streaming?
WebRTC live streaming delivers a live video to viewers over the same real-time technology browsers use for video calls, so the picture typically arrives in under a second. Standard HLS live streaming sends short downloadable segments instead, which is very reliable at scale but typically puts viewers several seconds behind.
DynTube uses WHEP, the standard way for a player to request a WebRTC stream from a server, on its new live system. Your encoder still publishes the way it always has; only the viewer side changes. The DynTube player negotiates WebRTC first, and if it cannot connect it plays the same stream over HLS, so nobody is left with a blank player.
WebRTC or HLS
When is WebRTC worth it, and when is HLS enough?
Both lanes come from the same stream. The question is how much delay your event can absorb.
| Criterion | WebRTC (WHEP) | HLS |
|---|---|---|
| Typical delay to the viewerTypical ranges, not DynTube measurements | Typically under a second | Typically several seconds, often 6–15 s |
| Fits best | Auctions, live Q&A, betting, coaching, interactive classes | Broadcasts, services, conferences and events where a few seconds do not matter |
| If the viewer cannot connect | The player falls back to HLS automatically | Plays as normal |
| Availability | New live system, per-account entitlement with a per-account stream limit | Every live stream |
WebRTC playback is switched on per account and per stream; confirm entitlement for your account before you plan an event around it.
The mechanism
What happens between your encoder and a WebRTC viewer?
Described as far as the current product verifies it, and no further.
- You publish as usualIngest
- Your encoder publishes to the new live system over RTMP, RTMPS or SRT, using the server URL and stream key from the dashboard. Nothing about your encoder changes for WebRTC.
- WebRTC is switched on for the streamSetting
- When your account has WebRTC playback, the stream’s WebRTC option is available when you create it on the new live system. Each account has its own limit on WebRTC streams.
- The player asks for a short-lived ticketPlayback
- When a viewer opens the embed, DynTube runs its normal playback checks and then issues a short-lived WebRTC playback token. The token travels inside the player’s data, never in the embed address.
- WebRTC first, HLS as the safety netFallback
- The player negotiates WebRTC and starts playing in real time. If the connection fails or no media arrives, it switches to HLS for that viewer and carries on.
{
"source": {
"type": "webrtc",
"src": "https://<edge>/v1.0/webrtc/whep/live_…",
"whepToken": "<short-lived token>",
"hlsFallback": { "type": "hls", "src": "<signed HLS URL>" }
}
}OBS walkthrough
How do you set up a WebRTC live stream with OBS?
Five steps from a new stream to a sub-second test, using OBS as the example encoder.
- 01
Create the stream on the new live system
- 02
Copy the server URL and stream key
- 03
Point OBS at DynTube
- 04
Start streaming and confirm it is live
- 05
Test the delay with a clock
The rest of live
What else comes with the new live system?
WebRTC sits alongside the live features you already use.
Scheduled streams
Schedule prerecorded videos to go live once or on a recurring pattern.
Live scheduling
Opt-in recording
Record a stream into a project you choose, when your plan includes recording. Recording is never automatic.
Live recording
Live audience reporting
Stream sessions, unique and concurrent viewers and watch time for each stream.
Analytics
Questions
WebRTC live streaming questions
Direct answers, each within the current product boundary.
How low is the latency of WebRTC live streaming on DynTube?
WebRTC playback typically delivers a live picture in under a second, against several seconds for standard HLS. Actual delay depends on your encoder settings, your upload connection and the viewer’s network, so test with a clock in your scene before an event that depends on it.
Is WebRTC playback included in my plan?
WebRTC playback is switched on per account rather than included by default, and each account has a limit on how many streams can use it. Talk to us to confirm entitlement and the stream limit for your account before you plan an event around it.
What happens if a viewer cannot use WebRTC?
The DynTube player tries WebRTC first. If it cannot connect, or no media arrives, it switches that viewer to HLS automatically and keeps playing, a few seconds behind. Other viewers stay on WebRTC.
Do I need a special encoder for WebRTC?
No. You publish over RTMP, RTMPS or SRT from OBS or any compatible encoder that accepts a custom server and stream key. WebRTC is used on the viewer side only; publishing from the browser over WebRTC is not offered.
Can I encrypt a stream on the new live system?
Not today. Encrypted HLS live streaming is available only on the legacy live system, for eligible plans and stream configurations. Streams on the new live system, including WebRTC streams, cannot enable it.
Put a clock in your scene and see the gap for yourself
Start a trial, run a test broadcast from OBS, and talk to us about WebRTC playback for your account.