幹壞事是進步最大的原動力
在 Hacker News Daily 上看到「Show HN: API to query catalogs of 20 streaming services across 60 countries (movieofthenight.com)」這個，但這個服務反而不是重點，有許多人發現裡面錯誤率頗高，而且也沒有台灣的資料，反倒是裡面有人提到 JustWatch 這個服務看起來比較好用...
像是「Friends」(這邊用的是中國的翻譯片名) 可以看到在台灣是在 Netflix 上，美國的話則是在 HBO Max (串流) 與 Apple TV (購買) 上可以看到。不過查 MythBusters 在兩個平台上都沒看到資料...
但整體上來說 JustWatch 搜出來的品質還是好不少...
RabbitMQ 要在 3.9 版推出 Streams (目前 3.9 還在 RC)：「RabbitMQ Streams Overview」，在 Hacker News 上有一些討論可以看：「RabbitMQ Streams Overview (rabbitmq.com)」。
這樣 RabbitMQ 可以同時有 queue 與 stream 的能力，對於一些小專案應該會方便不少，算是打隔壁棚 Kafka 的痛點之一，弄一組 HA cluster 至少要三台 ZooKeeper 加上兩台 Broker，基礎建設還要有對應的 HA load balancer 機制，在 AWS 上可以拿 ELB 偷懶，如果是實體機房的話也許用 F5 擋，或是用 open source 的 Keepalived (或是老一點的 Heartbeat) + nginx。
目前還不知道 scalability 的能耐，不過印象中在 queue 的單台 throughput 不差，如果沒有意外的話，streaming 的部份對小型專案應該夠用。
首先是 Apple 宣佈了無損的音樂串流服務，不另外加價：「Apple Music Launching Spatial Audio With Dolby Atmos and Lossless Audio in June at No Extra Cost」，官方新聞稿在「Apple Music announces Spatial Audio with Dolby Atmos; will bring Lossless Audio to entire catalog」。
再來是 Amazon 也宣佈跟上，本來就有提供無損的 Amazon Music HD 下放到 Amazon Music Unlimited 方案也可以聽了：「Amazon Music Matching Apple by Offering Hi-Fi Tier at No Extra Cost」。
這對 Spotify 的壓力應該不小，畢竟已經先宣佈會推出無損版，但卻反而先被競爭對手出招先行制定價錢了...
差不多一年前提到了 Kafka 打算拔掉 ZooKeeper 的計畫 (在「Kafka 拔掉 ZooKeeper 的計畫」這邊有提到)，昨天 Confluent 發了一篇進展：「Apache Kafka Made Simple: A First Glimpse of a Kafka Without ZooKeeper」。
這件事情可以在「KIP-500: Replace ZooKeeper with a Self-Managed Metadata Quorum」這邊看到說明，另外在 Jira 上面則是在 KAFKA-9119 這邊追蹤。
目前的好消息就是 KIP-500 的程式碼都已經推進 trunk，目標在 2.8 釋出時就可以用：
So we’re very pleased to say that the early access of the KIP-500 code has been committed to trunk and is expected to be included in the upcoming 2.8 release.
文件裡面會用「Kafka Raft Metadata mode」或是「KRaft」稱呼這種模式：
For the first time, you can run Kafka without ZooKeeper. We call this the Kafka Raft Metadata mode, typically shortened to KRaft (pronounced like craft) mode.
然後有缺一些功能，另外就是常態性宣導這是測試版，建議不要在 production 環境用：
Beware, there are some features that are not available in this early-access release. We do not yet support the use of ACLs and other security features or transactions. Also, both partition reassignment and JBOD are unsupported in KRaft mode (these are anticipated to be available in an Apache Kafka release later in the year). Hence, consider the quorum controller experimental software—we don’t advise subjecting it to production workloads. If you do try out the software, however, you’ll find a host of new advantages: It’s simpler to deploy and operate, you can run Kafka in its entirety as a single process, and it can accommodate significantly more partitions per cluster (see measurements below).
目前丟出來的測試數據可以看到有大幅改善，但仔細看居然是停機與恢復時間：
不知道實際的效能上有多少影響 (正面或是負面)，還是得等了...
看到「Debian donation for Peertube development」這則消息，Debian 決定資助 10K 歐元提供給 PeerTube 發展。
不過更大的幫助應該是 PR 上的部份，這帶出來的曝光度以及「認可」的部份比 10K 歐元重要的多。
回到 Debian 決定資助的原因，是因為 DebConf20 需要一個非封閉式平台的直播架構，而 PeerTube 看起來很適合這個情境：
This year's iteration of the Debian annual conference, DebConf20, had to be held online, and while being a resounding success, it made clear to the project our need to have a permanent live streaming infrastructure for small events held by local Debian groups. As such, Peertube, a FLOSS video hosting platform, seems to be the perfect solution for us.
前幾天在「有風聲說司法部會把 Chrome 拆出 Google」這邊有提到 YouTube 很難取代的問題，這個算是其中的一個方向，試著在解決平台壟斷的問題...
一樣是在 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」這個產品：
Got one of those "camlink" USB converters because I was curious about em, and WHOAH I was shocked. UVC output, 20ms delay and signal looks to be properly grabbing 1080P@30. Single chip solution under a small sink and costs under $20. What in the heck is this. pic.twitter.com/J7HYM3cf3M
— Arsenio Dev (@Ascii211) June 4, 2020
而作者在 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
把直播系統包在一起的服務 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
AWS 推出了 Live 用的硬體設備 AWS Elemental Link，可以直接將影音訊號轉完後丟到 AWS 自家的 AWS Elemental MediaLive 服務上：「New – AWS Elemental Link – Deliver Live Video to the Cloud for Events & Streams」。
機器很輕 (450g) 也不大 (32 立方英呎，大約 524 立方公分)：
界面上吃 Live 領域常用的 SDI (3G-SDI) 或是 HDMI，規格上只能轉 1080p60 (剛好也是 3G-SDI 的上限)，然後設備除了透過一般電力供電以外，也可以用 PoE 供電，可以少接一條電源線：
Link takes a single video input as a source and sends a single video output up to 1080p 60fps to AWS Elemental MediaLive. Set up requires three connections to begin streaming video to MediaLive: a power source, an IP network, and a 3G-SDI or an HDMI video source. Link also supports Power over Ethernet (PoE) so you can use as few as two cables.
價位上是賣 USD$995，但對於有 SDI 類的設備價錢不熟。看了一下旁邊棚子 Blackmagic Design 的產品，好像沒看到類似可以直接送到網路服務的產品...
在 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，沒有太考慮額外的計算成本...
在「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)：
不確定其他家的情況...