Low latency streaming for live surveillance: the glass to glass latency budget, which protocols land under a second, and how to measure and cut the delay.
Latency is a budget, not a single number. Every stage from lens to screen spends part of it.
The camera and the player usually spend more of it than the network does.
WebRTC lands under a second. LL-HLS and HTTP-FLV sit at one to a few seconds. Classic HLS and MPEG-DASH run many seconds behind.
"Ultra low latency" has no standard meaning. Ask for milliseconds, measured glass to glass.
Live response needs sub second video: steering PTZ, talking through a camera, following a subject, checking an alarm.
Reviewing recordings does not. There, smooth playback and full quality matter more than speed.
You can measure latency yourself in ten minutes with a running clock and a phone camera.
Search for low latency streaming and almost every result comes from the broadcast world: sports, auctions, gaming and webinars. Latency is treated as a feature you switch on.
Surveillance is a different problem. The viewer is an operator who must act on what is on screen. The source is a security camera, whose own settings often add more delay than any protocol. The useful question is not which protocol is fastest on a slide, but where the time actually goes between lens and screen.
This guide breaks end to end delay into its stages, shows where each protocol spends its time, and explains how to measure and cut latency on your own cameras.
Low latency streaming is the delivery of live video with the shortest practical delay between an event happening in front of a camera and that event appearing on a viewer's screen. For live surveillance, low latency streaming usually means under one second glass to glass, fast enough for an operator to react while the event is still unfolding.
Glass to glass latency is the full delay, from the glass of the camera lens to the glass of the monitor. It is the only figure an operator lives with. Figures that measure one part of the chain, such as the network or the server alone, always look better than the real thing.
Whatever the vendor using it decides. There is no standard definition of low, ultra low or real time latency.
Broadly, the industry talks about three bands. Standard streaming runs many seconds behind live. Low latency brings that down to a few seconds. Ultra low latency, sometimes called real time, means under a second. But the boundaries move from vendor to vendor.
So ignore the label. Ask for a number in milliseconds, measured glass to glass on a camera and network like yours, and ask what the figure leaves out. A number that excludes the camera or the player buffer is not the number your operators will see.
Six stages spend the latency budget.
Capture and exposure. The sensor needs time to gather light for each frame. At 25 frames per second a new frame begins every 40 milliseconds, so an event waits on average half a frame to be captured. At night many cameras slow the shutter, which stretches this stage.
Camera encoding and the key frame interval. The camera compresses each frame, usually as H.264 or H.265. Encoding is quick on modern cameras, but settings matter. Key frames are the complete pictures a player needs before it can start, so a viewer who joins between them waits for the next one, unless the server asks the camera for a fresh one. "Smart" codec modes that stretch the gap to many seconds make live views slow to open.
Network transport. Distance costs little: light in optical fibre covers roughly 200 kilometres every millisecond. Congestion, Wi-Fi, cellular links and packet loss cost far more. Protocols that deliver every packet in strict order, as TCP does, hold up everything behind a lost packet until it is resent.
Server processing. Passing video through as it arrives costs very little time. Converting it to another codec, resolution or bitrate costs at least a frame and a great deal of processing. Cutting video into segments, as HLS does, means waiting for each segment to finish.
Player buffer. Usually the largest single cost, and the most often hidden. A WebRTC player keeps a small reserve, called a jitter buffer, measured in tens or hundreds of milliseconds. An HLS player keeps several whole segments, measured in seconds.
Decode and display. The browser decompresses each frame and waits for the monitor's next refresh, every 16.7 milliseconds at 60 hertz. A wall of many tiles adds decoding work.
Add them up and a well tuned local path shows an event in a fraction of a second, while the same camera through a classic HLS player can be many seconds behind. Almost all of that gap sits in two stages: packaging and the player buffer.
Every common streaming protocol falls into one of three classes, set less by the network than by how the protocol packages and buffers video.
Under a second. Video flows frame by frame with a small buffer. WebRTC lives here, and so does SRT from a camera or encoder to a server. This is the class for live response.
One to a few seconds. Video flows continuously or in very small pieces, with a cushion of a second or more. LL-HLS and HTTP-FLV land here, which suits supervision screens.
Many seconds. Video travels in segments several seconds long, and the player holds several before it starts. Classic HLS and standard MPEG-DASH live here, which suits large audiences and recorded playback.
WebRTC. The open standard behind browser video calls, published by the W3C, sends video over UDP as a continuous flow of small packets. There are no segments to wait for, and lost packets are recovered or concealed without holding up the rest. Most remaining delay sits in the camera and the jitter buffer. WebRTC lands under a second.
LL-HLS. Apple's Low Latency HLS splits each segment into partial segments published as soon as they are ready; Apple's documentation gives the example of six second segments built from 200 millisecond parts. Its authoring specification recommends one second parts and tells players to start at least three parts behind the live edge. Apple describes the result as latency in the range of standard television broadcasts, which in practice means a few seconds.
SRT. Secure Reliable Transport carries video over poor links such as cellular and satellite. It resends lost packets within a fixed window, its latency setting, then releases video at a steady pace. The SRT library documentation sets a default of 120 milliseconds, and the IETF specification draft recommends three to four times the link's round trip time. SRT brings video in; browsers do not play it.
RTMP. RTMP runs over a single TCP connection and adds little delay of its own. No modern browser plays it, so today it pushes video into a platform rather than to viewers.
HTTP-FLV. The same continuous flow as RTMP, over an ordinary web connection, played by a small browser player. With no segments, it typically lands at one to a few seconds, set mostly by the player buffer.
Classic HLS. Defined in IETF RFC 8216, HLS delivers video as short files listed in a playlist. The RFC tells players not to start less than three target durations, roughly three segments, from the live end. Apple recommends six second segments. Together, those rules put a standard player around 18 seconds behind live before the camera or network are counted.
MPEG-DASH. Segments listed in a manifest and buffered before playback, so standard DASH sits in the same class as HLS. A chunked low latency mode brings it closer to LL-HLS; our guide to CMAF explains the format.
Because operators act on what is on screen, and every second of delay is a second in which the scene has moved on. Four jobs depend on sub second video.
Steering a PTZ camera. Operators move a pan, tilt and zoom camera by watching the picture respond. With several seconds of delay they overshoot, correct and overshoot again while the subject walks out of frame.
Talkdown and two way audio. Speaking through a camera speaker is a conversation. If each reaction arrives seconds late, the exchange falls apart, and the warning lands after the person has climbed the fence.
Live pursuit across cameras. Following a person or vehicle means picking them up as they enter each view. With a long delay the operator is always looking where the subject was.
Alarm verification. The first task after an alarm is to look at the live picture and decide whether it is real. A delayed picture can show an empty scene while the intruder is still there. And when the control room radios "he is at the north gate", that should still be true.
Not every screen needs sub second video.
Reviewing recordings. Playback, search and evidence review are not live. A few seconds of buffer makes scrubbing smooth.
Overview walls and supervision screens. A wide view watched for patterns rather than action works well at a few seconds. LL-HLS fits here.
Public displays and large audiences. A lobby screen values stability over speed.
Very weak or locked down networks. A slower protocol that always plays beats a fast one that never connects, so a good system falls back on its own rather than showing a black tile. Our comparison of HLS and WebRTC for security teams covers this trade in depth.
WebRTC latency is the delay added by the WebRTC path itself: packetising, the network, the jitter buffer and decoding. On a good local network it is a small part of the budget, and the camera often costs more.
Four things push it up: a relay server, known as TURN, when firewalls block a direct path; packet loss, which makes the jitter buffer grow; Wi-Fi and cellular links, which vary from moment to moment; and any server that encodes the video again. The W3C statistics specification for WebRTC defines measures browsers report on every connection, including round trip time and jitter buffer delay, so engineers can see exactly where the time goes. Our guides to WebRTC for surveillance and WebRTC signaling go deeper.
A running clock, the camera and a second phone are enough to measure glass to glass latency to within a few tens of milliseconds.
1. Open a clock that shows milliseconds on a laptop or tablet.
2. Point the camera at that screen, in focus and well lit.
3. Open the live view on the monitoring screen and place it beside the clock.
4. Photograph both screens at once with a second phone.
5. Subtract the time in the live view from the time on the clock. The difference is your glass to glass latency.
6. Repeat about ten times and take the middle value, because single readings vary with frame timing.
7. Repeat where it matters: the control room, a remote office, over the VPN, at night, and on the busiest wall layout.
Measure the path operators actually use, with the same browser, network and layout, not a single tile on an empty test bench.
Most delay is removed with settings, not by switching protocols.
1. Set a sensible key frame interval. One to two seconds is common, and Apple's HLS specification asks for a key frame every two seconds. Avoid smart codec modes on cameras used for live response.
2. Avoid converting video. Pass the camera's own H.264 or H.265 stream through wherever the browser can play it.
3. Use the sub stream for small tiles, and keep the main stream for the full screen view, the PTZ camera being steered and the alarm being checked.
4. Keep the frame rate up. At 25 or 30 frames per second capture delay stays small.
5. Prefer wired over wireless. Ethernet removes the jitter that makes buffers grow.
6. Provide relay servers for strict networks, so live view stays sub second instead of dropping to a slower fallback.
7. Size the SRT latency to the link: three to four times the measured round trip time. Too small and lost packets cannot be resent in time. Too large adds delay for nothing.
8. Measure again after every change.
Myth: more bandwidth means lower latency. Bandwidth decides how much video fits through, not how quickly it arrives. A fast connection feeding a large buffer is still slow.
Myth: latency is simply a protocol choice. The protocol sets the class; the camera, server and player decide where in it you land.
Myth: a shorter key frame interval always lowers latency. It makes views open faster and allows shorter HLS segments, but changes little for a WebRTC view already playing, and raises the bitrate.
Myth: zero latency is possible. Sensors, encoders, networks and screens all take time. The right target for live surveillance is under a second.
Myth: lower latency means a worse picture. Not when video is passed through untouched. Quality is set by the camera and the stream chosen.
Visylix is an automated AI video surveillance platform built in India, and live view is where it starts. Its native streaming engine, built in house, delivers sub second live view over WebRTC in any modern browser, down to under 200 ms in ideal conditions, with nothing to install at the desk.
Video passes straight through. Wherever the browser can play the camera's H.264 or H.265 video, Visylix delivers it without conversion. Only where a browser cannot play H.265 does Visylix convert it to H.264, for live view.
Views open fast and stay live. Viewers join at the live edge, and the camera is asked for a fresh key frame the moment someone starts watching. The buffer stays small on a local network, a little larger across the internet, and adjusts to the network. Lost packets are recovered automatically.
Every network gets a picture. If WebRTC cannot get through, the player falls back automatically to HTTP-TS, then LL-HLS with short partial segments, then classic HLS. Relay servers are supported for strict networks.
The right stream for every tile. On the live grid and on video walls up to 6x6, Visylix picks each camera's main or sub stream by tile size and connection speed; enlarging a tile switches it to the main stream. Recordings keep the camera's full original resolution. Our guide to adaptive bitrate streaming covers stream choice in depth.
Remote cameras on poor links. SRT ingest, with a configurable latency setting and passphrase encryption, brings in cameras on cellular or satellite links, one of 13+ protocols the engine speaks, with ONVIF for discovery and control.
Speed that serves action. Sub second video makes the rest of Visylix work live: PTZ control, presets, patrol tours and autotracking; two way audio and rule driven talkdown; and alarms raised by 22 AI analytics built in house, with Sudarshan rules deciding what happens next. Visylix ships as a Docker image on your own hardware, so video never leaves the building.
Plans. Starter and Pro include unlimited cameras on the VMS licence, from ₹4,999 or $49 per month. AI analytics are a separate subscription billed per camera per month, on the cameras you choose. Talk to us for AI pricing.
Low latency streaming earns its place on every screen where an operator acts: steering PTZ cameras, talking through a camera speaker, following a subject from camera to camera and verifying alarms; and on remote links where SRT holds delay steady over a poor connection.
It disappoints when it is chased on screens that do not need it, such as recorded playback and lobby displays; when the player buffer is squeezed on a weak link and the picture stalls; when the camera, not the protocol, is the real bottleneck; and when a vendor quotes a figure that leaves out the camera or the player.
Low latency streaming is live video delivered with the shortest practical delay between an event in front of a camera and that event appearing on a screen. In live surveillance it usually means under one second glass to glass, so an operator can steer a camera, speak through it or check an alarm while the event is still happening.
Under one second glass to glass is the right target for live monitoring, PTZ control, talkdown and alarm verification. A few seconds is acceptable for overview walls and supervision screens that are watched for patterns rather than for action. Recorded playback has no latency target at all, because the video is already in the past and smooth, full quality review matters more.
Glass to glass latency is the total delay from the glass of the camera lens to the glass of the viewer's screen. It includes capture, camera encoding, the network, server processing, the player buffer, decoding and display. It is the only latency figure an operator actually experiences, so it is the one to ask for when comparing streaming systems.
Low latency is good wherever a person has to act on live video, such as steering a camera or talking to someone at a gate. Its cost is a smaller buffer, which leaves less cushion for a poor connection, so a weak link may stall more often. For recordings and large audiences, a little more delay in exchange for smoother playback is usually the better trade.
On, for live work over a good network. An ultra low latency setting usually shrinks the player buffer, which cuts delay. On a shaky Wi-Fi or cellular connection the same small buffer can cause stalls, so a slightly larger buffer may give a better experience. The label itself has no standard meaning, so judge the setting by the delay you measure.
No. Every stage of the journey takes some time: the camera sensor gathering light, the encoder compressing each frame, the network, the server, the player and the screen. Zero delay is physically impossible. What is possible is delay too small to notice. For live surveillance, the realistic and useful target is under one second from lens to screen.
HLS sends video as a series of short files, and the player waits for several of them before it starts. The HLS specification tells players to start at least three segment durations behind the live end, so with six second segments a classic player sits many seconds behind. WebRTC sends video as a continuous flow of small packets with only a small buffer.
Point the camera at a screen showing a running clock in milliseconds. Put the live view next to that clock, then photograph both screens together with a second phone. The difference between the two times is your glass to glass latency. Repeat about ten times, take the middle value, and test from every place operators actually watch.
Visylix delivers sub second live view over WebRTC in any modern browser, down to under 200 ms in ideal conditions. Video passes through without conversion wherever the browser can play it, each view opens with a fresh key frame, and the player falls back automatically to HTTP-TS, LL-HLS and HLS on networks that block WebRTC. Everything runs on your own servers.