How Video Segmentation and M3U8 Manifests Actually Work

Two completely different things in this series share the word "chunking," and it's worth separating them before going further. The chunked upload tutorial covered splitting a large source file into 50-200MB parts to get it onto AIOZ Stream's servers in the first place, a one-time upload concern. This article is about a different split entirely: how a finished, encoded video gets divided into short playback segments and described in an M3U8 manifest, the file structure a player actually reads to stream it.

TL;DR:

• Upload chunking (50-200MB parts, covered separately) and playback segmentation (the subject here) share a name and nothing else, one happens once at upload time, the other defines how a finished stream gets delivered every time it plays.
• HLS uses two tiers of M3U8 file: a Master Playlist listing each bitrate-ladder rung, and a Media Playlist per rung listing the actual short segments a player requests in sequence.
• Segment duration is a real engineering tradeoff, not an arbitrary number. Apple's own HLS guidance moved from a 10-second to a 6-second target specifically to balance faster ABR reaction against manifest and request overhead.
• A Media Playlist can point to genuinely separate segment files, or use EXT-X-BYTERANGE to serve sub-ranges of one larger file instead, per the HLS spec.
• AIOZ Stream's docs don't expose segment duration or byte-range behavior as configurable API parameters, manifest generation happens automatically once resolution, bitrate, and codec are set.

Master playlist vs. media playlist

HLS uses two distinct kinds of M3U8 file, and the difference is defined by what their URI lines point to. Per the IETF's own HLS specification: "A Playlist is a Media Playlist if all URI lines in the Playlist identify Media Segments. A Playlist is a Master Playlist if all URI lines in the Playlist identify Media Playlists." A Master Playlist is the file a player fetches first, one line per rung in the bitrate ladder, each carrying the BANDWIDTH attribute the ABR article already covered. Each of those lines points to a separate Media Playlist, one per rung, and that's the file that actually lists playable content: "A Media Playlist contains a list of Media Segments, which, when played sequentially, will play the multimedia presentation." The Master Playlist is a table of contents; the Media Playlist is where the video actually is.

What's actually inside a media playlist

A handful of tags do most of the real work. EXTINF is required before every segment and states its exact duration, "This tag is REQUIRED for each Media Segment." EXT-X-TARGETDURATION sets a ceiling for the whole playlist, every segment's actual duration must stay at or under it, since longer segments than declared can trigger playback stalls. EXT-X-VERSION declares which protocol features the playlist uses, required whenever a tag beyond the original spec's baseline appears. EXT-X-MEDIA-SEQUENCE numbers the first segment currently listed, defaulting to 0 if absent, and that number has to climb every time an old segment gets dropped off a live playlist. EXT-X-PLAYLIST-TYPE declares whether the playlist can still grow (EVENT, segments only get appended) or is permanently finished (VOD, nothing changes once published). EXT-X-ENDLIST is the explicit signal that no more segments are coming, the tag that turns an open-ended live playlist into a closed, complete one.

Why segment duration is a real tradeoff, not a random number

Shorter segments mean an ABR algorithm can react to a changing connection faster, the next decision point is always close by, but they also mean more manifest entries, more individual HTTP requests, and slightly worse compression efficiency per segment since each one has to be independently decodable. Longer segments compress a little better and cut request overhead, but leave a player stuck on a bad bitrate decision for longer before the next chance to switch. Apple's own HLS guidance has moved on this exact tradeoff, and said so directly: "We used to recommend a ten-second target duration... we do believe that going forward, six seconds makes for a better tradeoff." That's not a claim the shorter number is free, Apple's own guidance acknowledges the real cost of re-encoding existing content to match a new target, it's an explicit statement that the tradeoff's balance point moved. That number connects directly to client buffering behavior too, since HLS clients are expected to start playback roughly 3 segments behind the live edge, a 6-second target duration means around 18 seconds of buffer, the same 3-segment logic behind the buffering guidance in the Glass-to-Glass latency article, applied here to steady-state buffering rather than startup latency specifically.

One file or many? EXT-X-BYTERANGE

A Media Playlist doesn't strictly need separate files per segment. The EXT-X-BYTERANGE tag lets a playlist describe a segment as a byte range within one larger file instead, format #EXT-X-BYTERANGE:<n>[@<o>], length in bytes and an optional offset. When the offset is left out, the spec is explicit about what happens: "the sub-range begins at the next byte following the sub-range of the previous Media Segment," meaning sequential segments don't each need their own offset written out. That's a genuinely different packaging choice from generating hundreds of small standalone .ts or .m4s files, fewer files to manage server-side, at the cost of needing every client to correctly handle range requests against one larger resource rather than simple whole-file fetches.

Live vs. VOD manifests

A VOD Media Playlist is static: every segment is listed once, EXT-X-ENDLIST appears, and the file never changes again after publishing. A live playlist works the opposite way, a sliding window that grows on one end and can shed old segments on the other, with real rules governing how aggressively it's allowed to shrink. The spec sets a floor: a server can't remove a segment if doing so would leave less than three times the target duration's worth of content in the playlist, and every removal has to increment EXT-X-MEDIA-SEQUENCE by one so clients can tell what's been dropped. Removed segments still have to stay reachable for a period equal to their own duration plus the playlist's total duration, so a client that was mid-request when a segment rolled off doesn't just hit a dead link. None of this applies to VOD content at all, which is exactly why EXT-X-PLAYLIST-TYPE matters, it tells a client up front which set of rules governs the file it's reading.

What AIOZ Stream actually exposes

Checked directly against AIOZ's video API documentation: segment duration and byte-range behavior aren't configurable parameters anywhere in the create-video request. Manifest generation happens automatically once resolution, bitrate, and codec are set per quality object, the platform handles building the actual M3U8 structure and deciding how segments get packaged. The one HLS-adjacent choice that is exposed is container_type, mpegts or mp4, which affects segment packaging format rather than duration or file-versus-byte-range structure, traditional MPEG transport-stream segments versus fragmented MP4. Someone needing a specific target duration or byte-range-versus-separate-files behavior for a particular player compatibility reason would need to verify AIOZ's actual defaults directly rather than assume either approach from the docs alone, since neither is stated. That's a reasonable design choice for most integrations, not a shortcoming to work around: manifest structure is exactly the kind of detail most developers building on top of a video API don't want to hand-tune per upload, and automatic generation means one less parameter to get wrong. It only becomes a real limitation for the narrower case of matching an existing player's specific expectations, a legacy device that only handles one segment-packaging style, for instance, where AIOZ's automatic choice may not be adjustable to fit.

Frequently Asked Questions

Is this the same "chunking" as the chunked video upload tutorial?
No. Upload chunking splits a large source file into 50-200MB parts for a one-time upload. This article covers playback segmentation, how a finished, encoded video gets divided into short segments a player streams.

What's the difference between a Master Playlist and a Media Playlist?
A Master Playlist lists Media Playlists, one per bitrate-ladder rung. A Media Playlist lists the actual short segments that play back sequentially. Master is the table of contents; Media is where the content is.

Why did Apple change its recommended segment duration from 10 to 6 seconds?
To rebalance the tradeoff between ABR reaction speed and manifest/request overhead, shorter segments let a player react to network changes sooner at the cost of more individual requests.

What does EXT-X-BYTERANGE actually do?
It lets a playlist describe a segment as a byte range inside one larger file instead of a separate standalone segment file, reducing the number of files a server has to manage.

How does a live manifest differ from a VOD manifest?
A VOD playlist is static and complete, marked with EXT-X-ENDLIST. A live playlist is a sliding window that can drop old segments, with a spec-mandated floor of at least 3x the target duration's worth of content kept available at all times.

Can I set a custom segment duration on AIOZ Stream?
Not through any documented API parameter. Segment duration and byte-range behavior aren't exposed as configurable fields; manifest generation happens automatically based on the resolution, bitrate, and codec settings per quality object.

Related Reading

• Video Container Formats Explained: why none of these four consumer containers is what HLS/DASH segments actually use
• What Is AV1 and Should You Use It: how a codec's compressed output gets packaged into the segments and manifests covered here
• Widevine vs FairPlay vs PlayReady: how CMAF packaging builds on the same segment structure covered here
• TVOD vs SVOD vs AVOD vs W2E: Monetization Models Compared: how SSAI ad insertion actually splices into the manifest structure covered here
• What Is Video on Demand (VOD) and How It Actually Works: why a VOD manifest specifically stays static once built, and how seeking works within it
• What Is Adaptive Bitrate (ABR)Streaming and How It Works: how a player actually chooses between the rungs this manifest structure describes
• How to Build a Video Bitrate Ladder: A Practical Guide: where the rungs a Master Playlist lists actually come from
• Glass-to-Glass Latency Explained: the same 3-segment buffering logic applied to startup latency specifically

References

• RFC 8216: HTTP Live Streaming: the Master/Media Playlist definitions, tag behaviors, EXT-X-BYTERANGE mechanics, and live-playlist retention rules quoted above
• Streaming Learning Center: Apple's HLS Encoding Recommendation Changes: the direct Apple quote on the 10-to-6-second segment duration shift, cited above