Tag: encoding

Raspberry Pi 5 拿掉硬體的 H.264 encoding

在 HN 上看到「Raspberry Pi 5 has no hardware video encoding and only HEVC decoding (raspberrypi.com)」，原文指到 Gordon Hollingworth 的回覆這邊，可以看到這是上個月的消息了。

Raspberry Pi 一直都有硬體 H.264 encoding 的能力，不過這個在 Raspberry Pi 5 上被拿掉了，所以得用軟體壓。

官方有提到 Raspberry Pi 5 的 CPU 因為比之前快很多，單顆就有辦法做到 1080p60 (而 RPi5 有 4 CPU)，所以除了 power consumption 以外應該不是大問題：

Obviously, the bad thing is the power consumption, but actually it only takes around 1 processor to encode 1080p60 with our default settings (which is still better quality than the PI 4 hardware encoder).

不過 HN 上猜是授權費用之類的問題，我在想是不是新的晶片組的 encoding license 都綁在一起，H.264 + H.265 得一包一起買，而 H.265 的授權費是眾所皆知的貴...

當 desktop 應該是還好，但就心裡有個底...

提議 OpenJDK 的程式碼 UTF-8 化

在 Hacker News 上看到提議把 OpenJDK 的程式碼 UTF-8 化：「Make JDK source code UTF-8 (openjdk.org)」，原始的 jira ticket 在「Make JDK source code UTF-8」這邊。

主要是現在的 source code 沒有統一標準：

Currently, the source code in the JDK is in an ill-defined encoding. There is no official declaration of the encoding used. It is "mostly ASCII", but the relatively few non-ASCII characters used are not well-defined. In many cases, it is latin-1, but I am pretty certain other encodings are used for e.g. Asian translations.

而 mailing list 上看起來還是有想要維持 ASCII 的討論：「Making the source code utf-8」，不過他提出來的理由我覺得不太行，在 console 跑 vi 或是 emacs 我覺得不太是個好理由...

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

AOM-AV1 v3.5.0 的效能改善

在翻資料的時候翻到「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 也低不少。

I have no capslock and I must scream

前幾天看到「I have no capslock and I must scream (marginalia.nu)」這個討論，原文的標題是致敬於「I Have No Mouth, and I Must Scream」這篇小說，所以就決定把原標題留起來好了...

原文在「I have no capslock and I must scream」這邊，在原文的後面提到了 Mozilla 的這張 ticket，應該就是寫這篇文章的「主因」了：「Replace the Text Encoding menu with a single override item Repair Text Encoding」。

這種行為也是為什麼即使 Chrome 愈來愈爛，也不打算跳去 Firefox 的原因...

用 TSV 而不用 CSV

最近常常需要提供資料給其他部門 (非技術類的部門)，有時候需要提供一些表格類的資料，傳統大多數人比較熟的是產生 CSV 格式的資料讓使用者可以用 Excel 打開，但這個格式其實有很多問題，最常見的就是 encoding 與資料有逗號 comma 的問題。

如果是在 Python 下，其中一個解法是用 openpyxl 直接產生 .xlsx，但用起來還是沒那麼有下面提到的方法順手。

如果是 shell script 時就比較麻煩了，像我這次手上有一堆影片檔，要用 FFmpeg 確認每個影片的 resolution 與 framerate 再提供給同事，這時候如果還是想產生 .xlsx 就累了...

下面要提到的解法好像記得是在 K 社的時候同事教的，用 TSV 檔格式 (當然檔名要取 .tsv)，然後 encoding 用 UTF-16 (LE) 就可以解決上面提到的兩個問題，產生出來的檔案可以讓 Excel 直接打開。

在 StackOverflow 上的「Is it possible to force Excel recognize UTF-8 CSV files automatically?」這邊翻一翻，會發現裡面提到比較好的解法其實都是產生 TSV。

這邊另外推薦，就算是寫程式，也還是可以先產生出 UTF-8 的版本 (通常副檔名我都會先取 .txt)，然後用 iconv 或是 piconv 轉成 UTF-16 (LE)：

iconv -f utf8 -t utf16le a.txt > a.tsv

包到 Makefile 裡面用起來其實還蠻順手的...

超快速的 Base64 encoding/decoding 實做

看到「Base64 encoding and decoding at almost the speed of a memory copy」這個，可以超級快速編解碼 Base64 的資料。

實做上是透過 Intel 的 AVX-512 加速，在資料夠大的情況下 (超過 L1 cache 的大小)，可以達到接近字串複製的速度 (這邊提到的 memcpy())：

We show how we can encode and decode base64 data at nearly the speed of a memory copy (memcpy) on recent Intel processors, as long as the data does not fit in the first-level (L1) cache. We use the SIMD (Single Instruction Multiple Data) instruction set AVX-512 available on commodity processors. Our implementation generates several times fewer instructions than previous SIMD-accelerated base64 codecs.

不過這樣 AMD 暫時要哭哭...

Twitch 用 VP9 直播...

Twitch 整理了一篇「How VP9 delivers value for Twitch’s esports live streaming」，說明他們用 VP9 的經驗談。

裡面有很大的篇幅是在講 VP9 與 H.264 的比較，不過這兩個用的技術就已經不是同一個年代了，沒有進步的話就不用出來玩了...

裡面有講到一些有趣的東西，像是提到是用 FPGA 即時壓縮：

In this article, we will show that the FPGA-based real-time VP9 encoding can deliver at least 25% bitrate savings compared to the highest-quality H.264 encoders deployed in Twitch’s production today.

然後提到 1080p60 至少省了 25% 的頻寬 (這邊應該是相較於 H.264)：

VP9’s Compression Efficiency for Live 1080p60 Encoding: We Can Achieve At Least 25% Bitrate Savings

查了一下，在桌機上的瀏覽器都差不多支援了：

VP9 is implemented in these web browsers:

Chromium and Google Chrome (usable by default since version 29 from May and August 2013, respectively),
Opera (since version 15 from July 2013),
Mozilla Firefox (since version 28 from March 2014),
Microsoft Edge (as of summer 2016).

行動裝置的話 Android 4.4+ 有支援，但在 iOS 上沒有支援...

整體看起來普及率算是不低，可以引入當主力 codec 降低頻寬成本，當設備不支援 VP9 時 (應該只有 iOS 透過 Safari 觀看的情況) 就用 H.264 stream 提供服務。

Chrome 72+ (目前在 Beta 的版本) 對延伸套件的影響

我的桌機平常都是跑 beta channel 的 Chrome，所以前陣子已經升級到 72，然後發現兩個問題：

從 dev console 可以看到問題都是 Referer 沒被送出，導致有檢查 Referer 的網站拒絕存取，後來在「chrome.webRequest」這邊發現是 Chrome 72+ 改了規則，裡面提到了：

Starting from Chrome 72, the following request headers are not provided and cannot be modified or removed without specifying 'extraHeaders' in opt_extraInfoSpec:

Accept-Language
Accept-Encoding
Referer
Cookie

Starting from Chrome 72, the Set-Cookie response header is not provided and cannot be modified or removed without specifying 'extraHeaders' in opt_extraInfoSpec.

不確定這個設計的目的是什麼，但反正已經中獎了，總是得回報給各 extension 的維護者讓他們修正 (用 beta channel 的重要任務之一？)。

所以就先去 Tampermonkey 開 ticket，也很迅速的在 beta 版修正了 (所以只能先改裝 beta 版)：「GM_xmlhttpRequest unable to set referer in Chrome 72+ #629」。

另外跟 Referer Control 的開發者回報這個問題，也修正出新版上架了，更新就生效了：「refererControlDisqus.html」。

目前看起來還有「Spoofs Lang」得修，不過這個軟體好久沒更新了，不知道有沒有機會...

Amazon API Gateway 支援壓縮了...

Amazon API Gateway 支援壓縮了：「Amazon API Gateway Supports Content Encoding for API Responses」。

You can now enable content encoding support for API Responses in Amazon API Gateway. Content encoding allows API clients to request content to be compressed before being sent back in the response to an API request. This reduces the amount of data that is sent from API Gateway to API clients and decreases the time it takes to transfer the data. You can enable content encoding in the API definition. You can also set the minimum response size that triggers compression. By default, APIs do not have content encoding support enabled.

打開後傳回的資料就會自動壓縮了，然後還可以設定觸發的 response size... 依照文件 (Content Codings Supported by API Gateway)，目前支援的壓縮格式應該是最常見的 gzip 與 deflate。

這功能好像是一開始有 API Gateway 就一直被提出來的 feature request...