decoder

Google 推出 Jpegli：JPEG 的 encoder 以及 decoder

在 Hacker News 上看到「Jpegli: A new JPEG coding library (googleblog.com)」，原文是「Introducing Jpegli: A New JPEG Coding Library」。

裡面是有提到檔案大小可以更小：

Our results show that Jpegli can compress high quality images 35% more than traditional JPEG codecs.

但這邊沒有講壓縮率的部分是哪個「traditional JPEG codec」比較，大概就是「WebP 的檔案大小未必比 JPEG 小...」這邊的老招了，應該是跟 cjpeg 比，如果跟 MozJPEG 比的話就未必有那麼高了。

想要寫起來的是 Hacker News 留言有提到命名的邏輯，這個 -li 結尾的用法可以看出來是 Google 蘇黎世團隊的產品：

The suffix -li is used in Swiss German dialects. It forms a diminutive of the root word, by adding -li to the end of the root word to convey the smallness of the object and to convey a sense of intimacy or endearment.

This obviously comes out of Google Zürich.

這點還可以從其他的產品看到類似的命名，比較熟的是 Zopfli 以及 Brotli。

Facebook 使用 AV1 的記錄

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 的進展...

Apple 對 PNG 解碼的 bug

前幾天的 Hacker News Daily 上看到「PNG Parser Differential」這個，對應的討論在「PNG Parser Differential (vidbuchanan.co.uk)」這邊可以看到。

作者想要利用 threading 加速處理 PNG 格式，結果寫出了 bug，但意外發現 Apple 的 PNG decoder 也犯了一樣的問題：「Ambiguous Decodes #3」。

作者做了一個特別的 PNG 放在網站上，在非 Safari 的情況下會是：

而拿 iPhone 的 Safari 讀的話，可以看到：

應該是 implementation bug，還蠻有趣的 bug...

Branchless UTF-8 解碼器

看到「A Branchless UTF-8 Decoder」這篇，先來回憶一下「非常經典的 UTF-8...」這篇，以及裡面提到的 encoding：

因為當初在設計 UTF-8 時就有考慮到，所以 decoding 很容易用 DFA 解決，也就是寫成一堆 if-then-else 的條件。但現代 CPU 因為 out-of-order execution 以及 pipeline 的設計，遇到 random branch 會有很高的效能損失，所以作者就想要試著寫看看 branchless 的版本。

成效其實還好，尤其是 Clang 上說不定在誤差內：

With GCC 6.3.0 on an i7-6700, my decoder is about 20% faster than the DFA decoder in the benchmark. With Clang 3.8.1 it’s just 1% faster.

而後來的更新則是大幅改善，在 Clang 上 DFA 版本比 branchless 的快：

Update: Björn pointed out that his site includes a faster variant of his DFA decoder. It is only 10% slower than the branchless decoder with GCC, and it’s 20% faster than the branchless decoder with Clang. So, in a sense, it’s still faster on average, even on a benchmark that favors a branchless decoder.

所以作者最後也有說這是個嘗試而已 XD：

It’s just a different approach. In practice I’d prefer Björn’s DFA decoder.

Google 推出 VP8 的硬體設計

Google 推出了 VP8 編碼與解碼的硬體設計，代號「Anthill」：「Introducing "Anthill," the First VP8 Hardware Encoder IP Release」。

透過 Anthill，對於 GPU 的 loading 及電源消耗會大幅降低：(這是在 ARM 平台上的估算)

不過比較奇怪的是只有寫 H1 encoder RTL 不收錢？重點在 decoder 吧？

Google does not require payment of any license fee or royalty in connection with use of the H1 encoder RTL.

另外 source code 不直接公開，必須填表格索取...