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

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):

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

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 提供服務。

AWS 也把 Kafka 包出來當服務了...

AWS 發表把 Kafka 包起來當服務賣的 Amazon MSK:「Introducing Amazon Managed Streaming for Kafka (Amazon MSK) in Public Preview」。

另外 Kafka 所需的 ZooKeeper 部份已經被包進去了,不需要另外付費:

You do not pay for Apache Zookeeper nodes that Amazon MSK provisions for you, or data transfer that occurs between brokers and nodes within clusters.

目前看起來只提供 us-east-1 區域使用。

又一個 TCP BBR 的測試結果

TCP BBRGoogle 發表的 TCP congestion control 演算法,是一個純伺服器端就能夠改善 TCP 壅塞處理的機制。在 Linux Kernel 4.9 之後被納入了。

Spotify 有大量資料要傳到使用者端 (像是音檔),剛好是 TCP BBR 改善的對象之一,實際測試後得到了很不錯的改善數據:「Smoother Streaming with BBR」。

Spotify 公佈的資料沒有提到平台,所以先稍微了解一下他的音質,也就是「Audio settings」這篇。

在 Desktop 是 160kbps/320kbps Ogg (Standard/HQ)。在 Web Player 則是 128kbps/256kbps AAC (Standard/HQ)。

行動平台部份比較複雜,在 iOS 上是 96kbps/160kbps/256kbps Ogg (Normal/High/Extreme),另外有 Automatic 自動調整的設定。在 Android 平台則是 24kbps HE-AACv2 (Low) 與 96kbps/160kbps/320kbps Ogg (Normal/High/Very high) 以及 Automatic。

而最後 Chromecast 則是 128kbps/256kbps (Standard/Premium)。

測試時可以發現 shutter (指跟不上播放速度) 的情況降低了 6%~10%,而且下載速度增加了 5%~7% (對於慢速的裝置改善更多,10%~15%):

Taking daily averages, stutter decreased 6-10% for the BBR group. Bandwidth increased by 10-15% for the slower download cohorts, and by 5-7% for the median. There was no difference in latency between groups.

而各地區的差異也可以看出來改善很多:

另外他們在測試時,剛好遇到秘魯的機房連外發生問題,結果意外發現 BBR 還是可以穩定在這種網路環境下運作:

In Peru, the non-BBR group saw a 400-500% increase in stutter. In the BBR group, stutter only increased 30-50%.

In this scenario, the BBR group had 4x bandwidth for slower downloads (the 10th percentile), 2x higher median bandwidth, and 5x less stutter!

Ubuntu 18.04 上可以直接設定 BBR,在 Ubuntu 16.04 則可以參考「Ubuntu 16.04 用 speedtest-cli 測試 TCP BBR 效能」這篇的方式升級 kernel 後設定 BBR。

不吃電池的 HD Camera Streaming...

Hacker News Daily 上看到「Towards Battery-Free HD Video Streaming」這個,不使用電池僅靠反射產生訊號,可以達到 HD 畫質的 Camera Streaming (在原型機上測試可以跑出 720p/10fps):

Finally, we design a proof-of-concept prototype with off-the-shelf hardware components that successfully backscatter 720p HD video at 10 fps up to 16 feet.

而且畫質比想像中好很多,算是比「可用」的等級還高不少:

愈來愈多在研究用 backscatter 拼一些比較複雜的應用...

AWS Media Services 推出一卡車與影音相關的服務...

AWS 推出了一連串 AWS Elemental MediaOOXX 一連串影音相關的服務:「AWS Media Services – Process, Store, and Monetize Cloud-Based Video」。

但不是所有的服務都是相同的區域... 公告分別在:

不過這邊還是引用 Jeff Barr 文章裡的說明,可以看到從很源頭的 transencoding 到 DRM,以及 Live 格式,到後續的檔案儲存及後製 (像是上廣告) 都有:

AWS Elemental MediaConvert – File-based transcoding for OTT, broadcast, or archiving, with support for a long list of formats and codecs. Features include multi-channel audio, graphic overlays, closed captioning, and several DRM options.

AWS Elemental MediaLive – Live encoding to deliver video streams in real time to both televisions and multiscreen devices. Allows you to deploy highly reliable live channels in minutes, with full control over encoding parameters. It supports ad insertion, multi-channel audio, graphic overlays, and closed captioning.

AWS Elemental MediaPackage – Video origination and just-in-time packaging. Starting from a single input, produces output for multiple devices representing a long list of current and legacy formats. Supports multiple monetization models, time-shifted live streaming, ad insertion, DRM, and blackout management.

AWS Elemental MediaStore – Media-optimized storage that enables high performance and low latency applications such as live streaming, while taking advantage of the scale and durability of Amazon Simple Storage Service (S3).

AWS Elemental MediaTailor – Monetization service that supports ad serving and server-side ad insertion, a broad range of devices, transcoding, and accurate reporting of server-side and client-side ad insertion.

引個前同事的 tweet,先不說 Amazon SWF 的情況 (畢竟 Amazon SWF 還可以找到其他用途),倒是 Amazon Elastic Transcoder 很明顯要被淘汰掉了:

這種整個大包的東西是 AWS re:Invent 才有的能量,平常比較少看到...

利用 Side-channel 資訊判斷被 HTTPS 保護的 Netflix 影片資訊

在「Netflix found to leak information on HTTPS-protected videos」這篇看到了研究員透過 VBR 所透露出的 side channel 資訊,成功的取得了被 HTTPS 保護的 Netflix 影片資訊。這對於美國的 ISP 是個大利多 (加上之前通過的法案),但對於個人隱私則是嚴重的打擊。

這項研究的準確率非常高:

To support our analysis, we created a fingerprint database comprised of 42,027 Netflix videos. Given this collection of fingerprints, we show that our system can differentiate between videos with greater than 99.99% accuracy. Moreover, when tested against 200 random 20-minute video streams, our system identified 99.5% of the videos with the majority of the identifications occurring less than two and a half minutes into the video stream.

而且他們居然是用這樣的單機分析:

null

苦啊...

收 Wikimedia (包括維基百科) 的 Recent Changes

所以有新的 streaming protocol 取代本來的 RCStream:「Get live updates to Wikimedia projects with EventStreams」。

這次新的 protocol 是走標準協定:

EventStreams is built on the w3c standard Server Sent Events (SSE). SSE is simply a streaming HTTP connection with event data in a particular text format. Client libraries, usually called EventSource, assist with building responsive tools, but because SSE is really just HTTP, you can use any HTTP client (even curl!) to consume it.

直接用瀏覽器打開也可以看到一直冒出來新的訊息...

Amazon 決定在自家的購物網站上停售 Google Chromecast 與 Apple TV

這大概是這幾天最刺激的事情... Amazon 決定在自家購物往站上停售 Google ChromecastApple TV:「Amazon to Ban Sale of Apple, Google Video-Streaming Devices」。

引用新聞的報導說明,因為 Chromecast 與 Apple TV 不相容於 Amazon 自家的 Prime Video,所以下令所有的店家停售:

The Seattle-based Web retailer sent an e-mail to its marketplace sellers that it will stop selling the Apple TV and Google’s Chromecast since those devices don’t "interact well" with Prime Video. No new listings for the products will be allowed and posting of existing inventory will be removed Oct. 29, Amazon said. Prime Video doesn’t run easily on its rival’s hardware.

至於會不會引起反壟斷調查呢?站在看好戲的立場當然是很希望,但這兩個產品就算不在 Amazon 上買,也有一卡車的競爭對手有賣... 不曉得後面會怎麼發展。