What Is HLS, and How Do M3U8 Playlists Work?

1. Your encoder makes one stream. For a live stream it pushes RTMP, RTMPS or SRT to the platform.
2. A packager cuts the stream into segments a few seconds long and writes a playlist that lists them in order.
3. A web server, the origin, holds the playlist and the segments as ordinary files.
4. A CDN, a network of delivery servers, caches those files close to your viewers.
5. The player downloads the playlist, then each segment in order. For a live stream it reloads the playlist to find new segments.

Most streams come in several qualities. A master playlist lists each one, and RFC 8216 tells players to switch between them as network conditions change. That is adaptive bitrate streaming: on a weak connection the picture drops to a lower quality instead of stopping.

Because every file travels over plain HTTP, HLS works with ordinary web servers and content delivery networks, as Apple puts it. It usually runs over TCP, like most web pages, so lost packets are sent again. The price is delay, which a later section covers.

Segment length is the packager's choice. The example in RFC 8216 uses a 10 second target, and YouTube asks for 1 to 4 second segments when you send HLS to it. HLS carries on-demand video as well as live video; the difference is whether the playlist keeps growing.

RFC 8216 names two kinds. A master playlist lists the qualities: one EXT-X-STREAM-INF line per quality, with its bandwidth, resolution and codecs, then the address of that quality's own playlist. A media playlist lists the segments: a target duration, then an EXTINF line with the length in seconds before the address of each segment.

Here are real lines from the two public test streams in the next section. These are two rows from Apple's sample master playlist, for two of its six resolutions; the real file has more rows.

A media playlist then lists the segments. This is the top of the 720p media playlist of the Mux test stream. That stream stores each segment as its own MPEG-2 transport stream file, .ts, and the real file lists 64 segments.

Apple's sample does it differently. It keeps every segment of a quality inside one fragmented MP4 file, a form that Apple added to HLS in 2016. A byte range then follows each EXTINF line.

A live playlist has no end tag. The packager adds a line for each new segment and drops old ones, and the player reloads the file to keep up.

A player knows a playlist by its address, which usually ends in .m3u8 (.m3u is also allowed), or by its content type, application/vnd.apple.mpegurl or audio/mpegurl.

Two public sample streams work today. Both are on demand, and both are third-party files that can move.

To test an address, paste it into Safari or Chrome (version 142 or newer), which play HLS on their own. Firefox and Edge need a player such as hls.js, an open-source project on GitHub with a demo page. A live stream has the same kind of address; the playlist just keeps changing while you watch.

The platform receives your stream, transcodes it into several qualities, packages HLS or DASH and gives the files to a CDN. Your viewer's player never sees RTMP; it reads a playlist. That is why browsers cannot play an RTMP stream, and why viewers get HLS and not RTMP.

YouTube is the exception on the ingest leg. It also accepts HLS as an ingest protocol, for HDR and for codecs that RTMP cannot carry, such as HEVC. YouTube Help says the ingest address starts with https instead of rtmp, and it needs transport stream segments of 1 to 4 seconds. Our platform table shows what each service accepts.

As a creator you rarely make HLS yourself. You make it only when you host video on your own website or app, with a media server or a video host that packages it.

RFC 8216 tells a player that joins a live stream not to start less than three target durations from the end of the playlist. With 6 second segments, a common setting, that is about 18 seconds behind live, before encoding and network delay. YouTube Help says the same in plain words: HLS has higher latency because it sends segments of video instead of a continuous stream like RTMP. For that reason YouTube turns its ultra low latency option off for HLS ingest.

Apple documents Low-Latency HLS, an extension of the protocol for live streams; vendors report a few seconds of delay. For real-time use, such as a conversation with guests, look at WebRTC instead.

• Your loop sends RTMP or RTMPS. A loop is your 24/7 stream of pre-recorded videos. Streamloop sends it to YouTube, Twitch, Kick, Facebook or any custom RTMP address. The platform makes the HLS for your viewers, and you never touch a playlist.
• A loop plays files, not streams. A loop plays videos that you upload or import from a link, such as Google Drive, YouTube or a direct .mp4 link. An HLS URL is a live stream, not a file, so it is not a loop source.
• Live Scenes can pull a live HLS stream. Live Scenes is the Streamloop studio for live sources, such as a camera or another stream, with graphics on top. In the studio, add HLS stream under Live inputs and paste the m3u8 URL. Use it for a partner feed, a public camera stream or another channel's output. Set a slate, a fallback screen, for when the stream drops. A scene sends RTMP or RTMPS to up to 5 destinations, at up to 1080p60, with no guest cameras. Choose Scene when you create a stream and describe your use case; access is granted within 24 hours.

Streamloop does not give you an HLS address to embed on your own website. Use the platform's embed player instead. Or send the loop to a custom RTMP destination on a media server or video host that makes HLS.