What Is HLS Streaming (HTTP Live Streaming)?
HLS streaming (HTTP live streaming) is an HTTP-based adaptive bitrate video delivery protocol developed by Apple. It divides live or on-demand media into segments referenced by M3U8 playlists. Compatible players retrieve these segments from a web server, or content delivery network (CDN) and can switch between quality levels as network conditions change.
How Does HLS Streaming Work?
An HLS workflow has three stages: preparing media streams, delivering content over HTTP, and playing the segments in a video player.
Step 1: Encode and Package the Media
The source audio and video are encoded into one or more variants at different bitrates and resolutions. A segmenter or packaging system then divides each variant into short media segments and generates an M3U8 media playlist that lists the segments in playback order. When multiple variants are available, a multivariant playlist (also called a master playlist) references their respective media playlists.
Step 2: Deliver HLS Segments Over HTTP
The generated playlists and media segments are made available through an origin server, where video players can request them over HTTP. For large-scale delivery, a CDN can cache these files at edge servers closer to viewers, reducing the load on the origin server and improving delivery efficiency.
Step 3: Retrieve and Play the Segments
The video player first requests the HLS playlist. If a multivariant playlist is available, the player selects an appropriate variant and retrieves its media playlist. It then downloads the listed segments and plays them as a continuous stream, switching between variants as network conditions change. For live streaming, the player also reloads the media playlist periodically to discover newly available segments.
Beyond the basic delivery process, HLS is designed to support consistent playback across varying network conditions and streaming requirements. Two important aspects of this flexibility are adaptive bitrate streaming, which helps maintain playback quality as network conditions change, and low-latency delivery options for live streaming.
What Is Adaptive Bitrate Streaming in HLS?
Adaptive bitrate streaming (ABR) is a playback technique that automatically switches between video variants with different bitrates and, often, resolutions as network conditions change.
HLS provides these variants through a multivariant playlist. During playback, the player estimates available network throughput and selects a suitable variant.
When bandwidth drops, the player can switch to a lower-bitrate variant to help reduce buffering. When conditions improve, it can switch to a higher-quality variant.
By adapting video quality to available throughput, ABR helps balance video quality and playback stability, although quality changes may be visible when network conditions fluctuate.
What Is Low-Latency HLS (LL-HLS)?
Low-Latency HLS, or LL-HLS, is an extension of HLS designed to reduce live-streaming latency. LL-HLS builds on the same HLS architecture, using playlists and media segments delivered over HTTP.
In standard HLS, players typically wait until a complete media segment is available before downloading it. LL-HLS reduces this delay by making smaller portions of each segment, called partial segments, available as they are produced. This allows players to retrieve media before the full segment is complete.
To further reduce latency, LL-HLS also uses preload hints to let players request upcoming media in advance. With blocking playlist reloads, the server holds playlist update requests until new media is available, eliminating the need for repeated polling.
Together, these features reduce waiting during live playback while retaining HLS’s CDN-friendly delivery model. Achieving low latency in practice still requires support across the packaging, delivery, and playback pipeline.
What Are the Benefits and Limitations of HLS Streaming?
HLS is widely used for delivering video across different devices, networks, and regions. Its main advantages include broad compatibility, scalable HTTP delivery, and adaptive playback. However, it also introduces trade-offs, particularly in latency-sensitive applications and workflows that require multiple video renditions.
Key Benefits
-
Broad device support: HLS works across many mobile devices, smart TVs, and streaming platforms. Browser playback can use native HLS support or a compatible JavaScript player, depending on the browser, player, and media format.
-
Scalable content delivery: HLS packages video into playlists and media segments that CDNs can cache and deliver from edge locations, making the protocol well suited to delivering video to geographically distributed audiences.
-
Adaptive video quality: HLS supports multiple bitrate variants, allowing compatible players to switch quality levels as network conditions change and reduce buffering.
Main Limitations
-
Higher live latency: HLS playback usually waits for new segments to be generated, listed in the playlist, requested, and buffered, which can keep live streams farther behind the live edge than real-time protocols such as WebRTC. LL-HLS reduces HLS latency, but low-latency playback depends on compatible encoding, packaging, CDN delivery, and player support.
-
Encoding and storage overhead: ABR-based HLS workflows need multiple encoded renditions and playlists for different quality levels. Each rendition adds encoding time, storage use, packaging work, and playback testing.
When Should You Use HLS Streaming?
Choose HLS when you need to deliver live or on-demand video to audiences across regions and devices, and broad reach matters more than real-time interaction.
Common use cases include:
-
Live Streaming and Large-Scale Broadcasts: HLS suits sports, news, concerts, and other live events that need to reach viewers across regions. When lower latency is important, LL-HLS can bring playback closer to real time while retaining HTTP-based delivery and CDN scalability.
-
OTT and Video-on-Demand: HLS works well for online video streaming platforms offering films, series, catch-up content, and recorded events across phones, web browsers, and smart TVs. Adaptive bitrate streaming adjusts playback quality to changing network conditions, while CDN caching supports delivery at scale.
HLS is generally less suited to applications that depend on very low latency and two-way interaction, such as video calls. WebRTC is often a better fit for these use cases.
HLS vs. Alternative Streaming Protocols
HLS is one of several technologies used in video streaming workflows. Some provide alternative ways to deliver video to viewers, while others handle stream ingestion, session control, or real-time communication.
The table below compares HLS with other streaming technologies, highlighting how they differ in purpose, delivery methods, and latency.
| Technology | Typical Role / Use Case | Main Difference from HLS |
|---|---|---|
| RTMP | Live stream ingestion | Primarily used for stream ingestion, while HLS delivers video to viewers. |
| RTSP | Streaming session control | Controls streaming sessions, while HLS delivers media through HTTP playlists and segments. |
| Microsoft Smooth Streaming (MSS) | Legacy adaptive HTTP streaming | Uses Smooth Streaming manifests instead of HLS M3U8 playlists. |
| Dynamic Adaptive Streaming over HTTP (MPEG-DASH) | Adaptive HTTP streaming | Uses MPD manifests instead of HLS M3U8 playlists |
| WebRTC | Real-time interactive communication | Enables real-time, two-way communication, while HLS focuses on one-to-many streaming. |
| LL-HLS | Low-latency HLS delivery | delivers partial segments sooner to reduce latency compared with standard HLS. |
| MoQ | Emerging low-latency media transport | Uses QUIC and Web Transport instead of HLS-style HTTP playlists and segments |
The following sections focus on RTMP, MPEG-DASH, and WebRTC because they highlight three distinct approaches to stream ingestion, adaptive HTTP delivery, and real-time interaction.
HLS vs. RTMP
RTMP (Real-Time Messaging Protocol) and HLS typically serve different stages of a live-streaming workflow. RTMP commonly carries a live feed from an encoder to a streaming server, while HLS delivers packaged media to viewers over HTTP.
A streaming platform can ingest a feed over RTMP, then process and package it for HLS delivery through a CDN. The two protocols often work together rather than compete directly.
HLS vs. MPEG-DASH
HLS and MPEG-DASH are the closest alternatives in this comparison. Both support adaptive bitrate streaming for live and on-demand video over HTTP, allowing players to adjust playback quality as network conditions change.
The main difference lies in their manifest formats and playback ecosystems. HLS uses M3U8 playlists, while MPEG-DASH uses an MPD (Media Presentation Description). The better choice depends on target devices, player compatibility, and existing encoding and delivery workflows.
HLS vs. WebRTC
WebRTC and HLS address different latency and interaction requirements. WebRTC supports real-time audio, video, and data exchange between browsers or devices, making it suitable for video calls and interactive sessions.
HLS is generally better suited to one-to-many streaming where broad audience reach and CDN-based delivery are priorities. WebRTC is a better fit when viewers or participants need to communicate with minimal delay. Some streaming services use both technologies for different parts of the overall streaming experience.
Does CDNetworks Support HTTP Live Streaming?
CDNetworks supports HLS for both live and on-demand video through its Media Acceleration Live Broadcast and Media Acceleration VoD services.
HLS Live Streaming with Media Acceleration Live Broadcast
CDNetworks Media Acceleration Live Broadcast delivers live video through the CDNetworks CDN.
Depending on the configured workflow, streams can be received through an ingest domain or retrieved from an origin server and distributed to viewers through a delivery domain.
The service supports HLS playback delivery and provides configuration options for segment duration, initial playlist segment count, and target playlist segment count. These settings allow streaming operators to adjust HLS delivery behavior according to their application requirements.
HLS VOD with Media Acceleration
CDNetworks Media Acceleration VoD supports HLS and DASH packaging, along with adaptive bitrate streaming. Content providers can configure multiple bitrate and resolution variants to support playback across different devices and network conditions.
Together, these services help organizations distribute live and on-demand video using CDN infrastructure and configurable media delivery workflows.
How to Optimize HLS Streaming for Lower Latency and Better Playback
Optimizing HLS requires balancing playback latency, startup time, buffering, and stream stability. Changing a single playlist or encoder setting does not necessarily improve all four
As an early adopter of HLS, CDNetworks has experience fine-tuning HLS delivery. Drawing on this experience, we recommend the following adjustments to help reduce delays while maintaining reliable playback.
-
Tune the Initial Playlist: CDNetworks allows you to configure the number of segments in the initial HLS playlist. If the target player can start playback with fewer segments, reducing this count may shorten startup time. Test the setting with target players to ensure smooth playback.
-
Align GOP and Segment Duration: HLS segments are typically cut at keyframe boundaries, so the encoder’s group of pictures (GOP) interval affects segment boundaries and how soon media becomes available. Coordinate the GOP interval with the target segment duration rather than shortening the GOP in isolation. Validate the settings with the encoder, packaging workflow, and target players.
-
Set the Target Playlist Segment Count: CDNetworks’ live-streaming configuration allows the number of segments retained before delivery to be adjusted. Reducing the count shortens the playlist window but does not automatically lower playback latency. It also gives the player less room to recover if segment generation or delivery is delayed. Test the setting alongside segment duration and player buffering under realistic network conditions.
HLS Streaming FAQs
Does HLS Use TCP or UDP?
HLS uses HTTP for media delivery, so the underlying transport depends on the HTTP version. HTTP/1.1 and HTTP/2 typically run over TCP, while HTTP/3 uses QUIC over UDP.
Does HLS Require a Dedicated Streaming Server?
HLS does not require a dedicated streaming server because standard web servers or CDNs can deliver HLS playlists and media segments. Live streams still need an encoding and packaging workflow to generate them.
Is HLS Free to Use?
HLS has a publicly available specification, and using the protocol itself does not typically incur a protocol-specific fee. However, codec or DRM licensing, encoding, hosting, and CDN delivery can add costs.
What Is the Typical Latency of HLS Streaming?
Latency for traditional HLS often ranges from 12 to 30 seconds, depending on segment duration, playlist settings, player buffering, and delivery configuration. LL-HLS can reduce latency when the full delivery chain supports its low-latency features.