{"id":6738,"date":"2026-07-13T11:11:49","date_gmt":"2026-07-13T11:11:49","guid":{"rendered":"https:\/\/www.5centscdn.net\/blog\/?p=6738"},"modified":"2026-07-13T11:11:53","modified_gmt":"2026-07-13T11:11:53","slug":"mpeg-ts-vs-fmp4","status":"publish","type":"post","link":"https:\/\/www.5centscdn.net\/blog\/mpeg-ts-vs-fmp4\/","title":{"rendered":"MPEG-TS vs fMP4: Which HLS Segment Format to Use"},"content":{"rendered":"
<\/div>\n

MPEG-TS vs fMP4 is one of the most important decisions when packaging HLS. At some point, you hit a fork in the road: should your segments be MPEG-TS (.ts) files or fragmented MP4 (.m4s) files? For years there was no choice\u2014HLS meant MPEG-TS, full stop. Today, fMP4 is not only supported but increasingly the default, and the format you pick affects storage, CDN efficiency, device compatibility, and whether you can even use certain codecs and DRM.<\/p>\n\n\n\n

This guide is written for the engineer making that decision. It explains what each format is, how they differ in concrete terms, why the industry has been migrating from MPEG-TS to fMP4, and when the older format still earns its place. It is not about converting a .ts recording from your dashcam into a playable .mp4 \u2014 it is about which segment format belongs in your streaming pipeline.<\/p>\n\n\n\n

What Is MPEG-TS?<\/strong><\/h2>\n\n\n\n

MPEG-TS (MPEG Transport Stream)<\/a> is a container format defined back in MPEG-2 Part 1 (ISO\/IEC 13818-1) for broadcasting \u2014 satellite, cable, and terrestrial TV. Its defining design choice is that it chops everything into small, fixed-size packets of just 188 bytes, each carrying its own timing and synchronization information. That structure was built for one purpose: surviving a lossy transmission channel. If some packets are corrupted or dropped over the air, the rest of the stream keeps playing.<\/p>\n\n\n\n

\"MPEG-TS
MPEG-TS packet structure<\/strong><\/figcaption><\/figure>\n\n\n\n

When Apple launched HLS in 2009, it chose MPEG-TS as the segment format, largely because early iOS hardware already decoded transport streams natively and the format’s resilience suited unreliable networks. So a classic HLS stream is a playlist (.m3u8) pointing at a series of .ts segment files, each a self-contained few seconds of transport stream.<\/p>\n\n\n\n

Under the hood, MPEG-TS is more elaborate than it looks. Media is first wrapped into packetized elementary streams (one for video, one for audio, and so on), then chopped into those 188-byte transport packets and interleaved together. Small tables called PSI (Program Specific Information) \u2014 including the Program Association Table and Program Map Table \u2014 tell a decoder which packets belong to which program and stream. This machinery is what lets a single transport stream carry multiple TV channels at once, which was exactly the point in broadcast. For a single HLS segment it is mostly unused capability, carried along as extra structure.<\/p>\n\n\n\n

The strength \u2014 tiny self-describing packets \u2014 is also the weakness. All those 188-byte packet headers add up to real overhead, and because the rest of the streaming world (browsers, DASH, modern devices) standardized on MP4-based formats, MPEG-TS increasingly became the odd format out that only HLS still required. It is a broadcast-era container doing a job the broadcast use case never fully needed on the open internet.<\/p>\n\n\n\n

What Is fMP4?<\/strong><\/h2>\n\n\n\n

Fragmented MP4 (fMP4) is the MP4 container \u2014 built on the ISO Base Media File Format (ISOBMFF)<\/a> \u2014 written as a series of small, independently decodable fragments instead of one monolithic file. The segment files carry a .m4s extension. A plain MP4 keeps all its indexing metadata in one place and generally needs the whole file before smooth playback; fMP4 breaks the media into fragments that can be streamed and played as they arrive, which is exactly what adaptive streaming needs.<\/p>\n\n\n\n

\"fMP4
fMP4 init + media segments<\/strong><\/figcaption><\/figure>\n\n\n\n

The reason fragmentation matters is worth making explicit. A regular MP4 is like a book with its full index at the very back \u2014 you need the whole thing before you can reliably jump around. Fragmented MP4 is like a book split into self-contained chapters, each with its own mini table of contents, so a reader can pick up any chapter and start immediately. For streaming, that means a player can fetch segment 47 without having downloaded 1 through 46, switch bitrates cleanly at fragment boundaries, and begin playback almost immediately \u2014 the behaviors adaptive bitrate streaming depends on.<\/p>\n\n\n\n

Apple added fMP4 support to HLS at WWDC 2016, and it was a deliberate turning point: it let HLS and MPEG-DASH share the same underlying segment files, since DASH already used fMP4. One important structural difference from MPEG-TS is the initialization segment. With fMP4, a small init segment carries the setup information a player needs to decode the media segments, and the playlist references it with an #EXT-X-MAP tag:<\/p>\n\n\n\n

#EXTM3U<\/p>\n\n\n\n

#EXT-X-VERSION:7<\/p>\n\n\n\n

#EXT-X-MAP:URI=”init.mp4″<\/p>\n\n\n\n

#EXTINF:6,<\/p>\n\n\n\n

segment1.m4s<\/p>\n\n\n\n

#EXTINF:6,<\/p>\n\n\n\n

segment2.m4s<\/p>\n\n\n\n

#EXT-X-ENDLIST<\/p>\n\n\n\n

The player loads that init segment once, then all the .m4s media segments that follow. (With MPEG-TS, each .ts segment typically carries its own setup information inline, so no separate init segment is needed \u2014 part of why .ts is self-contained but heavier.)<\/p>\n\n\n\n

One point of frequent confusion worth clearing up: fMP4 is not a different format from MP4 \u2014 it is<\/em> MP4, just structured as fragments. And the standardized, portable profile of fMP4 that both HLS and DASH agree on is called CMAF, which is why you will often see \u201cfMP4\u201d and \u201cCMAF\u201d used almost interchangeably in a streaming context. If you want the deeper story of how one fMP4 set serves both protocols, see our guide to CMAF<\/a>.<\/p>\n\n\n\n

MPEG-TS vs fMP4: The Key Differences<\/strong><\/h2>\n\n\n\n

The two formats can carry the same video and audio, but they package it very differently. Here is what actually matters when you choose.<\/p>\n\n\n\n

<\/th>MPEG-TS (.ts)<\/strong><\/th>fMP4 (.m4s)<\/strong><\/th><\/tr><\/thead>
Origin<\/td>MPEG-2 broadcast (1990s)<\/td>ISOBMFF \/ MP4 family<\/td><\/tr>
Packet structure<\/td>Fixed 188-byte packets<\/td>Fragments (moof\/mdat)<\/td><\/tr>
Overhead<\/td>Higher (packet headers)<\/td>Lower<\/td><\/tr>
Init segment<\/td>None (self-contained)<\/td>Yes (#EXT-X-MAP)<\/td><\/tr>
Shared with DASH<\/td>No<\/td>Yes (same segments)<\/td><\/tr>
HEVC \/ H.265 in HLS<\/td>Not supported<\/td>Required<\/td><\/tr>
Legacy device support<\/td>Broadest (older iOS\/players)<\/td>Modern devices (HLS v7+)<\/td><\/tr>
CDN cache efficiency<\/td>Separate from DASH copy<\/td>One object serves both<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n

Overhead and Efficiency<\/strong><\/h3>\n\n\n\n

MPEG-TS wraps media in a stream of 188-byte packets, each with its own header. That fixed packetization is what makes it resilient, but the headers are pure overhead \u2014 at the same quality, .ts segments run slightly larger than the equivalent .m4s. Think of MPEG-TS like shipping a product in dozens of small identical boxes each with its own label and padding: robust, but a lot of packaging. fMP4 is more like shipping the same goods in fewer, right-sized cartons \u2014 less material spent on the wrapping.<\/p>\n\n\n\n

On any single segment the difference is modest \u2014 a few percent. But streaming multiplies everything by scale: every rendition, every segment, every viewer, every second watched. A few percent of overhead removed from a large VOD library or a high-concurrency live event turns into a meaningful reduction in storage and egress. It is the same logic that makes codec efficiency matter \u2014 small per-unit savings compound into real money once they are paid across millions of delivered segments. fMP4’s lower overhead is not dramatic per file, but it is free efficiency you keep collecting forever once you switch.<\/p>\n\n\n\n

Codec and DRM Requirements<\/strong><\/h3>\n\n\n\n

This one is often decisive: HLS only supports HEVC\/H.265 when you use fMP4 \u2014 the older MPEG-TS path cannot carry it. The same applies to modern codecs and to the Common Encryption used by DRM<\/a>, which is built around the fMP4\/CMAF structure. If your roadmap includes HEVC, AV1, or multi-DRM protection, fMP4 is not optional \u2014 it is a prerequisite.<\/p>\n\n\n\n

This single fact resolves the debate for a lot of teams before any efficiency argument is even made. Delivering 4K or HDR economically usually means HEVC or AV1; protecting premium content usually means Widevine, PlayReady, and FairPlay via Common Encryption. Both roads lead exclusively through fMP4 in HLS. So if your content strategy points at higher-efficiency codecs or studio-grade protection \u2014 and most serious streaming roadmaps do \u2014 the segment-format question is effectively already answered, and MPEG-TS simply cannot come along.<\/p>\n\n\n\n

CDN Efficiency<\/strong><\/h3>\n\n\n\n

Because fMP4 segments can be shared between HLS and DASH, you store and cache one set of files instead of a separate .ts set for HLS and an fMP4 set for DASH. That directly improves your CDN cache hit ratio<\/a> \u2014 one cached object serves both protocols instead of two objects competing for edge space. For anyone delivering to both ecosystems, this is a concrete storage and delivery saving, not just a tidiness win.<\/p>\n\n\n\n

Why Streaming Is Moving to fMP4<\/strong><\/h2>\n\n\n\n

Put the differences together and the industry direction is clear. Adopting fMP4 lets a platform serve HLS and DASH from a single set of segments, cut storage and packaging work, improve cache efficiency, and unlock HEVC, next-generation codecs, and modern DRM \u2014 all at once. For a workflow being built or modernized today, fMP4 is the sensible default, and MPEG-TS is the compatibility fallback rather than the starting point.<\/p>\n\n\n\n

\"Streaming
The migration to fMP4<\/strong><\/figcaption><\/figure>\n\n\n\n

This is a genuine reversal from a decade ago, when \u201cHLS\u201d simply meant \u201c.ts.\u201d The shift was gradual because it depended on device support catching up, but by now modern players and platforms handle fMP4 HLS routinely, and the remaining reason to reach for MPEG-TS is specifically to support old hardware.<\/p>\n\n\n\n

It is worth appreciating why the change took a full decade rather than happening overnight. A segment format is only useful if the viewer’s device can decode it, so even after Apple enabled fMP4 in 2016, operators had to keep serving .ts for years to avoid breaking playback on the installed base of older iPhones, smart TVs, and set-top boxes. As those devices aged out and fMP4-capable players became the overwhelming majority, the cost-benefit tipped: the efficiency, codec, and DRM advantages of fMP4 now clearly outweigh the shrinking population of TS-only devices. That is the quiet story behind most format migrations in streaming \u2014 the technology is ready long before the device fleet is, and the default flips only once the audience has caught up.<\/p>\n\n\n\n

When MPEG-TS Still Makes Sense<\/strong><\/h2>\n\n\n\n

MPEG-TS is not dead, and treating it as legacy-only would be a mistake in a few real situations:<\/p>\n\n\n\n