74MB Down Before the First Frame

We were building a private video delivery system for a client training portal. The video lived in Vercel's private blob store, served through an auth-gated proxy route. We got Range requests working. We got the 206 responses right. Playback still felt sluggish on anything slower than a fast office connection.

On a throttled connection, the video would sit loading for a long time before the first frame appeared.

The problem was the moov atom.

What the Moov Atom Is

An MP4 file has two main pieces: the media data (compressed video and audio samples) and a metadata index called the moov atom. The moov atom tells the browser how many tracks there are, where each sample starts, what codec was used, how long the video runs. Without it, the browser cannot decode anything.

If the moov atom is at the end of the file, the browser has to download the entire file before it can read the index. Only then does it know where to start playing. For a 74MB file on a slow connection, that means waiting for all 74MB to arrive before the first frame can show.

That is exactly what was happening. We checked the moov atom position: it sat at 99.7% of the file. The browser was pulling 73.8MB of compressed video data it could not yet decode before it could confirm the file was playable at all.

The Fix

This is a well-known problem with a well-known fix. The ffmpeg flag -movflags +faststart remuxes the file so the moov atom is written at the front:

ffmpeg -i input.mp4 -movflags +faststart output.mp4

When the moov atom sits at the front, the browser can start parsing and decoding almost immediately after the first bytes arrive over HTTP. Buffering behavior still depends on bandwidth, but the browser no longer has to wait for the full download to begin.

We also re-encoded the video at this step. The file went from 74MB down to 50MB with no visible quality loss. Smaller file, same content, less wait on slow connections.

Why It Slips Through Testing

The problem does not show up on localhost. Development machines serve files over loopback at speeds where a 74MB download finishes before a human notices the delay. The issue only surfaces when the file is served over a real network, and only then on slower connections.

curl does not reveal it either. curl streams bytes without caring where the moov atom sits. A successful curl response tells you the bytes are there, not that the browser can use them in a useful order.

How to Check Your Own Videos

ffprobe will tell you whether the moov atom is at the front or the back. Run it and look for unusual start_time values or use a tool like mp4info to inspect atom order directly.

The faster check: open the video in a browser on a throttled connection. Chrome DevTools has a network throttle. Set it to "Slow 3G" and try to start playback. If the video refuses to begin or takes more than a few seconds to show the first frame, the moov atom is probably at the wrong end.

Run the file through ffmpeg with -movflags +faststart before shipping any video through a delivery system. It costs nothing and it changes a broken experience into a functional one.

The Range requests get the seeking right. The faststart flag gets the start right. Both matter.