MPEG-TS vs. Fragmented MP4 in HLS: What .ts and CMAF Segments Actually Are
July 25, 2026 · 6 min read
An HLS media playlist is a list of segment URLs. What the playlist doesn't always make obvious is that those segments can be in two completely different container formats — MPEG-TS and fragmented MP4 (fMP4 or CMAF) — that have different binary structures, different compatibility profiles, and slightly different parsing requirements. A player or converter handles both, but understanding the difference explains a few behaviors that otherwise seem arbitrary.
MPEG-TS: the original HLS container
When Apple published the first HLS specification in 2009, the only segment container it defined was MPEG-2 Transport Stream (.ts). TS is a streaming-first format: it carries multiple audio and video elementary streams in short, fixed-size 188-byte packets, and each packet carries a Program Clock Reference (PCR) that lets a player synchronize them without any external metadata. This self-contained, packet-based structure was designed for broadcast transport where packets can arrive out of order or get lost entirely — properties that are largely irrelevant to HTTP delivery but harmless.
The downside of TS segments for modern web delivery is file size. The 188-byte packet header overhead, redundant timing information, and the fact that TS only natively carries H.264 and AAC (HEVC, VP9, and AV1 require nonstandard workarounds) have made it a legacy choice. Its strength is universal compatibility: every HLS implementation, in every browser and device that has ever shipped, supports TS segments.
Fragmented MP4: the modern alternative
Apple added fMP4 segment support in HLS draft version 7 (2016), standardized as ISO Base Media File Format fragments. An fMP4 file is a regular MP4 container split into a series of independent fragments, each containing a small run of frames that can be decoded without any other fragment. Two structural parts matter:
- The initialization segment (signaled by an
#EXT-X-MAPtag in the playlist): a fragment containing codec parameters, track structure, and timing metadata. It must be downloaded once and logically prepended before any media fragments can decode correctly. - The media fragments: sequential
.m4sfiles (or inline byte ranges in a single file) that carry the actual encoded frames, each starting with amoofbox followed by amdatbox containing the sample data.
fMP4 segments are more compact than equivalent TS segments (roughly 10–25% smaller in practice), support all modern codecs including HEVC and AV1, and share their container format with MPEG-DASH — which is why the same segment files can be referenced by both an HLS and a DASH manifest when a CDN wants to serve one set of media files to multiple streaming clients.
How a playlist signals which format it uses
The playlist signals the container type in two ways:
- The presence of an
#EXT-X-MAPtag is a strong indicator of fMP4: TS segments never need an initialization segment, so the tag only appears in playlists using fMP4 delivery. (TS segments can technically include#EXT-X-MAPfor unusual configurations, but this is rare enough to treat as an fMP4 signal in practice.) - The
CODECSattribute on#EXT-X-STREAM-INFcan include codec strings likehvc1,vp09, orav01— codecs that TS doesn't support — making fMP4 delivery implied. See H.264 vs. H.265 vs. VP9 vs. AV1 in HLS for what each codec string declares.
Some streams don't use either signal reliably. In that case, fetching the first segment and checking its magic bytes is unambiguous:0x47 as the first byte indicates MPEG-TS (the sync byte); a four-byte box size followed by ftyp at bytes 4–7 indicates MP4.
What this means for downloading and converting
For a tool that assembles HLS segments into a single file, the container type determines one key step:
- TS segments can be concatenated directly — their individual transport streams are self-describing enough that a simple byte concatenation followed by an ffmpeg remux produces a valid output.
- fMP4 segmentsrequire the initialization segment to be prepended first. Without it, the decoder can't interpret the samples in any of the media fragments. A converter that ignores the
#EXT-X-MAPtag will concatenate fragments that look like valid data but fail to decode.
This site's /convert page handles both: when a playlist carries #EXT-X-MAP, the initialization segment is fetched first and placed at the head of the download queue. The ffmpeg.wasm remux step then receives a valid fMP4 byte stream and produces a clean MP4 output using stream copy — no re-encoding.
CMAF: a profile of fMP4
You'll occasionally see the term CMAF(Common Media Application Format) alongside fMP4. CMAF is a packaging profile defined by ISO that constrains fMP4 to specific structural requirements — single-track chunks, strict box ordering, a specific set of allowed codecs — intended to maximize compatibility across HLS, DASH, and other clients. CMAF segments are valid fMP4, but not all fMP4 is CMAF. From a download perspective, they're handled identically: CMAF segments are just fMP4 with tighter constraints on what's inside.
Try it on a real stream
The easiest way to see segment format in the wild is to open a page with an HLS video, detect it with the Stream Video Downloader extension, and watch the /convert page's segment download phase. fMP4 streams show a separate initialization fetch at the start; TS streams don't. The underlying segment logic handles both transparently — you don't need to choose, just click Convert.