【ITニュース解説】Containers vs Codecs: Why "Convert to MP4" Can Shrink a File by 77% or Grow It by 79%

動画ファイルの扱いにおいて「MP4に変換すればファイルサイズが小さくなる」という認識は広く持たれている。確かにファイルサイズが大きく縮小するケースもあるが、逆に大きく増大することもあり、その結果は一様ではない。この現象を理解するには、動画ファイルの構造と「変換」という操作が具体的に何を意味するのかを把握する必要がある。

動画ファイルは、大きく分けて二つの層から構成される。一つは「コンテナ」、もう一つは「コーデック」である。

コンテナは、動画や音声、字幕などの複数のデータストリームを一つにまとめ、ファイルの構造を定義する仕組みである。これは例えるなら、様々な種類のデータを整理して格納する「ファイル形式」そのものだ。MP4、MOV、MKV、WebM、AVIなどがコンテナの具体例として挙げられる。コンテナは、各ストリームの再生順序や同期のためのタイムスタンプ、データの検索を効率化するインデックス、そしてタイトルや制作者などのメタデータを格納する役割も担っている。しかし、コンテナ自体がファイル全体に占めるサイズはごくわずかで、通常は全体の数パーセントにも満たない。

一方、コーデックは、動画や音声のデータを効率的に圧縮したり、圧縮されたデータを元に戻したりするためのアルゴリズムである。データ量を減らすことでファイルサイズを小さくし、ネットワーク上での転送やストレージへの保存を容易にするのが主な目的だ。映像用のコーデックにはH.264、HEVC (H.265)、VP9、AV1などがあり、音声用にはAAC、Opus、MP3などがある。動画ファイルの大部分のデータは、このコーデックによって圧縮されたストリーム（符号化されたデータ）として格納されている。したがって、動画ファイルのサイズは、主に映像ストリームと音声ストリームのビットレートと動画の再生時間に依存する。具体的には、「ファイルサイズはおよそ (映像ビットレート + 音声ビットレート) × 再生時間」という式で表せる。

動画ファイルの「変換」という操作には、実は二つの異なる種類がある。

一つは「リマックス（Remux）」と呼ばれる操作だ。これは、既存の動画や音声のストリームデータを、デコードや再エンコードすることなく、そのまま新しいコンテナにコピーする。例えば、.mkvファイルの中身をそのまま.mp4という箱に入れ替えるようなイメージである。この操作では、データの再圧縮が行われないため、ファイルサイズはほとんど変化せず、画質や音質の劣化も一切ない。ただし、この操作が可能なのは、ターゲットとなる新しいコンテナが、元のファイルで使われているコーデックをサポートしている場合に限られる。

もう一つは「トランスコード（Transcode）」と呼ばれる操作だ。これは、元の動画や音声のストリームを一度デコード（圧縮を解除）し、その後、別のコーデックや同じコーデックでも異なる設定で再エンコード（再圧縮）する。多くの「MP4変換ツール」がこのトランスコードを行っている。なぜなら、これらのツールの目的は「どこでも再生できる」互換性の高いファイルを作成することであり、そのためには一般的に広くサポートされているH.264（映像）とAAC（音声）といったコーデックに変換する必要があるからだ。トランスコードの場合、ファイルサイズは新しくエンコードされたストリームのビットレートや品質設定によって決まる。

実際にいくつかの変換事例を見てみると、このビットレートの変化がファイルサイズに大きな影響を与えていることがわかる。

ファイルサイズが縮小するケースとしては、次のような例がある。あるWebMファイル（VP9/Opusコーデック）をMP4に変換した際、元のファイルが約40MBだったものが約9MBへと77%も縮小した。これは、元のWebMファイルが比較的高いビットレートでエンコードされており、再エンコード時にH.264コーデックが、元の品質を許容範囲で維持しつつ、より低いビットレートで圧縮できると判断したためである。同様に、スマートフォンのHEVC MOVファイルがH.264 MP4に変換されて約48%縮小するケースもあった。HEVCは一般的にH.264よりも圧縮効率が高いとされるが、スマートフォンのリアルタイムエンコードは速度を優先するため、効率よりも高ビットレートになる傾向がある。そのため、より時間をかけて品質を重視した設定でH.264に再エンコードすることで、結果的にファイルサイズを小さくすることが可能なのだ。

一方、ファイルサイズが増大するケースも存在する。例えば、古いXviD/MP3コーデックを使ったAVIファイルをMP4にトランスコードしたところ、元の約80MBから約114MBへと43%も増大したケースや、効率的にエンコードされたMP4ファイルをMOVに変換した際に約80MBから約144MBへと79%も増大したケースなどがある。これは、品質を優先する設定（定品質モードなど）でトランスコードを行った場合に起こりやすい。このモードでは、入力ファイルのビットレートを考慮せず、デコードされた元のソースに近い品質を維持するために必要なビットレートを消費する。そのため、元のファイルがすでに低いビットレートで効率的に圧縮されていた場合、新しいエンコードが元のビットレートよりも高いビットレートを選択し、結果としてファイルサイズが増大してしまうことがある。

また、再エンコードには「世代損失」という影響も伴う。これは、元のコーデックによる圧縮ノイズ（ブロックノイズなど）を、新しいエンコーダが「本来の細かい情報」として認識し、それを保持しようとして余分なビットを消費してしまう現象だ。さらに、品質ターゲットは絶対的なものであり、「入力の何パーセント」という相対的なものではないため、元のファイルがどれだけコンパクトであっても、設定された品質レベルを達成しようとすれば、結果的にビットレートが高くなる可能性がある。

このような現象を理解した上で、開発者が動画変換を扱う際には、いくつかの意思決定のポイントがある。もし異なるコーデックのサポートが必要ない、つまりファイル形式だけを変えたい場合は、リマックス（-c copyオプションなど）を選択するのが最も良い。ファイルサイズは変わらず、品質劣化も発生しない。しかし、別のコーデックが必要な場合はトランスコードを選択することになる。その際、もしファイルサイズを特定の目標値にしたいのであれば、出力ファイルのビットレートを逆算して指定する「ターゲットサイズ圧縮」が有効である。もしサイズよりも品質を重視し、かつ特定のサイズ目標がない場合は、「定品質でトランスコード」を行う。この場合、最終的なファイルサイズはコンテンツの複雑さに応じて決まることになる。

変換を行う前に、入力ファイルの情報を確認することも非常に重要だ。ffprobeのようなツールを使って、ファイルのコーデック名、ビットレート、解像度、再生時間、全体サイズなどを調べておくことで、変換後のファイルサイズ変化をある程度予測できる。例えば、全体のビットレートが低く、XviDやmsmpeg4v3のような古いコーデックが使われているファイルの場合、品質を優先したH.264へのトランスコードではファイルサイズが大きくなる可能性が高いと予測できる。

これらのことから得られる重要な教訓は次のとおりだ。コンテナはあくまでデータを格納する「枠組み」であり、ファイルの実際のサイズは、その中に含まれるコーデックストリームのビットレートによって決まる。動画の「変換」は、データをコピーするだけの「リマックス」と、データを再圧縮する「トランスコード」の二つがあり、それぞれファイルサイズへの影響が全く異なる。高ビットレートでエンコードされた動画をトランスコードするとファイルサイズは縮小することが多いが、既に効率的に圧縮されたり、低ビットレートでエンコードされた動画をトランスコードすると、品質を維持しようとする結果、ファイルサイズが増大することがある。もしファイルサイズを小さくすることが目的であれば、「MP4に変換する」といった漠然とした指示ではなく、「最終的なサイズを〇MBにする」といった具体的な目標サイズを指示することが最も効果的である。