前回のアニメ編では、x264 medium・CRF 23 を基準に動き探索パラメータ(me_method / subme / me_range)を 1 個ずつ動かして、品質(VMAF)・圧縮率(同一 CRF でのサイズ差)・時間効率を全て計測しました。結論は「me_method の効果はサイズにしか出ず、それも 2% 止まり」「subme は 9 で打ち止め(10/11 は trellis=2 がないと無言で 9 に降格)」「me_range は無風」「preset を落とす方が圧倒的に効率的」という結果でした。
ただしアニメ編の素材は動きの少ない暗部シーンで、「動き探索が苦労しない素材だから差が出なかったのでは?」という疑問が残ります。そこで今回はエンコーダにとって厳しい条件である、群衆マラソン(crowd_run・1080p50)で同じ表を全部作り直しました。画面いっぱいに数百人のランナーがバラバラに動く、動き探索にとって最悪クラスの素材です。
先に結論です。
- me_method は、期待していたサイズ削減がこの素材でもほぼ出ない(tesa で −0.8%、アニメの −2.0% より小さい)。品質 ±0.01 は CRF 固定の仕様どおり
- subme は下げたときの崩壊が劇的。subme 0 は「サイズ +14.5% で品質 −2.12」。上は今回も 9 で打ち止め
- me_range は 50fps の激しい動きでも無風
- 組み合わせは trellis=1 のままでは全部 +0.36 に収束(11 倍の時間をかけた全部盛りも +0.38)。時間効率トップは subme 9 単発。追補として trellis 2 で subme 11 を解禁すると +0.60 まで伸び、preset placebo と VMAF 同点を約 1/5 の時間で出せた
検証環境と方法
環境はアニメ編と同じです(Threadripper 2990WX・BIOS で 8C/16T に制限 / ffmpeg 8.1.2 / x264 core 165 r3223 / libvmaf 既定モデル・全フレーム計測 / libx264 CRF 23 preset medium 基準)。素材だけが変わります。
| 項目 | 内容 |
|---|---|
| 素材 | crowd_run(群衆のマラソン)10 秒・1920×1080・50fps・8bit |
| 中間素材 | libx264 -qp 0 のロスレス(約 638 Mbps) |
| 基準 run | 24,356 kbps / VMAF 94.72 / エンコード 23.8 秒 |
基準の時点で 24 Mbps という数字が素材の難しさを物語っています(アニメ編は同じ CRF 23 で 14 Mbps でした)。以下、表の「サイズ差」「ΔVMAF」「時間比」はすべてこの基準との比較です。読み方もアニメ編と同じで、CRF 固定なのでパラメータの効果は基本的にサイズに出ます。品質(VMAF)が動いたときは、レート配分・モード決定の判断そのものが変わった印です。
me_method — 最悪クラスの素材でも、サイズはほぼ縮まない
「動きが激しい素材ほど探索アルゴリズムの差が出る(= 同一 CRF でのサイズ削減が大きくなる)」— 今回いちばん検証したかった仮説です。
| me_method | ビットレート kbps | サイズ差 | VMAF | ΔVMAF | VMAF 1%low | 時間 s | 時間比 |
|---|---|---|---|---|---|---|---|
| dia | 24,366 | +0.0% | 94.70 | −0.01 | 90.11 | 23.8 | ×1.00 |
| hex(基準) | 24,356 | +0.0% | 94.72 | +0.00 | 90.14 | 23.8 | ×1.00 |
| umh | 24,223 | −0.5% | 94.71 | −0.00 | 90.03 | 28.5 | ×1.20 |
| esa | 24,182 | −0.7% | 94.72 | +0.01 | 90.13 | 46.4 | ×1.95 |
| tesa | 24,153 | −0.8% | 94.73 | +0.01 | 90.16 | 52.3 | ×2.20 |
ΔVMAF ±0.01 は CRF 固定なので驚きはありません。期待していたのはサイズのほうですが、tesa の全探索に 2.2 倍の時間を払っても 0.8% しか縮みませんでした(アニメでは 2.0% 縮んだので、むしろ効果が減っています)。
これは直感に反しますが、理屈をつけるなら: 群衆のような複雑な動きはどのアルゴリズムでも「当てられない」のです。hex で見つかる動きベクトルは umh や esa でもほぼ同じところに落ち、外れるブロックはどのみち外れて残差符号化に回る。探索の丁寧さが活きるのは「正解がありそうで、雑な探索だと見逃す」中間帯の素材で、両極端(動きが単純すぎる/複雑すぎる)では差がつかない、ということのようです。
subme — 下は崩壊、上は今回も 9 で打ち止め
| subme | ビットレート kbps | サイズ差 | VMAF | ΔVMAF | VMAF 1%low | 時間 s | 時間比 |
|---|---|---|---|---|---|---|---|
| 0 | 27,887 | +14.5% | 92.60 | −2.12 | 86.27 | 13.6 | ×0.57 |
| 2 | 23,050 | −5.4% | 92.71 | −2.01 | 87.12 | 15.2 | ×0.64 |
| 4 | 23,146 | −5.0% | 93.53 | −1.19 | 88.58 | 18.9 | ×0.80 |
| 6 | 23,755 | −2.5% | 93.96 | −0.76 | 89.02 | 22.5 | ×0.95 |
| 7(基準) | 24,356 | +0.0% | 94.72 | +0.00 | 90.14 | 23.8 | ×1.00 |
| 8 | 24,635 | +1.1% | 94.81 | +0.10 | 90.22 | 25.0 | ×1.05 |
| 9 | 24,862 | +2.1% | 95.08 | +0.36 | 90.48 | 32.7 | ×1.38 |
| 10 | 24,862 | +2.1% | 95.08 | +0.36 | 90.48 | 32.8 | ×1.38 |
| 11 | 24,862 | +2.1% | 95.08 | +0.36 | 90.48 | 31.1 | ×1.31 |
見どころは subme 0 です。サブピクセル精度の動き補償を全部やめると、43% 速くなる代わりにサイズが 14.5% 膨らみ、そのうえ品質が 2.12 点落ちるという三重苦になりました。動き補償の精度が落ちる → 残差が増える → ビットが漏れる、を絵に描いたような結果で、「動き探索の存在意義は品質より先に圧縮率に現れる」ことがよく分かります。
上方向はアニメ編の再現でした。subme は RD 最適化・モード決定の精度そのものを変えるため、CRF 固定でも品質が動く例外です。subme 9 で +0.36(1% low +0.34)が上限、そして 9 / 10 / 11 の出力はまたしてもビットストリーム MD5 が完全一致。x264 は trellis=2 がないと subme 10(QP-RD)/ 11(full RD)を無言で 9 に降格します(SEI のオプション文字列でも subme=9 を確認)。
me_range — 50fps でも無風
アニメ編で「高速モーションの実写なら意味が出るはず」と宿題にしていたパラメータです。umh 固定で探索範囲を広げていきます。
| me_range | ビットレート kbps | サイズ差 | VMAF | ΔVMAF | VMAF 1%low | 時間 s | 時間比 |
|---|---|---|---|---|---|---|---|
| 16(既定) | 24,223 | −0.5% | 94.71 | −0.00 | 90.03 | 28.5 | ×1.20 |
| 24 | 24,227 | −0.5% | 94.72 | +0.00 | 90.07 | 30.8 | ×1.30 |
| 32 | 24,243 | −0.5% | 94.72 | +0.00 | 90.10 | 34.6 | ×1.46 |
| 48 | 24,252 | −0.4% | 94.72 | +0.00 | 90.14 | 38.8 | ×1.63 |
| 64 | 24,272 | −0.3% | 94.73 | +0.01 | 90.17 | 44.1 | ×1.86 |
結果はVMAF もサイズも小数第 1 位すら動きませんでした。考えてみれば 50fps ではフレーム間の移動量は 25fps の半分になるので、ランナーの激しい動きでも 1 フレームあたりでは 16 ピクセルにほぼ収まってしまう。しかも umh は探索の起点を予測ベクトルから取るので、等速で流れる動きなら範囲を広げる必要がそもそもない。me_range が効く条件(予測が外れるほど速くて大きい動き + 低フレームレート)は、現実の素材では思った以上にレアなのだと思います。
組み合わせ — 全て +0.36 に収束する
preset の動き探索部分を移植した設定(slower 相当 = umh+subme9、veryslow 相当 = umh+subme10+mr24、placebo 相当 = tesa+subme11+mr24)と、探索範囲まで盛った全部盛り、そして preset まるごとの参照点です。
| 設定 | ビットレート kbps | サイズ差 | VMAF | ΔVMAF | VMAF 1%low | 時間 s | 時間比 |
|---|---|---|---|---|---|---|---|
| 基準 medium | 24,356 | +0.0% | 94.72 | +0.00 | 90.14 | 23.8 | ×1.00 |
| umh subme8 | 24,485 | +0.5% | 94.81 | +0.09 | 90.21 | 30.0 | ×1.26 |
| slower 相当(umh subme9) | 24,723 | +1.5% | 95.07 | +0.36 | 90.54 | 36.6 | ×1.54 |
| umh subme11 mr24 | 24,729 | +1.5% | 95.08 | +0.36 | 90.52 | 39.6 | ×1.67 |
| veryslow 相当(umh subme10 mr24) | 24,729 | +1.5% | 95.08 | +0.36 | 90.52 | 40.2 | ×1.69 |
| placebo 相当(tesa subme11 mr24) | 24,647 | +1.2% | 95.08 | +0.37 | 90.59 | 75.4 | ×3.17 |
| 全部盛り(tesa subme11 mr64) | 24,701 | +1.4% | 95.09 | +0.38 | 90.62 | 262.6 | ×11.05 |
| preset slow | 24,513 | +0.6% | 95.07 | +0.35 | 90.27 | 53.8 | ×2.26 |
| preset veryslow | 23,416 | −3.9% | 95.20 | +0.48 | 90.41 | 119.6 | ×5.03 |
| preset placebo | 23,650 | −2.9% | 95.32 | +0.60 | 90.48 | 407.4 | ×17.15 |
組み合わせ勢は slower 相当から全部盛りまで、時間が ×1.54 → ×11.05 と 7 倍に伸びる間、ΔVMAF は +0.36 → +0.38 しか動きません。アニメ編と同じく trellis=1 のままでは subme 10/11 が 9 に降格される(SEI で確認済み)ため実効設定がほぼ同一になるうえ、tesa も me_range も無風なので、積めば積むほど「同じ結果を遅く計算する」だけになります。全部盛り(4 分 22 秒)と subme9 単発(32.7 秒)の品質差は 0.02 点でした。
preset 側はアニメ編と少し景色が違います。preset slow(×2.26 で +0.35)は、この素材では subme9 単発(×1.38 で +0.36)に時間効率で負けます。slow が積む ref 5 や trellis 2 のコストが複雑な絵では重く、リターンが伸びないためです。一方 preset veryslow は今回も「サイズ −3.9% + VMAF +0.48」と、動き探索チューンでは絶対に届かない圧縮率を持ってきました。品質の上積みよりも「同じ CRF でファイルが 4% 縮む」ことこそが preset の本体だ、というのが 2 素材を通した実感です。
追補: trellis 2 で subme 11 を解禁すると
ここまでの組み合わせが +0.36 で頭打ちになる直接の原因は、trellis=1 のままでは subme 10/11 が 9 に降格されることでした。では解禁したらどうなるのか。trellis=2 を足した 2 本を追加で回しました(SEI で実効 subme=11 になっていることを確認済みです)。
| 設定 | ビットレート kbps | サイズ差 | VMAF | ΔVMAF | PSNR-Y | SSIM | 時間比 |
|---|---|---|---|---|---|---|---|
| 基準 medium | 24,356 | +0.0% | 94.72 | +0.00 | 33.45 | 0.9929 | ×1.00 |
| umh subme11 me_range24 | 24,729 | +1.5% | 95.08 | +0.36 | 33.45 | 0.9929 | ×1.67 |
| trellis2 | 24,289 | −0.3% | 94.87 | +0.16 | 33.48 | 0.9928 | ×1.50 |
| umh subme11 me_range24 trellis2 | 24,054 | −1.2% | 95.32 | +0.60 | 33.35 | 0.9925 | ×3.28 |
trellis 2 単独は +0.16・サイズ −0.3%(×1.50)と、この素材では控えめです。しかし umh + subme11 + mr24 に trellis 2 を足すと景色が変わります。降格が解けて本物の subme 11(full RD)が動き出し、ΔVMAF は +0.36 の壁を越えて +0.60、1% low も +0.55。そして trellis=1 では +1.5% 太っていたサイズが −1.2% に反転しました。モード決定から量子化まで RD 最適化が一気通貫でつながると、ビットの使い方そのものが変わるわけです。
数字の並びで言うと、この設定(×3.28)は preset placebo(×17.15)と VMAF 同点(95.32)。約 1/5 の時間で同じ平均品質に届きます。一方サイズ削減では placebo(−2.9%)や veryslow(−3.9%)に届かないので、「品質狙いなら umh+subme11+mr24+trellis2、圧縮率狙いなら preset veryslow」という住み分けです。なお PSNR・SSIM はわずかに下がっており(33.45 → 33.35 / 0.9929 → 0.9925)、アニメ編の trellis 2 で見た「知覚品質を上げて数学的忠実度を下げる」psy 的挙動はここでも健在でした。
つまり組み合わせ節の結論はこう更新されます: 「動き探索だけ」の上限が +0.36 なのではなく、あれは trellis=1 の壁だった。量子化側の相棒を 1 個(trellis 2)連れてくれば +0.60 まで伸びる — ただし、それでも preset まるごとの圧縮率には届かない、という大枠は変わりません。
フレームで見る subme 0 の「ビット漏れ」
数字だけだと実感が湧かないので、基準と subme 0 の差が最も開いたフレーム(#197、VMAF 92.11 vs 87.23)をソースと比較してみます。まずソース(左)と基準出力(右)の並べて表示。
次が誤差ヒートマップです(輝度差 ×8 を黒→青→シアン→黄→赤で着色。明るいほど誤差が大きい)。上が基準(medium)、下が subme 0。
subme 0 は群衆全体がひとまわり明るく(= 誤差が大きく)、特にランナーの輪郭やゼッケンまわりのシアンの粒が増えているのが分かります。サブピクセル動き補償は消すと品質とサイズの両方が壊滅的になります。
まとめ(実写編 + 2 素材総括)
crowd_run(実写・最高難度)では:
- me_method: 品質 ±0.01 は CRF の仕様どおり。期待したサイズ削減も tesa で −0.8% どまり
- subme: 下げると崩壊(subme 0 = サイズ +14.5% かつ −2.12)。上は 9 で +0.36 が上限。9/10/11 同一出力は今回も同様
- me_range: 完全無風。50fps では 1 フレームの移動量が半分になるのも効かない理由
- 組み合わせ: trellis=1 のままでは +0.36 の壁(subme 降格のため。全部盛り ×11.05 は「同じ結果を遅く計算する」だけ)。trellis 2 で解禁すると +0.60・サイズ −1.2%(×3.28)= preset placebo と VMAF 同点を約 1/5 の時間で
- 時間効率の勝者: subme 9 単発(×1.38 で +0.36)。品質を積むなら umh+subme11+mr24+trellis2(×3.28 で +0.60)、圧縮率が欲しければ preset veryslow(−3.9%)
アニメ編と合わせた 2 素材・56 run の総括はこうなります。
x264 の動き探索は「下げると壊れるが、上げても伸びない」。medium の既定(hex / subme 7 / me_range 16)はすでに収穫逓減の崖っぷちに置かれていて、上に積む余地は subme 9 の +0.4〜0.6 点ぶんしかない。それ以上を求めるなら、動き探索ではなく trellis・refs・lookahead まで一括で動く preset を落とすのが正解 — 特に veryslow は品質を上げながらサイズを 4% 縮めてくる。逆に速度が欲しいときも、subme を下げるくらいなら preset を veryfast 側へ落とす方が制御された劣化になります。個別パラメータの出番は「preset で大枠を決めた後の最後の一押し(手軽に subme 9、本気なら trellis 2 + subme 11 のセット)」くらい、というのが今回の着地点です。
なお、アニメ編は暗部・低モーションの 1 シーンだけで結論を出すのはまだ早いので、動きの大きいエフェクトシーンや CG アニメなど、別シーン・別ソースでの追加検証を続編として予定しています。この総括もそこで更新するかもしれません。
検証データ: 各設定 1 run(x264 は同一設定・同一スレッド数なら決定的に同一出力になります)。VMAF は libvmaf 既定モデル・全 500 フレーム計測の平均値。計測には自作のエンコード検証ツール(ffmpeg + libvmaf のフロントエンド)を使用 — もう少し整えたら GitHub で公開予定です。
素材クレジット: “crowd_run” — SVT High Definition Multi Format Test Set(media.xiph.org の derf collection 経由)。研究・開発用途での利用。
コメント