Adaptive Bitrate and Video Infrastructure: A Technical Guide to HLS, DASH, and CDN

A streaming platform lives and dies by the quality of the viewing experience. Buffering, low video quality, slow start times - every second of poor video experience is a second closer to churn. And yet video infrastructure is an area where many platforms make casual decisions early in the build phase, only to pay the price later in technical debt and weaker user retention.

Adaptive bitrate streaming (ABR) is the technology that enables a smooth video experience under varying network conditions. It is the technology behind graceful quality degradation when a connection deteriorates, rather than buffering. This article covers what adaptive bitrate actually means, how the two dominant protocols HLS and DASH differ, how an encoding ladder is structured, what to consider when configuring your CDN, and how to measure video quality in production.

This is a technical article aimed at decision-makers and architects who want to understand what they are building - not at beginners, and not at video engineers who already live in these details every day.

What Is Adaptive Bitrate Streaming?

Traditional progressive download is straightforward: you request a file, it downloads, it plays. The problem is that the file is encoded at a fixed bitrate, and if your connection cannot sustain that rate, you get buffering.

Adaptive bitrate solves this by dividing the video into short segments - typically 2 to 10 seconds long - and encoding each segment at multiple quality levels with different bitrates. A manifest file describes all available representations. The player downloads the manifest, estimates available bandwidth, and continuously selects which quality level to request for the next segment.

If network quality drops, the player selects a lower bitrate. If it improves, the player steps up to higher quality. All of this happens seamlessly for the viewer - or should, if it is well implemented.

It is important to understand that ABR is not simply about choosing the right bitrate for the moment. A good ABR algorithm balances three competing objectives:

1. Maximum video quality: Always select the highest possible bitrate for available bandwidth.
2. Buffer stability: Maintain sufficient buffer to avoid playback interruptions.
3. Minimal switching: Avoid stepping up and down between quality levels too rapidly, which creates an unsettled viewing experience.

These objectives are not always compatible, and the ABR algorithm is where the trade-offs are made. Modern algorithms such as BOLA and machine-learning-based approaches derived from Pensieve account for buffer history, estimated future bandwidth, and the perceived cost of quality transitions.

HLS vs DASH: A Deep Dive

The two dominant ABR protocols today are HLS (HTTP Live Streaming) and DASH (Dynamic Adaptive Streaming over HTTP). The choice between them affects everything from DRM implementation to player complexity and device support.

HLS

HLS was developed by Apple and originally published to support iOS devices. The specification is maintained by Apple, and the relevant reference documentation is at Apple Developer Documentation.

HLS is mandatory on Apple platforms: Safari on macOS, all iOS devices, and Apple TV require HLS. That is a practical reality that means most platforms need to support HLS regardless of their other choices.

Historically HLS used MPEG-TS (Transport Stream) as its container format, but modern profiles support fMP4 (fragmented MP4), which reduces overhead and enables better integration with DASH.

HLS supports FairPlay as its DRM system, which is required for encrypted content on Apple platforms.

Low-Latency HLS (LL-HLS): Apple published an extension to the HLS specification for low latency, enabling live streaming with latency in the 1–2 second range. This is achieved through partial segments and push-preloading of the next segment.

DASH

DASH is an open standard maintained by the DASH Industry Forum (DASH-IF) and is the protocol that dominates on Android, web, and smart TV platforms outside the Apple ecosystem.

DASH is more flexible than HLS in its base specification. It supports multiple DRM systems via MPEG-CENC (Common Encryption), meaning a single encrypted content asset can be decrypted by both Widevine (Google/Android) and PlayReady (Microsoft) without re-encoding the content.

DASH manifest files are XML-based and called MPD (Media Presentation Description). MPD is more expressive than HLS manifests, offering more flexibility but also more complexity.

Low-Latency DASH (LL-DASH): Just as HLS has received low-latency extensions, DASH has followed suit with a similar architecture built on chunked transfer encoding and short segments.

Practical Choice: Both

In practice, most platforms support both. Apple devices require HLS. Other devices can use DASH. Modern video players such as Shaka Player and Video.js support both protocols, and with fMP4 as the container format, content can largely be shared between protocols - the manifest files differ but the actual video and audio segments can be identical.

This reduces storage and transcoding costs significantly compared to encoding separate asset sets for each protocol.

Encoding Ladder: The Foundation of Quality of Experience

An encoding ladder is the set of quality representations you provide per content item. It is one of the most consequential decisions in your video infrastructure, directly affecting cost, storage requirements, and quality of experience.

A classic static encoding ladder might look like this:

But a static ladder is a blunt instrument. A news broadcast with static frames and minimal motion can be delivered at excellent quality at 600 kbps at 720p. An action film with rapid cuts and complex motion may look inadequate at 4500 kbps at 1080p.

Per-title encoding is a more sophisticated approach where the encoding ladder is adapted for each individual content item based on its complexity. Netflix published research on this approach and it has become the industry standard for serious video operators. The result is either equivalent quality at lower cost, or better quality at the same cost.

Per-scene encoding takes it a step further and adapts the bitrate within a content item based on scene complexity. It requires a more sophisticated transcoding pipeline but delivers the best results.

Codec selection also fundamentally affects encoding ladder design. AVC/H.264 is the most compatible choice but the least efficient. HEVC/H.265 delivers approximately 40 percent better compression at the same quality level. AV1 improves further but requires more encoding resources and still has limited hardware decode support on older devices. A modern encoding ladder needs to account for which codecs your target audience can actually decode.

CDN Configuration for ABR Streaming

A CDN (Content Delivery Network) is the infrastructure that delivers your video segments with low latency to end users worldwide. CDN configuration is not neutral - incorrect configuration can undermine the benefits of a well-designed encoding ladder and ABR algorithm.

Cache policy for segments versus manifests: Segment files are static and should be cached aggressively with long TTL values. VOD manifest files can be cached similarly. Live streaming manifest files contain continuously updated segment pointers and should have short TTL values or not be cached at the CDN level at all.

Origin shield: An origin shield configuration adds an extra caching layer between CDN edge nodes and your origin server. It reduces the number of cache misses that reach origin and is particularly important during high-popularity spikes - such as a major live premiere.

Regional coverage and routing: Ensure your CDN has strong coverage in the regions where your audience is located. Latency to the nearest CDN node affects start time. A CDN node in Amsterdam delivers low latency for European users but poorer performance for Southeast Asian users if no regional alternative is available.

Range requests: ABR players frequently request segments via HTTP range requests. Verify that your CDN configuration handles range requests correctly - incorrect caching of range requests can cause entire segments to be cached separately for each unique range request, defeating the cache entirely.

HTTP/2 and HTTP/3: Modern ABR streaming benefits from HTTP/2's multiplexing to request multiple segments in parallel without opening new TCP connections. HTTP/3 (QUIC) further improves performance during network transitions and on mobile networks with packet loss. Verify that your CDN supports and actively serves HTTP/2 and HTTP/3 to end users.

Monitoring Video Quality: QoE Metrics

You cannot optimise what you do not measure. And server-side metrics - traffic, bandwidth, error codes - do not tell you enough about the actual experience the end user encounters.

QoE (Quality of Experience) metrics measure the video experience from the user's perspective. They are typically collected via the player SDK and sent to an analytics backend in real time.

Start delay (Time to First Frame): How long from the user pressing play until the first video frame renders? Research shows users begin to abandon streams at delays beyond 2 seconds, and that each additional second of waiting increases the abandonment rate further.

Rebuffering ratio: The proportion of playback time spent in a buffering state. This is the metric that most strongly correlates with churn and user satisfaction. A rebuffering ratio of 0.5 percent is typically considered acceptable, but the industry aims for below 0.1 percent.

Retry frequency: How often does the player re-request a segment? High retry frequency can indicate unstable CDN nodes or origin problems.

Quality switches: How many times the player switches between bitrate levels during a session, and in which direction. Upward switches indicate improving network conditions, downward switches indicate degradation. High switching frequency can indicate an ABR algorithm that is too aggressive.

Average displayed bitrate: What bitrate level are users actually watching? If it is consistently lower than what your encoding ladder offers, it indicates network constraints or CDN problems.

Error rate by error type: Break down errors into categories - network errors, DRM errors, decoding errors - to prioritise troubleshooting effectively.

These metrics should be aggregated by device, region, carrier, application version, and content type. Patterns that only appear for a specific device or region quickly point toward the underlying cause.

Summary and Next Steps

Stable video infrastructure is built on a set of well-considered decisions that need to be made in the right order: protocol selection (HLS, DASH, or both), encoding ladder design suited to your content, CDN configuration that matches your audience's geography, and a QoE measurement infrastructure that gives you visibility into what is actually happening for end users.

The technology is mature and accessible. What distinguishes platforms is how carefully these decisions are made and how rigorously they are followed up.

Shapp builds and improves streaming infrastructure for clients at various scales. Read more about our specialisation in streaming and our guide to building a streaming platform, or contact us to discuss your infrastructure.