Adaptive bitrate streaming explained: how ABR ladders, HLS and DASH work, why they add delay and cost, and how surveillance uses main and sub streams instead.
Adaptive bitrate streaming encodes one video at several quality levels and lets each player switch between them as its connection changes.
It was built for one to many internet video: one title, millions of viewers.
Its price is delay and computing power: segments and buffers add seconds, and every quality level is another live encode.
Surveillance is many to few: hundreds of cameras, a handful of operators, and every second of delay matters.
Cameras already encode two streams. A good VMS picks the main or sub stream for each tile and each connection.
Evidence must keep the camera's original quality. Adapt the live view, never the recording.
True adaptive bitrate streaming earns its place when a camera is broadcast to the public at scale.
Search for adaptive bitrate streaming and nearly every result comes from online video: streaming platforms, player vendors and content delivery networks. Most explain the ladder, the manifest and the player well.
They all solve one problem: sending the same video to a huge audience over networks nobody controls. Security video has the opposite shape. A control room has hundreds of cameras and a few operators, and a delay of ten seconds can be the difference between stopping an incident and reviewing one.
This guide explains how adaptive bitrate streaming works, why it suits Netflix, and why surveillance reaches the same goal by another route.
Adaptive bitrate streaming (ABR) is a method of delivering video in which the same content is encoded at several quality levels, cut into short segments and listed in a manifest. The player measures its connection and, segment by segment, requests the highest quality it can play without stalling.
The IETF's RFC 9317, on operational considerations for streaming media, describes ABR as a technique for matching the quality of a stream to the bandwidth available: send enough that the player never stalls, but no more than it can take.
Adaptive streaming, ABR streaming and adaptive bitrate video streaming are the same idea under different names. The Netflix Help Center describes the result from the viewer's side: the service adapts to the speed of the connection, and may start at a lower resolution before stepping up.
Every adaptive bitrate system, whatever the brand, follows the same five steps.
1. Encode a ladder. The source is encoded several times, at different resolutions and bitrates. Each version is a rendition, and the set is a ladder. Apple's HLS authoring specification gives one example H.264 ladder with nine rungs, from 416 x 234 pixels at 145 kbps to 1920 x 1080 at 7,800 kbps.
2. Cut every rendition into segments. Each rendition is split into short files a few seconds long. Apple recommends six second segments and a key frame every two seconds. Segments line up across renditions, so the player can switch at any boundary.
3. Publish a manifest. A manifest is a small text file that lists every rendition, its bitrate and resolution, and where its segments live. HLS calls it a playlist. MPEG-DASH calls it a Media Presentation Description.
4. Measure the connection. The player reads the manifest and measures how quickly segments arrive. RFC 9317 notes that many players run a quick speed test at the start, then watch their own statistics, such as how fast the buffer is filling.
5. Switch per segment. Before each segment, the player picks a rendition. If its buffer is growing, it steps up. If the buffer is draining, it steps down before the picture stalls. Each player decides for itself, so a viewer on fibre and a viewer on a crowded train watch the same programme at very different quality.
RFC 9317 calls the logic behind that choice a rate adaptation or bitrate selection algorithm, and notes that most are proprietary.
Three names come up in every conversation about adaptive bitrate streaming protocols. They are often compared as rivals, but they do different jobs.
HLS (HTTP Live Streaming). Created by Apple and published by the IETF as RFC 8216. A master playlist lists the versions of a video, which the standard calls variant streams, and the standard says plainly that clients should switch between them to adapt to network conditions. HLS plays natively on Apple devices and, through a player library, almost everywhere else. LL-HLS is its low latency extension.
MPEG-DASH (Dynamic Adaptive Streaming over HTTP). The international standard ISO/IEC 23009-1. MPEG describes it as a way to run live and on demand streaming over ordinary, low cost internet infrastructure, with any media format. The DASH Industry Forum records that ISO ratified it in April 2012, after work by companies including Microsoft, Apple, Netflix and Samsung.
CMAF (Common Media Application Format). Not a delivery protocol, but a shared segment format, also from MPEG. One set of CMAF segments serves both HLS and DASH players, so a service packages once instead of twice. CMAF also lets a segment travel in smaller chunks while it is still being made, which RFC 9317 identifies as how LL-HLS and low latency DASH cut delay. Our guide to CMAF covers this in depth.
In short: HLS and DASH are two ways of telling a player what to fetch. CMAF is the common container the video travels in.
Netflix was one of the companies behind MPEG-DASH, as the DASH Industry Forum records. Apple devices are built around HLS, so services that reach every screen commonly support both, and CMAF lets them do it from one set of segments. The more useful lesson for a security buyer is what the Netflix model assumes: one title, a huge audience, every kind of network, and a few seconds of startup nobody minds. Every one of those assumptions changes in a control room.
Yes, for the job it was built for. It is why online video rarely stalls on a phone. But it has two costs that matter in security: delay and computing power.
Delay comes from segments and buffers. A player cannot play a segment until it has all of it, and it keeps several segments in hand as insurance. The HLS standard, RFC 8216, says a player joining a live stream should not start less than three target durations from the end of the playlist, because doing so can trigger stalls. With the six second segments Apple recommends, that alone puts a standard HLS viewer around 18 seconds behind live, before encoding and network time are added.
RFC 9317 sorts live delivery into bands that make the trade plain. Ordinary live streaming over HLS and DASH has no latency target shorter than 10 seconds. Low latency live aims for under 10 seconds, and the RFC notes the trade offs can include higher costs, lower quality and reduced flexibility for adaptive bitrates. Ultra low latency, under one second from camera glass to viewer screen, is mostly delivered with RTP or WebRTC rather than with segments.
Computing power goes on the ladder. Every rendition is a separate live encode: the server decodes the source and encodes it again at each rung. Our guide to transcoding versus encoding explains why that work is heavy. For one television channel, that is a sensible cost. Across a camera estate it multiplies fast. Two hundred cameras with a four rung ladder means eight hundred live encodes running around the clock, mostly for video nobody is watching.
Online video is one to many. Surveillance is many to few. That single difference changes nearly every design choice.
Audience. A streaming service sends one title to millions of viewers, so the cost of a ladder is shared. A control room has hundreds of cameras and a handful of operators, so a ladder per camera is paid for on every camera, all the time.
Network. Streaming viewers sit on home broadband and mobile networks nobody controls. Most operators sit on a managed local network where bandwidth is known and steady. The hard links are the exceptions: remote sites and managers viewing from outside.
Latency. A film that starts a few seconds late harms no one. A live view running 15 seconds behind means an operator watches an intruder who has already moved on.
Quality. A streaming service can lower quality on a weak connection, and the viewer forgives it. Evidence cannot be lowered: the plate or face in frame may be the only proof there is.
Viewing pattern. A viewer watches one video. An operator watches a grid of 16 to 36 small tiles and opens one full screen when something happens.
So surveillance needs the goal of adaptive bitrate streaming, the right quality for each screen and connection, without the delay or the transcoding. The answer has been inside the cameras all along.
Almost every IP camera can encode its picture more than once at the same time, at different settings. The full quality version is the main stream. A lighter version is the sub stream. Both leave the camera together, so no server has to transcode anything.
In effect, the camera supplies a two rung ladder at no cost to the server. The main stream serves recording, evidence and full screen viewing. The sub stream serves small tiles and remote viewing over slow links.
How to set the sub stream sensibly, as a starting point:
1. Resolution. Around 640 x 360 or 704 x 576 suits tiles on grids of 9 to 36. Keep the main stream's aspect ratio, so a tile does not stretch or crop when it changes stream.
2. Frame rate. 10 to 15 frames per second is plenty for a small tile. Keep the main stream at its full rate for evidence.
3. Bitrate. A few hundred kilobits per second is usually enough with H.264, and less with H.265. Use variable bitrate with a cap, so a busy scene does not flood a remote link.
4. Key frames. Set a key frame every one to two seconds on both streams. A viewer can only start decoding at a key frame, so a long interval makes every tile slow to appear.
5. Codec. H.265 needs noticeably less bitrate than H.264 for similar quality, but check that your operators' browsers can play it.
Then get the main stream right. Our guide to video bitrate gives recording figures by task, from general watching to face and plate capture.
A good video management system (VMS) makes the main or sub choice automatically, so operators never have to think about it. Four things drive the choice.
Tile size. A small tile on a 6x6 wall is a few hundred pixels wide. Sending it a 4K main stream wastes bandwidth on detail no one can see. The sub stream fits.
Connection speed. An operator on the local network can take main streams for large tiles. A manager on a slow link from home gets sub streams for everything but the camera they open.
Enlarging a tile. When an operator opens one camera large, that camera moves to its main stream while the rest of the wall stays light.
Decoding power at the desk. Every tile is decoded by the viewing computer. Thirty six 4K main streams can overwhelm a typical workstation. Thirty six sub streams play comfortably.
This is not adaptive bitrate streaming in the strict sense. There is no ladder on the server, and the choice is made per tile rather than per segment, so a change of quality means the tile connects to a different stream. It delivers what operators actually need: a smooth wall, low delay, and full quality the moment they look closely. Our guide to video walls covers layout and sizing.
Remote sites are where connections really vary: a pumping station on cellular, a construction site on satellite. Four practices matter more than any player algorithm.
Record at the edge. Keep recording on site, on a local recorder, an edge server or the camera's SD card, so a link failure never becomes a gap in evidence.
Use SRT where the link is lossy. SRT (Secure Reliable Transport) is an open source protocol from Haivision, published on GitHub. It encrypts the stream, recovers lost packets by asking for them again, and holds a steady delay that you set, which suits cellular and satellite links.
Use the sub stream for remote live view. It fits links where a main stream never would. Open the main stream only for the camera that matters.
Fill gaps after an outage. Cameras that support ONVIF Profile G can hand back footage from their own card once the link returns.
Adaptive bitrate streaming does have a place in the security world: wherever a camera stops being surveillance and becomes broadcast.
A city traffic camera shown live on a public website. A festival or pilgrimage site streamed to thousands of citizens. These are one to many again: a large audience, unknown networks, and a few seconds of delay nobody minds.
For these, the right design is a broadcast chain. Send the chosen camera's stream from the VMS to an encoder or streaming service that builds the ladder, and let a content delivery network carry it to the public. The trade is honest: you pay for transcoding and accept a delay of several seconds, but only on the handful of cameras the public sees.
Two rules keep this safe. Never expose the VMS itself to the public internet. And check the privacy law that applies before streaming identifiable people, because a camera that is right for a control room may need a wider, less detailed view before it is broadcast.
Visylix is an automated AI video surveillance platform built in India. Its native streaming engine, built in house, is designed for the many to few shape of security video. Rather than transcode every camera into a ladder, Visylix makes full use of the two streams your cameras already produce.
The right stream for every tile. For each tile on the live grid or video wall, Visylix automatically picks the camera's main or sub stream, based on tile size and connection speed. Small tiles and slow links get the sub stream. A full screen tile gets the main stream, and enlarging a tile switches it to full quality. A 36 tile wall stays smooth without wasting bandwidth.
Evidence at full quality, always. Recording and evidence keep the camera's full original resolution. Only the live view is scaled for the screen.
Sub second live view in the browser. Live view runs over WebRTC in any modern browser, sub second and down to under 200 ms in ideal conditions, with nothing to install at the desk. Viewers join at the live edge, the camera is asked for a fresh key frame the moment someone starts watching, and lost packets are recovered automatically. If WebRTC cannot get through a network, the player falls back on its own to HTTP-TS and then HLS. H.265 cameras play in browsers that support them, and Visylix converts H.265 to H.264 on the fly for the rest.
Built for remote sites and broadcast chains. SRT ingest, with a latency setting you choose and passphrase encryption, brings in cameras on cellular or satellite links. Across 13+ protocols, Visylix can also serve a camera's stream over RTMP, SRT or HLS to the streaming service that builds a public ladder.
Your video stays with you. Visylix ships as a Docker image on your own hardware: on premise, at the edge, hybrid, fully air gapped or in your own cloud account.
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. Talk to us for AI pricing.
Adaptive bitrate streaming earns its place in one to many video: public broadcasts of city, traffic and event cameras; training and briefing videos for large audiences; any feed watched by many people on networks you do not control; and video on demand, where a few seconds of startup cost nothing.
It disappoints as the live view of a control room, where segments and buffers add seconds operators cannot spare; across a large camera estate, where a ladder per camera multiplies transcoding for video nobody watches; and on managed local networks, where each camera's own main and sub streams already do the job.
Adaptive bitrate streaming is a way of delivering video in which the same content is encoded at several quality levels, cut into short segments and listed in a manifest. The player measures its connection and picks the best quality it can play without stalling, segment by segment. HLS and MPEG-DASH are the two common formats, and the method is standard across online video services.
Yes, for one to many video over unpredictable networks, where it keeps playback smooth on any connection. It is a poorer fit for live surveillance. Segments and player buffers add seconds of delay, and building a ladder of renditions means transcoding every camera around the clock. Security systems reach a similar result far more cheaply by choosing between each camera's main and sub streams.
Netflix was one of the companies behind MPEG-DASH, the international standard for adaptive streaming over HTTP, as the DASH Industry Forum records. Services that reach every kind of screen, including Apple devices built around HLS, commonly support both formats. The method underneath is the same either way: a ladder of renditions and a player that adapts to the connection, as the Netflix Help Center describes.
For streaming 1080p with H.264, the example ladder in Apple's HLS authoring specification uses 6,000 and 7,800 kbps, so roughly 6 to 8 Mbps. H.265 needs noticeably less for the same quality. Security cameras often run lower because their scenes are calmer, while cameras used for face or number plate capture need more. Our guide to video bitrate gives figures by task.
A fixed high bitrate setting asks for the top quality all the time. It looks best on a strong connection but stalls when the network dips. An adaptive high bitrate setting lets the player aim high, step down when the connection weakens and climb back when it recovers. The first favours peak quality. The second favours smooth playback at the best quality the network allows.
They measure different things. 4K is resolution, the number of pixels in each frame. Bitrate is how much data describes those pixels each second. A 4K stream squeezed into too little bitrate can look worse than a well fed 1080p stream. On a strong connection, 4K at a high bitrate looks best. On a weaker one, an adaptive setting often looks cleaner and does not stall.
For stereo AAC, Apple's HLS authoring specification recommends 32 to 160 kbps in total, with music and rich programme sound towards the top and speech towards the bottom. Security cameras usually carry mono speech, often as G.711 at 64 kbps or AAC at a modest rate. Audio is a small share of any stream, so the video bitrate decides your bandwidth.
Dynamic Adaptive Streaming over HTTP, usually called MPEG-DASH, is the international standard ISO/IEC 23009-1 for adaptive bitrate streaming. A manifest called the Media Presentation Description lists the available versions of a video and their segments. The player fetches segments over ordinary HTTP and switches versions as its connection changes. It supports live and on demand video and works with any media format.
Visylix automatically picks each camera's main stream or its lighter sub stream for every tile, based on tile size and connection speed. Small tiles and slow links get the sub stream, and a full screen tile gets full quality. Live view runs over WebRTC in any modern browser and falls back to HTTP-TS or HLS where a network needs it. Recordings always keep the camera's full original resolution.