video

AWS Elemental MediaConvert 支援 AV1

在「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 影片的載入速度

YouTube 的 embed 會載入大量的元件，所以就有專案把對使用者沒有意義的元件都拔掉：「Lite YouTube Embed」。

從比較可以看出來 Lite YouTube Embed 下載的元件少很多：

當然在功能上有差異，不過基本的功能應該都沒問題...

雖然還是 JavaScript 實做，但可以看到實際的程式碼大概 40 行而已？(註解的行數大約是程式碼的兩倍)：「lite-youtube-embed/src/lite-yt-embed.js」。

不過要注意的是，程式碼中用到 ES6 的 class 語法，所以如果要考慮到 IE11，應該是要打包轉換...

Chrome 將不會在 HTTPS 頁面上載入 HTTP 資源...

現在 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 上讀到就當作讀取失敗。

即時將動畫 Upscale 到 4K 畫質的演算法

看到「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 Time
Comparing 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.

用 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，沒有太考慮額外的計算成本...

用 YouTube 上的影片查發音

「Improve your English pronunciation using Youtube」這個服務利用 YouTube 上的影片與字幕提供界面，讓你可以知道現實世界的人怎麼發音的查詢系統。

系統本身不難做，主要是去撈大量資料，然後建立 search engine 提供，idea 與執行才是這個服務的賣點。

拿到後第一個想到的就是，一定要拿來查一下「IKEA」怎麼唸 XDDD

除了英文以外還可以查其他語言，包括中文...

Instagram 改善影片上架速度的方式

不是什麼魔法，其實是改產品面上的規格 (但是發表到 Instagram Engineering 上)：「Video Upload Latency Improvements at Instagram」。

最原始的版本是所有的格式都轉完後才可以上架：

然後把規格改成最高畫質的版本轉完後就可以先上架：

The idea is, instead of blocking until all video versions are available, we can publish the video once the highest-quality video version is available.

然後是把影片切段上傳，所以傳一半就可以先處理一半，變成 pipeline 的概念，但增加程式的複雜度，以及被迫要調整影片品質的參數：

Segmented uploads reduce upload latency in many cases but come with a few tradeoffs. For instance, segmented uploads increase the complexity of the pipeline. There are some quality metrics that are only available per segment at transcode time, such as SSIM. These metrics are not helpful to us on a per segment basis. Therefore, we need to do a duration weighted average of the SSIM of all segments to come up with the SSIM of the whole video. Similarly, handling exceptions is more complex since there are more cases to handle.

另外有一種特例是上傳的影片本身就已經符合伺服器的規格，這樣的話可以直接放行 (不過這樣不會有 security concern 嗎...)：

Another performance optimization we use to improve the upload latency and save CPU utilization is something we call a “passthrough” upload. In some cases, the media that is uploaded is already ready for playback on most devices.

都是想的出來而且會帶有 tradeoff 的方法，而不是完全正面的改善 :o

Cloudflare 改善了同時下載同一個檔案的效率...

在「Live video just got more live: Introducing Concurrent Streaming Acceleration」這邊 Cloudflare 說明他們改善了同時下載同一個 cache-miss 檔案時的效率。

本來的架構在 cache-miss 時，CDN 這端會先取得 exclusive lock，然後到 origin server 抓檔案。如果這時候有其他人也要抓同一個檔案，就會先卡住，避免同時間對 origin server 產生大量連線：

這個架構在一般的情況下其實還 ok，就算是 Windows Update 這種等級的量，畢竟就是一次性的情況而已。但對於現代愈來愈普及的 HTTP(S) streaming 技術來說，因為檔案一直產生，這就會是常常遇到的問題了。

由於 lock 機制增加了不少延遲，所以在使用者端就需要多抓一些緩衝時間才能確保品質，這增加了直播的互動延遲，所以 Cloudflare 改善了這個部分，讓所有人都可以同時下載，而非等到發起的使用者下載完才能下載：

沒有太多意外的，從 Cloudflare 內部數字可以看出來這讓 lock 時間大幅下降，對於使用者來說也大幅降低了 TTFB (time to first byte)：

不確定其他家的情況...

Mac 上讓 SSH 走 Socks5 的方式

在泰國住的飯店提供頗快的網路：

不過到 HiNet 看起來應該是有繞到美國之類的地區？

gslin@Gea-Suans-MacBook-Pro [~] [08:16/W4] mtr --report 168.95.1.1
Start: 2019-04-07T08:16:33+0700
HOST: Gea-Suans-MacBook-Pro.local Loss%   Snt   Last   Avg  Best  Wrst StDev
  1.|-- 10.10.20.1                 0.0%    10    1.8   2.0   1.3   3.1   0.6
  2.|-- node-iyp.pool-101-108.dyn  0.0%    10    3.9   3.6   2.7   4.5   0.6
  3.|-- 172.17.36.105              0.0%    10    3.2   4.1   3.2   8.3   1.5
  4.|-- 203.113.44.205             0.0%    10    6.5   5.3   3.9   6.7   1.0
  5.|-- 203.113.44.177             0.0%    10    5.4   4.8   4.0   7.2   1.0
  6.|-- 203.113.37.194             0.0%    10    4.6   6.5   3.0  11.1   2.5
  7.|-- in-addr.net                0.0%    10    3.9   4.4   3.1   5.6   0.8
  8.|-- ???                       100.0    10    0.0   0.0   0.0   0.0   0.0
  9.|-- pcpd-4001.hinet.net        0.0%    10  355.4 356.9 355.1 365.4   3.0
 10.|-- pcpd-3212.hinet.net        0.0%    10  215.6 216.6 214.2 225.4   3.4
 11.|-- tpdt-3022.hinet.net        0.0%    10  219.4 215.9 214.0 221.5   2.5
 12.|-- tpdt-3012.hinet.net        0.0%    10  218.9 217.2 215.0 218.9   1.4
 13.|-- tpdb-3311.hinet.net        0.0%    10  212.5 212.9 211.9 214.1   0.6
 14.|-- 210-59-204-229.hinet-ip.h  0.0%    10  213.5 212.7 212.0 213.7   0.6
 15.|-- dns.hinet.net              0.0%    10  214.4 214.5 213.7 216.0   0.7

這樣有些影音服務只吃台灣 IP 就沒辦法用了，所以就得找方法來解決... 想法是透過我在 GCP 上開的機器繞回 HiNet，所以就得找 Mac 上 SSH 要怎麼設定 Socks5。

本來以為要用 tsocks 之類的工具 (i.e. 用 LD_PRELOAD 處理 connect())，但意外的在「SSH through a SOCKS Proxy? (client = OpenSSH OS X)」這邊看到可以用內建的 nc 處理，因為 nc 有支援 Socks5。

所以就變成兩包 ssh 指令：

ssh -D 1081 gcp.server
ssh -D 1080 -o "ProxyCommand nc -X 5 -x 127.0.0.1:1081 %h %p" hinet.server

然後 127.0.0.1:1080 就是打通的版本了，可以讓瀏覽器直接掛上去使用。

至於後來想起來不需要用 Socks5，可以用 ssh -L 而笑出來又是另外一件事情了 :o

Zoom 也要 IPO 了...

最近的資訊網路圈子 IPO 案子好多，其中一個比較值得注意的是 Zoom：「Zoom, a profitable unicorn, files to go public」。

這家公司不像 PagerDuty 與 Pinterest，這兩家是沒賺過錢就丟單子出來了，而 Zoom 是有賺錢還打算出來 IPO：

Zoom, which raised a total of $145 million to date, posted $330 million in revenue in the year ending January 31, 2019, a remarkable 2x increase year-over-year, with a gross profit of $269.5 million. The company similarly more than doubled revenues from 2017 to 2018, wrapping fiscal year 2017 with $60.8 million in revenue and 2018 with $151.5 million.

啊不過 Zoom 真的蠻好用的，一群人在不同地方要討論事情時，用電子白板或是分享畫面都還不錯... 這幾天跟不是資訊圈子的人在用也都有很正面的 feedback。