幹壞事是進步最大的原動力
先前在「Zoom 不提供 End-to-end Encryption 給免費版用戶」這邊提到的事情，剛剛看到 Zoom 宣佈改變策略，變成無論是付費還是免費的使用者都會提供 End-to-end encryption：「End-to-End Encryption Update」。
Free/Basic 的使用者要認證才能用這個功能：
To make this possible, Free/Basic users seeking access to E2EE will participate in a one-time process that will prompt the user for additional pieces of information, such as verifying a phone number via a text message.
還是很怪，繼續觀望...
前幾天的新聞，Zoom 的新聞稿：「Zoom Acquires Keybase and Announces Goal of Developing the Most Broadly Used Enterprise End-to-End Encryption Offering」，Keybase 的新聞稿：「Keybase joins Zoom」，看到後就把本來的服務刪一刪了...
這篇屬名由 Zoom 創辦人發出的公告，裡面多到讓人不知道怎麼吐槽的部份，我們就把唯一的粗體字拉出來討論好了：
We are excited to integrate Keybase’s team into the Zoom family to help us build end-to-end encryption that can reach current Zoom scalability.
先不講先前被戳破根本就不是 end-to-end encryption 的問題，影音上面因為 transcoding 的問題，如果要在 video stream 上做 end-to-end encryption 的話分成兩種方式可以做：
a) 一種是發送端直接產生出多個不同 bitrate 的 video stream，這種方式其他家都已經很熟悉了，缺點也很明顯，就是吃各種資源，包括發送端的壓縮能力與頻寬。
b) 另外一種方式是產生出可以疊加的 video stream，有點像是 progressive image 的方式，第一個 stream1 的畫質最低，第二個 stream2 則是「補強」第一個 stream1，這樣子可以降低資源的需求。
另外有想到 Homomorphic encryption 的方式，直接可以疊加加密後的 stream1 + stream2，不過 bitrate 應該不會降低，就算真的設計的出來應該也沒用...
如果是 a) 的方式，業界對於 key 的交換都已經解的還不錯了，但這個方式沒什麼競爭性 (因為其他家也都已經做完了)。
如果是 b) 的方式，很明顯該找的是 codec 的公司 (要做出可以疊加的 codec)，而不是搞密碼學的公司。
回到原來的問題，現有的團隊有 2500 人，裡面的技術團隊沒辦法搞定 end-to-end encryption，ok 沒關係，那現在的 CTO Brendan Ittelson 應該可以建一個團隊吧？所以我翻了一下他的 LinkedIn 看了一下他的經歷，對不起我錯了，我瞬間不知道怎麼寫下去了，我豆頁痛...
這個連結在瀏覽器的 tab 上好幾天了，要寫這篇的時候試著找了一下當時是從哪個管道看到的來源，翻了一下看起來沒有在 Hacker News Daily 上面列出，但在 Hacker News 上面有找到討論串，不過最近沒有去從那邊翻連結...
Anyway，Zipcall 是使用 WebRTC 實做出來的會議系統，會議相關的流量會直接透過點對點的架構傳輸，不需要透過 server 交換。
由於架構上沒有 server 幫忙重新壓縮再轉給不同的使用者，也就 client 得自己處理，對硬體要求應該會比較高，另外對頻寬的要求也比較大。
另外他提到 latency 比較低這件事情，剛剛用兩隻 webcam 測試，一個掛到 vm guest 裡面，另外一個掛在 vm host 上面，測試下來很明顯可以感覺比起之前用 Zoom 高，可能要再研究到底是什麼原因，不確定跟 vm 有沒有關係，不過還在可以接受的範圍。
安全性與隱私性的實做方式也還得再看看是怎麼弄的，不過目前看起來應該可以先拿來玩玩...
最近武漢肺炎的關係，導致蠻多人會在家裡使用視訊會議，但背景一直是個問題... 然後就看到這篇文章：「Open Source Virtual Background」。
作者用 python-opencv 先處理 webcam 進來的影像 (看起來不只去背，還加上了 hologram 的效果 XDDD)，然後再用 pyfakewebcam 與 v4l2loopback 模擬成一個 webcam 餵回給視訊軟體，結果就惡搞成這樣了：
話說回來，最近各電商平台的 webcam 與視訊機都缺貨，還好之前有買個便宜的頂著，不然就得開筆電了...
在「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。
YouTube 的 embed 會載入大量的元件，所以就有專案把對使用者沒有意義的元件都拔掉：「Lite YouTube Embed」。
從比較可以看出來 Lite YouTube Embed 下載的元件少很多：
當然在功能上有差異，不過基本的功能應該都沒問題...
雖然還是 JavaScript 實做，但可以看到實際的程式碼大概 40 行而已？(註解的行數大約是程式碼的兩倍)：「lite-youtube-embed/src/lite-yt-embed.js」。
不過要注意的是，程式碼中用到 ES6 的 class 語法，所以如果要考慮到 IE11，應該是要打包轉換...
現在 Google Chrome 的穩定版是 77，到了十二月會推出的 79 的時候，就會有一連串的避免 HTTPS 頁面使用 HTTP 資源的措施：「No More Mixed Messages About HTTPS」。
首先是 79 的時候會有新的界面，讓使用者可以修改阻擋類的設定。
到了 80 的時候會試著將 HTTP 的影音 <audio> 與 <video> 升級到 HTTPS 連線，如果 HTTPS 讀不到的話就當作讀取失敗。但圖片 <img> 的部份則是會讀進來，只是安全性上會顯示 Not Secure。
到了 81 就是這系列的最終階段，包括 <img> 也會一使用 80 時影音的邏輯，沒辦法在 HTTPS 上讀到就當作讀取失敗。
看到「Anime4K」這個專案：
Anime4K is a state-of-the-art*, open-source, high-quality real-time anime upscaling algorithm that can be implemented in any programming language.
State of the art* as of August 2019 in the real time anime upscaling category, the fastest at acheiving reasonable quality. We do not claim this is a superior quality general purpose SISR algorithm compared to machine learning approaches.
他們提供的數據顯示 1080p -> 2160p (4K) 只要 3ms，對於 60fps 來說是相當足夠，而品質看起來也還不錯。
其中一個蠻有趣的問答是 1080p -> 2160p 反而比 480p -> 720p 簡單，因為 1080p 裡面因為有更多資料量，所以處理起來比較簡單：
Why not do PSNR/SSIM on 480p->720p upscaling
Story TimeComparing PSNR/SSIM on 480p->720p upscales does not prove and is not a good indicator of 1080p->2160p upscaling quality. (Eg. poor performance of waifu2x on 1080p anime) 480p anime images have a lot of high frequency information (lines might be thinner than 1 pixel), while 1080p anime images have a lot of redundant information. 1080p->2160p upscaling on anime is thus objectively easier than 480p->720p.
在 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，沒有太考慮額外的計算成本...
「Improve your English pronunciation using Youtube」這個服務利用 YouTube 上的影片與字幕提供界面，讓你可以知道現實世界的人怎麼發音的查詢系統。
系統本身不難做，主要是去撈大量資料，然後建立 search engine 提供，idea 與執行才是這個服務的賣點。
拿到後第一個想到的就是，一定要拿來查一下「IKEA」怎麼唸 XDDD
除了英文以外還可以查其他語言，包括中文...