Fragmented MP4 (fMP4) vs MPEG-TS: The Future of HLS Streaming

When Apple created HTTP Live Streaming (HLS) in 2009, they chose the MPEG-2 Transport Stream (MPEG-TS, or .ts files) as the core media container. It was robust, designed for noisy broadcast environments like satellite television, and supported easily by hardware decoders.

However, as OTT (Over-The-Top) internet streaming matured, the limitations of MPEG-TS became obvious. In 2016, Apple announced HLS support for Fragmented MP4 (fMP4). This paved the way for the Common Media Application Format (CMAF), fundamentally changing how video is packaged and delivered across the web.

The Legacy of MPEG-TS (.ts segments)

MPEG-TS was originally built for unreliable network transport. To ensure that missing bytes wouldn't corrupt the entire video, it packages data into tiny, fixed-size 188-byte packets. Each packet has a header, and audio and video packets are heavily multiplexed (interleaved) together.

While this is great for over-the-air television, HTTP over TCP/IP is already a reliable transport layer—TCP handles packet loss and retransmission natively. Therefore, the 188-byte packet structure of MPEG-TS introduces unnecessary padding and overhead on the internet.

Pros of TS: Universal compatibility with older devices (legacy Smart TVs, old set-top boxes).
Cons of TS: High overhead (up to 10-15% of bandwidth is wasted on transport headers), requires multiplexed audio/video which complicates alternate audio tracks.

What is Fragmented MP4 (fMP4)?

A standard MP4 file has a single large "moov" atom (metadata) at the beginning, followed by all the "mdat" (media data). You cannot easily play a standard MP4 until the entire file is downloaded (or until the moov atom is parsed).

Fragmented MP4 breaks the video down into smaller chunks. It places a small initialization segment (the "moov" box) at the very beginning, and then each subsequent chunk contains its own metadata ("moof" box) and media ("mdat" box). This allows a player to download and instantly play individual fragments without needing the entire file.

Key Advantages of fMP4 over MPEG-TS

1. Storage and CDN Efficiency (CMAF)

Before fMP4, broadcasters had to package two sets of files: MPEG-TS for Apple/HLS devices, and fMP4 for Android/DASH devices. With fMP4 supported in HLS (via CMAF - Common Media Application Format), you only encode and store the video once. Both the HLS .m3u8 manifest and the DASH .mpd manifest can point to the exact same fMP4 segments, cutting CDN storage costs in half.

2. Reduced Bandwidth Overhead

Because fMP4 strips out the legacy 188-byte MPEG-TS packet headers, the resulting segments are smaller. For high-volume streaming platforms, this reduction in overhead directly translates to lower CDN egress costs and faster buffer fill rates for end-users.

3. Better DRM Compatibility (CENC)

fMP4 utilizes Common Encryption (CENC). This allows a single encrypted media segment to be unlocked by multiple DRM systems (e.g., Apple FairPlay, Google Widevine, Microsoft PlayReady) simply by delivering the appropriate license keys in the manifest. MPEG-TS requires SAMPLE-AES, which is less universally supported.

4. Low-Latency Streaming

fMP4 is the foundation of Low-Latency HLS (LL-HLS) and Low-Latency DASH. It allows chunked transfer encoding, where a CDN can begin streaming parts of an fMP4 fragment to a player before the fragment has even finished encoding on the live origin server.

Implementing fMP4 in HLS (The Manifest)

An HLS media playlist using fMP4 looks slightly different than a traditional TS playlist. The most critical addition is the #EXT-X-MAP tag, which points to the Initialization Segment (the fMP4 header). All subsequent segments (usually ending in .m4s) rely on this init segment to decode properly.

#EXTM3U
#EXT-X-TARGETDURATION:6
#EXT-X-VERSION:7
#EXT-X-MEDIA-SEQUENCE:1
#EXT-X-MAP:URI="init.mp4"
#EXTINF:6.000,
segment_1.m4s
#EXTINF:6.000,
segment_2.m4s
#EXTINF:6.000,
segment_3.m4s
#EXT-X-ENDLIST

Generating fMP4 HLS with FFmpeg

To convert an existing video into an fMP4-based HLS stream using FFmpeg, you can use the hls_segment_type flag set to fmp4:

ffmpeg -i input.mp4 -codec:v libx264 -codec:a aac \
  -hls_time 6 -hls_playlist_type vod \
  -hls_segment_type fmp4 \
  -hls_segment_filename "segment_%03d.m4s" \
  output.m3u8

Notice that this will generate an output.m3u8 file, a series of segment_XXX.m4s files, and an init.mp4 file automatically.

Troubleshooting fMP4 Playback Issues

While fMP4 is the modern standard, migrating from TS to fMP4 can introduce a few specific issues:

Missing Init Segment: If the player fails to download the URI specified in the #EXT-X-MAP tag (due to a 404 or a CORS error), playback will fail instantly. The player cannot decode .m4s fragments without the moov metadata in the init file.
Codec Mismatches: fMP4 relies heavily on accurate codec strings in the master playlist (e.g., CODECS="avc1.4d401f,mp4a.40.2"). If the codec string in the master M3U8 does not match the actual encoded data inside the fMP4 fragments, MSE (Media Source Extensions) in the browser will reject the buffer and throw a decode error.
Legacy Device Support: While iOS 10+ and modern Android browsers fully support fMP4 HLS, very old Smart TVs (pre-2017) and legacy set-top boxes may only have hardware decoders configured for MPEG-TS. If you have a significant audience on legacy devices, you may need to maintain a TS stream alongside your fMP4/CMAF streams.

Conclusion

For any new streaming deployment, Fragmented MP4 (fMP4) via CMAF is the clear choice. It reduces storage costs, lowers bandwidth overhead, simplifies multi-DRM configurations, and enables sub-3-second latency for live events. While MPEG-TS will remain in legacy broadcast environments for years to come, the internet has fully embraced the efficiency of fMP4.