AOMediaCodec

MPEG-2 TS support for AV1 Hi guys. It seems that AV1 support in MPEG-2 TS is almost here. I've been waiting for years. AOMediaCodec/av1-mpeg2-ts Maybe next year we'll see some TV channels changing their official online broadcasts from AVC to AV1. Looking forward for the FFmpeg implementation, then I could use Dispatcharr to transcode to AV1 the local streams that I get from DVB tuners with TVHeadend.

AV2 decode speed: 5 decoders (dav2d, splot, avmdec, rav2d, rusty_av2d) benchmarked on x86 (AVX2) and Arm64 (NEON) I benchmarked five AV2 decoders, all at their 2 Nov HEAD, on 88 sample streams from 270p to 2048x1080. The machines were an i5-4590 (AVX2) and a Raspberry Pi 4B. Every decode was checked against the reference decoder, avmdec. Only dav2d and splot matched avmdec on all 88 streams; rav2d and rusty_av2d mostly failed or gave wrong output. On x86, dav2d is fast on 8-bit (2.4x avmdec on one thread) but slower than avmdec on 10-bit (0.63x), because its asm covers 10-bit much less. On the Pi, splot is fastest on one thread, while dav2d's NEON code gives it only about 1.3x over its own C build (about 4.5x for asm on x86). avmdec gets nothing from extra threads on single-tile streams. dav2d and splot get about 2-3.4x on 4 threads. At 1080p, only dav2d on the PC is clearly real-time. The full write-up, raw data and scripts are at the link. | 1 thread, vs avmdec | 8-bit | 10-bit | |---|---|---| | dav2d, PC | 2.44x | 0.63x | | splot, PC | 1.11x | 0.95x | | dav2d, Pi | 1.96x | 1.69x | | splot, Pi | 2.79x | 3.00x | | 1080p fps, 4 threads | | | | dav2d, PC | 85 | 27 | | splot, PC | 42 | 34 | | avmdec, PC | 14 | 12 | | splot, Pi | 9 | 9 | **Full report: github.com/EwoutH/AV2/tree/main/perf/2026-11-02-a… Decoders: - avmdec: AVM av2-enc d953d2e. - dav2d 9b5d2f6e. - rav2d 0.4.2 cf41e91. - rusty_av2d 9c8f6e6. - splot b682f58.

JPEG XL vs AVIF na web: comparei 24 fotos na mesma qualidade percebida; o resultado muda conforme a qualidade-alvo O Jake Archibald publicou esta semana uma comparação longa de JPEG XL e AVIF para uso na web, e hoje o Jyrki Alakuijala, co-designer do JPEG XL, escreveu no X uma posição diferente em parte. Rodei um teste pequeno antes de postar e o resultado ajuda a entender por que os dois podem ter razão. Contexto - Segundo o caniuse, o JPEG XL tem suporte no Chrome 155+ e no Firefox 158+, e parcial no Safari. O artigo do Jake parte disso: "JPEG XL has now landed in all major browsers". - Ele comparou AVIF (avifenc 1.4.2), JPEG XL por dois encoders (libjxl 0.12.0 e o jixel 0.4.2, mais novo) e WebP, medindo qualidade com SSIMULACRA2 e ColorVideoVDP. O que o Jake diz - Fotos com perda: o AVIF quase sempre gera arquivos menores. No esforço padrão, o melhor JPEG XL fica tipicamente 15% a 25% maior; no esforço máximo, 6% a 20%. - Screenshots, ilustrações e transparência: vantagem maior do AVIF. Sem perda: JPEG XL vence com folga. - Decode: JPEG XL leva 2 a 3x mais tempo em qualidade média, diferença que cai em qualidade muito alta. - JPEG existente: o JPEG XL reduz de 9% a 20% sem perda. - Recomendação dele: AVIF 4:4:4 como padrão, no maior esforço viável; olhar o JPEG XL via jixel quando o AVIF sair grande demais. E não usar 4:2:0 como padrão. O que o Jyrki diz - "AVIF can work well at quality 60 and below." Acima de 85, que ele chama de qualidade mediana da internet, o JPEG XL "works far more reliably". O que eu conferi - 24 fotos do conjunto Kodak (768x512), q de 20 a 99, 1.539 encodes, esforço padrão: avifenc -s 6 -y 444, cjxl -e 7 e jixel com a velocidade padrão. Tamanho interpolado na mesma nota SSIMULACRA2, mediana por imagem; "melhor JPEG XL" é o menor entre libjxl e jixel. - SSIMULACRA2 50 a 85: o AVIF ganhou por pouco. O melhor JPEG XL saiu de 0,7% a 7,6% maior (mediana). - SSIMULACRA2 90, que o Jake classifica como visualmente sem perda: o JPEG XL ficou menor em 19 de 24 fotos, mediana de 10,6% a menos. - O mesmo q 80 deu nota mediana 84 no AVIF, 77 no libjxl e 64 no jixel. Em q 90: 89, 86 e 82. - JPEG q85 convertido para JPEG XL sem perda: mediana de 14,1% menor, e as 24 voltaram idênticas byte a byte (sha256). O que isso é (e o que não é) - É um indício de que a resposta depende da qualidade-alvo, coerente com o que o próprio Jake mostra num exemplo ("JPEG XL catches up at very high quality"). - Não é um contra-benchmark. Usei só o esforço padrão, fotos pequenas e antigas (scans de filme), uma métrica e uma máquina. No conjunto do Jake, com imagens de 1598 px, a diferença a favor do AVIF foi maior. - O "quality 85/90" do Jyrki é configuração de encoder, não nota SSIMULACRA2. Não dá para ligar uma coisa à outra direto, e o item do q 80 mostra o tamanho do problema. Onde eu fico Para foto em qualidade média ou alta, o AVIF 4:4:4 continua sendo um padrão razoável. Se o site serve imagem muito perto do original, ou se o acervo já é JPEG, vale medir JPEG XL. Em qualquer caso, a comparação tem que ser na mesma nota de uma métrica, não no mesmo número de quality. Links - Artigo do Jake: jakearchibald.com - Jyrki no X: x.com - caniuse: caniuse.com - Encoders: AOMediaCodec/libavif · libjxl/libjxl · awxkee/jixel Perguntas 1. Em que qualidade vocês servem imagem hoje, e como chegaram nesse número? 2. Alguém já mede com SSIMULACRA2 (ou outra métrica) no pipeline, ou o quality é escolhido no olho? 3. Para quem tem acervo grande em JPEG: a conversão sem perda para JPEG XL já está no radar?

It's part of libavif. I've usually compiled it myself. aomediacodec/libavif avifenc supports args like enable-chroma-deltaq. I've used those but recently stopped, and nothing substantial changed.

> I think one overlooked aspect is that AVIF is container based. Many other image formats are. AVIF uses HEIC, the same container that HEIF does. > when AV2, AV3 etc. will come out, there won't be a need to go through another very difficult phase of sites adoption - it will still be AVIF just with newer codec inside, and it will be just up to browsers to catch up on newer versions and newer codecs will address technical needs as times goes. Fingers crossed, but AV2-based AVIF specs haven't even been finalized, so who knows. AOMediaCodec/av2-isobmff

Chromeが2022年に外したJPEG XLに、なぜ4年後に対応し直したのか 2026年10月6日に公開されたChrome 155で、JPEG XLという画像形式の表示に対応しました。GoogleはChromeでこの形式を一度試したうえで、2022年に「既存の形式に対して利点が足りない」としてコードごと外しています。同じ形式に、4年たって対応し直したことになります。 主要なブラウザでも、JPEG XLが表示できる環境が揃いつつあります。Safariは2023年から対応していて、Firefoxも10月13日に公開された158で、JPEG XLを初期設定で表示するようになりました。 読み終える頃には、JPEG XLが何を得意とする形式なのか、Googleが一度外した理由と対応し直した理由、AVIFやWebPとどう使い分ければよいのかを、自分のサイトや手元の画像に当てはめて考えられるようになると思います。 JPEG XLは、手元のJPEGを画質を落とさずに約20%小さくできる JPEG XLは、JPEGを策定してきた委員会が作った新しい画像形式で、国際規格ISO/IEC 18181として2021年から2022年にかけて発行されました。委員会は2018年4月に提案を公募し、2019年1月にGoogleのPIKとCloudinaryのFUIFという2つの提案を統合して1つの形式にすることを決めています。目標は、JPEGより60%以上効率よく圧縮することでした。 JPEG XLの特徴のうち、AVIFやWebPにないのは、今あるJPEGファイルを画質を一切落とさずに作り直せることです。平均で約20%小さくなり、必要なら元のJPEGとまったく同じファイルに戻すこともできます。ウェブにはこれまで撮りためたJPEGの写真が大量にあります。AVIFやWebPに変えるには一度画像を展開して圧縮し直す必要があり、そのたびに少しずつ画質が落ちますが、JPEG XLならその心配がありません。 ほかにも、1つの形式で次のことに対応しています。 - 画質を落とさない可逆圧縮と、ファイルを小さくする非可逆圧縮の両方 - 読み込みの途中から粗い画像を表示し、徐々に細かくしていくプログレッシブ表示 - HDR（PQとHLGの両方式）と広い色域 - 透明度（アルファチャンネル）、アニメーション、レイヤー - 画像の配信向けのLevel 5で、最大2億6843万画素、1辺26万2144ピクセル、1チャンネル16ビットまで。上位のLevel 10では、1辺が約10億ピクセル、1チャンネル32ビットまで扱える 2022年のChromeは、利点が足りず関心も広がっていないとして対応を外した ChromeがJPEG XLを試し始めたのは2021年です。3月にGoogleの開発者が、初期設定では無効にした実験用のフラグの中でJPEG XLを表示できるようにすると表明し、Chrome 91前後から、フラグを有効にすればJPEG XLを表示できるようになりました。 ところが2022年10月末、Chromiumの課題管理システムに、このフラグとコードを外すという方針が書き込まれました。報道で引用された理由は、次の4つです。 - 実験用のフラグとコードを、いつまでも残しておくべきではない - エコシステム全体に、JPEG XLの実験を続けるだけの関心がない - 既存の形式に対して、初期設定で有効にするほどの利点がない - Chrome 110でフラグとコードを外せば、保守の手間が減り、既存の形式の改良に集中できる この方針には、開発者向けのメーリングリストで反論が相次ぎました。投稿の中では、Facebook、Adobe、Intel、Shopify、The Guardian、Cloudinaryなどが、すでにJPEG XLを使う準備を進めていると挙げられています。それでも判断は変わらず、2022年12月にChrome 110に向けてコードが削除されました。Googleの担当者は、判断の材料として圧縮の性能、表示の速度、作るときの計算コスト、既存の形式を改良すれば足りるかどうか、ほかのブラウザやOSが対応しているかを挙げ、どうしても使いたい場合はWebAssemblyで表示する方法を勧めていました。 ほかのブラウザとPDFが先に動き、条件だった安全性にも答えが出た Chromeが外した翌年の2023年9月、AppleはSafari 17でJPEG XLに対応しました。iOS 17、iPadOS 17、macOS Sonomaなどに加え、アプリの中でウェブページを表示する部品でもJPEG XLを表示できます。ただしcaniuseの記録では、アニメーションとプログレッシブ表示には今も対応していません。 Mozillaも、2024年9月にFirefoxとしての見解を書き換えました。評価そのものは賛成でも反対でもない中立のままですが、メモリ安全なデコーダ（画像ファイルを読み解いて表示できる状態に戻すプログラム）であれば、Firefoxに組み込むことを受け入れるとしています。そのデコーダを、Google ResearchがプログラミングのRust言語で作ることにも合意しました。 2025年11月には、PDFの規格を扱う業界団体のPDF Associationが、同団体のカンファレンスで、HDRに対応する画像形式としてJPEG XLを第一候補に選んだと報じられました。ブラウザの互換性をそろえるために各社が毎年取り組む項目を決めるInterop 2026でも、JPEG XLは本格的に取り組む分野ではなく、調査を進める項目として入りました。 こうした動きを受けて、2025年11月、GoogleのRick Byersが、Chromeの技術責任者たちを代表して、2021年に始まった元のスレッドに投稿しました。Safariが対応したこと、Firefoxが見解を改めたこと、PDFが採用を表明したことに加え、バグへの投票やInteropの提案に開発者の要望が出ていることを挙げ、性能がよくメモリ安全なJPEG XLのデコーダをChromiumに組み込む提案を歓迎すると書いています。初期設定で有効にするには、通常の出荷基準を満たしたうえで、長く保守し続けることの約束が要る、という条件付きです。 その後の流れは次のとおりです。 - 2025年12月: Rustで書かれたデコーダjxl-rsを使う形で、Chromeの新機能として登録された - 2026年2月10日: Chrome 145で、実験用のフラグを有効にすれば表示できるようになった - 2026年8月24日: 出荷の提案が開発者向けのメーリングリストに出され、同じ日に承認に必要な3人の賛成がそろった - 2026年10月6日: Chrome 155で出荷。Android版と、アプリの中でウェブページを表示するWebViewも同じバージョンで対応した Firefoxも同じ8月24日に出荷を提案しています。デコーダはChromeと同じjxl-rsで、アニメーションとプログレッシブ表示に対応し、HDRの画像は通常の明るさの範囲で表示します。Firefox 152から試験機能の設定画面で有効にできるようになり、当初は157で出荷する予定でしたが、9月に158へ延期されました。 画像デコーダをRustで書き直したのは、画像ファイルが攻撃の入り口になるから GoogleもMozillaも、対応の条件としてメモリ安全なデコーダを求めました。画像のデコーダは、ウェブ上の誰かが作ったファイルをそのまま読み込んで解析するプログラムです。細工されたファイルを読み込ませると、プログラムが想定していないメモリの範囲を書き換えてしまうことがあります。 2023年9月に公開されたCVE-2023-4863がその例です。WebP画像を表示するライブラリlibwebpのバージョン1.3.2より前のものと、Chrome 116.0.5845.187より前のものには、ヒープバッファオーバーフローという欠陥がありました。細工したHTMLページを開かせるだけで、メモリの範囲外に書き込みができる欠陥です。Chromeのブログはこの件に触れていませんが、新しい画像形式を加えることは、同じ種類の欠陥が入り込む場所を1つ増やすことでもあります。 Chromeのブログでは、画像のデコーダは最も狙われやすい攻撃対象の一つで、C++で書いたものには脆弱性が出やすいので、Rustで書くことでこの種類の欠陥をそもそも起きないようにする、と説明しています。Chromeが別に持っているサンドボックス（プログラムを隔離して動かす仕組み）は、二段目の防御という位置付けです。ファジング（大量の壊れたファイルを自動で読み込ませて欠陥を探す試験）とAIによるコードレビューを重ねた結果、メモリ安全性に関わるバグはこれまで見つかっていないとしています。 jxl-rsの開発は2021年5月に始まっています。Rustでも安全性の検査を外して書く部分（unsafeなコード）は避けられませんが、jxl-rsではその部分を、書いた本人とは別のunsafe Rustに詳しい開発者がレビューする決まりにしています。最新版は2026年9月17日の0.7.4です。規格の参照実装は今もC++のlibjxlで、こちらは7月1日に0.12.0が出ています。 画像処理の分野では、速さを優先してC++で書かれたライブラリが長く使われてきました。新しい形式に対応するたびにC++のコードを増やすのではなく、ブラウザに入れる段階でRustで書き直すという順番は、ほかの画像形式や動画形式のデコーダにも広がっていくと思います。 AVIFとの比較では、画質の高さで有利な形式が入れ替わる 新しい画像形式として先に普及したのは、動画形式AV1をもとにしたAVIFです。どちらを使うかは、画像の種類と画質の目標で決まります。ここで紹介する比較は、どれもJPEG XLの開発者が出したものなので、その前提で読む必要があります。 Cloudinaryが2024年2月に公開した比較では、libavif 1.0.3とlibjxl 0.10.0を既定の速度設定と8スレッドで動かし、SSIMULACRA2という、人の見た目に近い画質の指標で同じ点数になるように圧縮して、ファイルの大きさを比べています。 - 60点（中程度の画質）: JPEG XLとAVIFのファイルの大きさは同じくらいで、圧縮にかかる時間はJPEG XLのほうが大幅に短い - 90点（元画像と見分けがつかない画質）: AVIFは従来のJPEG（libjpeg-turbo）より20%小さく、JPEG XLはそのAVIFよりさらに20%小さい。圧縮の速さはJPEG XLが2.5倍 2025年6月にJPEG XLの開発者を中心とする12人が公開した論文では、49枚の画像をCVVDPという別の画質指標で比べています。低い画質ではAVIFとJPEG XLはほぼ同じで、高い画質ではJPEG XLが10〜25%効率よく圧縮できました。HDR画像を集めた別のセットでも、同じ指標で、ごく低い画質ではAVIFが有利、中程度から高い画質ではJPEG XLが約20%有利でした。一方、人が見比べた主観評価の傾向では、イラストや図表、文字のような写真以外の画像でAVIFのほうが20〜30%効率がよく、室内の写真でもAVIFがわずかに上回っています。 形式の仕様にも違いがあります。AVIFの基本のプロファイル（Baseline Profile）では、1枚の画像として圧縮できるのは約890万画素（4K相当）まで、幅は8192ピクセル、高さは4352ピクセルまでで、それより大きい画像は複数のタイルに分けて作ります。プログレッシブ表示は任意の機能です。WebPは1辺16384ピクセル（非可逆圧縮では16383ピクセル）が上限です。 この結果からは、使い分けの方法が見えてきます。写真を高い画質のまま配信したいサイトや、既存のJPEGを大量に抱えているサイトでは、JPEG XLを試す価値があります。図やイラスト、画質を落としてでも小さくしたいサムネイルは、AVIFのままにしておく方法があります。どちらが有利かは画像によって変わるので、自分のサイトの代表的な画像を何枚か両方の形式で圧縮して、大きさと見た目を比べるのが確実です。 今のところ、JPEG XLだけで配信できるわけではない Chrome 155とFirefox 158がそろっても、JPEG XLを表示できない環境はしばらく残ります。caniuseのデータでは、Chromeと同じChromiumをもとにしたMicrosoft Edgeは154まで非対応で、155以降の対応はまだ記録されていません。Safariはアニメーションとプログレッシブ表示に対応していません。ブラウザの利用率で見ると、10月13日時点では完全に対応している環境が0.02%、一部対応が16.93%で、Chrome 155の利用者はまだこの数字に反映されていません。 そのため当面は、HTMLのpicture要素で複数の形式を並べ、ブラウザが表示できる最初の形式を選ばせる方法が現実的です。 <picture> <source srcset="photo.jxl" type="image/jxl"> <source srcset="photo.avif" type="image/avif"> <img src="photo.jpg" alt="商品の写真" width="1200" height="800"> </picture> JPEG XLに対応したブラウザはphoto.jxlを、対応していないブラウザはAVIFかJPEGを読み込みます。同じ画像を3つの形式で用意する手間はかかりますが、libjxlのcjxlを既定の設定で使ってJPEGから変換したファイルなら元のJPEGに戻せるので、JPEG XLを原本として保管しておくこともできます。 画像を作る道具も揃ってきました。ImageMagickはJPEG XLの読み書きに対応し、GIMP 3でも読み込みと書き出しができます。ffmpegは8.0でアニメーションのJPEG XLを書き出せるようになり、libvipsでも読み書きできます。libjxlの0.12.0では、djxlにJPEGへ戻すことを指定する --reconstruct_jpeg が加わり、これを付けると、元に戻せない場合はエラーで止まります。 まとめ 2022年にChromeがJPEG XLを外したときの理由は、既存の形式に対する利点が足りないことと、エコシステムの関心が広がっていないことでした。その後の4年で、Safari、Firefox、PDFが先に対応を表明し、GoogleとMozillaが求めたメモリ安全なデコーダもRustで用意されました。既存のJPEGを画質を落とさずに小さくできるという点は、当時から変わっていません。手元に大量のJPEGがあるなら、まずは自分の画像で、どれだけ小さくなるのかを試してみてもよいのではないでしょうか。 参考文献 - Chrome for Developers, "Shipping JPEG XL in Chrome"（2026年10月6日） developer.chrome.com - Chrome 145 リリースノート developer.chrome.com - Chrome Platform Status, JPEG XL decoding chromestatus.com - blink-dev, Intent to Prototype: JPEG XL decoding support（2021年3月〜） groups.google.com - Chromium, 削除コミット 166a9f3（2022年12月9日） chromium.googlesource.com - The Register, "Google kills forthcoming JPEG XL image format in Chromium"（2022年10月31日） theregister.com - The Register, "PDF spec will adopt JPEG XL – another chance for the format?"（2025年11月10日） theregister.com - Mozilla standards-positions PR #1064（2024年9月） standards-positions#1064 - Mozilla dev-platform, Intent to ship: JPEG XL（2026年8月） groups.google.com - WebKit, "WebKit Features in Safari 17.0"（2023年9月） webkit.org - Interop 2026 github.com/web-platform-tests/interop/blob/main/2… - caniuse, JPEG XL caniuse.com - JPEG, JPEG XL jpeg.org - JPEG XL 作業計画（規格の各パートの版） jpeg.org - Sneyers, J. ほか (2025). The JPEG XL Image Coding System: History, Features, Coding Tools, Design Rationale, and Future. arXiv:2506.05987 arxiv.org - Cloudinary, "JPEG XL and the Pareto Front"（2024年2月28日） cloudinary.com - AVIF仕様 github.com/AOMediaCodec/av1-avif/blob/main/index.… - RFC 9649, WebP Image Format rfc-editor.org - NVD, CVE-2023-4863 nvd.nist.gov - libjxl/jxl-rs libjxl/jxl-rs - libjxl/libjxl libjxl/libjxl

Odd, what are you using to create your avif's? I've done a bunch of work with them and the AVIF's were almost always significantly smaller than webp at equal or better quality. Encoding is a pain, to be sure; I ended up creating a workflow where my source would save things as PNG files (giant, but lossless) then running a avifenc (AOMediaCodec/libavif) to produce the avif, and trashing the PNG. Decoding though, all browsers have support, it's great.