HLS Protocol Deep Dive: Unveiling M3U8 and the Magic of Streaming Slicing

Imagine you are sitting on a speeding subway train, watching a 4K movie on your phone. The signal fluctuates, but the video doesn’t freeze or buffer. Instead, it smartly switches between high definition and standard definition, playing smoothly throughout.

This isn’t magic; this is the HLS (HTTP Live Streaming) protocol guarding your experience.

As a killer feature introduced by Apple during the iPhone 3GS era, HLS has completely changed the way we consume video. Today, through this in-depth report, we will dismantle the technical skeleton behind the HLS protocol and see how it breaks down massive video streams into pieces to conquer the global internet.

1. Paradigm Shift: The Revolution from Push to Pull

RTMP is like a phone call (persistent connection), while HLS is like text messaging (pull on demand)

Before HLS dominated, the streaming world was ruled by RTMP (Real-Time Messaging Protocol).

• RTMP is like a phone call (Push Mode): The server must maintain a dedicated, continuous line with your device. The server gets exhausted staring at every user and proactively pushing data to you. When there are too many people, the server crashes.
• HLS is like text messaging (Pull Mode): HLS does not maintain a persistent connection. It chops the video into countless small files and places them on ordinary HTTP servers. Your player acts like a diligent porter, proactively pulling these files as needed.

Why did HLS win? Because it can penetrate firewalls. Corporate firewalls usually block RTMP’s non-standard ports, but HLS uses standard HTTP/HTTPS (ports 80/443), passing through as freely as regular web browsing. Furthermore, it can leverage existing CDN (Content Delivery Network) infrastructure, allowing edge nodes to share the load for the origin server, easily supporting millions of concurrent users.

2. Core Mechanism: The Art of Pizza Slicing in Streaming

The core philosophy of HLS is very simple: Slice the infinitely long media stream into a series of short, HTTP-based static files.

It’s just like you can’t eat a huge pizza in one go, so HLS cuts it into countless small pieces (Segments). The player takes one piece to eat at a time, and goes for the next one after finishing.

The Three Carriages of HLS Architecture:

1. The Server: Responsible for slicing the original video, generating .ts or .m4s media files, and creating a playlist (.m3u8).
2. CDN Distribution: These segment files are essentially ordinary static files that can be cached on server nodes closest to your home.
3. The Client: The smartest part. The player is responsible for downloading the playlist, monitoring your internet speed, and deciding whether the next piece of pizza should be a large one (high bitrate) or a small one (low bitrate).

3. M3U8: Not Just a File, But a Treasure Map

M3U8’s two-layer design: Master Playlist is the main menu, Media Playlist is the serving list

You might often see the .m3u8 extension. It is not the video itself; it is an index file (Playlist), which is the treasure map or menu in the player’s hands.

HLS’s M3U8 is divided into two levels, designed very ingeniously:

Level 1: Master Playlist — The Main Menu

This is your first entry point when accessing a video. It tells the player: “I have 720p, 1080p, and even 4K versions. Which one do you need?”

#EXT-X-STREAM-INF:BANDWIDTH=800000,RESOLUTION=640x360
video_low/index.m3u8
#EXT-X-STREAM-INF:BANDWIDTH=5000000,RESOLUTION=1920x1080
video_high/index.m3u8

The player will intelligently choose the most suitable version based on the BANDWIDTH and RESOLUTION tags, combined with current network conditions. This is where the secret of Adaptive Bitrate (ABR) lies.

Level 2: Media Playlist — The Serving List

Once a version is selected (e.g., 1080p), the player downloads this specific playlist. It lists the address and duration of every video segment.

#EXTINF:6.000,
segment_100.ts
#EXTINF:6.000,
segment_101.ts

• #EXTINF: Tells the player the duration of this small video segment, precise to milliseconds.
• #EXT-X-ENDLIST: If this tag appears at the end of a VOD file, it means the show is over; if it is a live stream, this tag will not appear, and the player will continuously refresh the list to look for new segments.

4. Container Evolution: MPEG-TS vs. fMP4

From the bulky MPEG-TS to the streamlined fMP4: Saving 5-10% traffic and supporting HEVC encoding

Not just the transmission method, but the HLS packaging box is also evolving.

• The Old School: MPEG-TS (.ts): Born in the digital TV era. Its characteristic is robustness; every tiny data packet (188 bytes) can be decoded independently. However, in internet transmission, its encapsulation overhead is high (stuffing invalid data to make up bytes), and browsers struggle to process it.

• The New Star: fMP4 (Fragmented MP4): The standard Apple announced support for at WWDC 2016. It has a more compact structure, saving 5-10% in traffic. Most importantly, it supports modern high-efficiency coding formats like H.265/HEVC. Even better, fMP4 brings the possibility of CMAF (Common Media Application Format)—meaning the same video file can be fed to both HLS and MPEG-DASH, cutting storage costs in half!

5. Conclusion: The Future of HLS is Faster

Although HLS is stable, it originally had a shortcoming: high latency (usually 10-30 seconds). Because to prevent buffering, players often pre-download 3 segments before starting playback.

But driven by the latest LL-HLS (Low Latency HLS) technology, HLS is moving towards sub-second latency. Through Preload Hints and incremental transmission, HLS is redefining the real-time nature of live streaming.

From a small feature on the iPhone to the cornerstone supporting global streaming, the HLS protocol proves: Sometimes, breaking a big problem into countless small problems (slicing) is the most efficient strategy.

This article is based on the 2025 latest HLS protocol technical report.