Adaptive Bitrate Streaming (ABR)

General definition

Adaptive Bitrate Streaming (ABR) solves a simple problem: the sender cannot know each viewer’s bandwidth, and it changes minute by minute. So the source is transcoded into an encoding ladder, a set of renditions at increasing resolution and bitrate (for example 360p at 800 kbit/s, 720p at 2.5 Mbit/s and 1080p at 5 Mbit/s), each cut into segments of a few seconds. A manifest lists the renditions and their segments. The player downloads segments over plain HTTP, measures how fast they arrive and how full its buffer is, and picks the rendition for the next segment accordingly.

The two dominant formats are HLS, Apple’s HTTP Live Streaming (RFC 8216) with M3U8 playlists, and MPEG-DASH, the ISO standard with an XML manifest. Both can share the same fragmented MP4 segments through CMAF, so one set of files serves every device. Because delivery is ordinary HTTP, segments cache on any CDN, which is how a single live event reaches millions of viewers without a media server per connection.

• Switches happen at segment boundaries, so shorter segments adapt faster but add overhead; 2 to 6 seconds is typical
• Latency is measured in seconds: classic HLS runs 15 to 30 seconds behind live, and the low-latency variants (LL-HLS, LL-DASH) bring that to around 2 to 4 seconds using partial segments and chunked transfer
• The ABR algorithm lives in the player, trading off throughput estimates, buffer occupancy and the cost of visible quality changes
• Everything is prepared in advance by a transcoding step, so the server does no per-viewer work

Real-time calls solve the same bandwidth problem the other way round. In WebRTC, simulcast or scalable video coding has the sender encode several layers at once, and a media server chooses which layer to forward to each receiver, switching in milliseconds based on congestion feedback. There is no segment and no HTTP cache, which keeps latency under half a second but means every viewer costs the server bandwidth. ABR is for one-to-many playback where seconds of delay are fine; simulcast is for conversations where they are not.

In the Ethora ecosystem

Ethora is a chat and calling platform, not a video streaming service, so its adaptation mechanism is the WebRTC one: calls run through an SFU that forwards the simulcast layer each participant’s connection can sustain, with bandwidth estimation on every leg adjusting in real time. That is the right tool for group calls, audio-only calls and anything where people are talking to each other and a two-second delay would be unusable.

Where a product needs ABR, for example to broadcast a webinar or a recorded consultation to a large audience, the usual pattern is to keep the interactive session on the calling stack and hand a copy to a separate streaming pipeline that transcodes it into an HLS or DASH ladder. On a dedicated or self-hosted deployment that pipeline can run in the same cloud account as the Ethora backend so the media never leaves infrastructure you control. The voice and video call API page lists what the calling stack includes.