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.

AVIF 與 WebP 的懶人包設定?

看到「AVIF and WebP encoding quality settings」這包,看起來是 AVIFWebP 的懶人包設定。

一分鐘版的懶人包設定是基於一般 JPEG 的 quality 設定為 60 時的畫質,與 AVIF 的 50,WebP 的 65 差不多:

If you usually encode JPEGs with quality setting 60, then encode AVIF with quality setting 50 and WebP with quality setting 65. You should expect your AVIF files to be on average 36% smaller and your WebP images 15% smaller than the equivalent JPEG image.

後面給的複雜一點,包括了 JPEG quality 在 50/60/70/80 的情況。

作者用的是 DSSim 判斷圖片壓縮後的品質,看了維基百科裡面的說明,讓我想到 2016 年時 Netflix 公開的 VMAF,針對影片的品質分析:「Netflix 評估影片品質的方法」。

不過沒碰太多這塊的東西,不確定 DDSim 目前是否有被認可... 留下來當作參考。

用 Machine Learning 改善 Streaming 品質的服務與論文

Hacker News 上看到「Puffer」這個服務,裡面利用了 machine learning algorithm 動態調整 bitrate,以提昇傳輸品質。

測試得到的數據後來被整理起來一起放進論文:「Continual learning improves Internet video streaming」。

在開頭介紹了 Fugu 這個演算法:

We describe Fugu, a continual learning algorithm for bitrate selection in streaming video.

而 Puffer 就是實驗網站:

We evaluate Fugu with Puffer, a public website we built that streams live TV using Fugu and existing algorithms. Over a nine-day period in January 2019, Puffer streamed 8,131 hours of video to 3,719 unique users.

這個站台提供了許多真實的頻道進行測試:

Stream live TV in your browser. There's no charge. You can watch U.S. TV stations affiliated with the NBC, CBS, ABC, PBS, FOX, and Univision networks.

可以看到 Fugu 的結果很好,比起其他提出的方案是全面性的改善:

這邊是用 WebSocket 測試,並且配合了不同的 TCP congestion algorithm,沒有太考慮額外的計算成本...

OS X 接藍芽耳機要注意的地方...

Twitter 上看到 OS X 接藍芽耳機時的音質問題:

看了一些討論,看起來除了蘋果自己的耳機外,其他家的藍芽耳機不一定會開 AAC 或是 aptX。雖然現在沒有其他家的藍芽設備,但以後如果買了要注意一下...

也是拿來掃 PHP 程式碼的 PHPStan...

PHPStan 也是 PHP 的靜態分析工具,官方給的 slogan 是「PHP Static Analysis Tool - discover bugs in your code without running it!」。然後官方給了一個 GIF,直接看就大概知道在幹什麼了:

Phan 類似,也是要 PHP 7+ 才能跑,不過實際測試發現不像 Phan 需要 php-ast

PHPStan requires PHP ^gt;= 7.0. You have to run it in environment with PHP 7.x but the actual code does not have to use PHP 7.x features. (Code written for PHP 5.6 and earlier can run on 7.x mostly unmodified.)

PHPStan works best with modern object-oriented code. The more strongly-typed your code is, the more information you give PHPStan to work with.

Properly annotated and typehinted code (class properties, function and method arguments, return types) helps not only static analysis tools but also other people that work with the code to understand it.

拿上一篇「用 Phan 檢查 PHP 程式的正確性」的例子測試,也可以抓到類似的問題:

vendor/bin/phpstan analyse -l 7 src/
 1/1 [▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓] 100%

 ------ --------------------------------------------------------------
  Line   src/Foo.php
 ------ --------------------------------------------------------------
  13     Method Gslin\Foo::g() should return string but returns null.
 ------ --------------------------------------------------------------


 [ERROR] Found 1 error

這樣總算把積壓在 tab 上關於 PHP 工具都寫完了,之後要用才有地方可以翻... XD

用 Phan 檢查 PHP 程式的正確性

Phan 這套也是拿來檢查 PHP 程式用的,也是儘量避免丟出 false alarm。不過 Phan 只能用在 PHP 7+ 環境,原因是使用 php-ast,另外有一些額外建議要裝的套件:

This version (branch) of Phan depends on PHP 7.1.x with the php-ast extension (0.1.5 or newer, uses AST version 50) and supports PHP version 7.1+ syntax. Installation instructions for php-ast can be found here. For PHP 7.0.x use the 0.8 branch. Having PHP's pcntl extension installed is strongly recommended (not available on Windows), in order to support using parallel processes for analysis (or to support daemon mode).

最新版還只能跑在 PHP 7.2 上面,用的時候要注意一下 XD (我在測試時,require-dev 指定 0.11.0,結果被說只有 PHP 7.1 不符合 dependency,後來放 * 讓他去抓適合的版本)

像是這樣的程式碼:

class Foo
{
    /**
     * @param string $p
     * @return string
     */
    function g($p) {
        if (!$p) {
            return null;
        }
        return $p;
    }
}

就會產生出對應的警告訊息:

src/Foo.php:13 PhanTypeMismatchReturn Returning type null but g() is declared to return string

也是掛進 CI 裡面的好東西...

用 Psalm 掃出 PHP 有問題的程式碼

Psalm 的 slogan 是「A static analysis tool for PHP」,由 Vimeo 發展並開放出來的軟體:「vimeo/psalm」。

目前是 v0.3.71,所以需要 PHP 5.6 以上才能跑:

  • v0.3.x supports checking PHP 5.4 - 7.1 code, and requires PHP 5.6+ to run.
  • v0.2.x supports checking PHP 5.4 - 7.0 code and requires PHP 5.4+ to run.

Psalm 主要的目標是找出哪邊「已經發生錯誤」,而不像其他幾套的目標是「預防」,這樣可以避免過高的 false alarm...

GitHub 上的 Continuous Integration (CI)

GitHub 寫了一篇「GitHub welcomes all CI tools」,不過對我來說比較有趣的是各家 CI 在 GitHub 上的市占率:

可以看到 Travis CI 還是擁有壓倒性的佔有率 (大約一半),這跟他提供免費的 public repository 方案有關。但以另外一個角度來看,這也讓使用商用版本 (travis-ci.com) 的人有大量的範例可以參考,而不需要擔心資源太少。

Heroku CI 正式推出

月初才提到「Heroku 也要進入 CI 市場...」,前幾天就開放使用了:「Heroku CI Is Now Generally Available: Fast, Low Setup CI That’s Easy to Use」。

收費方式是依照 Heroku Pipelines 收費,一個 Heroku Pipelines 是 USD$10/month:

Each CI-enabled Heroku Pipeline is charged just $10/month for an unlimited number of test runs.

比起其他棚是無限量 Travis CI 的 $69/month (1 concurrent job,不限時間),或是 CircleCI 的 Free 方案 (1 concurrent job,限時每個月 1500 分鐘) 或是 USD$50/month (2 concurrent job,不限時間),感覺有些微妙...

感覺還是先繼續用 Travis CI 好了,目前 Open Source Project 的標準,路邊可以隨便檢到很多範例用... (像是用 Google".travis.yml" "language:php" site:github.com 就可以找到很多 PHP 的範例)

Netflix 評估影片品質的方法

Netflix 在發了一篇很長的文章,說明怎麼評估 video quality:「Toward A Practical Perceptual Video Quality Metric」,文章雖然有點長,但其實還蠻好懂的...

講的白話一點,Netflix 想要做各種壓縮方式的改善,但在超大的量的情況下 (scale) 缺乏自動化打分數的機制:

All of the challenging work described above hinges on one fundamental premise: that we can accurately and efficiently measure the perceptual quality of a video stream at scale.

如果先不考慮 scale 問題,影片的評估方式有人工處理以及常見的計算方法 (像是 MSEPSNRSSIM):

Traditionally, in video codec development and research, two methods have been extensively used to evaluate video quality: 1) Visual subjective testing and 2) Calculation of simple metrics such as PSNR, or more recently, SSIM.

前者因為牽涉到人工,所以不 scale,而後者跟「人的觀感」還是不夠正相關:

Without doubt, manual visual inspection is operationally and economically infeasible for the throughput of our production, A/B test monitoring and encoding research experiments.

Although researchers and engineers in the field are well-aware that PSNR does not consistently reflect human perception, it remains the de facto standard for codec comparisons and codec standardization work.

Netflix 的作法其實很簡單:(但是每一步都很仔細)

  • 首先先把影片依照手上有的 metadata 歸類,然後再挑出代表性的剪輯,並且產生不同 bitrate 的檔案。
  • 用人工對這些剪輯評分。
  • 用機器產生各種既有計算方法的分數 (PSNR、SSIM、...)。
  • 用數學方法把人工的與機器算的分數建立 model。
  • 然後對於未知的影片先寄算出既有方法的分數 (PSNR、SSIM、...),然後套用 model 推估人的觀感。

沒什麼特別發明出來的演算法,只是苦工 XDDD