What is HLS streaming?

The three parts of an HLS stream

An HLS presentation has a multivariant playlist (RFC 8216 calls it a master playlist; the current draft revision renamed it), one media playlist per rendition, and the media segments themselves. The multivariant playlist lists the available renditions with their peak bitrate, resolution and codecs. Each media playlist lists that rendition's segments in order with their durations. The segments hold a few seconds of encoded video and audio each.

Segments were first MPEG-2 transport stream files with a .ts extension, the same format used in broadcast television. Since 2016 HLS has also supported fragmented MP4 (fMP4) segments. These are now the preferred choice for two reasons. The same segments can serve MPEG-DASH players, and fMP4 handles HEVC and AV1 cleanly. The video formats hub explains MP4 and the other containers if these names are new. Audio-only renditions can be packed AAC, MP3 or AC-3, and subtitles travel as WebVTT segments. Playlists are served with the MIME type application/vnd.apple.mpegurl.

The tags that matter

A complete list is in RFC 8216. These are the ones you will see in nearly every stream.

What a player does with all this

On load, the player fetches the multivariant playlist and chooses a first rendition. Apple's guidance is that a client plays the first variant listed before it has measured any bandwidth. So the order of that list is a deliberate choice by the author. The player then fetches the chosen media playlist, downloads the first segments, and starts decoding once it has enough buffered to be confident of continuous playback.

From then on the loop is simple: measure how quickly the last segment arrived, compare with the BANDWIDTH values in the multivariant playlist, and decide whether the next segment should come from a higher or lower rendition. Because every rendition is segmented at the same timestamps, switching means fetching the next segment from a different media playlist and nothing more. No renegotiation with the server is involved, because the server is just serving files.

Segment length and keyframes

Apple's authoring specification recommends a target duration of six seconds and keyframes at least every two seconds. Shorter segments let the player switch renditions and recover from stalls faster. The cost is more playlist entries and more HTTP requests per minute. Longer segments are friendlier to caches. Whatever the length, each segment must begin with a keyframe. Otherwise a player switching into it would have nothing to decode from. This is why the transcoding guide spends so long on keyframe intervals.

Making an HLS package with ffmpeg

For a single rendition, FFmpeg's hls muxer does the segmenting and playlist writing in one command.

1. Encode and segment: ffmpeg -i source.mp4 -c:v libx264 -crf 21 -g 48 -keyint_min 48 -sc_threshold 0 -c:a aac -b:a 128k -f hls -hls_time 6 -hls_playlist_type vod -hls_segment_type fmp4 index.m3u8. With 24 fps input, -g 48 places a keyframe every two seconds.
2. Check the output: index.m3u8 is the media playlist, init.mp4 the initialisation segment, and index0.m4s onward the media segments.
3. Serve the folder over HTTPS with the correct MIME types and open the playlist in Safari, or in another browser through hls.js, to confirm playback.
4. For a full ladder you would repeat with several renditions and write a multivariant playlist that lists them; the transcoding guide has the multi-rendition command.

Where HLS plays

• Safari on macOS, iOS and iPadOS plays HLS natively through the ordinary video element. On iPhone this was for years the only way to stream at all, because Media Source Extensions were not available there.
• Chrome, Firefox and Edge on desktop do not play HLS natively. They do support Media Source Extensions, so a JavaScript library such as hls.js reads the playlist and feeds segments to the browser's decoder.
• Apple TV, Android TV, smart TV platforms and games consoles all ship HLS support. That makes it the lowest common denominator for reaching every screen.
• The VideoBB embeddable player handles both paths automatically; the embed guide shows how to place it, and the embedding guide covers sizing and options.