フレームレートを 30 から 24 に落としたら、ファイルは 14.4% 小さくなり、PSNR は 46.11 dB のまま一桁も動かなかった。シャープネス値も 4.13 のまま。数字だけ見れば「無料で 14% 得した」という話になる。
実際には 372 フレーム、全体の 20% が消えている。私の測り方が、それを見る能力を持っていなかっただけだ。
この一件が、今回の検証で一番学びになった部分だった。画面録画を十数回圧縮して、ビットレート・解像度・フレームレート・コーデックの四つを一つずつ動かした記録を書くが、結論と同じくらい「何を測れていなかったか」を書いておきたい。
素材と前提
使ったのは実在の会議でも製品デモでもなく、自作した架空の管理画面の録画。ブランド名も SKU も倉庫名も金額も全部作り物で、11 px の等幅 SKU コードと 13 px の商品名をわざと入れてある。画面録画を圧縮したとき最初に壊れるのは、この手の小さい文字だからだ。62 秒、1920×1080、30 fps、音声トラック付き、310,087,773 バイト（画面表示は 295.7 MB）。
ここで一つ、後の全パーセンテージが乗っかっている前提を先に書く。この元ファイルは QP 14・keyint=1、つまり全イントラで撮ってある。 合成フレームは静止部分が完全に同一なので、CBR 42 Mbps でも 18 MB、CRF 12 でも 10 MB にしかならず、三桁 MB にするには全イントラにするしかなかった。これは QuickTime 系の画面録画ソフトが軽圧縮で吐く形そのものでもある。逆に言えば、録画ソフト側が既にフレーム間予測をかけていれば元ファイルは十数 MB で、削れる余地はずっと小さい。
圧縮側は ImgIng（ https://imging.ai/ ）のブラウザ内動画圧縮を使った。画質段階・解像度・フレームレート・出力形式が独立したプルダウンになっていて、三つ固定して一つだけ動かせる。単変量で比べるにはこの形が要る。実行環境は M4 の Mac 一台なので、以下の秒数はこの機械限定の値として読んでほしい。
測定側は、固定の壁時計タイムスタンプで 10 フレーム抜いて PSNR を取る方式。フレーム番号では抜かない（出力側でフレームレートが変わり得るため）。解像度が変わった出力は LANCZOS で元サイズに戻してから比較する。加えて、表の小さい文字の領域だけを切り出して横方向の隣接差分の平均をシャープネスとして取った。文字の輪郭が残っていれば高く、潰れれば下がる。
何も変えない一回目で、すでに 92.8% 減
取り込んで押すだけ。9.2 秒で 21.34 MB、元の 7.21%。
重要なのは「何を変えなかったか」のほう。出力は 1920×1080 @ 30 fps のまま、1860 フレーム全部あり、62.08 秒、音声も残っている。削減は全部ビットレートから来ている（40 Mbps → 2767 kb/s）。PSNR 46.17 dB、SSIM 0.9989、文字領域だけなら 43.45 dB。48 秒地点を 3 倍に拡大して一文字ずつ見ても、元ファイルと区別がつかない。
普通はここで終わりでいい。終われなかったので、残りの十数回がある。
画質段階＝ビットレートのつまみ
このツールにビットレート入力欄はなく、四つの画質段階がそのままビットレートに相当する。解像度とフレームレートを「元のまま」に明示的に固定すると、四段階すべて 1920×1080 @ 30 fps で出力され、違うのはビットレートだけ：2767 / 2502 / 2212 / 1925 kb/s、サイズは 21.34 / 20.32 / 18.07 / 15.84 MB。端から端まで動かして追加で 29% 減る。
代償は文字領域の PSNR で 0.42 dB、シャープネスは四段階とも 4.13（元ファイル 4.15）で動かない。
ついでに二つ。「容量優先」段階の説明には「長辺 1080 px 以下・最大 24 fps」と書いてあるのに、プルダウンで元解像度・元フレームレートを明示選択すると 1920×1080 @ 30 fps のまま出てくる。明示選択が段階側の上限を上書きする。そしてもう一つ、「スマート推奨」段階のほうが「視覚的ほぼロスレス」段階より大きい（21.34 対 20.32）。名前から受ける印象が逆だ。
解像度を下げたら 26.6% 大きくなった
次が解像度。長辺 1920 を 1280 へ。画素数は 44% になる。
出てきたのは 25.73 MB。同じ段階・同じフレームレートで解像度だけ元のままの対照が 20.32 MB。26.6% 大きい。パラメータを確認し直してから信じた。原因はビットレート側で、1280 の選択肢には 3200 kb/s が割り当てられていて、元解像度側の 2502 kb/s より高い。画素は減り、毎秒のビットは増える。
解像度とビットレートが独立した二つの予算だと考えれば、理屈としてはおかしくない。困るのは画質のほうで、文字領域の PSNR は 43.41 から 29.13 へ、一段で 14.28 dB 落ちる。シャープネスは 4.13 から 2.81。さらに長辺 854 まで下げると、SKU コードと商品名はもう読めない。「ぼやけた」ではなく、字として判別できない。
つまり今回一番気まずい偶然はここにある。小さい文字を壊した唯一のステップが、容量を返してくれなかった唯一のステップでもある。
測っていないものは語れない
冒頭のフレームレートの話に戻る。30→24 で 14.4% 減り、PSNR もシャープネスも動かない。だがこの「動かない」は、抜きフレーム比較がコマ落ちに対して構造的に無感だから出ている値だ。両方の動画の同じ時刻を取れば、その瞬間はどちらも静止した表であり、一致して当然になる。
実際のフレーム数は 1860 対 1488。372 枚、ちょうど 20% が消えている。失われたのはカーソルの動きと表スクロールの連続性で、私はそれを測る指標を今回ひとつも用意していない。だから書けるのは「14.4% 小さくなった」までで、「フレームレートを下げても画質は落ちない」とは書けない。この二つの文の間には、まだやっていない実験が一式ある。
最後に残っていたのが出力形式だった。段階・解像度・フレームレートを全部固定して、コンテナとコーデックだけ変える。VP9 は 24.32 MB で H.264 より 19.7% 大きい（得たのは 0.68 dB）。AV1 は 6.40 MB、同じ 1920×1080 @ 30 fps・同じ 1860 フレームで H.264 比 67% 減、文字領域の PSNR は 0.74 dB しか落ちず、シャープネスは 4.09。
シャープネスの列を縦に見ると話は単純で、最低段階 4.13、24 fps 4.13、VP9 4.14、AV1 4.09 と元ファイルの 4.15 付近に張り付いたままなのに、解像度を動かした瞬間 2.81、1.36 と落ちる。
一本の動画で一度ずつ試しただけなので、VP9 が一般に劣るとも AV1 が常に最小だとも言うつもりはない。AV1 は実行時の機能検出を通った端末でのみ選べる仕組みで、この機械では通って動いたが、通らないときに UI がどう見えるかは確認できていない（手元の Chromium は二種類とも対応と返してきた）。出力三本をローカルの <video> に載せて三つのエンジンで再生位置が実際に進むところまでは確認したが、アップロード先での再エンコード結果は一つも試していない。相手の環境が読めないなら MP4 / H.264 が依然として考えなくていい答えだ。
順番としては、コーデック → フレームレート → 画質段階 → 最後に解像度。前の三つは合計しても 1 dB 未満でシャープネスは無傷、解像度だけが文字を壊し、しかも中間段階では容量的にも損をする。ただしこの結論が効くのは「大部分が静止・文字が多い・動きは局所」という種類の映像に対してだけで、同じ既定設定で別の自作サンプルを通すと、スライド型の会議録画は 40.7%、全画面が毎フレーム変化するクリップは 45.9% で PSNR は 26.52 dB まで落ちた。「画面録画は 9 割減る」は画面録画という素材の性質であって、動画圧縮一般の話ではない。