How a Single FFmpeg Command Can Cut CDN Video Bandwidth Costs by 90%

During a routine CDN bandwidth alert the team discovered a 1 GB training video that had been viewed by 2,500 employees. The expected traffic was roughly 2.5 TB (2500 × 1 GB), but the CDN logs showed a staggering 120 TB, indicating a 50‑fold increase.

Using Chrome’s developer tools the author observed that a single playback generated three initial HTTP 206 requests, followed by a rapid series of additional 206 requests with the Range header jumping back and forth. The video’s size (8 GB when fully downloaded) and the number of 206 requests (3,700) confirmed the abnormal behavior.

The root cause lies in the MP4 file structure. An MP4 consists of several boxes, most notably ftyp, moov (metadata), and mdat (media data). The moov box contains the index that tells the player where each sample resides. When moov is placed at the end of the file, the player must first seek to the tail to read the index, generating the first two 206 requests, and a third request is issued when playback starts.

Chrome uses the FFmpegDemuxer to parse MP4 files. Its normal flow is to read ftyp + moov (head) → read mdat → play. Because the problematic file’s moov is at the end, the player performs the extra seeks, and the interleaving of audio and video packets is poor: large blocks of audio precede video, causing the demuxer’s mov_find_next_sample() function to repeatedly choose the “closest” DTS frame even though its file offset is far away. This results in frequent back‑and‑forth range requests.

The author reproduced the issue with FFmpeg by extracting a 5‑second segment from the problematic video and counting the number of "Range" lines in the trace (5 s → 5,078 requests). Disabling interleaved reading with -interleaved_read 0 reduced the count to three requests, confirming that the interleaving strategy drives the excess traffic.

Applying the command ffmpeg -i bad.mp4 -c copy -movflags faststart good.mp4 moves the moov box to the beginning and re‑interleaves audio‑video packets. After re‑uploading the processed file, a new Chrome trace showed only a single 206 request and total bandwidth equal to the file size.

Further tests on a long, poorly interleaved video ( longbad.mp4) demonstrated that the default interleaved read generates thousands of range requests, while forcing non‑interleaved read ( -interleaved_read 0) drops the count to three. The author therefore recommends using FFmpeg fast‑start for short videos and adopting streaming formats such as HLS for long‑form content to achieve better bandwidth efficiency and smoother playback.

ffmpeg -i bad.mp4 -c copy -movflags faststart good.mp4

ffmpeg -interleaved_read 0 -i https://example.com/longbad.mp4 -ss 60 -t 5.0 -y output.mp4 -loglevel trace 2>&1 | grep "Range"