現実世界を動かす技術をシェアしよう！～身近なものづくりから最先端テクノロジーまで大募集！～

FFmpeg による可逆圧縮の比較

Last updated at 2026-09-23Posted at 2026-07-29

はじめに

本記事は、FFmpeg（full-build版）がサポートする可逆圧縮（Lossless） ビデオコーデックのエンコード性能を、実動画を用いて比較・検証したものです。

計測には同一のテストスクリプトを使用し、圧縮率（元ファイルサイズ ÷ 圧縮後ファイルサイズ）、圧縮時間、品質指標（SSIM / VMAF） の 3 軸で評価しました。

本更新では YUV420測定 を導入し、元動画が yuv420p(rawvideo) であることを踏まえ、FFmpeg標準の品質評価フィルタである SSIM（libavfilter ssim） と VMAF（libvmaf） を用い、常に yuv420p に正規化して測定しています（fps=24,format=yuv420p,scale=out_chroma_loc=left:flags=bicubic）。これにより、RGB系や yuv422p系コーデックの色空間変換による不可逆性も評価できます。

さらに今回の再測定では、Netflixが2026年6月にリリースした VMAF v1 (vmaf_v1.0.16) を採用しています。従来の vmaf_v0.6.1 との差異については末尾の補足章を参照してください。

注意事項

本記事の検証は FFmpeg 9.0.2 full-build (gyan.dev) に限定しています
FFmpeg 以外の実装を使用した場合、結果が異なる可能性があります
エンコーダの性能は、入力動画の特性に大きく依存します。参考値としてご覧ください

ffmpeg がサポートする可逆圧縮エンコード

FFmpeg の full-build 版で利用可能な可逆圧縮エンコーダのうち、本テストで対象とした 10 種類を以下に示します。

エンコーダー名称	ffmpeg オプション	特徴	出力pix_fmt
FFV1	`-vcodec ffv1`	非可逆コーデックに依存しない純粋な可逆圧縮。フレーム内+フレーム間予測を持ち、アーカイブ用途に広く使われる。FFmpegのデフォルト可逆コーデック	yuv420p
FFvhuff	`-vcodec ffvhuff`	FFmpeg 独自の Huffman 符号化ベース可逆圧縮。高速で実装がシンプル。HuffyuvをベースにFFmpeg向けに最適化されたもの	yuv420p
Huffyuv	`-vcodec huffyuv`	古典的な可逆圧縮コーデック。1990年代から使われる歴史あるコーデックで、FFvhuffのベースになった。本ビルドでは yuv422p出力のみ対応のため、yuv420p入力では420→422→420変換が不可逆となる	yuv422p
MagicYUV	`-vcodec magicyuv`	比較的新しい可逆圧縮コーデック。高速で圧縮率も良好。マルチスレッド対応で編集用途にも向く	yuv420p
Ut Video	`-vcodec utvideo`	高速な可逆圧縮に特化したコーデック。RGB/YUV両対応で、Windows環境の編集用中間コーデックとして人気が高い	yuv420p
PNG Video	`-vcodec png`	静止画 PNG の動画版。フレーム単位で PNG 圧縮を行う。YUV→RGB変換が入るため、元が yuv420pの場合、厳密には非可逆（0.9988）	rgb24
QTRLE	`-vcodec qtrle`	Apple QuickTime RLE。シンプルなランレングス符号化。単純なCGや画面収録では高圧縮だが、自然画では膨張する場合もある。YUV→RGB変換が入る	rgb24
H.264 (x264) ultrafast	`-vcodec libx264 -crf 0 -preset ultrafast`	x264 の可逆モード（CRF=0）。ultrafastプリセットで速度重視。フレーム間予測により高圧縮率を実現	yuv420p
H.264 (x264) medium	`-vcodec libx264 -crf 0 -preset medium`	x264 の可逆モード。mediumプリセットでバランス重視。ultrafastより圧縮率は高いが時間はかかる	yuv420p
H.265 (x265) ultrafast	`-vcodec libx265 -crf 0 -preset ultrafast -x265-params lossless=1`	x265 の可逆モード。ultrafastプリセットで速度重視。H.264より新しい世代の符号化効率を持つが、ロスレスでは計算コストが高い	yuv420p

補足：除外したエンコーダ

Lagarith：FFmpeg にエンコーダが含まれていない（デコーダのみ）のため対象外
H.264 veryslow / H.265 medium：BBBで1分超の長時間エンコードとなるため除外（テストの実用性を優先）
AV1（libaom-av1, libsvtav1）：可逆圧縮モードは存在するが、エンコード時間が数十分～数時間に及ぶため実用的なテスト範囲を超えるとして除外
ProRes（prores_ks）：ProResは 4:4:4 RGBおよび 4:4:4 YCbCrプロファイルでは可逆圧縮 として動作するが、本テストのように yuv420p 入力を扱う場合は 4:2:0 へのサブサンプリングと量子化が入り非可逆 となるため、完全な可逆圧縮の比較対象として除外。YUV420での可逆を求めるならProResは選択肢にならない

テスト環境

項目	内容
OS	Windows 11
CPU	AMD Ryzen 7 (Zen5)
FFmpeg	full-build 9.0.2 (gyan.dev) - libvmaf/libzimg対応
Python	3.13（uv管理）
品質チェック	FFmpeg標準フィルタ SSIM (ssim) / VMAF v1 (libvmaf version=vmaf_v1.0.16_3d0h + CAMBI+motion) - 常に yuv420pに正規化して測定

テストスクリプト benchmark.py (Github Gist) は YUV420測定・VMAF v1対応版を使用。

品質指標について（SSIM / VMAF）

本ベンチマークでは FFmpeg に標準搭載されている2つの客観的品質指標を使用しています。

SSIM (Structural Similarity Index) - libavfilter ssim:

元画像と圧縮後画像の 輝度・コントラスト・構造 の類似度を 0〜1 で評価。1.0が完全一致
計算が軽量で高速。可逆圧縮の確認（SSIM=1.0になるか）に最適
本テストでは All:0.999... を小数4桁まで表示。Y:1.0 U:0.999... のようにY/U/V成分別にも確認可能
コマンド例: [enc][ref]ssim=stats_file=nul

VMAF (Video Multimethod Assessment Fusion) - libvmaf:

Netflixが開発した人間の主観評価に近いとされる品質指標。0〜100（v1の4K@3Hモデルは0-110）で評価、100が完全一致
複数の品質特徴量を機械学習で統合。SSIMより人間の知覚に近い
本テストでは VMAF v1 (v1.0.16_3d0h) を使用。詳細は補足章参照
計算コストが高い（BBBで5-6分）。モデルは vmaf_v1.0.16_3d0h、追加特徴量に cambi (バンディング検出) と motion を有効化
コマンド例: [enc][ref]libvmaf=log_fmt=json:model=version=vmaf_v1.0.16_3d0h:feature=name=cambi|name=motion
可逆圧縮では理論上 VMAF=100 となるはず。今回の再測定で真の可逆コーデックは BBBで100.00、Sintelで99.26を達成

本記事では 可逆性の厳密な確認は SSIM、人間の知覚的な劣化度合いの参考として VMAF を併記しています。

テストで用いる動画ファイル

Xiph.org が提供するフリー動画素材（rawvideo YUV4MPEG2形式）を使用。

Big Buck Bunny（BBB）

項目	内容
ファイル名	`big_buck_bunny_1080p24.y4m`
解像度	1920×1080
フレームレート	24 fps
長さ	9分56秒
ファイルサイズ	41.47 GB

Blender Foundation制作。自然風景や毛並みなど動きの多い複雑なシーン。

Sintel Trailer

項目	内容
ファイル名	`sintel_trailer_2k_1080p24.y4m`
解像度	1920×1080
フレームレート	24 fps
長さ	52秒
ファイルサイズ	3.63 GB

暗いシーンやスモークが多く、BBBとの比較に適しています。

テスト結果：Big Buck Bunny（VMAF v1）

圧縮率比較

元ファイル 41.47 GB を各エンコーダで可逆圧縮。

順位	エンコーダー	圧縮率	圧縮時間	出力サイズ	SSIM(yuv420)	VMAF v1
1	H.264 (x264) medium	6.17x	2m16.0s	6.72 GB	1.0000 🟢	100.00 🟢
2	H.265 (x265) ultrafast	5.35x	2m07.7s	7.74 GB	1.0000 🟢	100.00 🟢
3	H.264 (x264) ultrafast	4.64x	17.48s	8.93 GB	1.0000 🟢	100.00 🟢
4	FFV1	4.06x	46.12s	10.20 GB	1.0000 🟢	100.00 🟢
5	Ut Video	2.67x	16.28s	15.54 GB	1.0000 🟢	100.00 🟢
6	MagicYUV	2.62x	16.46s	15.81 GB	1.0000 🟢	100.00 🟢
7	FFvhuff	2.42x	14.39s	17.14 GB	1.0000 🟢	100.00 🟢
8	Huffyuv	1.91x	15.70s	21.75 GB	0.9998 🟡	100.00 🟡*
9	PNG Video	1.57x	1m53.9s	26.41 GB	0.9988 🟡	99.33 🟡
10	QTRLE	0.77x	5m11.5s	54.07 GB	0.9988 🟡	99.33 🟡

*HuffyuvはSSIM 0.9998だがVMAF v1では100.00。VMAF v1は色差の微小な補間誤差に対して寛容（詳細後述）。

圧縮時間比較

圧縮時間 × 圧縮率相関図

ポイント

真の可逆コーデック7種は VMAF v1で100.00を達成。v0.6.1では99.20だったが、v1では完全一致と判定されるようになった
PNG/QTRLEは 99.33 と明確に減点。YUV→RGB変換の丸め誤差がVMAF v1でも検出されている
HuffyuvはSSIMでは0.9998と非可逆だが、VMAF v1では100.00。色差の高周波誤差に対してVMAF v1はSSIMより鈍感 な例。SSIMでの判定が必須

テスト結果：Sintel Trailer（VMAF v1）

元ファイル 3.63 GB。

圧縮率比較

順位	エンコーダー	圧縮率	圧縮時間	出力サイズ	SSIM(yuv420)	VMAF v1
1	H.264 (x264) medium	14.40x	7.46s	258 MB	1.0000 🟢	99.26 🟢
2	FFV1	11.68x	2.09s	318 MB	1.0000 🟢	99.26 🟢
3	H.264 (x264) ultrafast	11.15x	1.22s	333 MB	1.0000 🟢	99.26 🟢
4	H.265 (x265) ultrafast	9.58x	7.26s	387 MB	1.0000 🟢	99.26 🟢
5	Ut Video	5.70x	1.02s	651 MB	1.0000 🟢	99.26 🟢
6	MagicYUV	5.28x	0.99s	703 MB	1.0000 🟢	99.26 🟢
7	PNG Video	4.65x	4.68s	799 MB	0.9993 🟡	98.05 🟡
8	FFvhuff	3.52x	0.82s	1.03 GB	1.0000 🟢	99.26 🟢
9	Huffyuv	2.69x	1.11s	1.35 GB	1.0000 🟢*	99.22 🟡
10	QTRLE	2.00x	12.88s	1.82 GB	0.9993 🟡	98.05 🟡

*HuffyuvはSintelではSSIMが四捨五入で1.0000だが、BBBでは0.9998。コンテンツにより補間誤差の出方が異なる。VMAF v1では99.22と真の可逆より0.04低い。

圧縮時間比較

圧縮時間 × 圧縮率相関図

エンコード結果の分析

1. 圧縮率の階層構造

グループ	圧縮率目安	該当コーデック
高圧縮群	4〜15x	H.264 medium/ultrafast, H.265 ultrafast, FFV1
中圧縮群	2.5〜6x	MagicYUV, Ut Video, FFvhuff, PNG
低圧縮群	0.8〜3x	Huffyuv, QTRLE

高圧縮群はフレーム間予測を利用。

2. SSIM/VMAFから見る完全可逆性（YUV420測定）

今回の YUV420測定では、FFmpegの ssim および libvmaf フィルタを用い、元 yuv420p に対する真の可逆性を評価しています。

測定フィルタ:

[0:v]fps=24,format=yuv420p,scale=out_chroma_loc=left:flags=bicubic[enc];
[1:v]fps=24,format=yuv420p,scale=out_chroma_loc=left:flags=bicubic[ref];
[enc][ref]ssim / [enc][ref]libvmaf=version=vmaf_v1.0.16_3d0h

コーデック	BBB SSIM/VMAF v1	Sintel SSIM/VMAF v1	原因
Huffyuv	0.9998 / 100.00	1.0000 / 99.22	yuv420→yuv422→yuv420 変換。Huffyuvは yuv422p出力のため、420(540行)→422(1080行)で補間が発生。BBBは高周波色差が多くSSIMで検出、Sintelでは四捨五入で1.0。VMAF v1はこの色差誤差に寛容で100.00/99.22。
PNG Video	0.9988 / 99.33	0.9993 / 98.05	YUV→RGB→YUV 変換。BT.709係数 + 8bit丸めで ±1LSB誤差。VMAF v1でも99.33/98.05と減点。
QTRLE	0.9988 / 99.33	0.9993 / 98.05	同上

教訓: 真の yuv420可逆が必要なら FFV1 / FFvhuff / MagicYUV / Ut Video / x264 / x265 を選ぶべき。Huffyuvはこのビルドでは yuv420p非対応。

3. ユースケース別おすすめコーデック

順位	おすすめ	理由
⭐1位	H.264 (x264) ultrafast	4.64x(BBB)/11.15x(Sintel)で17秒/1.2秒。バランス最優秀。VMAF v1 100.00/99.26
2位	FFV1	純粋可逆でアーカイブ標準。4.06x/11.68x。VMAF v1 100.00/99.26
3位	MagicYUV / Ut Video	16秒(BBB)で最速級。編集用中間コーデックに最適
4位	H.264 medium	最高圧縮率 6.17x/14.4x だが時間長。長期アーカイブ向け
❌非推奨	PNG/QTRLE	YUV→RGB変換で非可逆(0.9988)かつ低圧縮率。VMAF v1でも99.33/98.05と減点。QTRLEはサイズ増大
⚠️注意	Huffyuv	yuv422p出力のため yuv420に対してはSSIM 0.9998。VMAF v1では100.00になるためSSIMでの確認が必須

補足: VMAF v0.6.1 と VMAF v1 の違いと移行理由

本記事の初版では vmaf_v0.6.1 を使用していましたが、今回 VMAF v1 (v1.0.16_3d0h) に移行しました。その理由と差異をまとめます。

VMAFとは

VMAF (Video Multimethod Assessment Fusion) はNetflixが開発したフルリファレンスの客観的品質指標で、複数の画質特徴量をSVM回帰で融合して人間の主観評価に近いスコアを出力します。2021年にエミー賞受賞。

v0.6.1 (VMAF v0世代) の特徴と欠点

リリース: 2018年、FFmpegのデフォルトモデルとして現在も広く使われる
特徴量: VIF(4スケール) + DLM(Detail Loss) + MCPD(動き) の3つ。lumaのみでchromaを見ない
バンディング非対応: 滑らかなグラデーションの階段状劣化を検出できない
視聴距離モデル: Phoneモデルは標準スコアを2次多項式でマッピングする後処理で、過大評価しがち
動き: 上限なし、60fpsで過小評価、高動きで過大評価
NEG: 別モデル vmaf_b_v0.6.3 として提供、デフォルトOFF。シャープ化でスコアが不当に上がる

VMAF v1 (2026年6月リリース) の改善点

Netflix Tech Blog "VMAF v1: Good Is Not Good Enough" より:

圧縮アーティファクトへの感度改善: DLMに加え AIM(Additive Impairments) を追加。v0は解像度を上げる際、圧縮歪みよりスケーリング歪みを好む傾向があったのを修正
視聴距離モデルをCSFベースに刷新: Barten CSFモデルで特徴量自体を視聴距離に応じて変調。1080p@3H / Phone@5H / 4K@1.5H / 4K@3H を同一モデルで扱える
バンディング対応 (CAMBI): Contrast Aware Multiscale Banding Indexを統合。v0では見逃していたバンディングを検出
Chroma対応: SpEED-QAをchromaチャンネルに適用。YUV→RGB変換や 420→422変換の色差劣化を検出可能に
NEGデフォルトON: シャープ化などのエンハンスメントによるスコアの不当な上昇を抑制
動き特徴量の改善: 上限を設け、5フレーム窓(i-2,i,i+2)でHFR対応
高速化: 重いVIFを削除、chromaを低解像度で測定することで、機能追加にもかかわらずv0より高速
10bit測定推奨: SDRでも10bitで測定することでバンディングをより正確に捉える

項目	v0.6.1	v1 (v1.0.16_3d0h)
特徴量	VIF+DLM+MCPD (lumaのみ)	DLM+AIM+CAMBI+chroma+MCPD (NEG ON)
色差検出	不可	可
バンディング検出	不可	可 (CAMBI)
視聴距離	3H固定 + 多項式マッピング	CSFベースで 3H/5H/1.5H対応
スコア範囲	0-100	0-100 (4K@3Hは0-110)

本ベンチマークでの実測差異

動画	コーデック	v0.6.1	v1	差分	解釈
BBB	真の可逆 (FFV1/x264等)	99.20	100.00	+0.80	v1では完全一致が100と正しく判定されるように
BBB	PNG/QTRLE	98.57	99.33	+0.76	v1はluma重視が改善されたため、色差誤差の減点がv0より小さくなる場合もある
BBB	Huffyuv (SSIM 0.9998)	99.20	100.00	+0.80	色差補間誤差はv1では寛容に扱われる。SSIMでの判定が必要
Sintel	真の可逆	98.87	99.26	+0.39	BBBと同様、100に近づく
Sintel	PNG/QTRLE	97.85	98.05	+0.20
Sintel	Huffyuv	98.87	99.22	+0.35	SSIM 1.0だがVMAFでは0.04減点、色差誤差をv1が微かに検出

重要な発見:

v0.6.1は真の可逆でも99.20/98.87と100にならなかったが、v1ではBBBで100.00と完全一致を正しく認識
しかしv1は 色差の微小な誤差に対してSSIMより鈍感。Huffyuvの0.9998がVMAF 100.00になる例。可逆性の厳密な判定はSSIMが必須、VMAFは人間の知覚的品質の参考として使うべき
警告 covariance matrix is singular: v1で完全一致フレームを測定すると必ず出る警告。共分散行列が特異になるためで、スコアは正常。無視してOK

移行推奨コマンド

# 旧 (v0.6.1)
ffmpeg -i enc.mp4 -i ref.y4m -lavfi "[0:v]format=yuv420p[enc];[1:v]format=yuv420p[ref];[enc][ref]libvmaf=model=version=vmaf_v0.6.1" -f null -

# 新 (v1, CAMBI+motion有効, 10bit推奨)
ffmpeg -i enc.mp4 -i ref.y4m -lavfi "[0:v]format=yuv420p10le,scale=out_chroma_loc=left:flags=bicubic[enc];[1:v]format=yuv420p10le,scale=out_chroma_loc=left:flags=bicubic[ref];[enc][ref]libvmaf=log_fmt=json:model=version=vmaf_v1.0.16_3d0h:feature=name=cambi|name=motion" -f null -

FFmpeg 9.0.2 full-buildでは model=version=vmaf_v1.0.16_3d0h が使用可能。モデルファイルは share/model/vmaf_v1.0.16/ に同梱。

（参考）テストスクリプト（YUV420測定・VMAF v1版）

PIX_FMT_MAP = {
    "ffv1": "yuv420p", "ffvhuff": "yuv420p",
    "huffyuv": "yuv422p", "magicyuv": "yuv420p", "utvideo": "yuv420p",
    "png": "rgb24", "qtrle": "rgb24",
    "libx264": "yuv420p", "libx265": "yuv420p",
}

def run_quality_check(...):
    # YUV420測定: 常に yuv420p で元動画に対する可逆性を評価
    ssim_filter = "fps=24,format=yuv420p,scale=out_chroma_loc=left:flags=bicubic"
    vmaf_filter = "fps=24,format=yuv420p10le,scale=out_chroma_loc=left:flags=bicubic" # v1は10bit推奨
    ssim_cmd = [ffmpeg, "-i", encoded, "-i", original,
                "-lavfi", f"[0:v]{ssim_filter}[enc];[1:v]{ssim_filter}[ref];[enc][ref]ssim=stats_file=nul", "-f", "null", "-"]
    vmaf_cmd = [ffmpeg, "-i", encoded, "-i", original,
                "-lavfi", f"[0:v]{vmaf_filter}[enc];[1:v]{vmaf_filter}[ref];[enc][ref]libvmaf=log_fmt=json:log_path=nul:model=version=vmaf_v1.0.16_3d0h:feature=name=cambi|name=motion", "-f", "null", "-"]

完全版は GitHub Gist参照。

実行方法

python benchmark.py  # GUIでy4m選択 → YUV420測定（SSIM/VMAF v1）

KEEP_TEMP=1 で一時ファイル保持、 benchmark_logs/ に encode/ssim/vmafログ保存。VMAF v1では covariance matrix is singular 警告は正常。

まとめ

第一候補は H.264 (x264) ultrafast：BBB 4.64x / Sintel 11.15x と速度・圧縮率バランス最良。VMAF v1 100.00/99.26
FFV1は純粋可逆で信頼性高い：アーカイブ標準。VMAF v1で100.00と完全一致を正しく認識
速度最優先なら MagicYUV/Ut Video：約16秒(BBB)で2.6x。VMAF v1 100.00
最高圧縮率なら H.264 medium：BBB 6.17x / Sintel 14.4x
PNG/QTRLEは完全可逆ではない：YUV→RGB変換でSSIM 0.9988、VMAF v1 99.33/98.05と減点
Huffyuvは yuv420に対してはSSIM 0.9998：VMAF v1では100.00になるため、可逆性の判定はSSIMが必須
YUV420測定 により、色空間変換による不可逆性も正しく評価可能になった
VMAF v1移行により、真の可逆が100.00と正しく判定されるようになったが、色差の微小誤差はSSIMほど厳しく見ない。両指標の併用が重要

目的に応じて適切なコーデックを選びましょう。

You get articles that match your needs
You can efficiently read back useful information
You can use dark theme

What you can do with signing up

FFmpeg による可逆圧縮の比較

はじめに

注意事項

ffmpeg がサポートする可逆圧縮エンコード

補足：除外したエンコーダ

テスト環境

品質指標について（SSIM / VMAF）

テストで用いる動画ファイル

Big Buck Bunny（BBB）

Sintel Trailer

テスト結果：Big Buck Bunny（VMAF v1）

圧縮率比較

圧縮時間比較

圧縮時間 × 圧縮率 相関図

ポイント

テスト結果：Sintel Trailer（VMAF v1）

圧縮率比較

圧縮時間比較

圧縮時間 × 圧縮率 相関図

エンコード結果の分析

1. 圧縮率の階層構造

2. SSIM/VMAFから見る完全可逆性（YUV420測定）

3. ユースケース別おすすめコーデック

補足: VMAF v0.6.1 と VMAF v1 の違いと移行理由

VMAFとは

v0.6.1 (VMAF v0世代) の特徴と欠点

VMAF v1 (2026年6月リリース) の改善点

本ベンチマークでの実測差異

移行推奨コマンド

（参考）テストスクリプト（YUV420測定・VMAF v1版）

実行方法

まとめ

圧縮時間 × 圧縮率相関図

圧縮時間 × 圧縮率相関図