What is M3U8?

M3U8 is the UTF-8 form of the M3U multimedia playlist format and is widely used for HTTP Live Streaming manifests. Its text entries can describe variants, segments, keys, and date-range metadata.

Multivariant playlist: variant streams and renditions

Media playlist: ordered segment URIs with tags

Media segments and keys fetched by URI

An HLS client follows URIs from the multivariant playlist to the media playlist of each rendition selected for playback, such as separate video and audio, and then to those renditions’ media segments.

How M3U8 works

An M3U8 document is a line-oriented UTF-8 text file. Each line is a URI, is blank, or starts with #; lines that begin with #EXT are tags and other # lines are comments. In HLS, a multivariant playlist advertises variant streams and alternative renditions, while a media playlist enumerates the media segments of one rendition. Clients switch between variants according to network conditions and reload a media playlist periodically unless the playlist declares that it will not change, as described below. Packagers write these playlists after encoding and segmenting the media.

Key facts

#EXTM3U must be the first line of every HLS playlist. Some tags, such as #EXT-X-VERSION and #EXT-X-TARGETDURATION, apply to the whole playlist, while media segment tags bind to what follows them: #EXTINF is required for each media segment and applies only to the next segment URI, and some other tags apply to all following segments until another instance of the same tag. Moving, deleting, or inserting tag and URI lines can therefore change meaning even when the result is still valid text.
A playlist is one of two kinds, never both. A multivariant playlist, called a master playlist in RFC 8216, describes variant streams and points to other playlists; a media playlist lists the segments of one rendition in playback order. RFC 8216 requires clients to fail to parse a playlist that mixes media segment tags with master playlist tags.
Relative URIs are resolved against the URI of the playlist that contains them, so moving a playlist can change where they resolve; keep the referenced files in the same relative layout or update the URIs. Under standard URI resolution, a relative reference with its own path does not inherit the query string of the base URI. A token or signature in the playlist URL’s query is therefore not carried over to segment, key, or child-playlist requests, and a signed-URL scheme has to sign each referenced URI or authorize those requests another way.
Name or serve a playlist so that clients accept it. RFC 8216 requires an HLS playlist to be identifiable either by a URI path ending in .m3u8 or .m3u or by the HTTP Content-Type application/vnd.apple.mpegurl or audio/mpegurl, and says clients should refuse playlists identified neither way. The text must be UTF-8 without a byte order mark; clients should fail to parse a playlist that has one.

When M3U8 matters

M3U8 matters whenever you generate, host, or ingest HLS. A producer has to get tag order, durations, and URIs right for the playlist to be valid, and a host has to keep every URI in it reachable from wherever the playlist is served. Treat a playlist from an untrusted source as a list of fetch instructions: RFC 8216 notes that clients will make network requests to whatever its URIs name, and FFmpeg’s HLS demuxer by default restricts which file extensions a playlist may reference.

Working with M3U8

RFC 8216 requires clients to reload a media playlist periodically unless it declares #EXT-X-PLAYLIST-TYPE:VOD, or #EXT-X-PLAYLIST-TYPE:EVENT together with #EXT-X-ENDLIST. While a media playlist lacks #EXT-X-ENDLIST, the server must publish a new version with at least one new segment between 0.5 and 1.5 target durations after the previous one. Add #EXT-X-ENDLIST once the final segment is listed, and use #EXT-X-PLAYLIST-TYPE:VOD to declare that the playlist cannot change. A growing playlist changes at a fixed URL while its segments do not, which is the property to plan caching around.

How Transloadit helps with M3U8

Transloadit’s /video/adaptive Robot generates M3U8 playlist files together with the media segments when its technique is hls, and an HLS playlist next to the MPEG-DASH manifest when it is cmaf.

The Robot’s documentation says its result files carry a relative_path metadata property and that the storage path should be built from it so the playlist files keep working, which is the relative-URI rule above in practice. It also lists the CORS response headers to configure for browser players that fetch the playlists and segments from another origin.

Video adaptive Robot: HLS, MPEG-DASH, and CMAF

Explore Transloadit’s file formats & compression capabilities