點擊上方“LiveVideoStack”關注我們

作者?|?Fengjiao Peng

譯者?|?姜金元

技術審校?|?曾凱

Mimir

影音探索

#004#

據思科公司的一項調查顯示：到2022年，視頻將占到所有消費者互聯網流量的82%以上，比2017年增長了15倍?，F在人們隨時隨地都可以觀看視頻，比如在家使用Wi-Fi、在手機上、在火車上，在城市里和山間；晚飯后，全家人一起在網上觀看視頻，或者當孩子們熟睡以后，在凌晨三點觀看視頻。這些網絡條件的多樣性給在線視頻流帶來了前所未有的挑戰。

截至2020年12月31日，Vimeo視頻播放器每個月要支持高達1000億次播放，每天有29.7萬個新視頻上傳到我們的平臺。高分辨率和無縫播放體驗對于創作者的成功來說至關重要。我們付出了很多努力來優化觀看體驗，從存儲層的分配、CDN的選擇和交付，到構建超輕量級播放器的算法效率的提高，而設計一個好的視頻流算法則是最重要的方面之一。

ABR（自適應碼率技術）是現代引領無縫觀影的主流技術。在早期的順序流式傳輸（progressive streaming）中，CDN是將整個視頻封裝起來并通過一個轉碼器將視頻交付給用戶。在自適應流媒體會話中，視頻被分割成了短的切片，對于大多數的商業播放器來說，該切片的長度為3或6秒。每個視頻切片都有不同質量的轉碼版本可供選擇，包括360p、720p、1080p等。對于每個切片，ABR算法通過衡量當前的帶寬和吞吐量來選擇最合適的質量檔位（如圖1）。

圖1: ABR技術。每個電影片段代表一個切片。在播放過程中，ABR算法可以根據網絡條件上下切換畫質，以確保更好的觀看體驗。在上圖中，視頻質量從1440p切換到720p。

挑戰

為了優化用戶QoE（衡量用戶觀看體驗的質量高低的指標），ABR算法的目標其實是相互矛盾的: 我們希望盡可能提供最高質量的視頻，但是下載一個尺寸超過吞吐量的視頻切片又會導致延遲的發生。當帶寬發生變化時，我們希望通過上下切換質量檔位來自適應它，但是不必要的檔位切換也會影響到QoE。該算法需要注意的是所有通用的QoE標準，而不是過分側重其中的某一個。

在Vimeo，我們對良好的播放體驗作了以下定義:

• 首屏快速打開：一般的經驗法則是，如果一個頁面或視頻加載時間超過3秒，有超過50%的概率會被用戶放棄。

• 保持首屏高質量，并在整個視頻播放過程一直延續高質量播放。

• 無卡頓：在播放過程中，無卡幀和緩沖情況。

• 最小檔位切換：無縫播放是關鍵。

為了達到這些目標，我們開發了一個強化學習算法——Mimir。這是一個適用于Vimeo播放器的通用ABR解決方案，該算法能自適應全球不同網絡狀況和全天的網絡波動。

我們使用A3C算法（Asynchronous Actor-Critic Agents）來作為我們的學習框架，其中多個agent在獨立、異步的環境中工作，采集數據并更新中央agent。關于A3C的更多具體細節，可以參考Volodymyr Mnih等人提出的“Asynchronous Methods for Deep Reinforcement Learning”[1]。我們從Vimeo數以百萬計的真實播放會話中采集數據并使用這些數據在一個離線播放器中模擬真實的播放情況，而播放環境被編程為真實播放器在實際中的播放狀態。在訓練中，通過環境模擬播放會話并生成當前狀態的快照，包括觀察到的歷史吞吐量、過去的視頻切片大小、下載時間、當前緩沖區大小等（如圖2）。這些狀態會發送到agent，從而形成一個行動者網絡（actor network）。然后行動者采取某個行動，例如為當前切片選擇某一檔位。網絡環境執行該動作，并記錄獎勵r，這是所有QoE指標的總和。當一個會話結束時，該行動會有一個累積的獎勵R，以此來衡量這次行動的長期表現。評估網絡（critic network）通過對比該狀態的平均獎勵v和獎勵R來進行評估。在每個會話結束時，行動和獎勵被發送回中央agent。中央agent執行梯度下降算法（gradient descent）來更新自己的參數，然后將自己復制給行動者，如此循環往復。

圖2:訓練循環

Mimir的成功源于四個重要的設計決策：

• 建立正確的獎勵模型

• 為agent提供大量信息，用以模擬下載時間

• 編程實現盡可能接近真實播放器環境

• 均衡訓練數據

模擬播放

某個強化學習agent在模擬環境中訓練后，再被部署到現實環境中，往往會出現訓練偏差。Vimeo播放器包含一組非常明確的規則，用于在小緩沖區的約束下下載和播放視頻。例如，當一個視頻切片的下載時間超過8秒時，就會發生下載超時錯誤。遇到這個錯誤時，播放器會丟棄已經為該切片下載的數據，并以較小的碼率重新請求整個切片。在訓練中，agent需要通過將錯誤（當下載時間超過8秒時下載失敗的情況）反映在獎勵中來學習。

獎勵r將用戶感知到的QoE告知agent。結合我們在最近工作中看過的結果，我們將其表述為：

r = αQ( ) + βR( ) + γS( ) + (播放器自定義規則)

其中Q()是與切片檔位（240p、360p、720p 等）線性相關的正獎勵；R()是重新緩沖的長度，以秒為單位；S()是檔位切換的步長（例如，如果從 1080p 切換到 720p，則步長為 720 ? 1080 = ?360）。R()和S()是懲罰項，因此總是負數，α、β和γ是加權參數。在實踐中，用戶感知到的視頻質量與視頻的分辨率不一定呈線性關系，線性函數Q()也只是一個簡化的假設。隨著轉碼技術的發展，通過部署將視覺感知和注意力考慮在內的智能算法，一些低質量的轉碼也可以看起來非常好，這也是Vimeo研究的另一個重要主題！有些用戶可能更喜歡帶有絕對零緩沖體驗的較低質量的視頻，其他用戶則可能更愿意忍受一些緩沖來觀看更高質量的視頻。還有一件重要的事，不管你怎么寫成本函數，Mimir都表現得很好，這也使得更改這些規則變得非常容易。（有關商業模式和用戶畫像如何影響QoE定義的更多信息，請查看 Steve Robertson’s Demuxed 2018 talk [2]。）

自定義播放器規則依賴于播放器，包含任意的獎勵或懲罰。在Vimeo播放器中，它們是：

• 視頻首屏獎勵：如果該切片是視頻的前幾個片段，獎勵更高的質量。

• 下載超時懲罰：如果存在下載超時錯誤，那么該視頻切片實際上是無法下載的，所以這個懲罰抵消了Q()，也是對消耗過多CDN成本的懲罰。

在傳統的 ABR 算法中，這些規則很難插入到現有的優化邏輯中。而這些規則正是強化學習算法大放異彩的地方！在模擬測試中，與基于吞吐量算法的baseline相比，Mimir在獲得的總獎勵方面提升了26 ±3%，重新緩沖的情況減少了69%。

在圖3所示的測試播放過程中，吞吐量（紫線）在1~4 Mbps之間快速波動，像這樣的快速波動在高峰時段是經常發生的。Mimir始終在傳輸720p的視頻流。當藍線下降時，它遇到了兩個超時事件，分別在67秒和162秒的時候，但它會迅速將一個視頻切片的質量調整到240p來恢復緩沖區，因此沒有發生重新緩沖的錯誤。相比之下，baseline是一種基于吞吐量的算法，無法持續傳輸高質量視頻，并且在錯誤地切換到更高質量后，會發生重新緩沖錯誤。請注意，baseline算法是如何連續發生兩個超時錯誤的。第一次超時錯誤之后，如果不經過手動編程，它是無法降低視頻質量的。

圖3: 播放過程測試

在圖 4 所示的第二個播放過程中，吞吐量的波動較小，但隨后出現了一次大幅下降。Mimir始終保持540p的視頻傳輸，在緩沖區建立之后，開始傳輸720p的視頻。在首屏開啟時，它所傳輸的視頻質量比baseline算法更高。在約140秒吞吐量下降時，Mimir會通過降低視頻質量以將緩沖區大小保持在零以上。在數學方面，Mimir試圖最大限度地延長播放高質量視頻 （720p）的時間。對于不喜歡視頻質量突然下降和恢復的用戶，也可以訓練它一直播放540p的視頻。

圖4: 第二個播放過程測試

圖5所示，在會話中下載超時后Mimir的行動分布圖，該會話以大約16Mbps的速度穩定地傳輸1080p的視頻。Mimir是不知道當前確切吞吐量的，因此根據剩余緩沖區大小（以秒為單位）來決定下一個質量是多少。如果緩沖區中還剩15秒（帶有15s標簽的藍線），Mimir大約有45%的概率會繼續選擇1080p。如果緩沖區中還剩 6或7秒，Mimir會將碼率降低到720p。如果緩沖區只剩下幾秒鐘，Mimir會將碼率降低到240p。

圖5: Mimir 在不同剩余緩沖區大小下切換碼率的概率

下載時間建模

Mimir成功的關鍵在于預測未來的吞吐量和下載時間。Mimir掌握的關于當前會話的信息越多，如：手機或有線電視、手機數據類型（4G、5G等）、農村或城市、一天或一周中的時間等等，它在吞吐量估計方面就會表現越好。如前所述，吞吐量估計在視頻剛啟動時是很難預測的。為了在會話開始之前提供對吞吐量的良好估計，我們存儲了一個包含世界上2萬個地理位置的哈希表，以及它們在Vimeo上顯示的平均值、標準差和95%的吞吐量（如圖6）。該模型將字符串作為輸入，并在運行時查找吞吐量。此表會定期更新，以跟上全球網絡最新的變化。對于數據很少或沒有數據的區域，模型會加載一個空字符串作為其輸入并返回一個默認行為。例如，美國紐約的平均網絡吞吐量和95%吞吐量分別是美國阿伯茨福德（Abbotsford）的324%和436%。正因如此，Mimir開始在阿伯茨福德地區采取不那么激進的策略。

圖6：按城市劃分的Vimeo播放器平均網絡吞吐量（2020 年 8 月至 11 月）。缺失區域的播放會話太少，我們無法很好地估計吞吐量。一般來說，發達國家的高密度城市中心的平均吞吐量超過20Mbps（想想 4G），足以傳輸1080p的視頻。在更多的農村地區，即使在同一個國家，吞吐量也會下降到每秒幾兆字節。請記住，Vimeo的流媒體速度取決于我們的CDN以及其他因素，因此該圖并不反映平均本地帶寬。

當我們為一個視頻切片發送HTTP請求時，總的下載時間（dT）由兩部分組成：首字節時間(time-to-first-byte，TTFB)和下載時間（dt），dt由視頻切片大小（size）除以吞吐量（throughout）得到。TTFB取決于用戶的網絡狀況以及該視頻段最近是否已緩存在CDN中。值得注意的是，TTFB與視頻切片大小無關。模型將TTFB與下載時間分開是很重要的。

假設我們只為模型提供總下載時間（dT）作為輸入。該模型可能會假設：

dT = size / throughput + error

然而，如果我們同時提供TTFB和下載時間（dt）作為輸入：

dT = TTFB + dt = TTFB + size / throughput + error

當平均TTFB遠大于dt時，例如該視頻未緩存在CDN上時，第一個模型會導致吞吐量估計出現較大偏差。假設對于某個視頻切片，TTFB等于60 ms，dt等于30 ms，視頻切片大小為 500 KB。這兩個模型的吞吐量估計值分別為：

throughput = size / dt = 500 / 30 = 16.67 KB/ms

throughput = size / dT = 500 / (600 + 30) = 0.79 KB/ms

第一個是實際吞吐量，第二個是agent所認為的吞吐量（如果沒有給出單獨的TTFB和下載時間）。一個是4K畫質，另一個則是540p！因此，在模擬和部署中分離TTFB和下載時間是很重要的。

在實踐中，我們收集了數十萬條吞吐量和TTFB trace數據，我們在隨機采樣的TTFB和吞吐量trace數據環境中啟動每個播放會話。

平衡訓練數據

平衡數據，這是機器學習中一個經典而又永恒的話題。我們通過從Vimeo平臺的10萬個真實視頻流會話中隨機采集的吞吐量數據和3萬個視頻數據來進行訓練。由此產生的Mimir模型可以處理常見的吞吐量范圍，但在切換到高質量（2K、4K）或處理低吞吐量會話（低于240p，意味著永久重新緩沖）時遇到了麻煩。我們意識到，需要訓練Mimir處理各種吞吐量分布以及同樣的每一次轉碼。

將2K和4K的視頻添加到視頻數據集并添加低吞吐量的數據有助于解決上述問題。我們的最終吞吐量數據采集策略從0.4~0.7 Mbps、0.7~2 Mbps、2~3 Mbps、3~4 Mbps、4~7 Mbps、7~20 Mbps 和 20+ Mbps 的數據集合中采集了相同數量的會話。這些范圍分別對應于 240p、360p、540p、720p、1080p、1440p 和 2160p的碼率，這是我們目前在Vimeo上使用到的有效的轉碼檔位。

最后

在之后的文章中，我還會繼續給大家分享更多關于在線A/B測試中調試Mimir和將它部署到實際應用中的經驗。

注釋：

[1]https://arxiv.org/abs/1602.01783

[2]https://www.twitch.tv/videos/326113867?collection=u1vmyYMIYBXvlQ

---

致謝

本文已獲得作者Fengjiao Peng授權翻譯和發布，特此感謝。

原文鏈接：

https://medium.com/vimeo-engineering-blog/one-ai-streaming-videos-for-all-aeaedb8e5378

本文編輯：Alex

封面圖?by Jackson So on Unsplash

---

掃描圖中二維碼或點擊閱讀原文

了解大會更多信息

喜歡我們的內容就點個“在看”吧！

總結

以上是生活随笔為你收集整理的Mimir：通过AI向所有人提供视频服务的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。