A moov box at byte 28 did not make this MP4 a faststart file
DEV Community

A moov box at byte 28 did not make this MP4 a faststart file

Moov Box Location and Faststart Properties in MP4 Exports

Overview

Both MP4 exports placed their moov box at byte 28. At first glance, this seemed to confirm whether players needed to fetch the end of the file before starting playback. However, subsequent analysis revealed a more nuanced picture. The presence of repeated moof and mdat pairs followed by mfra frames meant that calling these files "ordinary faststart MP4s" would have overlooked the most relevant aspects of the inspection.

File Structure Findings

  • Each file's ftyp header occupies the first 28 bytes
  • The moov box begins immediately after the ftyp marker
  • While the offset tells us where movie metadata starts, it does not reveal how the rest of the media is organized
  • The recurring fragment boxes indicate a fragmented MP4 structure

This distinction matters because:

  • Ordinary faststart processing moves movie metadata to the front to let a player read it before downloading the remaining media payload
  • Fragmentation carries additional metadata alongside media fragments and is treated separately by the FFmpeg format documentation

Finding either layout alone cannot identify which software created the file internally. There is no evidence that these exports were produced by running FFmpeg faststart.

Methodology and Tools

The tests were conducted using ImgIng, leveraging its Chinese video compression workbench for the actual conversion. Inputs consisted of two existing WebM clips of ocean waves:

  1. Alexander Grebenkov - Ocean waves at Lækjavik beach, Iceland (CC BY 3.0)
  2. ื“ื•ื“ ืฉื™ - Water waves in Herzliya beach (CC BY-SA 4.0)

Exports were configured with MP4 selection and the "prioritizing file size" option. Both conversions completed successfully. The resulting file sizes were:

Export Size
First export 912,701 bytes
Second export 2,198,495 bytes

Network and Playback Testing

The actual exports were served over a controlled local HTTP connection with:

  • Write budget: 256 KiB/s
  • Initial delay: 80 ms at the start of each request (application-level throttling, not a full network simulation)

For the larger fragmented export, performance metrics showed:

  • Chromium first-frame median:
    • With Range enabled: 7.909 seconds
    • Without Range: 1.403 seconds
  • Two runs per condition were performed

An early moov box does not guarantee an immediate picture, so this observation does not justify disabling the Range feature. Other playback engines exhibited different behaviors, and startup time alone does not determine whether viewers can seek to an undownloaded position.

Contextual Notes

  • The Iceland footage and Water waves clips were sourced from external creators; neither was filmed by the tester
  • Subsequent exports will be inspected by recording the full box sequence before labeling and checking first-frame playback and seeking independently against actual HTTP behavior
  • The test environment included Chromium 149, Firefox 151, and a WebKit 26.5 test build - not a released Safari browser
  • Results do not apply to mobile devices or production CDNs

Byte 28 remains a useful observation, but the fragments that follow it are what ultimately determine which question warrants further investigation.

Read on DEV Community ↗ ← Back to News

Comments

No comments yet. Start the discussion.