Fabrice Bellard 的新作品 TSAC codec

昨天在 Hacker News 上看到「TSAC: Low Bitrate Audio Compression (bellard.org)」這則 Fabrice Bellard 的新作品:「TSAC: Very Low Bitrate Audio Compression」。

Fabrice Bellard 這兩年玩很多 ML 相關的東西,像是 2021 的「LibNC: C Library for Tensor Manipulation」,以及 2023 的「ts_zip: Text Compression using Large Language Models」,這次則是用上了 transformer

tsac is based on a modified version of the Descript Audio Codec extended for stereo and a Transformer model to further increase the compression ratio. Both models are quantized to 8 bits per parameter.

翻了一下 Descript Audio Codec,已經算是很厲害的了,在 44.1KHz mono 的情況下可以做到 8kbps (~1KB/sec):

With Descript Audio Codec, you can compress 44.1 KHz audio into discrete codes at a low 8 kbps bitrate.

TSAC 則是將 mono 的版本做到 5.5kbps,另外 7.5kbps 就能傳雙聲道,也還是低於原來的 8kbps:

TSAC is an audio compression utility reaching very low bitrates such as 5.5 kb/s for mono or 7.5 kb/s for stereo at 44.1 kHz with a good perceptual quality. Hence TSAC compresses a 3.5 minute stereo song to a file of 192 KiB.

聽了一下算蠻厲害的,直接拿音樂來壓還是有不錯的效果?

從技術上的情境可以知道兩端都需要有足夠的算力 (得跑 ML algorithm),然後在頻寬很不足的情況下通訊?商用的情境好像偏少一點,現在連沙漠與深山中都有衛星可以用,也許還是有些情境下用的到,像是 LoRa 的速度就差不多在這個區間。

倒是軍事上面需要考慮不少極端情況,用的機會可能比較高?

最近 AV1 的支援度

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).

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 應該是還好,但就心裡有個底...

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 部份,他們評估了 dav1dlibgav1 之後,選擇用 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 也低不少。

生一個 static 版本的 ffmpeg

目前有丟出來的 FFmpeg 執行包都會因為軟體授權不相容的問題,沒辦法把想要的東西都包進去 (或者無視授權丟出來 XD),但反正看一看沒看到適合的,所以弄了一天包了一包出來。另外也是因為同樣理由,這邊也只能提供步驟讓大家自己編...

我的主力放在 AV1VP9 的支援上,步驟就寫在「FFmpeg」這邊了,裡面是先開了一個 Docker container 再去裝環境,接著再把會用到的 source code 用 git clone 拉下來再固定版本,所以應該是不會有太大的意外。

另外可以看到 libfdk-aac 與 libx264 兩包我就直接拉系統的套件來包,主要是查了一下版本還算堪用,而且也不是主力要處理的東西,就不想要再自己拉下來編了。

這邊就是整理一下感想...

首先是 Rust 一直在推新功能,然後各家的軟體也幾乎就是馬上跳進去用這些新功能,所以只能用 rustup 跟到最新版的 Rustc 去編 rav1e

然後 x265 搞不定 static compile 的問題,卡在沒有 libgcc_s.a 可以用,如果還要搞 GCC 的話就太累了...

這樣在 AV1 與 VP9 的支援度就比較完整了,另外內建 libvmaf 也可以拿來分析...

Framework 筆電也遇到缺料問題,換了音源晶片

Framework 的筆電最近在社群很紅,模組化設計讓維修變容易,而且也有許多規格上的客製化空間。在「Marketplace」這頁可以看到很多東西可以換,除了比較常見的無線網卡、SSD、記憶體以外,像是主機板、鍵盤甚至連 USB、HDMI 接口都是模組。

不過這邊要提到的是 audio chip 也在這波 supply chain 的供貨問題而中招了:「Solving for Silicon Shortages」,Hacker News 上的討論「Framework: Solving for Silicon Shortages (frame.work)」也可以看一下。

從文章裡看起來是 Realtek ALC295 的交期爆炸了:

Chips that would normally have 16-20 week lead times (meaning we’d place typically binding orders that far ahead of needing parts in our hands) went up to 52 weeks. In one case, we even got notified of a 68 week lead time on a chip!

We were able to get enough Realtek ALC295 audio CODECs to develop the Framework Laptop and get through the first few months of production, but nowhere near enough to fulfill ongoing demand from the US and Canada, let alone the additional countries we’d like to ship to.

所以決定換到 Tempo 92HD95B

Luckily, we were able to find an alternative CODEC that lets us stay in production: the Tempo 92HD95B.

查了一下 datasheet,本來的 Realtek ALC295 是 QFN-48,而 Tempo 92HD95B 是 QFN-40,看起來得改不少東西... 應該是連 open market 上都翻不到而被迫換設計,跟我們家的情況也很像,看起來最近大家都哭到爆炸了 :o

Amazon EC2 推出 VT1 Instance

看到 Amazon EC2 推出新機種 vt1,專門為影片壓縮而推出的 family type:「New – Amazon EC2 VT1 Instances for Live Multi-stream Video Transcoding」。

主要是透過 Alveo U30 Data Center Accelerator Card 這張卡加速,號稱比 GPU 機器還要省 30% 的費用 (CPU 的話可以到 60%):

These VT1 instances feature Xilinx® Alveo™ U30 media accelerator transcoding cards with accelerated H.264/AVC and H.265/HEVC codecs and provide up to 30% better price per stream compared to the latest GPU-based EC2 instances and up to 60% better price per stream compared to the latest CPU-based EC2 instances.

看規格支援 H.264H.265,不過看起來沒支援 royalty-free 的 VP9AV1...

另外這跟 AWS Elemental MediaConvert 以及 AWS Elemental Live 好像稍微有點打對台?另外專利的費用不知道怎麼算...

Google 新推出的 Lyra audio codec

Hacker News Daily 上看到「Lyra audio codec enables high-quality voice calls at 3 kbps bitrate」,講 Google 新推出的 Lyra audio codec:「Lyra: A New Very Low-Bitrate Codec for Speech Compression」,論文在「Generative Speech Coding with Predictive Variance Regularization」這邊可以抓到。

目前 Google 提出來的想法是想辦法在 56kbps 的頻寬下實現還堪用的視訊通話:

Pairing Lyra with new video compression technologies, like AV1, will allow video chats to take place, even for users connecting to the internet via a 56kbps dial-in modem.

這次的突破在於可以使用 3kbps 的頻寬傳輸,但清晰度比 Opus 的 6kbps 效果還好不少。

Google 在文章裡面給了兩個 sample,一個是乾淨背景音,另外一個是吵雜的背景音,跟 Opus 與 Speex 比起來都好很多。

論文是說不需要太高的運算力,但沒翻到 GitHub 之類的 source code,先當作參考:

We provide extensive subjective performance evaluations that show that our system based on generative modeling provides state-of-the-art coding performance at 3 kb/s for real-world speech signals at reasonable computational complexity.

Amazon Transcribe 可以吃其他格式了

Amazon TranscribeAWS 推出語音轉文字的服務,先前只有提供 WAVFLACMP3MP4 格式,現在則是多支援不少格式:

Today, we are excited to announce native support for media files in AMR, AMR-WB, Ogg and WebM format by Amazon Transcribe.

AMRAMR-WB 以前還蠻常看到的,最近比較少看到了,可能是專利加上選擇性多之後用的人就變少了。

再來是 OggWebM 兩個都是開放格式。

上次拿 Amazon Transcribe 測日文的影片,先用 FFmpeg 把 MP4 檔內的 audio track 抽出來再丟上去轉,轉完後用 andyhopp/aws-transcribe-to-srt 把 Amazon Transcribe 輸出的 JSON 再轉成 SRT 檔,就辨識正確度測起來算是堪用,但專有名詞 (像是人名) 就得另外處理,不過比什麼都沒有好不少...