Which fragmented MP4 format would you use, and why?

We all know and love MP4 files. Whether referred to as ISOBMFF, or CMAF, or other closely related terms that essentially refer to variations of the same container format, they are at the core of any modern streaming solution, and in particular adaptive streaming (or ABR) that relies on the fragmentation of the container into small and easily downloadable “segments” of content that the player can gradually obtain and render.

But when it comes to fragmenting, there are 2 main flavours out there (and tons of confusing terminology, in particular the use of “fragmented MP4” (fMP4) to refer to both).

  1. Multiple MP4 files, with one file per segment (or “hard-parted” as a customer recently called it - not accepted terminology, but I kinda like it).
  2. A single MP4 file, internally fragmented (or “soft-parted” by contrast) - In this case, delivery of segments relies on the origin service supporting byte-range requests to retrieve the relevant fragments.

At Bitmovin, we support both containers (or “muxings” as we call these things):

  1. fMP4 muxing for hard-parted outputs
  2. MP4 muxing with fragmentDuration set to a non-null value, for soft-parted outputs.

There is a very small speed advantage in using the segmented / hard-parted approach due to the way our encoder works (parallelised encoding), but otherwise both offer the same set of features (eg. DRM, etc.)

So, from the perspective of encoding and playback, both formats are essentially functionally equivalent (with our products at least), but the rest of the workflow may dictate that you choose one over the other.

Why would you use one over the other? Our community would love to hear about your experience on this!

  • I would use multiple MP4 files (“hard-parted”)
  • I would use a single MP4 file (“soft-parted”)

0 voters

7 Likes