Streaming Protocol
HLS (HTTP Live Streaming)
Last updated: June 03, 2026
HLS (HTTP Live Streaming) is a streaming protocol developed by Apple that delivers video by splitting it into small HTTP-downloadable segments with a manifest file (.m3u8) that tells the player which segments to fetch and in what order. It supports adaptive bitrate streaming — switching quality in real time based on available bandwidth — and is the dominant delivery protocol for OTT streaming across iOS, Android, smart TVs, and web browsers.
HTTP-based delivery
Adaptive bitrate
m3u8 manifest
Apple origin
Widest device support
Where it fits in OTT stack
Video Source
Encoder / Transcoder
HLS Packager
CDN Edge
Player (m3u8)
Device Playback
How it works
- The encoder transcodes the source video into multiple quality renditions (e.g. 1080p, 720p, 480p, 360p).
- The HLS packager splits each rendition into short segments (2–10 seconds each) and writes them to storage.
- A master manifest (.m3u8) is generated listing all available renditions with their bandwidth and resolution.
- Each rendition has its own media manifest (.m3u8) listing the segment URLs in sequence.
- The CDN caches both manifests and segments at edge nodes — close to viewers globally.
- The player fetches the master manifest, selects the best starting rendition based on current bandwidth.
- During playback, the player monitors download speed and switches renditions dynamically via ABR.
Key components
- Encoder / transcoder — produces multiple quality renditions from the source video
- HLS packager — segments video into chunks and generates .m3u8 manifest files
- Master manifest (.m3u8) — lists all available renditions with bandwidth and resolution metadata
- Media manifest (.m3u8) — per-rendition playlist of segment URLs in sequence
- TS or fMP4 segments — the actual video chunks delivered over HTTP (fMP4 preferred for LL-HLS)
- CDN — caches and distributes segments and manifests globally from edge nodes
- HLS player — reads manifests, manages ABR switching, and handles DRM license requests
Performance impact
- CDN-friendly HTTP delivery — segments cache efficiently at edge nodes, reducing origin load significantly
- Adaptive bitrate switching eliminates most buffering by matching quality to available bandwidth in real time
- Native device support across iOS, Android, smart TVs, and browsers — single protocol covers virtually all devices
- Segment-based delivery enables DVR, time-shifting, and catch-up TV without additional infrastructure
- LL-HLS reduces live stream latency from 20–30 seconds to under 3 seconds for latency-sensitive use cases
- fMP4 segments (vs legacy TS) reduce overhead and improve seeking performance in modern players
Common issues
- Manifest staleness during live streams — players fail to fetch updated playlists if CDN TTLs are misconfigured
- Segment duration inconsistency — variable segment lengths cause ABR switching instability and seeking errors
- DRM license request failures — HLS + FairPlay (iOS) requires correct key server configuration and certificate handling
- LL-HLS adoption gaps — older players and CDNs may not support partial segments, causing fallback to standard HLS latency
- Bitrate ladder misconfiguration — too few renditions or wrong resolution/bitrate pairs leave mobile viewers underserved
- Origin overload on cache miss — large live events can overwhelm origin if CDN caching is not correctly configured
When HLS is the right choice
- Any OTT platform requiring delivery across iOS devices — HLS is the only natively supported protocol on Apple platforms
- Multi-device delivery where a single protocol must cover web, mobile, smart TV, and CTV
- Live streaming where CDN scalability and HTTP infrastructure compatibility are required
- VOD delivery where adaptive bitrate playback and CDN caching efficiency are priorities
- Low-latency live use cases (sports, auctions, live events) where LL-HLS can reduce latency to under 3 seconds
Signals your HLS setup needs attention
- Buffering spikes on mobile networks despite sufficient bandwidth
- Playback failures on iOS or Apple TV devices
- High origin server load suggesting CDN cache miss rates are elevated
- Live stream latency consistently above 10 seconds where real-time viewing matters
- Seeking errors or incorrect resume positions in VOD playback
Real-world example
An OTT platform standardizing on HLS for multi-device delivery
A regional OTT platform was delivering video using RTMP for live streams and MP4 progressive download for VOD. Playback quality was inconsistent across devices, buffering was frequent on mobile networks, and smart TV support required separate infrastructure.
Challenge
- RTMP live streams were not supported on iOS devices — a large portion of their audience.
- MP4 progressive download had no quality adaptation — mobile users on 3G experienced constant buffering.
- Smart TV apps required a separate delivery stack, doubling infrastructure complexity.
- No CDN caching was possible with the existing setup — origin server costs were high at scale.
Action taken
- Migrated all live streams from RTMP to HLS using a cloud transcoding pipeline.
- Converted the VOD library to HLS with multi-rendition bitrate ladders (1080p, 720p, 480p, 360p).
- Configured the CDN to cache HLS segments — reducing origin load by 85%.
- Deployed a single HLS player SDK across web, iOS, Android, and smart TV apps.
- Enabled LL-HLS for live sports streams to reduce latency from 30 seconds to under 4 seconds.
Outcome
Buffering rate dropped by 52% within 30 days of migration. iOS playback issues were eliminated entirely. CDN caching reduced delivery costs by 38%. A single HLS pipeline now serves all devices and content types — live and VOD — from one unified infrastructure.
FAQs
What is HLS (HTTP Live Streaming)?
HLS (HTTP Live Streaming) is a streaming protocol developed by Apple that delivers video over standard HTTP by splitting it into small segments and using a manifest file (.m3u8) to guide the player through available quality renditions. It supports adaptive bitrate streaming — automatically adjusting quality based on available bandwidth — and is the most widely supported protocol for OTT streaming globally.
What does HLS stand for?
HLS stands for HTTP Live Streaming. It was developed by Apple in 2009 and standardized by the IETF in RFC 8216. Despite 'Live' in the name, HLS is used for both live streaming and video on demand (VOD) delivery.
How does HLS streaming work?
HLS works by encoding video into multiple quality renditions and splitting each into short segments (typically 2–10 seconds). A manifest file (.m3u8) lists the available renditions and their segment URLs. The player reads the manifest, selects the appropriate quality tier based on current bandwidth, and fetches segments sequentially over HTTP — switching between renditions in real time as network conditions change.
What is the difference between HLS and MPEG-DASH?
HLS and MPEG-DASH are both adaptive bitrate streaming protocols that work over HTTP. HLS was developed by Apple and has native support on all Apple devices. MPEG-DASH is an open standard with no royalties and is preferred for Widevine DRM delivery on Android and web. Most OTT platforms use HLS as the primary protocol, with MPEG-DASH added for specific DRM or device requirements.
What is LL-HLS (Low-Latency HLS)?
LL-HLS (Low-Latency HLS) is Apple's extension to the standard HLS protocol that reduces end-to-end live stream latency from the typical 20–30 seconds down to under 3 seconds. It uses partial segments and playlist delta updates to enable near-real-time delivery — making it suitable for live sports, auctions, and other latency-sensitive use cases.
What is an HLS server?
An HLS server is any origin server or cloud transcoding service that generates HLS output — encoding video into segmented renditions and producing .m3u8 manifest files. In modern OTT stacks, HLS packaging is typically handled by a cloud transcoding pipeline (such as AWS MediaConvert or Enveu's transcoding layer) rather than a traditional media server.