FFmpeg 動画圧縮のベストプラクティス——実測で見る完全ガイド

FFmpeg の動画圧縮は結局 3 つのつまみ——CRF（品質）、preset（速度）、コーデック（効率）——のバランスです。本ガイドは CRF の理論から 2-pass エンコード、H.264 vs H.265 vs AV1 ベンチマーク、実シナリオ（Web / SNS / アーカイブ / HLS）まで踏み込み、すべてコピペで動くコマンド付きで解説します。

CRF（Constant Rate Factor）を理解する

CRF は品質ベース圧縮で最重要の設定。「視覚品質を一定に保て、ビットレートは必要に応じて変動させていい」とエンコーダに伝えるパラメータです。CRF 低 = 高品質 = ファイル大。CRF 高 = 低品質 = ファイル小。

H.264（libx264）の CRF 値

ffmpeg -i input.mp4 -c:v libx264 -crf 23 output.mp4

H.264 の CRF レンジは 0（ロスレス）〜 51（最低品質）。値ごとの傾向：

CRF	品質レベル	典型的な用途	ファイルサイズ（CRF 23 比）
0	ロスレス	アーカイブ、編集マスター	10〜50 倍
14	ニアロスレス	プロのポスプロ	4〜6 倍
18	視覚的にロスレス	高品質配信、プレミアムストリーム	2〜3 倍
20	優秀	高品質 Web 動画	1.5〜2 倍
23	良好（デフォルト）	汎用、Web 配信	1 倍（基準）
26	許容範囲	SNS、モバイル配信	0.5〜0.7 倍
28	やや低	帯域制約のある配信	0.3〜0.5 倍
32	低	プレビュー、サムネイル	0.15〜0.25 倍
40	非常に低	極端な圧縮（ギリギリ視聴可）	0.05〜0.1 倍
51	最低	使うな	極小

多くの用途でのスイートスポットは CRF 18〜28。 18 未満は、ほとんどの視聴者が知覚できない品質差にビットを使っているだけ。28 を超えるとアーティファクトが見えてきます。

H.265（libx265）の CRF 値

H.265 は H.264 と同じ視覚品質をだいたい 40〜50% 低いビットレートで達成できます。ただし CRF スケールがずれる：H.265 の CRF 28 ≒ H.264 の CRF 23 くらい。

ffmpeg -i input.mp4 -c:v libx265 -crf 28 output.mp4

CRF（H.265）	H.264 CRF 換算	品質レベル
18	約 14	ニアロスレス
22	約 18	視覚的にロスレス
24	約 20	優秀
28	約 23	良好（デフォルト）
32	約 26	許容範囲
36	約 30	低

適切な CRF をどう選ぶか

実用的な手順：

1. デフォルトで始める（H.264 なら 23、H.265 なら 28）
2. 出力を確認——品質に納得できるか？
3. ±2〜4 のレンジで調整
4. A/B テスト——同じ複雑シーンを 2 つの CRF でエンコードして比較

圧縮アーティファクトが目立つシーンは：速い動き、細かいテクスチャ（草、布）、グラデーション（空、霧）、ディテールの細かい暗いシーン。初心者向け解説は FFmpeg で動画を圧縮するガイド を参照。

エンコードプリセット：速度 vs 品質

FFmpeg の preset パラメータは、エンコーダが圧縮最適化に CPU 時間をどれだけ使うかを指定します。遅いプリセットほど圧縮が良くなる（同じ品質で小さいファイル）が、エンコード時間が伸びる。

H.264 プリセットのベンチマーク

すべて CRF 23、1080p 60fps の 2 分動画で計測：

Preset	エンコード時間	ファイルサイズ	品質（VMAF）
ultrafast	15s	85 MB	92.1
superfast	22s	62 MB	93.8
veryfast	30s	48 MB	94.5
faster	40s	42 MB	95.0
fast	52s	38 MB	95.3
medium	70s	35 MB	95.5
slow	120s	33 MB	95.7
slower	210s	31 MB	95.8
veryslow	450s	30 MB	95.9
placebo	1800s	29.5 MB	95.9

ポイント：

• medium がデフォルト、ワークフロー上のスイートスポット
• medium → slow でファイルサイズ約 6% 削減、時間は 70% 増
• medium → veryslow で約 14% 削減、時間は 6.4 倍
• placebo は veryslow とほぼ同じ——使うな
• ultrafast は medium より 2.4 倍デカいファイルを作る——本番納品に使うな

# Good default for most use cases
ffmpeg -i input.mp4 -c:v libx264 -crf 23 -preset medium output.mp4

# When encoding time matters more than file size
ffmpeg -i input.mp4 -c:v libx264 -crf 23 -preset fast output.mp4

# When file size matters more than encoding time
ffmpeg -i input.mp4 -c:v libx264 -crf 23 -preset slow output.mp4

H.265 プリセットの挙動

H.265 もプリセット名は同じだが、各段階でエンコードがかなり遅い：

Preset	H.264 時間	H.265 時間	H.265 ファイルサイズ
fast	52s	180s	25 MB
medium	70s	300s	22 MB
slow	120s	600s	20 MB

H.265 は同じプリセットで H.264 の約 3〜5 倍時間がかかるが、同等品質で 30〜40% 小さいファイルになる。

2-pass エンコード

2-pass はビットレート（つまり最終ファイルサイズ）を精密に制御したいとき必須——「この動画は 50MB 以下に収めたい」みたいな指定がある場合。

仕組み

• Pass 1：FFmpeg が動画を解析して複雑度ログを書き出す
• Pass 2：そのログをもとに、複雑なシーンに多くのビット、単純なシーンに少なめのビットを割り当てる

基本コマンド

# Pass 1 — analyze (output is discarded)
ffmpeg -i input.mp4 -c:v libx264 -b:v 4M -pass 1 -f null /dev/null

# Pass 2 — encode using analysis data
ffmpeg -i input.mp4 -c:v libx264 -b:v 4M -pass 2 output.mp4

目標ビットレートの計算

目標ファイルサイズに収めたいとき：

動画ビットレート = (目標サイズ bit - 音声 bit) / 動画長 (秒)

例：10 分の動画、目標 100MB、音声 128kbps：

Audio size = 128,000 bps × 600s = 76,800,000 bits = 9.6 MB
Video bitrate = (100 MB - 9.6 MB) × 8,000,000 / 600 = 1,205,333 bps ≈ 1.2 Mbps

ffmpeg -i input.mp4 -c:v libx264 -b:v 1200k -pass 1 -c:a aac -b:a 128k -f null /dev/null
ffmpeg -i input.mp4 -c:v libx264 -b:v 1200k -pass 2 -c:a aac -b:a 128k output.mp4

CRF vs 2-pass：どっちを使う？

方式	向いてる場面	制御軸
CRF	一定品質、サイズは気にしない	品質ベース
2-pass	サイズ／ビットレートをピン留め	サイズベース
CRF + maxrate	品質維持＋ビットレート上限	ストリーミング向け

ストリーミング用にビットレート上限を付けたいとき：

ffmpeg -i input.mp4 -c:v libx264 -crf 23 -maxrate 4M -bufsize 8M output.mp4

CRF 23 の品質を狙いつつ 4 Mbps で頭打ちにする——帯域が限られるストリーミングで使えます。

コーデック比較：H.264 vs H.265 vs VP9 vs AV1

正しいコーデック選びは、圧縮効率・エンコード速度・再生互換性のトレードオフです。

圧縮効率

同じ視覚品質（VMAF 95）での相対ファイルサイズ：

コーデック	相対ファイルサイズ	H.264 比の圧縮率
H.264（libx264）	100%	基準
H.265（libx265）	55〜65%	35〜45% 小
VP9（libvpx-vp9）	55〜65%	35〜45% 小
AV1（libaom-av1）	40〜50%	50〜60% 小

エンコード速度

1080p 60fps ソースを同等品質でエンコードしたときの相対時間：

コーデック	エンコード時間（相対）	注
H.264	1 倍	高速、最適化が進んでる
H.265	3〜5 倍	目に見えて遅い
VP9	5〜10 倍	非常に遅い（デフォルトでシングルスレッド）
AV1（libaom）	20〜50 倍	極端に遅い
AV1（SVT-AV1）	3〜8 倍	AV1 のはるかに速い実装

再生互換性（2026 年）

コーデック	ブラウザ	モバイル	スマート TV	ハードウェアデコード
H.264	99%+	99%+	99%+	ほぼすべて
H.265	Safari、Edge（一部）	iOS、Android 5+	多くのモダン機	一般的
VP9	Chrome、Firefox、Edge	Android 5+	限定的	増えつつある
AV1	Chrome、Firefox、Edge、Safari 17+	フラッグシップ機	限定的	出てきた段階

実用コマンド

# H.264 — maximum compatibility
ffmpeg -i input.mp4 -c:v libx264 -crf 23 -preset medium -c:a aac -b:a 128k output.mp4

# H.265 — 40% smaller, good mobile support
ffmpeg -i input.mp4 -c:v libx265 -crf 28 -preset medium -c:a aac -b:a 128k output.mp4

# VP9 — royalty-free, good for web
ffmpeg -i input.mp4 -c:v libvpx-vp9 -crf 30 -b:v 0 -row-mt 1 -c:a libopus -b:a 128k output.webm

# AV1 (SVT-AV1) — best compression, modern devices
ffmpeg -i input.mp4 -c:v libsvtav1 -crf 30 -preset 6 -c:a libopus -b:a 128k output.mp4

どのコーデックを選ぶか

シナリオ	推奨コーデック	理由
最大限の互換性	H.264	どこでも再生できる
帯域節約 + Apple エコシステム	H.265	圧縮良好、iOS/macOS でネイティブ
Web 中心 + ロイヤリティフリー	VP9	Chrome/Firefox 対応、ライセンス料なし
将来性 + 最高圧縮	AV1（SVT-AV1）	50% 以上削減、対応拡大中
観衆混在	H.264 + H.265/AV1 フォールバック	デバイス別に最適コーデック配信

コンテナ形式の切り替えについては 動画フォーマット変換ガイド を参照。

解像度スケーリングのベストプラクティス

解像度を「単に変える」だけではダメな話です。

代表的な解像度

名称	解像度	典型的なビットレート（H.264）	典型的なビットレート（H.265）
4K UHD	3840x2160	15〜30 Mbps	8〜15 Mbps
1440p	2560x1440	8〜15 Mbps	4〜8 Mbps
1080p Full HD	1920x1080	4〜8 Mbps	2〜4 Mbps
720p HD	1280x720	2〜4 Mbps	1〜2 Mbps
480p SD	854x480	1〜2 Mbps	0.5〜1 Mbps
360p	640x360	0.5〜1 Mbps	0.3〜0.5 Mbps

アスペクト比を保ったスケーリング

片方の次元には -1 を、もう片方が偶数になるように -2 を使う（多くのコーデックが偶数を要求する）：

# Scale to 720p width, auto-calculate height (divisible by 2)
ffmpeg -i input.mp4 -vf "scale=1280:-2" -c:v libx264 -crf 23 output.mp4

# Scale to 1080 height, auto-calculate width
ffmpeg -i input.mp4 -vf "scale=-2:1080" -c:v libx264 -crf 23 output.mp4

スケーリングフィルタの品質

FFmpeg は複数のスケーリングアルゴリズムを持ちます。デフォルト（bilinear）はだいたいこれで十分ですが、品質重視のダウンスケールには Lanczos：

# High-quality downscale with Lanczos
ffmpeg -i input.mp4 -vf "scale=1280:720:flags=lanczos" -c:v libx264 -crf 23 output.mp4

アルゴリズム	速度	ダウンスケール品質	向いてる用途
fast_bilinear	最速	低	リアルタイム処理
bilinear	速い	中	デフォルト、汎用
bicubic	中	良	中程度の品質要求
lanczos	やや遅い	最良	最終納品、品質重視
spline	やや遅い	優秀	Lanczos の代替

アップスケールするな

原則、動画のアップスケールはやらない。720p ソースを 1080p でエンコードするのは、実ディテールを増やさないまま帯域を浪費するだけ。どうしても必要なときは最小限に、Lanczos で：

# If you must upscale (avoid when possible)
ffmpeg -i input_720p.mp4 -vf "scale=1920:1080:flags=lanczos" -c:v libx264 -crf 20 output.mp4

音声圧縮

動画圧縮の話で音声は見落とされがちですが、最適化すると帯域がだいぶ浮きます。

推奨設定

用途	コーデック	ビットレート	コマンド
一般 Web 動画	AAC	128 kbps	-c:a aac -b:a 128k
高品質動画	AAC	192 kbps	-c:a aac -b:a 192k
音楽中心	AAC	256 kbps	-c:a aac -b:a 256k
WebM/VP9 動画	Opus	128 kbps	-c:a libopus -b:a 128k
ポッドキャスト／話声	AAC	64 kbps	-c:a aac -b:a 64k
ポッドキャスト／話声（Opus）	Opus	48 kbps	-c:a libopus -b:a 48k

ラウドネス正規化

動画間の音量がバラバラなのはあるあるな問題。FFmpeg の loudnorm フィルタで放送基準に正規化：

# Normalize to -16 LUFS (standard for streaming)
ffmpeg -i input.mp4 -c:v copy -af "loudnorm=I=-16:TP=-1.5:LRA=11" -c:a aac -b:a 128k output.mp4

音声を捨てる

音声が要らないとき：

ffmpeg -i input.mp4 -an -c:v libx264 -crf 23 output.mp4

音声を再エンコードしないでコピー

音声がすでに適したフォーマットなら：

ffmpeg -i input.mp4 -c:v libx264 -crf 23 -c:a copy output.mp4

現場で使う圧縮シナリオ

Web 配信（汎用）

最も多いシナリオ——サイト埋め込み用の圧縮：

ffmpeg -i input.mp4 \
  -c:v libx264 -crf 23 -preset medium \
  -vf "scale=1920:1080:flags=lanczos" \
  -c:a aac -b:a 128k \
  -movflags +faststart \
  output.mp4

ポイント：

• -movflags +faststart でメタデータをファイル先頭に移動。プログレッシブ再生が可能になる（Web では必須）
• CRF 23 は品質とサイズのバランスが良い
• AAC 128k は Web コンテンツとしては十分

SNS 向け最適化

Twitter/X、Instagram、TikTok などプラットフォームごとの要件：

# Optimized for social platforms (H.264, AAC, fast start)
ffmpeg -i input.mp4 \
  -c:v libx264 -crf 23 -preset medium \
  -profile:v high -level:v 4.0 \
  -pix_fmt yuv420p \
  -vf "scale=1080:1920:force_original_aspect_ratio=decrease,pad=1080:1920:(ow-iw)/2:(oh-ih)/2" \
  -c:a aac -b:a 128k -ar 44100 \
  -movflags +faststart \
  output.mp4

• -profile:v high -level:v 4.0 で広い互換性を担保
• -pix_fmt yuv420p で全デバイス再生を保証
• scale + pad フィルタでレターボックス付き 9:16 縦動画を作る

アーカイブ（最高品質、最小ロス）

長期保存でファイルサイズを気にしない場合：

ffmpeg -i input.mp4 \
  -c:v libx264 -crf 16 -preset slow \
  -c:a flac \
  output.mkv

• CRF 16 で視覚的なディテールをほぼすべて保持
• FLAC はロスレス
• MKV は MP4 より多くのコーデックに対応

ストリーミング（HLS の ABR）

ABR ストリーミング用に複数品質を生成：

ffmpeg -i input.mp4 \
  -map 0:v -map 0:a -map 0:v -map 0:a -map 0:v -map 0:a \
  -c:v libx264 -crf 22 \
  -c:a aac -b:a 128k \
  -var_stream_map "v:0,a:0 v:1,a:1 v:2,a:2" \
  -b:v:0 5M -maxrate:v:0 5.5M -bufsize:v:0 10M -s:v:0 1920x1080 \
  -b:v:1 2.5M -maxrate:v:1 2.75M -bufsize:v:1 5M -s:v:1 1280x720 \
  -b:v:2 1M -maxrate:v:2 1.1M -bufsize:v:2 2M -s:v:2 854x480 \
  -f hls -hls_time 6 -hls_list_size 0 \
  -master_pl_name master.m3u8 \
  stream_%v/playlist.m3u8

バッチ圧縮スクリプト

ディレクトリ内の全動画を処理：

#!/bin/bash
# 批量压缩目录下所有视频
for f in *.mp4; do
  ffmpeg -i "$f" \
    -c:v libx264 -crf 23 -preset medium \
    -c:a aac -b:a 128k \
    -movflags +faststart \
    "compressed_${f}"
done

FFHub でのクラウド圧縮

このガイドのコマンドは FFHub.io にそのまま投げて動きます：

# Compress a video in the cloud (no local FFmpeg needed)
curl -X POST https://api.ffhub.io/v1/tasks \
  -H "Authorization: Bearer YOUR_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "command": "ffmpeg -i https://example.com/input.mp4 -c:v libx264 -crf 23 -preset medium -c:a aac -b:a 128k -movflags +faststart output.mp4"
  }'

CPU を食うエンコードをクラウド側に逃がせるので、ローカルやアプリサーバーが楽になります。バッチ動画変換 や、アプリサーバーで FFmpeg を回すとパフォーマンスに響くケースで特に有効です。

クイックリファレンス

一行コマンド集

# Good default compression
ffmpeg -i input.mp4 -c:v libx264 -crf 23 -c:a aac -b:a 128k -movflags +faststart output.mp4

# Aggressive compression (smaller file)
ffmpeg -i input.mp4 -c:v libx264 -crf 28 -preset fast -c:a aac -b:a 96k output.mp4

# High-quality compression (larger file)
ffmpeg -i input.mp4 -c:v libx264 -crf 18 -preset slow -c:a aac -b:a 192k output.mp4

# Maximum compression with H.265
ffmpeg -i input.mp4 -c:v libx265 -crf 28 -preset medium -c:a aac -b:a 128k output.mp4

# Future-proof with AV1
ffmpeg -i input.mp4 -c:v libsvtav1 -crf 30 -preset 6 -c:a libopus -b:a 128k output.mp4

判断ツリー

1. 最大互換性が要る？ H.264 を使う
2. ファイルを小さくしたい？ H.265（Apple/モバイル）か VP9（Web）
3. 最小サイズで時間に余裕がある？ AV1
4. 目標サイズが決まってる？ 2-pass エンコード
5. 品質を一定にしたい？ CRF
6. 大量処理？ fast か veryfast
7. 重要な 1 本？ slow プリセット

まとめ

効果的な動画圧縮は、結局のところ品質（CRF）・速度（プリセット）・サイズ（コーデック選択）の 3 つのバランス。デフォルト（CRF 23、medium、H.264）から始めて、要件に応じて調整するのが王道です。実コンテンツでテストすること——トーキングヘッド動画とアクションシーンでは圧縮挙動がまったく違うので。

ここに載せたコマンドはすべて標準 FFmpeg。ローカル、サーバー、FFHub みたいなクラウドサービス、どこでも動きます。基本を押さえれば、任意の動画圧縮シナリオに対応できます。

よくある質問（FAQ）

ストリーミング動画には CRF をいくつにする？

HLS / DASH のアダプティブストリーミングなら CRF 21–23 と -maxrate、-bufsize の上限併用が標準です。CRF で複雑なシーンでも品質を保ち、ビットレート上限で視聴者のバンド幅を保護します。最高品質バリアントは CRF 23、中品質は CRF 24–25、最低品質は CRF 26–28。

2-pass エンコードと CRF、いつどちらを使う？

画質の一貫性が大事なら CRF（Web / アーカイブ用途のほぼ全て）。指定サイズに収める必要があるなら 2-pass（Discord の 25MB 上限、放送規格、広告仕様など）。2-pass は CRF の約 2 倍時間がかかりますが、サイズを精密に制御できます。画質優先でビットレート上限が必要なら、CRF と -maxrate、-bufsize の組み合わせが折衷案。

H.265 が H.264 よりずっと遅いのはなぜ？

H.265 は 30–40% の圧縮率優位を達成するために、フレームごとに より多くのブロックサイズ・予測モード・動きベクトルを評価します。HEVC 規格は H.264 より仕様上複雑で、複雑度と効率のトレードオフです。実測で libx265 -preset medium は同品質出力で libx264 -preset medium より 3–5 倍遅くなります。

AV1 は 2026 年に本番運用できる？

配信側は可能、ただし注意点あり。AV1 ハードウェアデコーダはフラッグシップスマホ、現行ゲーム機、Apple Silicon に普及していますが、古いデバイスは H.264 フォールバックが必要。エンコード側では SVT-AV1（libsvtav1）が実用的選択 —— 同品質で H.264 より 3–8 倍遅い、libaom-av1 の 20–50 倍遅いと比べたら使える速度。Netflix、YouTube、Vimeo はすでに対応クライアントに AV1 ストリームを配信しています。

異なるソースの動画をバッチ圧縮して画質を揃えるには？

CRF モードを使い、bitrate モードは使わない —— CRF は各ソースの複雑度に自動適応します。シンプルなシェルループ -c:v libx264 -crf 23 -preset medium -c:a aac -b:a 128k -movflags +faststart で混在入力に対して体感品質が揃った出力を生成。ファイルサイズの上限が必要なら -maxrate と -bufsize を上乗せ（例：-maxrate 4M -bufsize 8M）。

-preset slow で本当にファイルが小さくなる？

なります、ただし収益逓減。medium → slow で 同品質下 ~6% サイズ削減、エンコード時間 ~70% 増。medium → veryslow で ~14% 削減、エンコード時間 6.4 倍。placebo は veryslow とほぼ同等 —— placebo は使わない。実用的スイートスポット：medium（デフォルト）、slow（夜間バッチ、本番配信）、fast（リアルタイムやプロキシ用途）。

関連記事

• FFmpeg で動画を圧縮する方法 - 動画ファイルサイズ削減の入門ガイド
• FFmpeg で動画フォーマットを変換する方法 - MP4、MKV、WebM などコンテナを切り替える
• API での動画バッチトランスコード - クラウド API で大規模圧縮を自動化