moov atom not found とは

MP4ファイルは、「atom（アトム）」または「box（ボックス）」と呼ばれるブロックがいくつも集まってできています。中でも特に重要なのが次の atom です。

  • mdat（Media Data atom）：動画・音声のデータそのもの
  • moov（Movie atom）：ファイルの目次にあたるインデックス情報（タイムスタンプ、サンプルの位置など）

moov がないと、プレーヤーもFFmpegもファイルを再生・処理できません。

エラー例:
moov atom not found
Invalid data found when processing input

なぜ moov がファイル末尾にあるのか

FFmpegは何も指定しないと、エンコードが終わってから moov をファイルの末尾に書き込みます。エンコード中は mdat の大きさがわからず、moov に書く内容（各フレームの位置）が決まらないためです。

[デフォルト構造]
ftyp | mdat（巨大な映像・音声データ） | moov（インデックス）

この並びには、次の2つの問題があります。

  1. プログレッシブダウンロード（ダウンロードしながらの再生）の開始が遅れる：HTTP の Range リクエスト（ファイルの一部だけを取る要求）に対応したサーバーなら、プレーヤーは末尾の moov を先に取りに行くので、全体のダウンロードを待たずに再生できます。ただし、そのぶん再生の開始が遅れます。
  2. 録画中にクラッシュすると壊れる：moov を書き込む前にプロセスが終了すると、moov のない壊れたファイルになります。

moov を先頭に置く：-movflags faststart

新しくMP4を作るときに -movflags faststart を付けると、moov をファイルの先頭に移せます。

ffmpeg -i input.mp4 -c copy -movflags faststart output_fast.mp4

moov が先頭に来るので、ストリーミング再生ができ、Webでも早く表示が始まります。

[faststart構造]
ftyp | moov（インデックス） | mdat（映像・音声データ）

エンコード時に faststart を指定する

ffmpeg -i input.mp4 -c:v libx264 -crf 23 -c:a aac -movflags faststart output.mp4

qt-faststart で既存ファイルを最適化

FFmpeg のソースコードの tools/ にある qt-faststart でも、既存のMP4を変換できます（gyan.dev の Windows 版ビルドには入っていません）。

qt-faststart input.mp4 output_fast.mp4

qt-faststart は再エンコードせず、moov を先頭に移すだけです。速く終わり、画質も落ちません。

録画クラッシュで壊れたファイルの修復

録画中にクラッシュして moov がないファイルは、FFmpegだけでは直せません。同じ機器・同じ設定で撮った正常なファイルがあれば、オープンソースの untrunc で moov を作り直せる場合があります。

untrunc ok.mp4 broken.mp4

ok.mp4 は見本にする正常なファイル、broken.mp4 は壊れたファイルです。うまくいくと broken_fixed.mp4 ができます。

商用ツール

  • Remo Video Repair
  • Stellar Video Repair

フラグメント化MP4で耐クラッシュ性を上げる

録画に使うなら、フラグメント化MP4が向いています。先頭に空の moov を1回だけ書き、そのあとは映像・音声を短い区切り（moof と mdat の組）ごとに追記していく形式です。

ffmpeg -i input.mp4 -c copy \
  -movflags frag_keyframe+empty_moov+default_base_moof \
  -frag_duration 4000000 \
  output_frag.mp4
  • frag_keyframe：キーフレームごとにフラグメント（区切り）を作ります
  • empty_moov：ファイルの先頭に空の moov を置きます
  • default_base_moof：tfhd に default-base-is-moof フラグを立て、データの位置を各 moof からの相対位置で表します
  • -frag_duration 4000000：1つのフラグメントを長くても4秒で区切ります（単位はマイクロ秒）。frag_keyframe も付けているので、それより前にキーフレームが来ればそこで区切られます

この形式なら、途中でクラッシュしても部分的には再生できます（HLS/DASHに近い構造です）。

実測: 処理時間とサイズ

計測したコマンドは次のとおりです。

ffmpeg -i input.mp4 -c copy -movflags +faststart output.mp4
項目 実測値
処理時間 0.49 秒（実時間の 242.58 倍速）
出力サイズ 353.29 MB

計測環境: Core i9-14900KF（32スレッド）／FFmpeg 8.1（gyan.dev）／素材は 1920x1080・30fps・120秒・351.4 MB の映像（Big Buck Bunny をループ、CC BY 3.0）に、128 kb/s の AAC 音声を1本加えた MP4 で、全体で 353.29 MB です。2026-09-05 に計測しました。生データはデータセットで公開しています。

なぜ 0.49 秒で終わるのか

120秒の動画が 0.49 秒、実時間の 242.58 倍速で終わります。このコマンドは映像も音声もエンコードしないからです。FFmpeg がしているのは、圧縮済みのパケットをそのまま読んで書き戻し、ファイル末尾にあった moov atom を先頭へ移して、位置の情報（オフセット）を書き直すことだけです。時間がかかるのはストレージの読み書きとインデックスの書き換えで、CPUのコアを使い切るような処理ではありません。

同じマシン・同じ素材で比べると、フィルタをかけずにそのまま再エンコードした場合（-c:v libx264 -crf 23 -preset medium）は 27.97 秒、VP9 への変換は 729.16 秒かかりました。同じ計測の -c copy 系では、-map 0 -c copy によるストリームコピーが 0.41 秒、音声だけを再エンコードする afade が 1.03 秒でした。処理時間を決める分かれ目は、映像を再エンコードするかどうかです。faststart は映像も音声も再エンコードしない側です。

この時間は、ファイルサイズとストレージの速さでほぼ決まります。2GB級のファイルやネットワークドライブ上では、そのぶん長くなります。解像度やコーデックが重くなっても、faststart の時間は増えません。

出力は 353.29 MB で、入力と同じ大きさです。-c copy はストリームをそのまま通し、faststart は moov の位置を変えるだけだからです。351.4 MB の映像との差は、音声トラックのぶんです。この操作で見るべき数字は、サイズではなく時間です。

faststart は正常なMP4の並びを整える処理で、壊れたMP4を直す処理ではありません。録画中のクラッシュで moov が欠けたファイルは、このコマンドでは直せません。

Webで公開するMP4なら、エンコードするときに最初から -movflags +faststart を付けておくのがいちばん速く済みます（後から処理する必要がなくなります）。付け忘れても、後から付けるのにかかるのは 0.49 秒です。

MP4のatom構造を確認する方法

ffprobe で atom の構造を調べられます。

ffprobe -v trace -i input.mp4 2>&1 | grep -E "type:'(ftyp|moov|mdat)'"

よくある質問

Q: moov atom not found のファイルを再エンコードできないか？

できません。moov がないと、FFmpegはファイルのどこにフレームがあるのかわからないので、読み込みの段階で失敗します。先に修復ツールで直す必要があります。

Q: -movflags faststart は常に使うべきか？

Webや配信に使うなら付けてください。手元で再生するだけなら不要です。ただし録画に使うなら、frag_keyframe+empty_moov のほうがクラッシュに強いです。

Q: faststart の処理時間は？

再エンコードしないので、数秒以内に終わります。353.29 MB のファイルで 0.49 秒でした。

関連記事