【ITニュース解説】Converting MOV to MP4 Without Re-Encoding: What FFmpeg Actually Does (Tested)

MOVファイルをMP4ファイルに変換する作業は、一見すると簡単な処理に思えるが、特にFFmpegのような強力なコマンドラインツールを使用する際には、その動作原理を深く理解していなければ、予期せぬ問題に直面することがある。システムエンジニアを目指す者にとって、ファイル形式やデータの取り扱いに関する正確な知識は不可欠であり、ここではMOVからMP4への「再エンコードなし」の変換に焦点を当て、その正しい理解と潜む落とし穴について解説する。

まず、多くの人が思い浮かべる「ファイル変換」とは異なる、「リミックス」という概念を理解する必要がある。MOVファイルとMP4ファイルは、どちらも「コンテナフォーマット」と呼ばれるものであり、動画や音声のデータ（これらを「ストリーム」と呼ぶ）を格納するための「箱」に過ぎない。多くの場合、これらの箱の中身、つまり動画ストリームはH.264形式、音声ストリームはAAC形式である。通常の「再エンコード」とは、この箱の中身のデータを一度完全に解読し、別の形式や品質で改めてエンコードし直す作業を指す。この方法では、品質がわずかに劣化する可能性があり、またファイル全体を処理するため、ファイル再生にかかる時間と同程度の長い処理時間を要する。一方、「リミックス」とは、箱の中身であるデータ（ストリーム）自体には一切変更を加えず、そのまま別のコンテナ（箱）に入れ替える作業である。FFmpegで「-c copy」オプションを使用することは、このリミックス処理を実行することを意味する。この方法であれば、データに品質劣化は一切なく、処理も非常に高速である。リミックスが正しく行われた場合、入出力ファイルのサイズはコンテナの構造の違いによるわずかなオーバーヘッド分しか変わらず、数キロバイト程度の差に収まることが一般的である。もし出力ファイルのサイズが元のファイルより大幅に小さくなっている場合は、何らかのデータが失われている可能性が高い。

ウェブサイトに動画をアップロードする場合など、多くの人がアクセスする環境で利用する際には、「-movflags +faststart」オプションを追加することが推奨される。MP4ファイルは、動画のメタデータやインデックス情報（moovアトムと呼ばれる）をファイルの最後に記述する構造を持つことがある。この場合、プレイヤーはファイルを完全にダウンロードし終えるまで再生を開始できないことがあるため、再生開始に時間がかかる原因となる。「faststart」オプションは、このインデックス情報をファイルの先頭に移動させることで、ファイルダウンロード中に再生を開始できるようにし、ユーザー体験を向上させる効果がある。

しかし、このリミックス処理にはいくつかの「落とし穴」が存在する。最初の落とし穴は、「-c copy」オプションが「すべてのストリームをコピーする」という意味ではない、という点である。FFmpegのデフォルトの動作は「ストリーム選択」であり、入力ファイルから一つの動画ストリームと一つの音声ストリームを自動的に選択し、それ以外のストリームは無視する。したがって、「-c copy」は選択されたストリームを再エンコードせずにコピーすることを意味するだけで、入力ファイルに複数の音声トラック、解説トラック、または字幕トラックなどが含まれていても、デフォルトではそれらの多くは無視されてしまう。この際、FFmpegは警告なしに正常終了（終了コード0）するため、ユーザーはデータが失われたことに気づきにくい。この問題を解決するためには、「-map 0」オプションを使用する。これは、入力ファイル（0番目の入力ファイル）の「すべてのストリーム」をコピー対象として明示的に指定するオプションである。したがって、正しいコマンドは「ffmpeg -i input.mov -map 0 -c copy output.mp4」となる。リミックス後には「ffprobe input.mov」と「ffprobe output.mp4」というコマンドを実行し、それぞれの出力からストリームの数を比較することで、意図したすべてのストリームがコピーされたかを確認することが重要である。また、SRT形式のようなテキストベースの字幕トラックは、MP4コンテナに直接格納することができない。FFmpegはこれらの字幕トラックも黙って削除してしまうため、字幕を保持したい場合は「-c:s mov_text」オプションを使って、MP4が対応する形式に明示的に変換する必要がある。

二番目の落とし穴は、MP4コンテナが一部のコーデックを格納することを許可していない、という点である。コンテナは「箱」であっても、その箱に入れられる中身（ストリームのエンコード形式、すなわちコーデック）には互換性の問題がある。例えば、プロフェッショナルな動画編集でよく使われる「ProRes」形式の動画は、MOVファイルには格納できるが、MP4コンテナの仕様では直接サポートされていない場合が多い。このようなProResコーデックを含むMOVファイルに対してリミックスを試みると、FFmpegは「Codec not currently supported in container」といったエラーメッセージを出力し、変換処理を拒否する。これはFFmpegの不具合ではなく、MP4コンテナの仕様による制限であり、特別なオプションを追加してもリミックスは不可能である。この状況に直面した場合の選択肢は三つある。一つは、元のMOVファイルのまま保持すること。もう一つは、ProResコーデックを格納できる別のコンテナ形式（例：Matroska）にラップし直すことである。そして最後の選択肢が、実際に「再エンコード」を行うことである。再エンコードの一般的なコマンドは、「ffmpeg -i input.mov -c:v libx264 -crf 23 -c:a aac output.mp4」となる。これは、動画ストリームをH.264形式に、音声ストリームをAAC形式に再エンコードするものであり、「-crf 23」は標準的な品質レベルを指定する。しかし、再エンコードは品質劣化を伴う非可逆な処理であるため、リミックスが不可能な場合の最終手段としてのみ使用すべきである。

三番目の落とし穴は、コマンドが正常終了したからといって、すべてがうまくいったと鵜呑みにしてはいけない、という点である。上記で述べたストリームの欠落や変換失敗を確実に検出する唯一の方法は、出力ファイルの「バイトサイズ」を元のファイルと比較することである。リミックスが成功し、すべてのストリームがコピーされた場合、出力ファイルのサイズは元のファイルと数キロバイト程度の差に収まるはずである。もし出力ファイルが元のファイルの半分やそれ以下のサイズになっているなど、明らかに小さくなっている場合は、何らかのストリームが欠落している可能性が極めて高い。繰り返しになるが、ストリームが欠落した場合でもFFmpegは警告なしに正常終了することがあるため、コマンドの終了コードだけを信頼することはできない。したがって、変換作業後には、まず出力ファイルのサイズを元のファイルと比較し、次に「ffprobe」コマンドで入出力ファイルのストリームリストを比較するという、二段階の健全性チェックを必ず行うべきである。これらの確認作業を終えて初めて、元のファイルを削除するなどの次のステップに進むことが許される。

結論として、MOVファイルをMP4ファイルに変換する際の基本的な判断は以下の通りである。入力ファイルがH.264動画とAAC音声を含んでいる場合は、「-map 0 -c copy -movflags +faststart」というオプションを用いてリミックスを行い、その後に必ず出力ファイルのサイズとストリームリストが元のファイルと一致していることを確認する。もし入力ファイルがProResのようなMP4コンテナでサポートされないコーデックを含んでいる場合は、リミックスは不可能であるため、元のMOVファイルを保持するか、別のコンテナにラップするか、あるいは品質劣化を許容して再エンコードするかのいずれかの方法を選択する必要がある。これらの注意点を理解し実践することで、FFmpegを用いたファイル変換をより正確かつ安全に行うことが可能となる。