Every time you watch Netflix, catch a Twitch broadcast, or open a stream on your Apple TV, HTTP Live Streaming is doing the work behind the glass. HLS (HTTP Live Streaming) is an adaptive bitrate streaming protocol built by Apple that delivers video and audio as small HTTP segments, indexed by a playlist file. It chops your video into short chunks, ships them over the same HTTP that powers every website, and lets the player pick the right quality for each viewer’s connection.
That design is why HLS plays on almost any device, slips through firewalls like normal web traffic, and scales to millions of viewers over a CDN. It’s the most widely used delivery protocol in online video.
This blog will explain what HTTP Live Streaming is, how it works, and how to deliver an HLS stream to any screen.
What Does HLS Mean in Video Streaming?
HLS stands for HTTP Live Streaming, an adaptive bitrate protocol that delivers audio and video as small HTTP segments indexed by a manifest file. Apple built it to move video over ordinary web infrastructure instead of specialized streaming servers.
The protocol does one job well: delivery.
HLS takes an encoded video, splits it into segments a few seconds long, and hands those segments to any HTTP server or CDN to push out to viewers. Because the segments travel as standard web files, they play on phones, tablets, laptops, smart TVs, and set-top boxes without special software.
HLS is an egress protocol, not an ingest one. It moves the finished video the last mile to the viewer’s screen. Something else (usually RTMP or SRT) carries your camera feed the first mile into the platform.
HLS as an Apple-Built Protocol
Apple launched HLS in 2009 for the iPhone and iOS devices. Safari and iOS still play HLS natively, which means no plugin and no extra player code on Apple hardware.
The protocol outgrew Apple years ago. The IETF published it as an open specification, RFC 8216, and today Android, Windows, smart TVs, and every major browser handle it through HTML5 players. Netflix, Twitch, and most OTT services lean on it.
HLS for Live and On-Demand Video
The “live” in HTTP Live Streaming is a bit of a misnomer. HLS carries both live broadcasts and on-demand (VOD) libraries, and the mechanics are nearly identical.
For a live stream, the server creates segments in real time as the broadcast happens. For VOD, the segments already exist as a stored file. Either way, the player reads the same kind of playlist and requests the same kind of chunks.
How Does HTTP Live Streaming Work?
HLS works in four stages: encode the video, cut it into segments, distribute those segments over HTTP, then reassemble them in the viewer’s player. Each stage happens on ordinary web infrastructure, which is what makes the protocol so easy to deploy.
Here’s the pipeline end to end:
- Encode the source into a supported codec (H.264 or H.265).
- Segment the encoded video into short chunks and write a manifest.
- Distribute the chunks over HTTP, usually through a CDN.
- Reassemble the chunks in the player using the manifest as a map.
The Encoding and Segmenting Stage
Encoding reformats your raw video so any device can decode it. HLS requires H.264/AVC or H.265/HEVC, the two codecs that modern players understand almost universally.
Segmenting then slices the encoded video into short files. The default segment is 6 seconds, down from the original 10 seconds Apple used until 2016. The encoder also builds duplicate sets of those segments at different resolutions, so the same second of video exists at 240p, 480p, 720p, 1080p, and up.
The .m3u8 Manifest File
The manifest is the brain of an HLS stream. It’s a text file with a .m3u8 extension that lists every segment, its duration, and where the player can fetch it.
HLS actually uses two manifest layers. A master playlist lists the available quality renditions and points to each one. A media playlist under it lists the individual segments for that specific rendition. The player reads the master first, picks a rendition, then works through that media playlist chunk by chunk.
HTTP and CDN Delivery
HLS segments move as plain HTTP files, which is the protocol’s superpower. They ride over TCP, cache on any content delivery network, and pass through firewalls and proxies that would block a specialized streaming port.
A CDN copies your segments to edge servers close to viewers. A person in Tokyo and a person in Toronto pull the same stream from different nearby locations, so both get low buffering without hammering your origin server.
Player Reassembly and Buffering
The player does the final assembly. It downloads the manifest, requests segments in order, and stitches them into continuous playback while keeping a few segments buffered ahead.
That buffer is the safety net. If the network hiccups, the player draws from buffered segments instead of freezing, and the viewer never sees the stall.
What Is Adaptive Bitrate Streaming in HLS?
Adaptive bitrate streaming lets an HLS player change video quality mid-stream as the viewer’s network conditions shift. It’s the reason a video drops to a softer resolution during a dip instead of stopping to buffer, then sharpens back up when bandwidth returns.
ABR works because HLS already created those duplicate renditions during segmenting. The player measures download speed in real time and switches to whichever rendition the connection can sustain. Viewers on fiber get 1080p or 4K; viewers on a weak cellular signal get 480p and keep watching.
This is HLS’s biggest advantage over older protocols. Without adaptive bitrate, a slow connection stalls the whole video; with it, playback continues at the best quality the network allows.
How the Bitrate Ladder Works
The bitrate ladder is the set of renditions your stream offers, from lowest to highest. Each rung pairs a resolution with a bitrate, and the player climbs or drops the ladder as bandwidth changes.
A typical ladder runs something like this:
- 240p at ~0.5 Mbps for weak mobile connections
- 480p at ~1 Mbps for basic mobile
- 720p at ~3 Mbps for standard broadband
- 1080p at ~7 Mbps for strong connections
- 4K at ~22 Mbps for fiber and modern TVs
More rungs mean smoother switching, but each rung adds encoding and storage cost. Most workflows tune the ladder to their audience’s real devices.
What Is the HLS Streaming Format Built From?
The HLS format is built from four parts: a container that holds each segment, codecs that compress the media, a manifest that indexes the segments, and TCP as the transport underneath.
Together they define what an HLS stream actually is on the wire.
| Component | What HLS uses |
|---|---|
| Container | MPEG-2 Transport Stream (.ts) or fragmented MP4 (fMP4 / CMAF) |
| Video codec | H.264/AVC (universal) or H.265/HEVC (efficient) |
| Audio codec | AAC |
| Manifest | .m3u8 master + media playlists |
| Transport | HTTP over TCP |
| Captions | WebVTT |
| DRM | FairPlay, Widevine, PlayReady |
Containers and Codecs
HLS originally packaged every segment in an MPEG-2 Transport Stream container, the .ts files you’ll still see in most streams. Newer deployments use fragmented MP4 through CMAF, which lets one set of segments serve both HLS and MPEG-DASH so you don’t encode twice.
The codecs stay consistent. H.264/AVC gives you the widest device compatibility, and H.265/HEVC roughly halves the bitrate for the same quality on hardware that supports it. Audio rides as AAC.
Manifests and Transport
The .m3u8 manifest indexes everything, and TCP moves it. HLS deliberately runs over TCP rather than UDP because it’s built on HTTP, and because adaptive bitrate already compensates for TCP’s slightly slower delivery. A few seconds of lag matters less than a dropped frame for most on-demand and broadcast use cases.
Why Does HLS Have High Latency, and How Does LL-HLS Fix It?
Standard HLS carries 10 to 30 seconds of latency because the player has to wait for whole segments to download and buffer before it plays them. Longer segments and deeper buffers add reliability but push the delay up.
That lag is fine for a movie or a keynote, where nobody notices a 20-second offset. It breaks down for anything interactive, like an auction, a sports bet, or a live Q&A where the chat runs ahead of the video.
Where HLS Latency Comes From
Latency in HLS is mostly segment length times buffer depth. If each segment is 6 seconds and the player buffers three of them before playing, you’ve built in roughly 18 seconds before the first frame even appears.
The trade-off is real. Shorter segments cut latency but create more files, more requests, and more chances for a rebuffer on a shaky connection.
Low-Latency HLS (LL-HLS)
Low-Latency HLS trims the delay to 2 to 5 seconds by delivering partial segments before the full segment finishes. Instead of waiting for a complete 6-second chunk, the player pulls smaller pieces as they’re ready, using chunked transfer and CMAF fragments.
That brings HLS close to real-time while keeping its scale and device reach. LL-HLS now competes with WebRTC for live sports and events that need both a fast picture and a huge audience.
How Does HLS Compare to MPEG-DASH, WebRTC, RTMP, and SRT?
HLS wins on device reach and CDN scale; it loses on latency to protocols built for real time. The right choice depends on whether you’re delivering to a large passive audience or powering a two-way interaction, and on whether you’re carrying video in or pushing it out.
| Protocol | Role | Latency | Best for |
|---|---|---|---|
| HLS | Delivery (egress) | 10–30s (2–5s LL-HLS) | Large audiences, VOD, OTT, mobile |
| MPEG-DASH | Delivery (egress) | 6–30s | Non-Apple ABR, codec flexibility |
| WebRTC | Delivery (egress) | Sub-second | Auctions, betting, two-way video |
| RTMP | Ingest (first mile) | ~5s | Encoder-to-platform contribution |
| SRT | Ingest (first mile) | ~1–2s | Reliable contribution over rough networks |
HLS vs MPEG-DASH
HLS and MPEG-DASH are close cousins. Both run over HTTP, both use adaptive bitrate, and both index segments with a manifest. DASH is codec-agnostic and an open ISO standard, which gives it more flexibility, but it isn’t natively supported on Apple devices the way HLS is. Many platforms ship both from one CMAF package to cover every screen.
HLS vs WebRTC
WebRTC beats HLS on speed and loses on scale. It delivers sub-second, peer-to-peer video that’s ideal for interactive use, but it strains past a few thousand concurrent viewers without a specialized network. HLS goes the other way: a few seconds slower, but effortless to fan out to millions over a CDN.
HLS vs RTMP and SRT
RTMP and SRT aren’t really HLS competitors; they’re teammates. Both are ingest protocols that carry your encoder’s feed the first mile into a streaming platform, where it gets transcoded and repackaged as HLS for delivery. A typical live workflow uses SRT or RTMP in and HLS out.
When Should You Use HLS for Your Stream?
Use HLS whenever you’re delivering to a broad audience across mixed devices and a few seconds of latency won’t hurt the experience. Its device reach and CDN scale make it the default for most live and on-demand video.
Best-Fit HLS Use Cases
HLS is the right protocol for the majority of streaming workflows:
- On-demand libraries (VOD): broad compatibility across every browser and device
- Large live audiences: concerts, keynotes, worship services, and conferences that scale over a CDN
- OTT delivery: Roku, Apple TV, and Fire TV apps that expect an HLS URL
- Mobile-first streaming: native playback on iOS and Android with adaptive bitrate
When to Reach for a Lower-Latency Protocol
Skip standard HLS when the interaction can’t tolerate a 20-second delay. Live auctions, sports betting, casino streams, and two-way shows need sub-second delivery, which is WebRTC territory. LL-HLS covers the middle ground when you want near-real-time timing without giving up HLS scale.
How Do You Stream With HLS Using Castr?
You stream with HLS on Castr by sending your feed in over RTMP or SRT, letting Castr transcode and package it, then grabbing an HLS playback URL for your player, website, or OTT app. Castr delivers every stream over HLS by default, so the last-mile protocol is handled for you.
From Encoder Ingest to HLS Playback
Getting a stream live takes a short path from encoder to HLS output:
- Create a livestream in Castr and pick a hosting region.
- Point your encoder (OBS, vMix, or hardware) at the RTMP or SRT ingest URL and key.
- Start streaming; Castr ingests the feed and packages it for delivery.
- Open the Playback tab and copy the HLS URL or the embed iframe for your site.
Castr also pulls from an existing source. You can feed it an RTMP, SRT, HLS, or RTSP pull URL instead of pushing from an encoder.
HLS Delivery, ABR, and OTT on Castr
Castr handles the parts of HLS that competitors leave you to build. It runs adaptive bitrate so viewers automatically get the best quality their connection supports, and it delivers over a multi-CDN backbone powered by Akamai, Fastly, and CloudFront.
For OTT, Castr generates HLS URLs that drop straight into Roku, Apple TV, and Fire TV apps. When 10 to 30 seconds is too slow, its sub-second streaming add-on switches delivery to WebRTC for real-time, interactive playback in the Castr player.
HTTP Live Streaming reaches almost any screen at scale, which is exactly why it carries most of the video you watch online. Castr delivers your stream over HLS by default, with adaptive bitrate, multi-CDN delivery, OTT-ready HLS URLs, and a sub-second option when you need real time.
Sign up for Castr’s free plan and deliver your first HLS stream today.