幹壞事是進步最大的原動力
HN 上「AV1 video codec gains broader hardware support (fullystacked.net)」這篇在說 AV1 的支援度變得更好了，原文不長，在「The AV1 video codec gains broader hardware support」這邊。
在 Can I Use 上的 AV1 video format 可以看的比較清楚：
不過在瀏覽器上離直接取代掉其他的 video codec 還早，但算是個起頭，至少 iPhone 15 Pro 與 iPhone 15 Pro Max 上的 Safari 支援了，接下來就是看桌機的 Edge 什麼時候才又想到要把 AV1 開回來：
Edge has stopped supporting AV1 completely at some point prior to version 116 (additional information required).
Facebook 整理了一份他們採用 AV1 的記錄：「How Meta brought AV1 to Reels」，要注意這邊的產品線是短影片類型。
因為之前剛好也有碰到 codec 這塊，但最後是因為 AV1 在 client 的支援度還跟不上，而選了在 Android 上支援度更好的 VP9。
在文章前面有提到 server 端的需求，也就是 encoder 的部份，這是因為 AV1 的 encoding 真的很慢 (i.e. 外星技術)，還在每過幾個月就會看到 encoder 技術重大突破的階段，所以得花時間去研究。
Facebook 後來決定用 SVT-AV1，因為效能上好很多 (以他們測試的那個時間點)：
At any given point on the y-axis, SVT-AV1 can maximize encoding speed compared with any other production encoder. For example, the M8 preset is about as efficient as libvp9 preset 0, but M8 is almost 10 times faster.
而在 client 端的 decoder 部份，他們評估了 dav1d 與 libgav1 之後，選擇用 dav1d (iOS 與 Android 都是)：
Two major open source software decoders are compatible with multiple platforms: dav1d was developed by VideoLAN and the open source community and can serve as an app-level decoder, while Google’s libgav1 is integrated into the Android SDK.
[W]e decided to integrate dav1d into the player for both iOS and Android platforms.
但在軟解的情況下只能解 720p30，然後中高階的才能解 1080p30，不過這對於短影片來說夠用：
dav1d can support 720p30 real-time playback on most of the devices in our sample, achieving 1080p30 on certain mid-range and high-end models.
所以就 Facebook 目前提供的資料來看，這部份還沒到輕鬆應對的情況，還得繼續看各家 library 的進展...
在翻資料的時候翻到「Google Releases AOM-AV1 3.5 With More Speedups & Memory Optimizations」這篇，講 AOM-AV1 v3.5.0 的效能改善，看了 v3.4.0 的 changelog 可以看到最主要的大幫助是有 multithreading 的支援，但不確定跟其他的 AV1 library 相比可以有多快...
印象中 (好幾個月前的印象) 目前最快的應該是 SVT-AV1？記得 dav1d 有宣稱很快但不是 apple-to-apple 比較，比較像是 marketing 上的宣稱。
先前測試 AV1 在 Android 上的支援度與效能，記得在老一點的手機上軟解還是很辛苦啊，最後還是先選了 VP9 用，硬體解碼支援度比較廣，加上軟解需要的 CPU resource 也低不少。
目前有丟出來的 FFmpeg 執行包都會因為軟體授權不相容的問題，沒辦法把想要的東西都包進去 (或者無視授權丟出來 XD)，但反正看一看沒看到適合的，所以弄了一天包了一包出來。另外也是因為同樣理由，這邊也只能提供步驟讓大家自己編...
我的主力放在 AV1 與 VP9 的支援上，步驟就寫在「FFmpeg」這邊了，裡面是先開了一個 Docker container 再去裝環境，接著再把會用到的 source code 用 git clone 拉下來再固定版本，所以應該是不會有太大的意外。
另外可以看到 libfdk-aac 與 libx264 兩包我就直接拉系統的套件來包，主要是查了一下版本還算堪用，而且也不是主力要處理的東西，就不想要再自己拉下來編了。
這邊就是整理一下感想...
首先是 Rust 一直在推新功能，然後各家的軟體也幾乎就是馬上跳進去用這些新功能，所以只能用 rustup 跟到最新版的 Rustc 去編 rav1e。
然後 x265 搞不定 static compile 的問題，卡在沒有 libgcc_s.a 可以用，如果還要搞 GCC 的話就太累了...
這樣在 AV1 與 VP9 的支援度就比較完整了，另外內建 libvmaf 也可以拿來分析...
看到「How to Use AVIF: The New Next-Gen Image Compression Format」這篇在推銷用 AVIF 取代 JPEG 與 WebP。
首先是跑去 Can I Use 翻，發現 Google Chrome 85 之後支援了，另外在「Issue 960620: Support AVIF」這邊可以看到對應的 ticket，以及「AVIF Image Decode」這邊有狀態：
Enabled by default (tracking bug) in:
Chrome for desktop release 85
現在的 stabel channel 是 84，所以是下個 release 就會有了。以 Google Chrome 的市占率來說，推出來等於是支援度直接過半... 這點也的確有人批評，不過又是另外一個話題了。
對於不支援 AVIF 的瀏覽器，也有對應的 polyfill 可以上 (用 javascript 去補功能)，不過因為是透過 AV1 codec，能夠向下支援的版本還是不多，除非連 AV1 都透過 polyfill 支援：「AVIF (AV1 Still Image File Format) polyfill for the browser」。
另外在寫「WebP 的檔案大小未必比 JPEG 小...」這篇時有提過 AVIF 其實也不是完美的，畢竟是從 video codec 演化來的演算法，對於演算法判斷不重要的部位會掉比較多細節...
在「Is WebP really better than JPEG?」這邊發現在差不多的條件需求下，WebP 壓出來的檔案大小未必會比 JPEG 小。
先講結論：提供服務的人可以先確認自家的 JPEG 壓縮是不是有先用 MozJPEG (壓縮率更好)，然後再考慮要不要支援 WebP。
Google 在推 WebP 這個格式的時候，宣稱失真壓縮的部份可以比 JPEG 小 25%～34%：(出自「A new image format for the Web」)
WebP lossless images are 26% smaller in size compared to PNGs. WebP lossy images are 25-34% smaller than comparable JPEG images at equivalent SSIM quality index.
但作者發現 Google 之所以可以達到 25%～34% 這個數字，是因為比較的對象是 Independent JPEG Group 所釋出的 cjpeg，而如果拿 MozJPEG 相比的話應該得不到這個結果，另外也把 AV1 的 AVIF 拉進來一起測試了：
I think Google’s result of 25-34% smaller files is mostly caused by the fact that they compared their WebP encoder to the JPEG reference implementation, Independent JPEG Group’s cjpeg, not Mozilla’s improved MozJPEG encoder. I decided to run some tests to see how cjpeg, MozJPEG and WebP compare. I also tested the new AVIF format, based on the open AV1 video codec. AVIF support is already in Firefox behind a flag and should be coming soon to Chrome if this ticket is to be believed.
這邊作者測試用的圖集是 Kodak Lossless True Color Image Suite，測試的結果發現 WebP 的確比 libjpeg (cjpeg) 好一些，但沒有像 Google 講的那麼多 (這邊就不知道是不是現在的 libjpeg 又有改善)，而 WebP 與 MozJPEG 相比的話就沒有明顯優勢了：
WebP seems to have about 10% better compression compared to libjpeg in most cases, except with 1500px images where the compression is about equal.
However, when compared to MozJPEG, WebP only performs better with small 500px images. With other image sizes the compression is equal or worse.
I think MozJPEG is the clear winner here with consistently about 10% better compression than libjpeg.
另外也提到了 AVIF 的壓縮率很好，不過要注意演算法會把非重點部位的細節吃掉：
I think AVIF is a really exciting development and compared to WebP it seems like a true next-generation codec with about 30% better compression ratio compared to libjpeg. Only concern I have is the excessive blurring of low detail areas. It remains to be seen if this can be improved when more advanced tooling becomes available.
對網頁的應用來說，WebP 另外一個痛點是在 Safari 上的支援度，在 caniuse.com 的「WebP image format」這邊可以看到目前各瀏覽器都支援了，就剩下 Safari 還不支援，所以目前在 iOS 上得降回 JPEG：
不過這點之後也改變了，在 iOS 14 beta 裡的 Safari 可以看到支援 WebP 了：「Safari 14 Beta Release Notes」。
Media
New Features
Added WebP image support.
所以這個狀況變得有點微妙了...
在「2020/03/17 - AWS Elemental MediaConvert - 11 updated api methods」這邊看到的：
AWS Elemental MediaConvert SDK has added support for: AV1 encoding in File Group MP4, DASH and CMAF DASH outputs; PCM/WAV audio output in MPEG2-TS containers; and Opus audio in Webm inputs.
翻了一下同個站台的總表「AWS Elemental MediaConvert」這頁，看起來是第一次支援 AV1 輸出，這對於很在意頻寬的應用方便不少，另外翻了一下 Can I Use 這邊的資料「AV1 video format」，看起來也已經有不少環境可以用 AV1 了 (又看到 Safari，真不愧是 2020 年的 IE6)：
另外可以參考「Netflix Now Streaming AV1 on Android」這篇，Netflix 在今年稍早的時候也決定在 Android 平台上採用 AV1。