幹壞事是進步最大的原動力
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
除了英文以外還可以查其他語言，包括中文...
不是什麼魔法，其實是改產品面上的規格 (但是發表到 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
在「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)：
不確定其他家的情況...
在泰國住的飯店提供頗快的網路：
不過到 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
最近的資訊網路圈子 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。
看到「Remastering Star Trek: Deep Space Nine With Machine Learning」這篇，裡面用了類神經網路演算法，將本來只有 480p (SD) 的 Star Trek: DS9 升到 1080p (Full HD) 的版本，而且看起來效果還不錯...
意外的看到有人拿 Star Trek 的材料來玩... 依照作者的說明，DS9 一直沒有 Full HD 版的其中一個原因反而是因為「數位化」了。使用類比膠卷的母帶可以透過更高規格的重新掃描而得到高畫質版本，但 DS9 的母帶似乎已經是數位版了，所以反而造成無法透過重新掃描的方式取得 Full HD 版本：
While you can rescan analog film at a higher resolution, video is digital and can't be rescanned. This makes it much costlier to remaster this TV show, which is one of the reasons why it hasn't happened.
現有的 upscale 技術主要都還是以圖片為主，所以作者本來以為對於動態畫面的處理會遇到問題，但蠻意外的超出預期，從影片可以看出來：
看起來之後的 remaster 版本有可能可以靠這個方法先做初步，然後再讓人進去修？