WebサイトにMP4をアップロードしたら、再生開始がひどく遅れる——サーバーやプレーヤーによっては、ファイルの大部分または全体をダウンロードし終えるまで再生が始まらないこともある。短いクリップは平気なのに、長いものは最初の1フレームが出るまで延々と回り続ける。シークも不安定。犯人はほぼ必ず、ファイル末尾にあるmoovアトムです。直し方はFFmpegのフラグ1つ — -movflags +faststart — だけ。本記事では、なぜ効くのか、いつ必要なのかを解説します。所要時間：5分。
動作確認: FFmpeg 8.1
この記事でわかること
- moovアトムとは何か、なぜ位置が重要なのか
- 1行で済むfaststartの修正
- プログレッシブダウンロード・ストリーミングがローカル再生とどう違うか
- ファイルにすでにfaststartが適用済みか確認する方法
- faststartが必要なケースと不要なケース
- 再エンコード時にfaststartを適用する
- トラブルシューティングとFAQ
1. moovアトムと、なぜ位置が重要か
MP4（およびMOV）ファイルは「atom（box とも呼ぶ）」の集まりです。最も重要なのが moovアトム — 各フレームの位置・長さ・コーデック・シーク方法をプレーヤーに教える索引です。moovアトムを読まなければ、プレーヤーはメディアデータを解釈できません。
moovアトムが置かれる場所は2通りあります。
- ファイル末尾（FFmpegの既定）。エンコーダは完了するまで最終的な配置がわからないため、索引を最後に書きます。
- ファイル先頭（faststart）。索引がメディアより前にあるため、最初のバイトが届いた時点で再生を開始できます。
ローカル再生ではこれは問題になりません — プレーヤーはファイルのどの部分でも即座に読めます。Webでは、再生開始が遅くなるよくある原因になります。
2. 1行で済む修正
これが解決策のすべてです。再エンコードなし、画質変化なし：
ffmpeg -i input.mp4 -c copy -movflags +faststart output.mp4-c copy… ストリームをそのままコピーするので数秒で完了、画質劣化ゼロ。-movflags +faststart… mux後にFFmpegがもう一度パスを走らせ、moovアトムを先頭へ移動する。
出力はWebで再生開始が速くなり、ダウンロード中のシークにも対応します。
3. なぜ位置がWeb再生を壊すのか
違いは、ファイルがどう配信されるかにあります。
| シナリオ | ファイルの読まれ方 | faststartが必要か |
|---|---|---|
| ローカル再生（ダブルクリック） | 任意のバイトへランダムアクセス | 不要 |
| Webプログレッシブダウンロード | 先頭から順にバイトが届く | 必要 |
| HTTP疑似ストリーミング | プレーヤーが範囲要求、索引が早期に必要 | 必要 |
| HLS/DASHセグメント | 小さなセグメントごとの索引 | 通常はパッケージャが処理 |
ブラウザがHTTP経由でMP4を再生するとき、先頭から読み込みます。moovアトムが末尾にあると、プレーヤーはまずその索引を探さねばならず、取得のために追加のHTTP範囲要求を出すことがあり、サーバーやプレーヤーによってはファイルの大部分または全体を取得し終えるまで再生を開始できないこともあります。faststartなら索引が先頭にあるため、再生もシークもほぼ即座に始まります — これがプログレッシブダウンロードです。
4. ファイルにすでにfaststartが適用済みか確認する
再処理の前に、moovアトムの位置を確認しましょう。ffprobe でアトムの順序を報告させられます。
ffprobe -v trace input.mp4 2>&1 | head -n 40traceの出力から moov と mdat の順序を探します。moov が mdat の前にあればfaststart適用済み。moov が mdat の後にあれば、第2章の修正が必要です。
5. faststartが必要なケースと不要なケース
faststartを付けるべき場合：
- MP4をWebサイトやCDNから配信し、ブラウザ内で再生する。
- ダウンロード完了前に視聴を開始させたい。
- ダウンロード中にシーク（タイムラインのスクラブ）を動かしたい。
省略してよい場合：
- ローカル再生のみ（デスクトッププレーヤー、NAS、編集）。
- HLS/DASHのアダプティブストリーミングで配信する（セグメンタが索引を処理する）。
- これから再処理する中間ファイル。
Web配信で迷ったら付けておきましょう — コストは小さく、害もありません。
6. 再エンコード時にfaststartを適用する
すでに再エンコードしている場合（圧縮や変換など）は、同じパスでフラグを付ければ2回目の実行は不要です。
ffmpeg -i input.mp4 -c:v libx264 -crf 23 -c:a aac -movflags +faststart output.mp4H.264/AACにエンコードしつつ、moovアトムを先頭に書き込みます。エンコードに上乗せされるコストはほぼゼロです。
7. トラブルシューティング
問題1: フラグを付けたのにストリーミングできない
原因: MP4/MOV以外のコンテナで保存し直した（faststartはMOV/MP4 muxerにのみ適用される）。
解決策: 出力拡張子が .mp4 か .mov であることを確認。MKVやWebMにはfaststartは効きません。
問題2: コマンドは動くが想定より時間がかかる
原因: faststartはアトムを移動するためファイルを書き直す必要があり、FFmpegが出力に追加パスを行う。
解決策: 正常です。大きいファイルでは追加パスで多少時間が増えますが、-c copy と併用すれば再エンコードはしません。
問題3: 元ファイル再生時に「moov atom not found」
原因: ソースが途中で切れた、または最終化されていない（録画の中断など）ため、使える索引がない。 解決策: これは位置ではなく、moovアトムの欠損/破損という別問題です。復旧方法はmoovアトムのガイドを参照してください。
問題4: ダウンロード中のシークが飛ぶ・止まる
原因: プレーヤーまたはサーバーがHTTP範囲要求に対応していない。
解決策: サーバーが Accept-Ranges: bytes を返すことを確認。faststartはシークを可能にしますが、サーバー側も範囲要求を許可する必要があります。
よくある質問
Q1. faststartで画質は落ちる？ファイルは変わる？
A. いいえ。-c copy 併用ならmoovアトムを移動するだけで、音声・映像のビットストリームには手を付けません。
Q2. なぜFFmpegは既定でこれをしない？ A. エンコーダは完了するまで最終サイズと配置がわからないため、索引を最後に書くのが自然な既定です。faststartは並べ替えのために追加パスを行います。
Q3. 短いクリップは再生できるのに長いものはできません。なぜ？ A. 短いクリップは末尾のmoovアトムもほぼ即座に届くほど速くダウンロードできます。長いファイルはダウンロードに時間がかかるため遅延が顕在化します。faststartは両方を直します。
Q4. MOVファイルでも効きますか？
A. はい。faststartはMOV/MP4 muxerの機能なので、.mov 出力でも効きます。
Q5. HLS/DASHを使っています。それでも必要？ A. 通常は不要です。アダプティブストリーミングはメディアを索引付きの小さなセグメントに分割するので、ストリーミングサーバーが索引付けを処理します。
関連記事
Tested with FFmpeg 8.1 — verified with our command-check script 一次ソース: ffmpeg.org/ffmpeg.html / ffmpeg.org/ffmpeg-formats.html#mov