WebRTC and HLS: how camera video reaches the viewer
Cameras stream over RTSP, and browsers cannot read RTSP. So the server delivers the video in a format browsers understand — WebRTC or HLS. Here is how the two differ and why we use both.
Why browsers cannot play RTSP directly
RTSP is the language of surveillance systems: cameras, recorders and VLC speak it; Chrome, Safari and Firefox do not. Exposing a camera directly to the internet is also unsafe, and it could not serve hundreds of viewers anyway. So our server takes one RTSP stream from the camera and hands it out to viewers in a browser-friendly format. There are two such formats.
WebRTC — close to real time
WebRTC was built for video calls; it is the technology behind Google Meet. Video travels in small packets, mostly over UDP, and the browser shows it immediately without building up a large buffer. Delay is typically under a second, so what you see is what is happening now. Our player uses the standard WHEP protocol to receive the stream. WebRTC is always encrypted.
The weak spot: WebRTC needs its own path through the network. Corporate firewalls, hotel and café Wi-Fi and some VPNs block UDP traffic, and then the connection simply cannot be made.
HLS — gets through anywhere, but later
HLS cuts video into small files that the browser downloads one after another over ordinary HTTPS, just like images. It therefore works anywhere a web page loads; a firewall cannot tell it apart from a normal website. The price is delay: classic HLS is often 10–30 seconds behind, because the player buffers several files ahead. We use LL-HLS (Low-Latency HLS), which delivers smaller parts of each file and brings the delay down to a few seconds.
Side by side
| WebRTC | LL-HLS | |
|---|---|---|
| Order of delay | Under a second | A few seconds |
| Transport | Mostly UDP | HTTPS (ordinary web traffic) |
| Corporate firewall | May be blocked | Almost always gets through |
| Browsers | All modern ones | All modern ones; built into iPhone |
| When it is used | First choice — when “now” matters | When WebRTC cannot connect |
The exact delay depends on the camera, the network and where the viewer is. The table shows orders of magnitude, not a promise.
Why WebRTC first, then HLS
Our player picks the route by itself. It tries WebRTC first because it gives the best result. If the network does not let WebRTC through, the player falls back to LL-HLS automatically. Viewers have nothing to install or choose — they simply see the video, even from an office network. The only thing they might notice is a little more delay.
- Ski slope, sea, city view — a few seconds bother nobody; what matters is that the video opens for everyone.
- Building site, gate, event — “now” matters more here, and the WebRTC advantage shows.
On phones
Both routes work on Android and iPhone, in Chrome, Safari, Firefox and Edge, with no app. On mobile data WebRTC usually connects, though on some carrier networks or with a VPN on, the player will switch to HLS. On an iPhone in Low Power Mode the browser may block autoplay; the viewer then taps play once.
How camera settings affect this
- I-frame interval. A new viewer's video starts at the next key frame. An interval of 1–2 seconds gives a quick start and short HLS parts.
- B-frames. In H.264, B-frames make video stutter in browsers, especially over WebRTC. Turn them off on the camera.
- H.265. Most browsers cannot play it; for such cameras the server converts the video to H.264 while someone watches. See H.265 in the browser.
All recommended values in one place: camera settings for web streaming.
Why is the video sometimes a few seconds behind?
Most likely the viewer's network did not let WebRTC through and the player switched to LL-HLS. This is common on office and hotel Wi-Fi and with VPNs. The video works, just slightly later.
Do viewers need to install anything?
No. The player runs in an ordinary browser on desktop and mobile and chooses the route by itself.
Does it work on iPhone?
Yes, in Safari and other browsers. If the phone is in Low Power Mode, the viewer may need to tap play once.
Is WebRTC secure?
Yes. WebRTC video is always encrypted, and HLS travels over HTTPS. Viewers also only ever connect to our server and never see your camera's address.