Slow Web Video Playback: The moov Atom and Streaming
The same MP4 opens instantly in a local player but makes the web wait for the entire download before showing a frame. The problem is not bandwidth — it is where the index sits in the file.
The moov atom decides streamability
An MP4 is a set of chunks, and the moov chunk is the index — frame positions and timestamps, the table of contents a player needs before decoding anything. moov at the front: a few kilobytes in, playback starts. moov at the end: the player must pull the whole file to build the directory — experienced as endless buffering or a black screen, worse the larger the file.
The position is decided at export time: most editors default to faststart (moov first), but some tools and settings write it last. That is why the "same video plays on some sites but not others" mystery usually ends here.
Diagnosis and fix
Check with an inspection tool — MP4 structure reveals whether moov sits front (streaming-friendly) or back. The low-tech test: drop the file into a web player; if frames appear before the download finishes, the index leads.
The fix needs no dedicated tool: the compression tool writes faststart output (done in-memory), so re-running the compression with unchanged parameters repositions the index. Remuxing to MP4 also solves it — the new file is written streaming-friendly.
Where it actually matters
Three scenarios care about moov position: embedded web playback (the video tag needs streaming); chat-app previews (thumbnails and instant-open rely on header data); CDN delivery (Range-based segment fetching degrades badly with a trailing index). Local playback, USB copies, and editor imports are unaffected.
Build the pre-publish habit: compress the final cut, confirm faststart, then upload. The third step is the one most often skipped — it changes neither quality nor size, but it is the difference between "opens instantly" and "spins forever" on the web.