點(diǎn)擊上方“LiveVideoStack”關(guān)注我們

作者?|?Fengjiao Peng

譯者?|?姜金元

技術(shù)審校?|?曾凱

Mimir

影音探索

#004#

據(jù)思科公司的一項(xiàng)調(diào)查顯示：到2022年，視頻將占到所有消費(fèi)者互聯(lián)網(wǎng)流量的82%以上，比2017年增長(zhǎng)了15倍。現(xiàn)在人們隨時(shí)隨地都可以觀看視頻，比如在家使用Wi-Fi、在手機(jī)上、在火車上，在城市里和山間；晚飯后，全家人一起在網(wǎng)上觀看視頻，或者當(dāng)孩子們熟睡以后，在凌晨三點(diǎn)觀看視頻。這些網(wǎng)絡(luò)條件的多樣性給在線視頻流帶來(lái)了前所未有的挑戰(zhàn)。

截至2020年12月31日，Vimeo視頻播放器每個(gè)月要支持高達(dá)1000億次播放，每天有29.7萬(wàn)個(gè)新視頻上傳到我們的平臺(tái)。高分辨率和無(wú)縫播放體驗(yàn)對(duì)于創(chuàng)作者的成功來(lái)說(shuō)至關(guān)重要。我們付出了很多努力來(lái)優(yōu)化觀看體驗(yàn)，從存儲(chǔ)層的分配、CDN的選擇和交付，到構(gòu)建超輕量級(jí)播放器的算法效率的提高，而設(shè)計(jì)一個(gè)好的視頻流算法則是最重要的方面之一。

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

圖1: ABR技術(shù)。每個(gè)電影片段代表一個(gè)切片。在播放過(guò)程中，ABR算法可以根據(jù)網(wǎng)絡(luò)條件上下切換畫質(zhì)，以確保更好的觀看體驗(yàn)。在上圖中，視頻質(zhì)量從1440p切換到720p。

挑戰(zhàn)

為了優(yōu)化用戶QoE（衡量用戶觀看體驗(yàn)的質(zhì)量高低的指標(biāo)），ABR算法的目標(biāo)其實(shí)是相互矛盾的: 我們希望盡可能提供最高質(zhì)量的視頻，但是下載一個(gè)尺寸超過(guò)吞吐量的視頻切片又會(huì)導(dǎo)致延遲的發(fā)生。當(dāng)帶寬發(fā)生變化時(shí)，我們希望通過(guò)上下切換質(zhì)量檔位來(lái)自適應(yīng)它，但是不必要的檔位切換也會(huì)影響到QoE。該算法需要注意的是所有通用的QoE標(biāo)準(zhǔn)，而不是過(guò)分側(cè)重其中的某一個(gè)。

在Vimeo，我們對(duì)良好的播放體驗(yàn)作了以下定義:

• 首屏快速打開：一般的經(jīng)驗(yàn)法則是，如果一個(gè)頁(yè)面或視頻加載時(shí)間超過(guò)3秒，有超過(guò)50%的概率會(huì)被用戶放棄。

• 保持首屏高質(zhì)量，并在整個(gè)視頻播放過(guò)程一直延續(xù)高質(zhì)量播放。

• 無(wú)卡頓：在播放過(guò)程中，無(wú)卡幀和緩沖情況。

• 最小檔位切換：無(wú)縫播放是關(guān)鍵。

為了達(dá)到這些目標(biāo)，我們開發(fā)了一個(gè)強(qiáng)化學(xué)習(xí)算法——Mimir。這是一個(gè)適用于Vimeo播放器的通用ABR解決方案，該算法能自適應(yīng)全球不同網(wǎng)絡(luò)狀況和全天的網(wǎng)絡(luò)波動(dòng)。

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

圖2:訓(xùn)練循環(huán)

Mimir的成功源于四個(gè)重要的設(shè)計(jì)決策：

• 建立正確的獎(jiǎng)勵(lì)模型

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

• 編程實(shí)現(xiàn)盡可能接近真實(shí)播放器環(huán)境

• 均衡訓(xùn)練數(shù)據(jù)

模擬播放

某個(gè)強(qiáng)化學(xué)習(xí)agent在模擬環(huán)境中訓(xùn)練后，再被部署到現(xiàn)實(shí)環(huán)境中，往往會(huì)出現(xiàn)訓(xùn)練偏差。Vimeo播放器包含一組非常明確的規(guī)則，用于在小緩沖區(qū)的約束下下載和播放視頻。例如，當(dāng)一個(gè)視頻切片的下載時(shí)間超過(guò)8秒時(shí)，就會(huì)發(fā)生下載超時(shí)錯(cuò)誤。遇到這個(gè)錯(cuò)誤時(shí)，播放器會(huì)丟棄已經(jīng)為該切片下載的數(shù)據(jù)，并以較小的碼率重新請(qǐng)求整個(gè)切片。在訓(xùn)練中，agent需要通過(guò)將錯(cuò)誤（當(dāng)下載時(shí)間超過(guò)8秒時(shí)下載失敗的情況）反映在獎(jiǎng)勵(lì)中來(lái)學(xué)習(xí)。

獎(jiǎng)勵(lì)r將用戶感知到的QoE告知agent。結(jié)合我們?cè)谧罱ぷ髦锌催^(guò)的結(jié)果，我們將其表述為：

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

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

自定義播放器規(guī)則依賴于播放器，包含任意的獎(jiǎng)勵(lì)或懲罰。在Vimeo播放器中，它們是：

• 視頻首屏獎(jiǎng)勵(lì)：如果該切片是視頻的前幾個(gè)片段，獎(jiǎng)勵(lì)更高的質(zhì)量。

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

在傳統(tǒng)的 ABR 算法中，這些規(guī)則很難插入到現(xiàn)有的優(yōu)化邏輯中。而這些規(guī)則正是強(qiáng)化學(xué)習(xí)算法大放異彩的地方！在模擬測(cè)試中，與基于吞吐量算法的baseline相比，Mimir在獲得的總獎(jiǎng)勵(lì)方面提升了26 ±3%，重新緩沖的情況減少了69%。

在圖3所示的測(cè)試播放過(guò)程中，吞吐量（紫線）在1~4 Mbps之間快速波動(dòng)，像這樣的快速波動(dòng)在高峰時(shí)段是經(jīng)常發(fā)生的。Mimir始終在傳輸720p的視頻流。當(dāng)藍(lán)線下降時(shí)，它遇到了兩個(gè)超時(shí)事件，分別在67秒和162秒的時(shí)候，但它會(huì)迅速將一個(gè)視頻切片的質(zhì)量調(diào)整到240p來(lái)恢復(fù)緩沖區(qū)，因此沒(méi)有發(fā)生重新緩沖的錯(cuò)誤。相比之下，baseline是一種基于吞吐量的算法，無(wú)法持續(xù)傳輸高質(zhì)量視頻，并且在錯(cuò)誤地切換到更高質(zhì)量后，會(huì)發(fā)生重新緩沖錯(cuò)誤。請(qǐng)注意，baseline算法是如何連續(xù)發(fā)生兩個(gè)超時(shí)錯(cuò)誤的。第一次超時(shí)錯(cuò)誤之后，如果不經(jīng)過(guò)手動(dòng)編程，它是無(wú)法降低視頻質(zhì)量的。

圖3: 播放過(guò)程測(cè)試

在圖 4 所示的第二個(gè)播放過(guò)程中，吞吐量的波動(dòng)較小，但隨后出現(xiàn)了一次大幅下降。Mimir始終保持540p的視頻傳輸，在緩沖區(qū)建立之后，開始傳輸720p的視頻。在首屏開啟時(shí)，它所傳輸?shù)囊曨l質(zhì)量比baseline算法更高。在約140秒吞吐量下降時(shí)，Mimir會(huì)通過(guò)降低視頻質(zhì)量以將緩沖區(qū)大小保持在零以上。在數(shù)學(xué)方面，Mimir試圖最大限度地延長(zhǎng)播放高質(zhì)量視頻 （720p）的時(shí)間。對(duì)于不喜歡視頻質(zhì)量突然下降和恢復(fù)的用戶，也可以訓(xùn)練它一直播放540p的視頻。

圖4: 第二個(gè)播放過(guò)程測(cè)試

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

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

下載時(shí)間建模

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

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

當(dāng)我們?yōu)橐粋€(gè)視頻切片發(fā)送HTTP請(qǐng)求時(shí)，總的下載時(shí)間（dT）由兩部分組成：首字節(jié)時(shí)間(time-to-first-byte，TTFB)和下載時(shí)間（dt），dt由視頻切片大小（size）除以吞吐量（throughout）得到。TTFB取決于用戶的網(wǎng)絡(luò)狀況以及該視頻段最近是否已緩存在CDN中。值得注意的是，TTFB與視頻切片大小無(wú)關(guān)。模型將TTFB與下載時(shí)間分開是很重要的。

假設(shè)我們只為模型提供總下載時(shí)間（dT）作為輸入。該模型可能會(huì)假設(shè)：

dT = size / throughput + error

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

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

當(dāng)平均TTFB遠(yuǎn)大于dt時(shí)，例如該視頻未緩存在CDN上時(shí)，第一個(gè)模型會(huì)導(dǎo)致吞吐量估計(jì)出現(xiàn)較大偏差。假設(shè)對(duì)于某個(gè)視頻切片，TTFB等于60 ms，dt等于30 ms，視頻切片大小為 500 KB。這兩個(gè)模型的吞吐量估計(jì)值分別為：

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

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

第一個(gè)是實(shí)際吞吐量，第二個(gè)是agent所認(rèn)為的吞吐量（如果沒(méi)有給出單獨(dú)的TTFB和下載時(shí)間）。一個(gè)是4K畫質(zhì)，另一個(gè)則是540p！因此，在模擬和部署中分離TTFB和下載時(shí)間是很重要的。

在實(shí)踐中，我們收集了數(shù)十萬(wàn)條吞吐量和TTFB trace數(shù)據(jù)，我們?cè)陔S機(jī)采樣的TTFB和吞吐量trace數(shù)據(jù)環(huán)境中啟動(dòng)每個(gè)播放會(huì)話。

平衡訓(xùn)練數(shù)據(jù)

平衡數(shù)據(jù)，這是機(jī)器學(xué)習(xí)中一個(gè)經(jīng)典而又永恒的話題。我們通過(guò)從Vimeo平臺(tái)的10萬(wàn)個(gè)真實(shí)視頻流會(huì)話中隨機(jī)采集的吞吐量數(shù)據(jù)和3萬(wàn)個(gè)視頻數(shù)據(jù)來(lái)進(jìn)行訓(xùn)練。由此產(chǎn)生的Mimir模型可以處理常見(jiàn)的吞吐量范圍，但在切換到高質(zhì)量（2K、4K）或處理低吞吐量會(huì)話（低于240p，意味著永久重新緩沖）時(shí)遇到了麻煩。我們意識(shí)到，需要訓(xùn)練Mimir處理各種吞吐量分布以及同樣的每一次轉(zhuǎn)碼。

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

最后

在之后的文章中，我還會(huì)繼續(xù)給大家分享更多關(guān)于在線A/B測(cè)試中調(diào)試Mimir和將它部署到實(shí)際應(yīng)用中的經(jīng)驗(yàn)。

注釋：

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

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

---

致謝

本文已獲得作者Fengjiao Peng授權(quán)翻譯和發(fā)布，特此感謝。

原文鏈接：

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

本文編輯：Alex

封面圖?by Jackson So on Unsplash

---

掃描圖中二維碼或點(diǎn)擊閱讀原文

了解大會(huì)更多信息

喜歡我們的內(nèi)容就點(diǎn)個(gè)“在看”吧！

總結(jié)

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

如果覺(jué)得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。