MP4とWebMを2026年に比較：最適な動画形式・コーデック・圧縮画質の選び方

動画を制作・変換したり、Webサイト向けに用意したりする際、特に重要なのが適切な形式と圧縮設定の選択です。ファイルは小さければよいというものではありません。ブラウザーで安定して再生でき、スマートフォンでも動作し、効率よくデコードでき、用途に見合う画質を維持する必要があります。

MP4、WebM、H.264、H.265/HEVC、VP9、AV1、FFmpeg、x264のエンコードプリセット、ブラウザーの互換性、モバイル端末のハードウェアデコード、画質評価について調べました。さらに、同じ元動画を複数のCRF値でエンコードし、見た目と客観的な指標の両方で比較する圧縮実験も行いました。

最終的に、ブラウザー、スマートフォン、外部アプリケーションの幅広い環境で動画ファイルを1種類だけ提供する必要がある場合は、H.264を使用したMP4を優先することにしました。

主にスマートフォンで視聴する短い動画では、細部をすべて残すことよりも読み込みの速さとファイルサイズの小ささを重視しました。大きなデスクトップモニターで見ても、通常の再生中はCRF 22と30の間に意味のある違いを感じられなかったため、x264のCRF 30を選びました。

ただし、重要な前提があります。CRF 30は、映画、高品質な映像作品、画質を最大限維持すべき素材に対する推奨値ではありません。そうした用途では、たとえばCRF 20前後の、はるかに控えめな設定が出発点になるでしょう。映画や高品質な実写映像について同等の実験は行っていないため、これらは別途検証するための初期値にすぎません。

この記事では、その技術的な判断理由、実際の圧縮結果と限界、そして自分のプロジェクトに適した動画形式と画質設定の選び方を説明します。

1. 動画コンテナとコーデックは別物

MP4とWebMを比べる前に、コンテナとコーデックの違いを押さえておく必要があります。

コンテナは映像、音声、タイムスタンプ、メタデータを1つのファイルにまとめる仕組みです。一方、動画コーデックは映像フレームの圧縮と復号の方法を決めます。

たとえばMP4にはH.264、HEVC、AV1の映像を格納できます。拡張子が同じでも、それぞれ圧縮特性や再生に必要な端末の条件は異なります。

構成要素	例	役割
動画コンテナ	MP4、WebM、MOV、MKV	映像、音声、時間情報をひとまとめにする
動画コーデック	H.264、HEVC、VP9、AV1	映像フレームを圧縮・復号する
音声コーデック	AAC、Opus、MP3	音声を圧縮・復号する
動画エンコーダー	x264、x265、SVT-AV1、libvpx-vp9	動画圧縮を実装する

ファイル名の拡張子を.webmから.mp4に変えても、動画コーデックは変換されません。同様に、AV1をMP4に格納したからといって、AV1のデコードに対応しない端末で再生できるようにはなりません。

動画の互換性を考える際は、コンテナ、動画コーデック、音声コーデック、コーデックのプロファイル、ビット深度、再生環境をひとまとまりとして確認してください。

2. MP4とWebM：Web動画にはどちらが適しているか

MP4もWebMも、現代の動画コンテナとして十分実用的です。実際の特性は格納するコーデックによって変わるため、どちらか一方が常に優れているわけではありません。

H.264を使用したMP4：実用上の互換性が非常に高い

H.264映像とAAC音声を格納したMP4は、長い年月にわたり非常に幅広い環境で利用されてきました。主要なデスクトップ・モバイルブラウザー、OS標準の動画プレーヤー、多くのサードパーティー製アプリケーションに対応しています。

スマートフォンやパソコンのハードウェア動画デコーダーにも広く対応しています。ソフトウェアデコードと比べて、ハードウェアデコードはCPU負荷を減らし、再生効率を高め、消費電力を抑えられる場合があります。

最大の弱点は圧縮効率です。新しいコーデックでは、見た目が同程度の画質でも、より低いビットレートにできることがよくあります。

それでも、ファイルサイズの極限までの削減より確実な再生を重視するなら、H.264は今なお優れた選択肢です。

VP9を使用したWebM：圧縮効率が高く、ブラウザー向き

WebMには通常、VP8、VP9、AV1の映像が格納され、音声にはOpusやVorbisがよく使われます。

VP9は同程度の視覚品質でH.264より高い圧縮効率を示すことが多く、現行のブラウザーに広く対応しています。新しいSafariもその対象です。

「SafariはWebMやVP9にまったく対応していない」という説明は正確ではありません。ブラウザーの対応状況は以前より大きく改善されています。

むしろ重要なのはブラウザー以外での互換性です。OS標準アプリ、古い端末、サードパーティー製ソフトウェアでは、一般的なH.264のMP4ほどWebMを安定して扱えない場合があります。

再生環境を管理できるブラウザー専用アプリなら、WebMは有力な選択肢です。一方、利用者がダウンロードしてさまざまなソフトウェアで開く可能性がある場合は、MP4/H.264のほうが予測しやすいでしょう。

実用面での違い

要件	MP4 + H.264	WebM + VP9
最新ブラウザーでの再生	非常に優れている	とても良好
古いブラウザー・端末への対応	一般に強い	環境への依存が大きい
ダウンロードファイルの互換性	一般に強い	ネイティブアプリごとの差が大きい
圧縮効率	良好	優れることが多い
ハードウェアデコード	非常に広く普及	広く使えるが端末次第
適した用途	幅広く再生できる1種類のファイル	クライアント環境が把握できるWeb配信

重要なのはWebMが良い形式かどうかではなく、その圧縮効率の利点が、自分の環境で生じる互換性上のトレードオフに見合うかどうかです。

3. H.264、H.265、VP9、AV1：どのコーデックを選ぶべきか

主要な動画コーデックにはそれぞれ、圧縮効率、エンコードの負荷、ハードウェア対応、ソフトウェア互換性、ライセンス条件の異なるバランスがあります。

コーデック	圧縮効率	実用上の互換性	主な用途
H.264 / AVC	良好	非常に優れている	一般的なWeb動画、モバイル再生、ダウンロード
H.265 / HEVC	一般にH.264より高い	環境次第	対応するApple製端末、管理された環境、高解像度動画
VP9	一般にH.264より高い	最新ブラウザーではとても良好	ブラウザーでの動画配信
AV1	非常に高い効率が期待できる	対応が拡大中だが古い端末に制限	最新のストリーミング、対応端末

これは定性的な比較であり、あらゆる映像に通用するビットレート順位ではありません。実際の効率は素材、エンコーダーの実装、目標画質、プリセット、測定方法によって変わります。

H.264：成熟しており、復号が速く、対応環境が広い

H.264は高度に最適化され、非常に多くのハードウェアとソフトウェアに対応しています。特別な再生アプリを必要とせず安定して動画を再生したい場合、この成熟度は強みになります。

弱点は、新しいコーデックのほうが効率よく圧縮できることが多い点です。またH.264には特許とライセンスに関する検討事項があり、該当する商用配信では確認が必要です。

H.265 / HEVC：高い圧縮効率と互換性のトレードオフ

HEVCは、画質が同程度ならH.264よりビットレートを大きく下げられる場合があります。高解像度の映像や、対応端末を管理できる環境で特に魅力的です。

多くのApple製デバイスはHEVCによく対応しています。ただしブラウザーや外部アプリの対応状況は、OSやインストール済みのデコードコンポーネントによって異なります。ライセンスも検討事項です。

HEVCは優れた選択肢になり得ますが、一般向けWebサイトでダウンロード用の形式をHEVCだけにすることは、私は自動的には選びません。

VP9：実用的なオープンな選択肢

VP9は良好な圧縮効率と現代のブラウザーでの広い互換性を備えています。動画をブラウザー内で再生し、環境を予測できるなら魅力的です。

私の用途では、ダウンロード後にWebMやVP9への対応が一定でないネイティブアプリで開かれる可能性がある点が主な欠点でした。

AV1：圧縮効率は非常に高いが、ハードウェア対応はまだ一様ではない

AV1は有望な現代の動画コーデックの一つです。従来のコーデックより大きくビットレートを削減できる可能性があり、ハードウェアデコードへの対応も広がっています。

ただし古い端末ではAV1デコーダーがなかったり、ソフトウェアデコードが必要だったりします。高解像度動画をソフトウェアで復号するとCPUとバッテリーの消費が増え、性能の低い端末では再生に問題が出ることもあります。

再生環境を管理できるならAV1は十分検討する価値があります。古い端末と新しい端末、一般的な外部プレーヤーのすべてを1種類のファイルでカバーしたいなら、H.264のほうが安全な初期選択です。

MDNの動画コーデックガイドには、各コーデックとブラウザーでの要件に関する有用な情報があります。

4. 動画形式は1種類にするか、複数用意するか

これは動画配信における重要な設計判断の一つです。

複数の形式を提供できるなら、対応端末にはAV1やVP9を配信し、それ以外にはH.264へフォールバックできます。これにより、幅広い再生互換性を保ちながら圧縮効率を改善できる可能性があります。

一方、複数形式を維持すると、エンコード、ストレージ、キャッシュ、検証、再生形式の選択が複雑になります。

元動画1本につき完成ファイルを必ず1種類にしたいのであれば、互換性を優先する戦略が適していることが多いでしょう。

私は、主要ブラウザーやスマートフォンだけでなく、ダウンロード後の一般的な利用でも代替形式なしで再生できるファイルが欲しかったため、MP4/H.264を選びました。

これはMP4/H.264の圧縮効率が最も高いという主張ではありません。新しいコーデックでファイルを小さくできる可能性より、再生結果の予測しやすさを優先した判断です。

5. モバイル向け動画では何を優先すべきか

動画圧縮は、実際にどのように視聴されるかに合わせるべきです。

スマートフォンで主に視聴する短いクリップと、大型テレビで見る長編映画とでは求められるものが違います。前者では微細な描写を残すことより、すぐ読み込めてモバイルデータ通信量を抑えられることが大切かもしれません。後者では画質が最優先になることがあります。

モバイル向けの短い動画では、ファイルが小さいと次の利点があります。

再生開始前に転送するデータを減らせる。
通信速度に制約がある場合、ダウンロードが早く終わる可能性がある。
端末上で必要な保存容量が少ない。
利用者のモバイルデータ通信量を減らせる。
エンコード後のビットレートが低ければ、通信速度が低い環境でも再生が安定しやすくなる場合がある。

ただし、ファイルが小さければ動画が絶対にバッファリングや停止を起こさない、というわけではありません。ネットワークの変動、ピークビットレート、サーバーの動作、再生バッファー、端末のデコード性能も影響します。

モバイル端末との互換性は拡張子だけで決まりません。ハードウェアデコード、コーデックのプロファイルとレベル、ビット深度、クロマサブサンプリング、解像度、フレームレート、ピークビットレートが重要です。幅390 CSSピクセルで表示する動画も、高密度のスマートフォン画面では実際にははるかに多くの物理ピクセルを使うことがあります。そのため、390ピクセル幅に縮小したフレームを確認することが、同じ端末で元動画を視聴することと同じとは限りません。実機と実際の再生条件で確認してください。

CRFが制御するのは画質であり、最大ビットレートを正確に制限するものではありません。総ファイルサイズが小さくても、複雑な映像では大きなビットレートのピークが発生し得ます。特に低速な回線でも安定再生させる必要があるなら、明示的なビットレート制限やVBV制約、適切な解像度制限、実際に近いネットワーク条件でのテストを検討してください。

原則は単純です。抽象的な最高画質ではなく、想定する視聴体験に合わせて最適化することです。

6. x264のCRFを理解する：低いほど高画質、高いほど小容量

H.264を選んだら、次はどの程度強く圧縮するかを決めます。

x264のCRF（Constant Rate Factor、固定品質係数）は、映像の細部をどれだけ残すかとファイルサイズのバランスを調整する設定です。

一般にCRFを低くすると高画質でファイルは大きくなり、高くすると圧縮による画質低下が増える代わりに小さくなります。

CRFは正確なビットレートや出力サイズを指定するものではありません。エンコーダーは素材に応じてビットを割り当てるため、単純な場面と細部の多い場面では、同じCRFでもファイルサイズが大きく違うことがあります。

また、CRFそのものがデコーダーの基本的な互換性を決めるわけではありません。CRF 22とCRF 30で適切にエンコードされた2本のH.264動画は、コーデック、プロファイル、レベル、ピクセル形式、解像度、フレームレートが同じ場合があります。

主な違いは、圧縮後の画質とビットレートの特性です。

重要なのは、異なるコーデックの実装間でCRFの数値を直接比較できないことです。x264のCRF 30とAV1エンコーダーのCRF 30が、同じ見た目の画質になるとは限りません。

7. 実際の圧縮実験：CRF 22から32まで

通常の再生中に違いが気になるまで、どれだけ圧縮できるかを確かめたかったのです。

すでに圧縮された短い動画を1本用意し、CRF 22、24、26、28、29、30、31、32でH.264の比較用ファイルを作成しました。

解像度、フレームレート、再生時間、フレーム数など、動画の主要な特性は維持しました。CRF変更の影響を比較できるよう、エンコーダー設定も統一しました。

ファイルサイズには大きな差が出ました。

CRF	元ファイルに対するおおよそのサイズ	意味
22	63%	控えめな圧縮で、細部がよりよく残る
24	49%	追加の画質低下を比較的小さく抑えて容量を削減
26	38%	多くの細部を残しながらさらに削減
28	30%	元動画との類似度が比較的高い小容量の出力
29	26%	より強い圧縮
30	23%	今回の素材で私が選んだ折衷案
31	21%	元動画への忠実度を下げてさらに削減
32	19%	テスト内で最小サイズ、測定上の画質低下が最大

これらの割合はテストした元動画に基づくもので、任意の動画で一般的に得られる削減率ではありません。また表の百分率はそれぞれ独立に丸めています。正確な相対削減率は、丸めた割合を割り算するのではなく、元のファイルサイズから計算してください。

最も意外だったのは、大型のデスクトップモニターでさえ、通常再生ではCRF 22とCRF 30の間に意味のある画質差を感じられなかったことです。

CRF 32を含む、さらに強く圧縮した版も調べましたが、そのクリップを普通に再生したときには大きな違いに気づきませんでした。

これは重要な観察でした。そもそもこれらの動画は、主に小さなモバイル画面で視聴される想定だったからです。デスクトップモニターでも画質低下が気にならないのであれば、想定する視聴体験を改善しない細部を残すために、ファイルサイズを大幅に増やす理由はほとんどありませんでした。

ただし、この結果は特定の種類の素材に対する主観的な観察です。すべての利用者、スマートフォン、動画で同じになると証明したわけではありません。高密度の画面を近距離で見ると、特に細部やグラデーションの圧縮ノイズが目立つ可能性があります。

8. 客観指標では画質低下が実際に確認された

再生中に差が見えないことは、2本の動画が数学的に同一であることを意味しません。

エンコード結果を客観的な画質指標でも比較しました。CRFが高くなるほど、元動画との類似度は下がりました。

高精細なモバイル画面での表示を近似するため、同じ条件で縮小した比較における代表的なSSIM値は次のとおりです。

CRF	おおよそのSSIM	CRF 28に対する出力サイズ
22	0.9934	2.13×
28	0.9869	1.00×
30	0.9837	0.79×
32	0.9795	0.63×

傾向は明確です。圧縮を強くするほど、測定上の忠実度は下がりました。細かく見ると、細い線や質感にも微妙な差がありました。

それでも、テストした動画の通常視聴での印象は非常によく似ていました。だからこそ、客観指標と主観評価を併用する意味があります。

SSIMが測るのは画像の類似度であり、人間の視聴体験のすべてではありません。時間方向のノイズ、知覚されるシャープさ、動きの見え方、特定の細部をどれだけ重要と感じるかまでは完全には反映できません。

VMAFも有用な知覚画質指標です。Netflixは2026年6月にVMAF v1モデルを公開し、その中にはスマートフォンでの視聴条件を想定したモデルもあります。これらは画面サイズや相対的な視聴距離が知覚画質に影響することを明示的に考慮しています。

調査中の控えめに圧縮したサンプルでは、平均VMAFが約95と報告されました。ただし、圧縮の強いCRF設定すべてについて一貫したVMAF測定系列が得られたわけではありません。そのためCRF 30や32が普遍的な画質基準を満たした、という主張にはVMAFを使っていません。

実用的な結論はもっと限定的です。今回テストした短い動画は、通常再生において強いH.264圧縮にも非常によく耐えたということです。

9. モバイル向け短編動画にCRF 30を選んだ理由

比較の結果、主にモバイル端末で視聴する同種の短い動画にはCRF 30を採用しました。

理由は次のとおりです。

短い動画であり、映画のような画質を提供する目的ではなかった。
速い読み込みと小さなダウンロードサイズが重要だった。
大型デスクトップモニターでもCRF 22と30の意味のある違いを感じなかった。
CRF 30は控えめな設定よりはるかに小さいファイルを生成した。
今回のサンプルではCRF 32も視覚的には許容できたが、複雑な素材での結果にはより不安が残った。

テストした出力では、CRF 30はCRF 28に対してファイルサイズが約21%小さくなり、CRF 22に対しては60%超小さくなりました。

心地よい画質、速い読み込み、適度な通信量が目的のモバイル向け短編動画であれば、十分に価値のあるトレードオフでした。

ただし前提は極めて重要です。30を選んだのは実際の視聴目的とテスト素材の結果によるもので、30がスマートフォン向けの本質的に最適なCRFだからではありません。

モバイル端末がCRF 30を必要としているわけではありません。もっと忠実度の高いエンコードでも問題なく表示できます。CRF 30は、その交換条件が許容できる場合に限り、元動画への忠実度の一部を小さなファイルと引き換える意図的な選択です。

内容の大きく異なる動画集に適用する前には、複雑な動き、暗い場面、グラデーション、文字、細かな質感を含む代表的なクリップを複数テストします。

10. 映画や高品質動画にCRF 30を勧めない理由

ここが今回の実験で最も重要な限界です。

私のCRF 30という結果を、長編映画、高品質な映像作品、プロ向け映像、大画面で見る動画にそのまま当てはめないでください。

そうした素材には、微妙なグラデーション、フィルムグレイン、暗所の場面、複雑な動き、細かい表面の質感、慎重にカラーグレーディングされた色が含まれることがあります。わずかな通信量削減より、それらを守ることが重要かもしれません。

一般的な高品質1080p動画なら、私はまずCRF 20前後という、より控えめなx264設定から始め、素材に応じて上下の値を試します。

画質の忠実度が重要なら、CRF 18～22が実用的な初期範囲になるでしょう。ただし、解像度、素材、要件によって適切な値はこの範囲外にもなり得ます。

この提案は一般に公開されているエンコード指針とも整合します。たとえばHandBrakeの画質設定ドキュメントでは、多くの1080p x264用途についてRF 20～24前後を推奨しています。

長編映画や高品質な映画映像で同じ統制実験を行ったわけではありません。したがって、CRF 20が常に最適だ、CRF 22で必ず十分だ、特定の映画はCRF 30では見られない画質になる、といった主張はできません。

正しい手順は、代表的なシーンを選び、複数の画質設定でエンコードし、想定するディスプレイで比較して、これ以上圧縮すると目に見える問題が出る境界を判断することです。

アーカイブや再編集、将来の再エンコードに使うなら、配信用に圧縮した版とは別に高品質なマスターを保存すべきです。

11. x264のveryslowプリセットを使った理由

CRFが圧縮品質の一面を調整するのに対し、x264のプリセットは、効率のよい符号化方法を探すためにエンコーダーがどれだけ処理を行うかを決めます。

x264には非常に速いものから非常に遅いものまで複数のプリセットがあります。一般に遅いプリセットほどCPU時間を使い、同程度の見た目の画質で圧縮効率を高められる場合があります。

同じ素材でmediumとveryslowを比較したところ、今回試した画質設定ではveryslowのほうが小さなファイルになりました。

一度だけオフラインでエンコードし、何度も再利用するなら、追加の処理時間をかける価値があります。

そのため-preset veryslowを選びました。

ただし、あらゆる場合に最適というわけではありません。動画を即座に処理する必要がある場合、CPUコストが高い場合、大量の未処理ファイルがある場合は、slowやmediumのほうが運用上のバランスがよいでしょう。

プリセットが主に変えるのはエンコード処理の複雑さと圧縮効率です。H.264が別のコーデックに変わるわけでも、完成ファイルがモバイル端末で本質的に再生できなくなるわけでもありません。

12. アニメ動画にはx264のanimationチューニングを使う

手描きアニメーションやアニメ調の映像には、x264の-tune animationを使います。

これはCRFとは別の設定です。チューニングは特定の映像特性に合わせてエンコーダーの判断を調整します。animationチューニングは、描画された輪郭、単色の領域、様式化された動きがある素材を想定しています。

そのため、私は次のように使い分けています。

アニメや描画されたアニメーション：-preset veryslow -tune animationを使う。
一般的な実写映像：animationチューニングを自動的に有効にせず、標準設定から始めるか、別の適切なチューニングを検討する。

ただし効果を誤解してはいけません。-tune animationを使えば必ず見た目がよくなったりファイルが小さくなったりするわけではありません。エンコーダーの動作が変わるだけで、結果は素材によります。

別途、CRFを固定してanimationチューニングの有無を比較しました。この条件では、チューニングを有効にするとファイルが約6%大きくなり、測定した画像の類似度はわずかに改善しました。見た目の差は小さいものでした。

CRF 22～32の主要なサイズ比較ではanimationチューニングを使っていません。したがって、その実験の正確なサイズや圧縮率が、-tune animationを有効にしても同じになると考えるべきではありません。

それでも、アニメ映像では専用のチューニングを選び、その素材のエンコード設定の一部としてサイズと画質を評価する方針です。

エンコーダーのチューニングは、普遍的な画質向上策ではなく、素材に応じた調整として扱うべきです。

13. モバイル向けの短いアニメ動画に使うFFmpeg設定

実際に再エンコードが必要な一般的なSDRアニメ動画について、私が初期設定として使うのは次のコマンドです。

ffmpeg -i input.mp4 \
  -map 0:v:0 -map '0:a:0?' \
  -c:v libx264 \
  -preset veryslow \
  -tune animation \
  -crf 30 \
  -profile:v high \
  -pix_fmt yuv420p \
  -c:a aac -b:a 128k \
  -movflags +faststart \
  output.mp4

このコマンドでは、主要な設定を明示しています。

-c:v libx264：ソフトウェアのH.264エンコーダーを使う。
-preset veryslow：処理速度より圧縮効率を優先する。
-tune animation：アニメーション向けのエンコーダー調整を有効にする。
-crf 30：この種の短編動画に選んだ強めの固定品質目標を設定する。
-profile:v high：現代の端末で広く対応しているH.264プロファイルを指定する。
-pix_fmt yuv420p：8ビットの4:2:0映像を出力する。
-map 0:v:0：最初の動画ストリームを選択する。
-map '0:a:0?'：最初の音声ストリームがあれば選択する。
-c:a aac -b:a 128k：音声がある場合に一般的なAAC音声としてエンコードする。
-movflags +faststart：MP4の初期化メタデータをファイル先頭付近に移す。

あくまで一例であり、どんな入力にもそのまま使える万能なコマンドではありません。元動画の条件によっては追加の処理が必要です。

特にHDRや10ビットの素材を、適切な色管理なしで安易に8ビットSDRへ変換してはいけません。色の誤り、ハイライト情報の消失、目立つバンディングを招く場合があります。回転メタデータ、可変フレームレート、サンプルアスペクト比、インターレース映像、特殊な音声チャンネル構成、解像度の制限にも注意が必要です。

元動画のフレームレートと寸法がすでに適切なら、通常はそのまま維持したほうが比較しやすく、不要なリサイズや動きの変化を避けられます。必要がないのに可変フレームレートの素材を固定フレームレートへ変換すると、フレームの複製や間引きが発生することがあります。リサイズする際は表示アスペクト比を維持し、選んだ4:2:0ピクセル形式に合う寸法にしてください。非常に高い解像度、フレームレート、H.264レベルは古い端末のデコード能力を超える場合があるため、互換性確保には解像度やフレームレートを意図的に下げる必要もあります。

14. 高品質動画向けの、より控えめなFFmpeg初期設定

ファイルサイズより元映像への忠実度がはるかに重要なら、低めのCRFから始めて結果を評価します。

たとえば一般的なSDR実写映像なら、次の設定が試験用の妥当な出発点になります。

ffmpeg -i input.mp4 \
  -map 0:v:0 -map '0:a:0?' \
  -c:v libx264 \
  -preset slow \
  -crf 20 \
  -profile:v high \
  -pix_fmt yuv420p \
  -c:a aac -b:a 192k \
  -movflags +faststart \
  output.mp4

この例のslowは汎用的な初期設定であり、veryslowより優れているという意味ではありません。追加の処理時間を許容できるならveryslowも合理的です。

この高画質用設定はテストを勧めるためのもので、私の短編動画の実験で有効性が証明された設定ではありません。

高品質な映像なら、まずCRF 18、20、22前後を試し、見た目で選んでください。扱いの難しい粒状ノイズや動きには別の設定が必要な場合があり、保存用マスターにははるかに控えめな圧縮が必要なこともあります。

15. 理由がないなら動画を再エンコードしない

非可逆圧縮には代償があります。すでに圧縮された動画を再エンコードすると、新しい出力が元と似て見えても、圧縮ノイズが追加される可能性があります。

変換する前に、元ファイルが互換性、サイズ、画質の要件をすでに満たしていないか確認してください。

既存の動画が対応するH.264映像とAAC音声を含み、映像を加工する必要がないなら、もう一度非可逆圧縮するよりストリームコピーが適している場合があります。

ffmpeg -i input.mp4 \
  -map 0:v:0 -map '0:a:0?' \
  -c copy \
  -movflags +faststart \
  output.mp4

この操作は圧縮済みストリームを再エンコードせずにコピーします。コンテナ内の配置を変えながら、再圧縮による追加の画質低下を避けられます。

ただし、画質を落として再エンコードする場合ほどファイルサイズが小さくなることは、通常ありません。

既存の動画が十分に小さく、互換性もあり、画質にも満足できるなら、そのまま使うことが最善の最適化かもしれません。

16. ファイルサイズだけで判断せず、エンコード結果を検証する

FFmpegが正常終了しても、その動画がすべての要件を満たすと証明されたわけではありません。

まずFFprobeで出力ストリームを調べます。

ffprobe -v error \
  -show_entries stream=codec_name,profile,pix_fmt,width,height,avg_frame_rate,nb_frames:format=duration,size \
  -of json output.mp4

コーデック、ピクセル形式、寸法、フレームレート、再生時間、音声ストリームを確認してください。

次に出力全体をデコードし、一部の破損や復号エラーを検出します。

ffmpeg -v error -xerror -i output.mp4 -f null -

圧縮実験では同じ元動画から作成した出力同士を比較してください。重要な条件を一定に保ち、一度に変更する主要設定は1つにします。

動画を動きのある状態で再生し、細部も確認して、グラデーション、暗部、動く物体、文字に注目します。

可能ならSSIM、PSNR、VMAFなどの客観指標も目視比較の補助に利用します。ただし高いスコアが1つ出たからといって、すべての圧縮ノイズが見えない証拠にはなりません。

最後に、代表的な端末での再生と、ダウンロード後の利用もテストしてください。ブラウザーの対応情報は有用ですが、互換性を重視するなら実機での確認が特に重要です。

17. MP4ファイルを正しく配信する

エンコード設定がよくても、Web配信の設定が悪ければ補えません。

一般的なプログレッシブ方式のMP4再生では、適切なContent-Type: video/mp4ヘッダーを設定し、部分取得やシークが必要な場合はHTTPバイト範囲リクエストに対応させます。

FFmpegの+faststartは、通常のMP4ファイルの初期化情報を先頭付近に移動します。プログレッシブ読み込みには役立ちますが、画質を高めたりビットレートを下げたりする効果はありません。

基本的なHTMLの動画要素でH.264のMP4を1つ配信できます。

<video controls playsinline preload="metadata">
  <source src="/media/video.mp4" type="video/mp4">
</video>

preload属性はブラウザーへのヒントであり、ダウンロード量の厳密な上限ではありません。また、自動再生のポリシーによっては、動画をミュートするか無音にする必要があります。

1ページに複数の動画があるなら、最初から全部をダウンロードさせないでください。必要なときだけ読み込めば、モバイル通信量を減らし、体感上の応答性を改善できる場合があります。

モバイル向けの短い動画では、ダウンロードを開始するタイミングの最適化も、ファイルサイズ削減と同じくらい重要になり得ます。

18. どの動画形式と画質を選ぶべきか

何を最優先するかによって答えは変わります。

目的	推奨する出発点
Web再生とダウンロードの両方で幅広く使える1種類のファイル	MP4 + H.264 + AAC（音声がある場合）
複数の形式を使える最新ブラウザー向け配信	AV1またはVP9、H.264へのフォールバックを用意
対応端末での最大限の圧縮	AV1を評価する
HEVC対応を管理できる再生環境	MP4 + HEVCを検討する
容量を最優先するモバイル向け短編動画	代表的な素材で試したうえでx264 CRF 30を検討する
アニメ・描画された映像	`-tune animation`を使ったx264を評価する
高品質な映画・映像	CRF 20前後の控えめな値からテストする
CPU時間を重視しないオフラインエンコード	x264の`slow`または`veryslow`を検討する
高速処理が必要でCPU資源が限られる	x264の`medium`または`slow`を検討する
既存動画が要件を満たしている	そのまま使うか、再エンコードせずにリマックスする
保存・将来の再編集	配信用ファイルとは別に高品質なマスターを残す

19. 最終的な選択と、実験から本当に分かったこと

動画形式、互換性、エンコード効率、実際の圧縮結果を調べたうえで、モバイル向け短編動画の実用的な配信設定を選びました。

形式はH.264のMP4です。新しいコーデックで最小サイズを狙うよりも、ブラウザー、スマートフォン、ダウンロード、外部アプリで予測どおりに再生できることを重視しました。

エンコーダーはlibx264とveryslowプリセットです。オフラインで処理でき、追加の時間を許容できたからです。

アニメ動画ではanimationチューニングを使用します。ただし、これはエンコーダーの動作を変えるもので、ファイルの縮小や画質の普遍的な改善を保証しないと理解しています。

モバイル向け短編動画ではCRF 30を選びました。大型のデスクトップモニターで比較しても、通常再生で意味のある画質差を感じない一方、ファイルサイズを大幅に削減できたからです。

これは映画や高品質映像にCRF 30が最適という意味ではありません。細部、グラデーション、粒状感、映像全体の忠実度がより重要なら、CRF 20前後などの控えめな値からテストします。映画映像について同等の統制実験は行っていないため、その数値が実験的に最適と証明されたものだとは述べません。

最も重要な結論は、すべての動画に共通する唯一の最適なコーデック、形式、CRF値は存在しないということです。

互換性を最大限重視し、ファイルを1種類にしたいなら、MP4/H.264は有力な初期選択です。フォールバックを提供でき、圧縮効率を高めたいならVP9やAV1を検討してください。スマートフォンで主に見る短い動画では、CRFを高くしても目的の視聴体験を損なわず十分小さくできるか試しましょう。映画や高品質な映像では、より控えめな画質設定を使い、慎重に確認してください。

まず再生要件を決め、次にコーデックを選び、最後に圧縮画質を設定します。そして、本当に重要な端末と条件で結果をテストしてください。新しいから、効率がよいから、一般に勧められているからという理由だけでコーデックやCRFを採用するより、はるかに確実な方法です。