WebM を AVIF に変換

AVIF がその手間に見合うのは、画像の容量が実際に誰かが見ている数値であるときだけです。下がらない Largest Contentful Paint の数値、パフォーマンス予算の中のページ容量の目標、プルリクエストで議論になっている Lighthouse のスコアなど。それらが当てはまらないなら、同じフレームの WebP 版は JPG より小さく、瞬時に符号化でき、フォールバックも要りません。それを使って先に進んでください。

予算が本物なら、AVIF は手に入る中でもっとも強力な選択肢で、ヒーロー画像や大きなポスターフレームでの差はわずかではありません。代償は 2 度払われます。いまは符号化の時間として、あとはマークアップの中のフォールバックとしてです。どちらも扱いやすいものですが、どちらも無料ではありません。そうではないふりをするページは、必要のない複雑さを売りつけているだけです。

AVIF は新しい画像コーデックではありません。動画コーデックからの単一のキーフレームである AV1 のイントラフレームを、HEIC と同じコンテナー一族に包んだものです。そして AV1 は WebM が運べるコーデックの 1 つで、新しいブラウザーの録画機能や現代的な Web 動画の多くがそれを使っています。

つまり元データが AV1 の WebM なら、この変換は AV1 が符号化したフレームをデコードし、それをもう一度 AV1 に渡して静止画として符号化させることになります。この往復はめずらしく好都合です。1 回目の処理が持ち込むノイズが、まさに 2 回目の処理が効率よく記述できる形だからです。可逆ではありません。間でフレームは完全に画素へデコードされます。それでもこの一群の中では一族内の変換にもっとも近いもので、動画からの AVIF の静止画が小さい容量でもよく持ちこたえる理由の 1 つです。

JPG や WebP はほぼ即座に現れます。AVIF は数秒かかり、そこそこの性能のノートパソコンで 4K のフレームでは数秒以上かかることもあります。これはページが遅いのではなく、AV1 の符号化にかかるコストです。

理由は探索です。AV1 は各画素ブロックを記述する膨大な数の方法から効率を得ており、エンコーダーはそのうち非常に多くを試してから選びます。100 万回配信されるファイルにとっては良い取引ですが、一度だけ見るファイルにとっては割に合いません。30 枚のフレームを変換して待たされているなら、それはサムネイルには WebP を使い、AVIF はページ上部の 1 枚のために取っておくべきだという合図です。

フレームは動画自身の画素寸法のまま、拡大縮小されずに、固定の画質 82 で符号化されて出てきます。1080p の録画は 1920×1080 の AVIF を、4K のキャプチャーはその 4 倍の面積を持ち、作るのにかなり時間がかかるものを生みます。

リサイズはここではなく、あとで行ってください。レスポンシブなソースを生成する仕組みは、あなたのレイアウトが必要とする幅を知っており、縮小済みのフレームより完全なフレームから始めたほうがよい結果を出します。AVIF では、いくつのサイズが符号化の時間に見合うかを決める場所でもあり、これは JPG では問題にならない、本物の問いです。

現行の主要なブラウザーはどれも AVIF をデコードできますが、対応は WebP より何年も遅れて実現しており、とくに更新を受け取らなくなった機器では、古いインストールがいまも残っています。AVIF だけを配信することは、そうした訪問者を遅くするのではなく、画像そのものを失わせるという判断です。

対処法は、AVIF のソースと WebP のソース、最後の <img> に JPG を持つ <picture> 要素です。3 行で JavaScript も要らず、ブラウザーは自分が理解できる最初のものを選びます。他の画像ですでにそれを行っているなら、このフレームも同じパイプラインに収まります。行っていないなら、それを加えることが AVIF をそもそも使うための前提条件です。

圧縮された動画から取り出された静止画は、動画コーデックがそれに対して行ったことをそのまま運びます。ビットは動きに費やされ、色は各方向で半分の解像度で保存され、スクロールやパンの最中に撮られたフレームはそもそも鮮明には符号化されていません。AVIF はそれらすべてを非常に効率よく保存しますが、何も修復しません。

実務上の帰結は、タイムスタンプが形式より重要だということです。静止した瞬間に撮って JPG で保存したフレームは、動きの途中に撮って AVIF で保存したフレームを、容量を含むあらゆる点で大きく上回ります。ブレたフレームは細部だらけで、エンコーダーはそれを記述するのにビットを費やさざるを得ないからです。瞬間を選ぶことが最適化であり、コーデックを選ぶことは端数の調整にすぎません。

Web ページ以外のすべてです。メールクライアントはそれを描画しません。オフィスソフトもほとんどそうです。印刷のワークフローもそうです。他人のサイトのアップロードフォームはその拡張子をよく完全に拒否し、AVIF を送られた同僚はたいてい「これは何ですか」と聞き返してきます。

その存在意義のすべては、ブラウザーによってデコードされ、あなたが費用を払っているネットワークを通じて配信されることにあります。スライドや文書、メッセージには JPG を、アーカイブや印刷の仕事には TIFF を使ってください。設計された用途の外で AVIF を使うのは、誰も開けない小さいファイルを作るだけで、最適化にはなりません。

AVIF の符号化は要求が高いので、それを提供するサービスは課金するか待ち行列に入れるか、回数を制限します。ここではブラウザーの中で動くので、上限はドロップゾーンの上に書かれているもの——バッチにつき 100 ファイル、1 ファイルにつき 100 MB——だけで、その裏で消費される 1 日の割り当てはありません。コストはあなた自身のプロセッサーで、その取引に見合うと決めたのはあなた自身です。

これは動画が機械から一度も出ないということでもあります。これはよくあるプライバシーの主張ですが、このペアには実務的な鋭さもあります。40 KB の画像を得るために大きな録画をアップロードするのは、結果に対して馬鹿げた量のネットワーク通信であり、このペアの他のほとんどの変換ツールが実際にそうしている形です。