Adaptive Bitrate Streaming with HLS and DASH

In the early days of video streaming, viewers with poor connectivity or older devices often faced a frustrating choice: either watch low-quality video that played smoothly, or high-quality video that constantly buffered and stuttered. Adaptive bitrate (ABR) streaming, which enables a video player to adjust resolution, bitrate, and other playback parameters in real-time based on the viewer’s network speed and device capabilities, changed all that. This article examines how HTTP Live Streaming (HLS) and Dynamic Adaptive Streaming over HTTP (DASH) enable adaptive bitrate streaming to improve viewer experience.

Why Deliver Media over HTTP?

Prior to the emergence of HLS and DASH, streaming protocols required expensive, specialized servers and often struggled with firewalls and network configurations. This made video streaming costly to deploy and maintain, limiting who could afford to offer streaming services. In traditional non-HTTP IP-based streaming, the client receives media that is typically pushed by a media server using either connection-oriented protocols, such as the Real-time Messaging Protocol (RTMP/TCP), or connectionless protocols, such as the Real-time Transport Protocol (RTP/UDP). Although RTMP is still widely deployed as an ingest protocol, it’s rarely used for last-mile delivery since the deprecation of the Flash player. (WebRTC, which uses UDP as the transport protocol and RTP at the application layer, has standardized real-time communication on the browser, but deploying it still remains non-trivial as it may require TURN relays or STUN servers for NAT traversal.) 

Around 2005, HTTP-based streaming emerged as an elegant video delivery paradigm, with better features and cheaper deployment costs. This paradigm treats media content like regular web content and delivers it in small chunks over the HTTP protocol. Clients pull the data from a standard HTTP server, which simply hosts the media content. 

HTTP-based streaming transformed video delivery from a specialized service requiring custom infrastructure into one that could leverage standard web technologies. Content providers can utilize ordinary web servers, standard CDN services, and existing caching mechanisms, thereby reducing deployment complexity and costs while enhancing reliability through standard web technologies.

Adaptive Bitrate Streaming

ABR works by offering multiple versions of the same video at varying resolutions and bitrate levels, allowing the player to switch between them in real-time. Think of it as a smart thermostat for video quality — it constantly monitors conditions and automatically adjusts to the optimal settings. The video player continuously analyzes metrics like download speed, buffer status, and dropped frames to make real-time decisions about video quality. When network conditions are good, the player requests higher-bitrate video segments. Conversely, if the network weakens, it switches to a lower bitrate to prevent buffering.

This client-driven approach shifts the processing burden from a central server to each individual viewer’s device. It also allows for personalized optimization, as players can adjust bitrate (and therefore, in most cases, quality) not only based on network speed but also on a device’s specific capabilities, such as its screen resolution and processing power.

The ABR process begins during video encoding. The raw video is converted into several versions, or renditions, each with a different bitrate and resolution, creating what’s typically called an encoding ladder. These renditions are then broken into smaller segments. A manifest file is created to serve as a guide for the player, telling it where to find all the different segments. The player uses this file to select and download the best rendition for the current viewing conditions, switching between them as conditions change.

HLS

HLS (HTTP Live Streaming) emerged from Apple in 2009, initially designed to bring video streaming to iOS devices when Adobe Flash wasn’t supported. The protocol’s simplicity became its strength; using standard HTTP infrastructure, HLS could work with ordinary web servers and content delivery networks without requiring specialized streaming hardware.

HLS works by chunking audio and video content into small media segments and uses extended M3U playlist files to describe the order and location of these segments. The client requests the M3U playlist via the HTTP protocol and dynamically selects the appropriate bitrate for playback. (m3u8 — meaning a UTF-8-encoded M3U file — is the most common extension for these files.)

These playlists are categorized into two types: multivariant playlists, which list available resolutions and bitrates, and media playlists, which contain the actual segment URLs for each quality tier.  Here’s an example of an HLS multivariant playlist (also known as a master playlist), with two variant streams, each with different resolutions and bitrates (720p and 360p):

An HLS playlist begins with the #EXTM3U tag, indicating that it is an extended M3U file containing metadata for media playback. The playlist above is also tagged with the VERSION tag, which is 7, and the INDEPENDENT SEGMENTS tag, indicating that each segment listed in the media playlists can be decoded independently, without requiring information from previous segments. 

The codecs are also listed, AVC, also known as H.264, for video, and AAC for audio. Besides AAC, HLS can also encode audio using MP3, AC-3, or EC-3. The media is encapsulated as an MPEG-Transport Stream or fragmented MP4, as Apple added support for fmp4 through CMAF.

The player then accesses the specified media playlist to retrieve and play the actual video and audio segments in sequence, using the URLs listed within it.

LL-HLS

Historically, HLS has favored stream reliability over low latency. Low-Latency HLS (LL-HLS) aims to reduce the glass-to-glass delay when streaming via HLS by reducing the time to start live stream playbacks and maintaining that time during a live streaming event. 

In traditional HLS, a player must wait for an entire segment (e.g., 6 seconds) to be fully generated and published before it can start downloading and playing it. This introduces inherent latency, as the player is always at least one segment behind the live edge.

LL-HLS solves this by breaking the first segment into smaller partial segments (e.g., 200ms chunks). Instead of waiting for a full 6-second segment, the player can:

1. Start playback earlier – As soon as the first partial segment (200ms) is available, the player can begin downloading and playing it, rather than waiting for the full segment.
2. Fetch updates incrementally – The player continuously loads subsequent partial segments as they become available, reducing the delay between media generation and playback.
3. Smoothly transition to full segments – After the initial partial segments, the stream switches back to normal-sized segments (e.g., 6s) for stability, but the initial low-latency boost has already been achieved.

By allowing players to consume media in smaller, more frequent chunks, LL-HLS reduces glass-to-glass latency from ~10-30 seconds (traditional HLS) to as low as 2-3 seconds, while maintaining reliability.

LL-HLS leverages HTTP/2, which features a server push mechanism that allows a server to proactively send resources to a client before the client explicitly requests them. This is particularly helpful for HLS, as it allows it to push the segments along with the playlist, reducing the overhead of establishing repeated HTTP/TCP connections.

DASH

While HLS was Apple’s solution, many in the streaming industry sought an open standard that any company could implement. As a result, DASH (Dynamic Adaptive Streaming over HTTP) was developed by the Moving Picture Experts Group (MPEG) as an open international standard (ISO/IEC 23009-1). 

A DASH server is essentially an HTTP server that hosts media segments, which are typically two to ten seconds each, or can be as long as the entire content duration in presentation time.

Each segment is encoded at multiple bitrate levels and listed in the manifest, known as the Media Presentation Description (MPD). The MPD is an XML document that provides an index for the available media segments at the server. While XML is more verbose compared to HLS’s text-based m3u8, it allows for greater flexibility in describing complex presentations with multiple codecs, languages, and accessibility features.

At the client side, DASH implements the bitrate adaptation logic, which issues timed requests and downloads segments that are described in the MPD from the server using HTTP GET messages. The DASH client estimates the available bandwidth in the network and uses information from the playback buffer to select a suitable bitrate for the next segment to be fetched. This behavior is known as bitrate switching, where the client’s goal is to fetch the highest-bitrate segments it can while maintaining sufficient data in the playback buffer to avoid video stalls and achieve a good QoE trade-off.

DASH segments are typically delivered as fragmented MP4 files, though the standard supports various container formats.

The ISO specification defines a hierarchical structure:

• Media Presentation Description (MPD): XML document describing the entire presentation
• Periods: Time intervals with consistent available media
• Adaptation Sets: Groups of interchangeable representations
• Representations: Specific encodings of media content
• Segments: Individual chunks of media data

DASH’s codec-agnostic design allows content providers to mix different video standards within the same presentation. A single DASH stream might offer H.264 for compatibility alongside HEVC or AV1 variants for devices that support these codecs. 

LL-DASH

MPEG-DASH segments are optimized for reliable delivery across Content Delivery Networks (CDNs), but introduce latency at various stages: the time required to encode and finalize each full segment, the propagation delay as segments traverse the CDN, and the player’s own buffering logic, which typically waits for multiple segments to ensure smooth playback.

LL-DASH is a variation of MPEG-DASH that integrates multiple techniques to minimize latency without compromising reliability. It breaks each segment into smaller, independently decodable chunks, often just a few hundred milliseconds in duration. Unlike traditional DASH, where the player must wait for an entire segment to be finalized, LL-DASH allows the origin server to begin transmitting chunks as soon as they are encoded. This means playback can start earlier, with the player assembling chunks incrementally as they arrive.

Precise timing is crucial for this process to be effective. The Media Presentation Description (MPD) manifest in LL-DASH includes availability timestamps, enabling the player to request chunks as soon as they are ready. To ensure accuracy, LL-DASH relies on synchronized clocks between the server and client, typically achieved through Network Time Protocol (NTP). Without this synchronization, players might request chunks too early or too late, undermining the latency gains.

In practice, LL-DASH requires players to maintain a small buffer of three to four chunks to absorb network variability. This is a significant reduction compared to traditional DASH, where buffers often hold multiple full segments. The result is a measurable drop in glass-to-glass latency—from tens of seconds to below five seconds. However, LL-DASH is not a magic bullet. Its performance depends on careful tuning: CDNs must efficiently handle chunked transfers, players must balance aggressive fetching with buffer management, and the entire pipeline must maintain tight clock synchronization.

CMAF

The streaming industry recognized that maintaining separate container formats created unnecessary complexity and costs. Content distributors needed to encode the same video twice — once in MPEG-TS containers for HLS and again in fragmented MP4 for DASH, which was not economical.

The Common Media Application Format (CMAF) emerged from collaboration between different organizations to address this fragmentation. CMAF enables both HLS and DASH to use the same fragmented MP4 container format while maintaining their distinct manifest structures.

The CMAF specification defines several logical media objects:

• CMAF Tracks contain encoded media samples (video, audio, or subtitles) in an ISO-BMFF container, optionally protected by Common Encryption. Each track consists of a header and one or more fragments.
• CMAF Switching Sets group alternative tracks of the same content at different bitrates, enabling adaptive bitrate streaming.
• Aligned Switching Sets contain time-synchronized tracks with different encodings (e.g., various codecs).
• CMAF Selection Sets combine switching sets of the same media type, offering alternatives like different languages or camera angles.
• CMAF Presentations synchronize multiple selection sets across different media types.

With CMAF, content providers can create a single set of media files that serve both HLS (.m3u8) and DASH (.mpd) manifests, dramatically reducing operational complexity and cutting costs.

Digital Rights Management (DRM)

DRM is a technology that encrypts digital media to prevent unauthorized use and piracy of copyrighted material. When a user attempts to play the stream, the video player requests a decryption key from a license server, which verifies the user’s and device’s authorization. Once verified, the server issues a license response with a decryption key, allowing the player to decrypt and play the stream. 

Norsk supports all major DRM systems, including Apple FairPlay, Google Widevine, and Microsoft PlayReady, providing a broad device and platform coverage for your HLS/DASH streams. Through the Norsk Studio UI, you can quickly configure DRM schemes with providers like EZDRM and Axinom, both of which offer cloud-based, standards-compliant license services.

Norsk Studio makes integrating either of them as simple as selecting your provider from a dropdown.

Using Norsk Studio for ABR with HLS and DASH

Norsk supports both HLS and DASH, and also enables you to utilize CMAF to package your content, allowing both HLS and DASH clients to play it. Our drag-and-drop platform, Norsk Studio, makes it easy to build live media workflows with the features you desire, such as ABR. 

Setting up an ABR ladder using Norsk Studio is as simple as dragging the ‘Encode Ladder’ component into the canvas and adding the rungs(renditions) you want on your ladder directly from the UI.

You can add and delete rungs as you wish, and by clicking the settings icon on either of the rungs, you get even more granular control of video properties like codec types, framerate, bitrates, etc. The UI also provides the ability to save your workflows as YAML files, which you can access for later use.

Connect that with an input and output, hit play, and you have a live workflow. 

We have conducted benchmarks on the type of cloud instance you need to run various standard ABR ladders using Norsk Studio and published our results here.

Conclusion

HLS and DASH are widely deployed protocols for delivering media to end consumers, especially popular for adaptive bitrate streaming. Norsk supports both HLS and DASH, as well as their low-latency extensions. Using Norsk Studio, you can build live media workflows in minutes and have your media delivered to broad audiences across devices and platforms thanks to our comprehensive protocol support — from traditional HLS/DASH to cutting-edge LL-HLS and LL-DASH for low-latency scenarios.