SlimeCodec NormMAP — 測定台帳と検証手続き
製品ページ(NormH.264)から開発過程・測定手続き・一次資料をこちらへ分離しています。数値は器(ベンチ)の生ログと突き合わせた実測値であり、検証できていない範囲は「検証できていない」と書きます。最終更新: 2026-07-27。
① 対ソース削減率(製品ページの −74.3% など): 入力ファイルに対して何 % 小さくなったか。入力のビットレートに強く依存し、膨れたマスターほど大きく出ます。実運用の請求額に直結する数字ですが、コーデックの効率を表す数字ではありません。
② 同一画質での効率改善(iso-VMAF BD-rate): 同じ画質を出すのに必要なビット量を、標準 x264 と比べた数字。コーデックとしての実力はこちらで、下の台帳が扱うのは全てこの ② です。
1. 同一画質(iso-VMAF)BD-rate 実測台帳 確定
負の値 = NormMAP が少ないビットで同じ画質に到達(勝ち)。BD-rate は VMAF → log10(rate) の三次近似です。
1-1. VOD 出荷帯(VMAF 93–96)・5 素材 — 看板の根拠はこれ
実際に配信する品質帯だけを密なラダーで測ったもの。対戦相手は x264 aq-mode 3 + psy-rd 1.00,0.15(標準的な VOD 設定)、NormMAP は strength 0.10、両腕とも同一バイナリ・同一 preset。広い品質域を跨ぐ測り方より信頼できます — 内挿の弦誤差(効果と同じ桁の誤差が乗る問題)を負わないためです。
| 素材 | 種別 | BD-rate(band) | BD-rate(band3・再測) |
|---|---|---|---|
| 自社 ProRes 4K マスター | 実カメラ・4K24 | −5.53% | −6.60% |
| crowd_run | 1080p50 高動き | −5.68% | −6.13% |
| park_joy | 1080p50 高動き | −4.32% | −4.97% |
| sintel trailer | 1080p24 CG | −4.08% | −2.69% |
| dinner | 1080p30 室内 | −2.61% | −3.62% |
| 中央値(n=5) | −4.32% | −4.97% | |
5 素材すべてで勝ち、幅は −2.6–6.6%、中央値 −4–5%。二回の独立したラダーで同じ位置に立ちます。これが製品ページの「同一画質で −4–5%」の出所です。
ただしこれは 1 素材の数字です。5 素材の中央値は −6.7% で、事前登録していた −10% のラインには届きませんでした。したがって当社は「一律 −10% 超」を看板にしません — 利得は素材に依存する、というのが判定結果です。だからこそ §2 の事前診断が製品の中心にあります。
1-2. 低ビットレート帯(720p・3G 相当) — 別条件での独立再現とゲートの実証
条件を全部入れ替えた測定 — 720p(Lanczos downscale)・0.3–1.5 Mbps・x264 aq-mode 1 相手・VMAF 内蔵 HD モデル vmaf_v0.6.1。素材も帯域も対戦相手も違うのに、勝ち幅は同じ 4–5% に着地します。
| 素材 | 条件 | BD-rate | iso-VMAF 帯 | 判定 |
|---|---|---|---|---|
| sintel (g2 高) | 720p aq1 clean | 約 −5% | 85–94 (watchable) | 勝ち。原資(高品質側の余白)がある素材で出た。保守側の値—測定器の CRF 下限クランプで norm 側が不利に出ており、実力はこれ以上 |
| sintel (g2 高) | 720p 3s aq1 (別ラダー) | −4.08% | 60–93 | 勝ち。① floor の独立再現 |
| water8 (実写4K) | 720p aq1 ゲート無し | 約 +4% | 45–81 | 負け。720p 化で原資が消えた素材 |
| water8 (実写4K) | 720p aq1 g2 ゲート ON | +0.1% | 40–82 | break-even。ゲートが負けを「最悪ゼロ」に止めた実証 |
| 4k-nature | 4K 同一サイズ (~8 MB) 対照 | 負け | x264 VMAF 70 (8.1 MB) vs Norm VMAF 69 (7.8 MB) | 同一サイズでは素の x264 がわずかに上。この素材に Norm 固有の同一画質での勝ちはありません |
| park_joy (g2=0) | 720p aq1 | −5.0% | 12–50 (視聴に耐えない帯) | 床・別枠。watchable 帯に乗らないため実運用判断に使わない |
∴ 確定している主張は一つ: ゲート込みの NormMAP は「原資があれば同一画質で 4–5% 少ないビットで済み、原資が無ければ break-even、負けには行かない」。VOD 出荷帯(§1-1)と低ビットレート帯(§1-2)というまったく違う二つの条件で、同じ 4–5% に着地しているのが、この数字を看板に置いている理由です。
否定された主張: 「一律 −10%」は成立しません。VOD 帯でも 3G 帯でも勝ち幅は ~5% で、事前登録した 10% 閾値を超えませんでした。削減率は content 依存です。
_vod_bench/ の band_results.tsv / band3_results.tsv / results.tsv / lever2_results.tsv に凍結してあり、bdrate_recheck.py を走らせると上表の各行が再導出されます(エンコードも VMAF 実行も不要)。負けた行も外れた点も消さずに残しています。
2. g2 事前診断 — 「効くか」をエンコード前に判定する
NormMAP の利得は素材依存です。そこで、入力映像から g2 指標(低 d 値の割合と高 d 値の縁の割合)を計算し、NormMAP を適用すべき素材かどうかをエンコード前に判定します。上の台帳で言えば、sintel(g2 高)は「効く」、water8 の 720p 化後は「効かない」と事前に出ます。
3. ゲート — 外れたときに損をしない構造
g2 診断が「効かない」と判定した区間では、NormMAP は素通し(標準 x264 と同じ経路)になります。これが台帳 4 行目の実証で、ゲート無しなら +4.0%(=4% 太る)だった water8 が、ゲート ON で +0.1% に収まりました。
導入判断の観点では、「当たれば減る・外れても現状維持」という非対称性が本製品の設計目標であり、その裏付けがこの一行です。
4. モジュール②を凍結した経緯 凍結
第二モジュールは当初 −10.03% を主張していましたが、①(floor)を基準にした純寄与で測り直したところ、寄与はゼロ〜マイナスでした。三アームを同一の中間条件で測った結果:
| アーム | vs x264 | vs ①(純寄与) | 判定 |
|---|---|---|---|
| ① floor のみ | −4.08% | — | これが実力 |
| ①+② 初期設定 | −3.56% | +0.50% | 純寄与ゼロ(むしろ微増) |
| ①+② 攻め設定 | +3.98% | +7.83% | 明確に損。−10.03% の主張は再現せず |
結論として②は既定 OFF の摘まみとして凍結し、製品の看板からは外しました。コードは残しますが、既定では通りません。
5. VMAF は NormMAP を過小評価する(検証中の知見)
上記の −4–5% はすべて VMAF を物差しにした数字です。ところが今週、VMAF が NormMAP の効きを構造的に低く見積もることが分かりました:
- VMAF は設計上、輝度しか評価しません。したがって色差(クロマ)領域で起きている差は、原理的にスコアへ乗りません。これは VMAF という指標の性質であって、当社の測定結果ではありません。
- 訂正(2026-07-27): 本項には以前「色差で測ると分離 5.13 倍」と記載していましたが、撤回します。この 5.13 倍は圧縮済み 1 素材(city3s)での動体検知の的中率であって、同一画質でのビット削減余地を示す数字ではありません。加えて元資料自身が「AV1 の色差量子化による副作用の可能性」を未排除の交絡として挙げており、当社の測定規約もこれをその週の誤りの一つとして記録しています。裏付けとして掲げるべきではありませんでした。
- 公開デモ NormAV1 切替え比較では、VMAF 54.57(数字上は「画質崩壊」)の出力を、多くの方が原本と言い当てられません。VMAF スコアの崩壊と、目で見た劣化はずれます。
∴ 台帳の −4–5% は「実力の下限」であり、視聴品質を基準にすれば数字はこれより大きく出ると見込んでいます。ただしその見込みは、下の §6 のとおりまだ測っていません。
6. 検証できていないこと(明示) 未検証
§5 の理由から、視聴品質を基準にすれば −20–25% に達すると見込んでいます。これは現時点で仮説であり、測定値ではありません。盲検用の刺激(参照 + 8 クリップ + 隠しキー)は用意済みですが、判定はまだ実施していません。
掲載の条件はあらかじめ決めてあります — ①複数の被験者による盲検 A/B(1 人ではなく)、②同一サイズで Norm が勝つ g2 高素材で行うこと(4k-nature は §1 のとおりこれに該当しません)、③第二段として「目が差に気づくまで Norm を縮め、x264 の検知点と比べる」。この三つが揃った時点で、数字と手順をこの頁に掲載します。外部被験者による裏書き(BT.500 的手続き)はその次の段階です。
- 「CDN 半分」「−42%」— 撤回しました。4k-nature で「x264 14.3 MB(VMAF 80) vs Norm 8.2 MB(VMAF 69)= −42%」としていたものですが、これは同一 CRF での比較です。Norm が小さいのは画質が 11 ポイント低いからであって、同じ画質を安く出したからではありません。同一サイズの対照(§1 の 5 行目)では x264 の方がわずかに上でした。過去資料に残っていた場合、無効です。
- 圧縮履歴ボーナス — 精査中。すでに一度圧縮された素材を入力すると ① の効きが伸びる傾向(中間 CRF 12/24/32 で −1.86 / −2.79 / −3.39%)が出ていますが、幾何的な副作用の可能性を排除できておらず、看板には載せていません。
- ProRes マスター入力に既知の不具合があり、修正待ちです。
7. 測定条件(再現のために)
| §1-1 VOD 出荷帯 | 1080p24–50 ＋ 4K24(自社 ProRes マスター)、VMAF 93–96 に絞った密ラダー。対戦相手 = x264 aq-mode 3 + psy-rd 1.00,0.15 |
|---|---|
| §1-2 低ビットレート帯 | 720p (Lanczos downscale) / 0.3–1.5 Mbps ラダー。対戦相手 = x264 aq-mode 1(NormMAP 側と同一 aq) |
| NormMAP 設定 | strength 0.10(§1-1 には strength 0.20 も併記) |
| 画質指標 | VMAF。1080p 素材は内蔵 HD モデル vmaf_v0.6.1、4K 素材は 4K モデル |
| BD-rate 算出 | VMAF → log10(rate) の三次近似 |
| 両腕の同一性 | 同一バイナリ・同一 preset を両腕に通す |
| 集計規律 | 素材別に読み、中央値に丸めない。VMAF ~50 未満の帯は実運用判断に使わない。広い品質域を跨ぐ BD-rate は内挿の弦誤差を負うため、看板には出荷帯限定の値(§1-1)を使う |
| 再計算 | _vod_bench/bdrate_recheck.py(凍結済みラダーから全行を再導出) |
| ソフトウェア版 | ffmpeg 6.1.1 / libvmaf 42276bc |
| ビルド構成 | Trial ティア(スレッド数 1・preset veryslow・TRIAL 透かし ON) — 下の注記を必ずお読みください |
上の測定はすべて Trial ティアのビルド(スレッド数 1・preset veryslow・TRIAL 透かし ON)で行いました。有償版の実出荷構成は スレッド 4–8・preset medium・透かし無しで、別物です。影響の向きは分かっている範囲で次のとおり:
- 透かしは x264 側・NormMAP 側の両腕に焼き込まれています。共通の固定ビット費用 W が両腕に乗るため比は 1 に寄り、差は必ず縮みます。つまり公開値 −4–5% はゼロ側に偏った下限で、透かしを外した真値はこれより大きい側にあります
- preset veryslow → medium の向きは不明です。veryslow の mb-tree / モード決定が NormMAP の仕事を先取りしている可能性があるため medium で取り分が増えると予測していますが、予測であって測定ではありません
本頁の数値は事前登録した測定規約に基づく実測です。素材・構成(バイナリ版・preset・スレッド数・透かしの有無)が変わると数値は変わります。お手元の映像での確認を推奨します — 無料トライアル。