「Improve your English pronunciation using Youtube」這個服務利用 YouTube 上的影片與字幕提供界面，讓你可以知道現實世界的人怎麼發音的查詢系統。
系統本身不難做，主要是去撈大量資料，然後建立 search engine 提供，idea 與執行才是這個服務的賣點。
拿到後第一個想到的就是，一定要拿來查一下「IKEA」怎麼唸 XDDD
除了英文以外還可以查其他語言，包括中文...
Tag: video
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。
用 NN 演算法重製 Full HD 版的 Star Trek: DS9
看到「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 版本有可能可以靠這個方法先做初步，然後再讓人進去修？
自動校正字幕時間的軟體 subsync
看到用 Python 寫的「smacke/subsync」這個軟體，可以自動校正字幕時間：
Language-agnostic automatic synchronization of subtitles to video, so that subtitles are aligned to the correct starting point within the video.
他把上面這個變成下面這個：
因為不是用 machine learning 所以速度意外的快。演算法是對影片本身產生一個 array，然後對字幕也產生 array，最後對兩個 array 用個簡單的公式校準：
- Discretize video and subtitles by time into 10ms windows.
- For each 10ms window, determine whether that window contains speech. This is trivial to do for subtitles (we just determine whether any subtitle is "on" during each time window); for video, use an off-the-shelf voice activity detector (VAD) like the one built into webrtc.
- Now we have two binary strings: one for the subtitles, and one for the video. Try to align these strings by matching 0's with 0's and 1's with 1's. We score these alignments as (# matching digits) - (# mismatched digits).
就這樣解決問題 XD
Google Hangouts 將會使用固定 IP 位置
Google 宣佈 Hangouts 將會使用固定 IP 位置，讓系統管理員更方便管理：「Dedicated Hangouts Meet IP addresses」。
We’re adding a range of official, fixed IP addresses to be used exclusively for classic Hangouts and Hangouts Meet in G Suite domains.
目前看到的資訊是：
IPv4: 74.125.250.0/24
IPv6: 2001:4860:4864:5::0/64
然後文章裡的說明是二月 14 日會變更：
Hangouts Meet and classic Hangouts will stop using the old IP address on February 14, 2019.
管理者可以調整關於這段 IP 的流量，通常是調高優先權？不過要調低也是可以...
Twitch 用 VP9 直播...
Twitch 整理了一篇「How VP9 delivers value for Twitch’s esports live streaming」，說明他們用 VP9 的經驗談。
裡面有很大的篇幅是在講 VP9 與 H.264 的比較，不過這兩個用的技術就已經不是同一個年代了，沒有進步的話就不用出來玩了...
裡面有講到一些有趣的東西，像是提到是用 FPGA 即時壓縮：
In this article, we will show that the FPGA-based real-time VP9 encoding can deliver at least 25% bitrate savings compared to the highest-quality H.264 encoders deployed in Twitch’s production today.
然後提到 1080p60 至少省了 25% 的頻寬 (這邊應該是相較於 H.264)：
VP9’s Compression Efficiency for Live 1080p60 Encoding: We Can Achieve At Least 25% Bitrate Savings
查了一下，在桌機上的瀏覽器都差不多支援了：
VP9 is implemented in these web browsers:
Chromium and Google Chrome (usable by default since version 29 from May and August 2013, respectively),
Opera (since version 15 from July 2013),
Mozilla Firefox (since version 28 from March 2014),
Microsoft Edge (as of summer 2016).
行動裝置的話 Android 4.4+ 有支援，但在 iOS 上沒有支援...
整體看起來普及率算是不低，可以引入當主力 codec 降低頻寬成本，當設備不支援 VP9 時 (應該只有 iOS 透過 Safari 觀看的情況) 就用 H.264 stream 提供服務。
把 YouTube 對 channel 與 user 的自動播放功能關掉...
YouTube 在 channel 與 user 頁面會自動播放會讓人覺得頗困擾 (頁面一打開就有聲音)，所以想要找看看有沒設定可以關掉... 找了之後發現很久前就有被問過，但是當時得到沒有這個功能的回答：「How do I DISABLE autoplay from other channels on my YouTube channel?」。
既然如此就只能找套件來解了... 目前是透過 Userscript 擋下自動播放，程式碼不長也蠻好懂的：「Disable YouTube Channel/User Home Page Video AutoPlay」。
這樣總算是不會被聲音搞到...