Both MP4 exports put their moov box at byte 28. That looked like a convenient answer to the question I was checking: would the player have to fetch the end of the file before it could start? But the next boxes changed the interpretation. These files contained repeated moof and mdat pairs, followed by mfra. Calling them ordinary faststart MP4s would have discarded the most useful part of the inspection.
I made the exports with ImgIng, using its Chinese video compression workbench for the actual test. The inputs were two existing WebM clips of ocean waves. I selected MP4 and the option prioritizing file size, ran both conversions, and captured the bytes written by the tool. Both operations completed. I did not recreate a plausible output with a separate encoder. The resulting files were 912,701 and 2,198,495 bytes.
In each file, ftyp occupied the first 28 bytes and moov started immediately afterward. Looking only at that offset would tell me where the movie metadata began. It would not tell me how the rest of the media was organized. The recurring fragment boxes identified a fragmented MP4 structure. That matters because an early moov does not, by itself, establish that it contains a complete index for every sample in the whole movie.
Ordinary faststart processing and fragmentation answer different structural questions. In the conventional case, moving the movie metadata toward the front lets a player read it before downloading the remaining media payload. Fragmented output carries additional metadata alongside its media fragments. The FFmpeg format documentation treats fragmentation separately from its faststart pass. Finding either layout in a file does not identify which software the application used internally. I have no evidence that these exports were produced by running FFmpeg faststart.
This is the exported Iceland clip in a local browser player after a frame appeared. It is not the product interface or a container inspection report. The picture establishes that the player decoded a visible frame at this point; the box inspection comes from the saved output bytes. Even the player’s displayed duration is a separate observation, not a substitute for checking the completed file.
I also served the actual exports over a controlled local HTTP connection. Responses shared a 256 KiB/s write budget, with an 80 ms delay at the start of each request. This was application-level throttling, not a complete network simulation. For the larger fragmented export, Chromium’s first-frame median was 7.909 seconds with Range enabled and 1.403 seconds without it, with two runs per condition. Its requests scanned later fragments in the Range case. An early moov clearly did not guarantee an immediate picture here.
That observation is not a reason to disable Range. The other playback engines behaved differently, and startup does not settle whether a viewer can seek to an undownloaded position. I also kept these exports separate from the ordinary MP4 comparison files: those were eight-second, silent derivatives, while the complete product exports retained audio and had different durations. Comparing their startup times as a product speed ranking would mix different inputs and layouts.
The Iceland footage is Alexander Grebenkov’s Ocean waves at Lækjavik beach, Iceland, used under CC BY 3.0; the image above is a player screenshot of the converted output. The second input was דוד שי’s Water waves in Herzliya beach, under CC BY-SA 4.0. Neither was footage I shot.
For the next export I inspect, I would record the box sequence before assigning a label. Then I would check first-frame playback and seeking separately against the actual HTTP behavior. This test used Chromium 149, Firefox 151, and a WebKit 26.5 test build, not a released Safari browser. It does not establish behavior on mobile devices or a production CDN. Byte 28 is a useful observation; the fragments after it determine which question to investigate next.
Top comments (0)