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
ftypheader occupies the first 28 bytes - The
moovbox begins immediately after theftypmarker - 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:
- Alexander Grebenkov - Ocean waves at Lækjavik beach, Iceland (CC BY 3.0)
- ืืื ืฉื - 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.
Comments
No comments yet. Start the discussion.