Tag: video

用 Raspberry Pi 4 與 HDMI-to-USB 組出 KVM over IP 裝置

一樣是在 Hacker News Daily 上看到的專案，弄出便宜的 KVM over IP 裝置：「TinyPilot: Build a KVM Over IP for Under $100」。

主要是他在 Twitter 看到了這則，裡面提到了「Video Capture Cards, HDMI to USB 2.0, High Definition 1080p 30fps, Video Record via DSLR,Camcorder, Action Cam for Live Broadcasting, Live Streaming, Gaming, Teaching, Video Conference」這個產品：

而作者在 eBay 上面也找到了一樣的裝置，但是更便宜 (所以是「親，$11 包郵」？XDDD)：

接下來是在接觸 pikvm 的時候發現了 µStreamer 這個專案：

µStreamer is a lightweight and very quick server to stream MJPG video from any V4L2 device to the net.

最後則是發現他使用的 HDMI-to-USB 裝置直接就是輸出 MJPG 格式，連 transcoding 都不用做了，大幅把 latency 降到 200ms：

其實從作者的文章可以知道，你想做的事情說不定在地球上已經有其他人做差不多了，重點是要找出來，而不需要自己硬幹 XD

AWS 推出直播服務 Amazon Interactive Video Service (Twitch-as-a-Service)

把直播系統包在一起的服務 Amazon Interactive Video Service：「Amazon Interactive Video Service – Add Live Video to Your Apps and Websites」。

這邊先抱怨一下，這個服務的網址是 https://aws.amazon.com/ivs/，但 Elastic Load Balancer (ELB) 卻是 https://aws.amazon.com/elasticloadbalancing/，這是差別待遇啊...

回到原來的主題，這個服務做了幾件事情。收到 RTMPS stream 後，他會轉成許多格式：

If you send the maximum 8.5Mbps, 1080p60 stream, Amazon IVS will create 8.5Mbps 1080p60, 3Mbps 720p60, 2Mbps 720p30, 1.2Mbps 480p30, 800Kbps 360p30, and 400Kbps 160p30 renditions in an ABR stream.

從這份列表可以看出他目前最高只支援 1080p60，而 1440p (2K) 或是 2160p (4K) 看起來都還不支援。

另外因為是包裝 AWS Elemental Media Services，所以有蠻多東西都一起可以拿進來用，像是廣告機制與 DRM，然後看起來可以選擇 CDN：

With AWS Elemental Media Services, you have a high level of control over all workflow components: transcoding and packaging configurations; levels of resilience; personalized ad insertion; and features like content protection for digital rights management (DRM). You also get to choose which video players and CDNs are used.

區域上只開了三區 (us-east-1、us-west-2 與 eu-west-1)，但我在看 AWS 上的標價時整個搞混：

一開始看的時候在找單位但發現沒標，後來研究了一下看起來應該是 per hour？這樣標看起來很像是前面一萬個小時只要 USD$0.32 啊？

另外一個比較有趣的事情是，看起來不像是用 CloudFront 做，因為收費區域的區分跟 CloudFront 不太一樣，實際開下去後發現似乎是用 Twitch 的架構？

我試著開了一個，給了 a9a09e285166.us-east-1.playback.live-video.net 這樣的 endpoint，實際測試發現的確是某種 CDN，指到台灣的機房：

;; ANSWER SECTION:
a9a09e285166.us-east-1.playback.live-video.net. 56 IN A 23.160.0.254
a9a09e285166.us-east-1.playback.live-video.net. 56 IN A 192.108.239.254

實際 traceroute 後發現不是 CloudFront，但反解後發現 dig 拋出了 Justin.tv 的資訊：

;; AUTHORITY SECTION:
0.160.23.in-addr.arpa.  300     IN      SOA     ib-ens.sjc02.justin.tv. admin.justin.tv. 44 10800 3600 604800 300

;; AUTHORITY SECTION:
239.108.192.in-addr.arpa. 300   IN      SOA     ib-ens.sjc02.justin.tv. admin.justin.tv. 49 10800 3600 604800 300

然後 traceroute 可以發現跟 video-edge-6ab612.tpe03.abs.hls.ttvnw.net (在 Twitch 上隨便找個實況抓的 hostname) 進到同一個機房 (在 router 還沒有擋下來的範圍)，看起來就是拿 Twitch 的頻寬做事 XDDD

Twitch-as-a-service XDDD

這包會不會是 Twitch 掛 AWS 牌推出的服務啊 XDDD

Zoom 最後決定所有使用者都有 End-to-end encryption 了

先前在「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.

還是很怪，繼續觀望...

棄用 Keybase (Zoom 買下 Keybase 的新聞)

前幾天的新聞，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 看了一下他的經歷，對不起我錯了，我瞬間不知道怎麼寫下去了，我豆頁痛...

玩一下 Zipcall，走 WebRTC 與 P2P 架構的會議系統

這個連結在瀏覽器的 tab 上好幾天了，要寫這篇的時候試著找了一下當時是從哪個管道看到的來源，翻了一下看起來沒有在 Hacker News Daily 上面列出，但在 Hacker News 上面有找到討論串，不過最近沒有去從那邊翻連結...

Anyway，Zipcall 是使用 WebRTC 實做出來的會議系統，會議相關的流量會直接透過點對點的架構傳輸，不需要透過 server 交換。

由於架構上沒有 server 幫忙重新壓縮再轉給不同的使用者，也就 client 得自己處理，對硬體要求應該會比較高，另外對頻寬的要求也比較大。

另外他提到 latency 比較低這件事情，剛剛用兩隻 webcam 測試，一個掛到 vm guest 裡面，另外一個掛在 vm host 上面，測試下來很明顯可以感覺比起之前用 Zoom 高，可能要再研究到底是什麼原因，不確定跟 vm 有沒有關係，不過還在可以接受的範圍。

安全性與隱私性的實做方式也還得再看看是怎麼弄的，不過目前看起來應該可以先拿來玩玩...

用 OpenCV 處理 webcam 的背景，再用 pyfakewebcam 接回給視訊軟體用...

最近武漢肺炎的關係，導致蠻多人會在家裡使用視訊會議，但背景一直是個問題... 然後就看到這篇文章：「Open Source Virtual Background」。

作者用 python-opencv 先處理 webcam 進來的影像 (看起來不只去背，還加上了 hologram 的效果 XDDD)，然後再用 pyfakewebcam 與 v4l2loopback 模擬成一個 webcam 餵回給視訊軟體，結果就惡搞成這樣了：

話說回來，最近各電商平台的 webcam 與視訊機都缺貨，還好之前有買個便宜的頂著，不然就得開筆電了...

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.