画面収録の圧縮で、フレームレートを 30 から 24 に落としたら、ファイルは 14.4% 小さくなって、画質の数値は 1 つも動きませんでした。ここだけ見れば「タダで得した」と書きたくなります。実際にはそう書けません。私の測り方が、落ちた分を見られない構造になっていたからです。この話を先に置いてから、残りの 3 つのつまみの話をします。
測定対象を先に書きます。スクリプトで管理画面を描いて収録した 62 秒のクリップで、1920×1080、毎秒 30 フレーム。スケルトンの読み込み、倉庫の絞り込み、モーダル入力、長い表のスクロールが入っています。ブランド名も商品名も型番もすべて架空で、実在のシステムではありません。収録方法が重要で、画面収録ソフトがほとんど圧縮せずに保存するやり方、つまりフレーム間の差分を取らずに 1 枚ずつ丸ごと残す形にしてあります。だから 295.7 MB あります。以下の削減率はすべてこの前提の上にあります。 収録ソフトの時点で一度圧縮されているクリップなら、絞れる余地はずっと小さくなります。
圧縮には ImgIng（https://imging.ai/ ）を使いました。登録も課金も不要で、処理がブラウザ内で完結するのが理由です。実行中はネットワークパネルを開いていましたが、動画方向の送信は 0 バイトでした。この作業台で触れるのは画質プリセット・解像度・フレームレート・出力フォーマットの 4 つだけです。毎回 1 つだけ変えて残り 3 つは「元のまま」に固定しました。
さてフレームレート、つまり 1 秒間に何枚の絵を出すかです。30 fps なら 1 秒 30 枚。プルダウンには 60 と 30 と 24 しかありません。30 から 24 にすると 20.32 MB が 17.39 MB になり、小さい文字の鮮明さを表す数値は 4.13 のまま動きませんでした。この鮮明さは、表の型番がある領域で隣り合うピクセルの明暗差を平均したもので、輪郭が立っているほど大きくなります。数値が動かないのは事実です。ただし 24 fps にした時点で、この 62 秒から 372 枚の絵が消えています。元の 1860 枚の 5 分の 1 です。消えたのは動きの連続性、カーソルが滑らかに動くかどうかの側で、私の比較は固定した時刻でフレームを抜き出して 1 枚ずつ突き合わせる方式なので、コマ落ちに対して構造的に無感覚です。 見つからなかったのではなく、見に行っていません。滑らかさについては測定値がないので、結論を書きません。
残りの 3 つは、もっとはっきりしています。
いちばん効いたのは出力フォーマットでした。フォーマットというのは絵をファイルに符号化するアルゴリズムのことで、ふだんの MP4 には H.264 が入っています。他を一切触らず出力を WebM の AV1 に変えるだけで、20.32 MB が 6.4 MB になりました。さらに 67% です。鮮明さは 4.13 から 4.09 に動いただけで、元素材の 4.15 とほぼ変わりません。同じ回に VP9 も試しましたが、このクリップでは H.264 より 19.7% 大きくなりました。1 本での結果なので一般化はしません。AV1 は常に選べるわけでもなく、その端末で符号化できるかを先に判定してから選択肢が開きます。
3 番目は画質プリセットです。4 段階を上から下まで下げ切ると 22.37 MB から 15.84 MB まで落ちて、さらに 29% 減ります。小さい文字の側は 0.42 dB しか落ちず、鮮明さは 4 段階とも 4.13 のまま。3 倍に拡大して型番を 1 文字ずつ見ても差が分かりませんでした。ひとつ引っかかったのは名前で、「スマート推奨」のほうが 22.37 MB、「視覚的にほぼロスレス」のほうが 20.32 MB です。名前から受ける印象と挙動が逆になっています。
そして解像度。1 フレームに縦横いくつピクセルがあるかという値で、4 つのうち小さい文字を壊すのはこれだけでした。長辺を 1280 に制限すると鮮明さは 4.13 から 2.81 に、854 にすると 1.36 まで落ちて、表の型番はもう読めません。他の 3 つをどう動かしても 4.09〜4.14 の範囲に留まっていたので、落ちるのは本当にここだけです。
しかも 1280 は容量すら得していません。元の解像度のままだと 20.32 MB、「長辺 1280」を選ぶと 25.73 MB で、下げないより 26.6% 大きいのです。画面に出ている数値を読むと理由が分かります。1280 の段にはビットレート、つまり 1 秒分の絵を表現するのに使うデータ量が 3200 kb/s 割り当てられていて、元解像度の段は 2502 kb/s です。画素を 3 分の 1 に減らして、1 秒あたりのデータは増やしている。小さい文字を 14 dB 失って、より大きいファイルを受け取ったことになります。
というわけで順番は直感の逆でした。まずコーデックを替え、次にフレームレートを落とし、次にプリセットを下げ、解像度はいちばん最後です。
最後にもうひとつ、4 つのつまみより前に置くべき判断があります。何を収録したのかを先に見ることです。既定設定のまま、この静止領域が大きい管理画面のクリップは 295.7 MB から 21.34 MB、92.8% 減りました。一方、画面全体が毎フレーム変化するクリップを別に作って同じ設定で通すと 45.9% しか減らず、元素材との差は 46.17 dB から 26.52 dB まで落ちて、見て分かるほど潰れます。スライド形式の会議収録は 40.7% でした。9 割という数字は圧縮の一般的な実力ではなく、「広い静止領域＋文字＋局所的な動き」という素材の性質のほうです。