本文來自 愛奇藝 技術產(chǎn)品中心 資深工程師 王亞楠在LiveVideoStackCon 2018熱身分享，并由LiveVideoStack整理而成。在分享中，王亞楠分別介紹了自動碼率調(diào)節(jié)的實現(xiàn)過程、現(xiàn)行算法與評價標準，并重點介紹了基于強化學習的自動碼率調(diào)節(jié)算法的技術架構與實現(xiàn)要點。

大家好，我是王亞楠，現(xiàn)在就職于愛奇藝終端網(wǎng)絡部署，今天很高興能在這個平臺來跟大家講述一下我們在愛奇藝做的一些很有意思的工作，這個工作主要就是我們基于強化學習做的自動碼率調(diào)節(jié)。

今天的主要內(nèi)容：

1.自適應碼流

2.強化學習

3.基于強化學習的自動碼率調(diào)節(jié)

今天的主要內(nèi)容分三個方面，第一，介紹一下什么叫自適應碼流，在自適應碼流中我會著重介紹為什么要用自動碼率調(diào)節(jié)。然后會給大家介紹一個很清晰的評價標準來衡量我們做的自動碼率調(diào)節(jié)。第二，介紹強化學習，可能在座的大部分人對強化學習的了解應該不是很多。第三，基于強化學習的自動碼率調(diào)節(jié)，在這里會簡單介紹一下怎么樣用強化學習來實現(xiàn)自動碼率調(diào)節(jié)，自動碼率調(diào)節(jié)現(xiàn)在已經(jīng)有一些算法了，但這些算法都有自己的優(yōu)勢，當然也有自己的短處，那么為什么我們要用強化學習來做？以及我們在用強化學習做自動碼率調(diào)節(jié)的時候，它應該是采用一種怎樣的技術架構，以及有哪些要實現(xiàn)的技術要點？

1、關于我們

我們項目組是隸屬于愛奇藝網(wǎng)絡終端部的，愛奇藝目前是國內(nèi)最大的長視頻網(wǎng)絡公司，僅在過去的一年，共增加兩千八百多部的電視劇，以及一萬多部的電影，移動端的月活動量達到6.1億，PC端也達到了3.6億，是除了微信和QQ之外，月活動量最多的一個應用。我們用戶的網(wǎng)絡環(huán)境和設備是千差萬別的，網(wǎng)絡環(huán)境主要分為三種， PC端主要用的是有線連接，手機端大多是的是WiFi，數(shù)據(jù)網(wǎng)絡用的不是太多，除了這三種還有其他網(wǎng)絡，比如連上一些其它的手機熱點等等。愛奇藝的終端也包括很多種，現(xiàn)在最多的用戶是手機用戶，除了手機還有一些比較常見的如PAD和PC。另外，在中國的家庭里面，網(wǎng)絡電視也是非常重要的一個方面。除此之外，還有一個特殊的應用——奇藝果，這是我們自己推出的一個很適合連接到網(wǎng)絡電視上，可以將你手機上內(nèi)容完全在電視上進行播放的一個工具，效果很好而且也很便宜。我們組一直致力于用技術手段為用戶提供更清晰流暢的觀看體驗，下面為大家介紹的自適應碼率調(diào)節(jié)就是提升觀看體驗的一種手段。

2、自適應碼流

2.1 介紹自適應碼流

用戶在觀看一個視頻的時候，需要將視頻內(nèi)容從服務器上取到本地才能觀看，在這個過程中因為用戶的網(wǎng)絡環(huán)境和設備千差萬別，如何在一個復雜的環(huán)境中給用戶提供一個清晰流暢的視頻，自適應碼流就是一個很好的解決辦法。因為它可以根據(jù)用戶的網(wǎng)絡情況來為用戶提供不同的碼率節(jié)目，它能夠更充分的利用用戶的帶寬，根據(jù)用戶的帶寬提供不同的碼率節(jié)目，相比較于之前單一的碼率節(jié)目，它所提供的節(jié)目會更清晰流暢。

自適應碼流包括兩個方面：

1）傳輸形式：HLS/DASH/Smooth Streaming

2）碼率調(diào)節(jié)算法：ABR

HLS是蘋果公司推出的一個傳輸協(xié)議，Smooth Streaming是微軟推出的一個標準協(xié)議，DASH是大家目前用的最多的開源的傳輸形式。我們可以通過碼率調(diào)節(jié)算法來確定如何通過用戶的網(wǎng)絡情況來提供不同碼率，它整個流程是在節(jié)目生產(chǎn)的時候就會被編碼為不同的碼率，根據(jù)用戶的不同情況，比如說在PC觀看還是在手機觀看，以及用戶的網(wǎng)絡情況不同，會給用戶分發(fā)不同碼率的節(jié)目，使得用戶在觀看的時候能夠不卡且清晰度最高。

2.2 實現(xiàn)過程

同一個用戶的帶寬在不同的時間段是會有一定的波動的，如果我們?yōu)橛脩糁惶峁﹩我淮a率的話，那在一部分時間之內(nèi)會造成用戶很大的帶寬浪費，這樣用戶的觀看體驗并不是很好，在一定觀看時間內(nèi)，當帶寬小于碼率的時候，會造成用戶觀看的時候非?？?，而卡頓是對用戶的觀看體驗影響最大的一個方面。

為了使用戶觀看時候能夠流暢，自適應碼流能夠根據(jù)用戶的不同的網(wǎng)絡環(huán)境和不同的設備類型，在特定的時間段內(nèi)來選擇特定的碼率，使得用戶在觀看的時候既能不卡，又能提供在他的網(wǎng)絡環(huán)境所能容納的最高的碼率節(jié)目，這樣用戶觀看下來就會比較清晰、流暢。

當在剛開播的時候用戶的網(wǎng)絡環(huán)境可能不太好，或者是Buffer中沒有內(nèi)容，這時先給他一個比較低的碼率，當用戶的網(wǎng)速起來之后，或者當它的Buffer慢慢的變多之后，我們會給他提供一個比較高的碼率，這樣的話，他可以切換到這樣一個更高的碼率，如果用戶的網(wǎng)速變得更好，那么我們也可以給他提供更高清的碼率，但是這個在切換的時候，我們會選擇一定的時間點，這個時間點也就是我們在自適應碼流中所稱為的關鍵幀。那么我們?nèi)绾胃鶕?jù)用戶的當前狀態(tài)來確定下一個要播放碼率呢？目前采用的幾個通用的方面，主要是帶寬，還有目前已經(jīng)緩存了多少的數(shù)據(jù)，設備的類型，以及當前設備所能支持的碼率。當協(xié)議確定之后，就要通過自適應碼流的一個非常關鍵的技術，也就叫自適應碼率調(diào)節(jié)來根據(jù)用戶的網(wǎng)絡環(huán)境來進行碼率的調(diào)節(jié)。

2.3 現(xiàn)行自動碼率調(diào)節(jié)算法

1）基于帶寬的算法：FESTIVE

基于帶寬的算法主要是通過用戶前一段時間的網(wǎng)絡變化，然后來預估后續(xù)可能的網(wǎng)絡帶寬，然后根據(jù)預估的帶寬，來決定這個用戶所適合的碼率。

2）基于Buffer的算法：BOLA

基于Buffer是因為用戶的網(wǎng)絡環(huán)境的變化最終會體現(xiàn)到用戶的Buffer中，也就是Buffer中緩存了多少數(shù)據(jù)，是受帶寬的影響的，那么只要基于Buffer，也可以決定我下一個將要選擇的碼率。

3）綜合考慮Buffer和帶寬的算法：MPC

基于Buffer和帶寬的算法，也就是把這兩種因素綜合考慮起來。

各自優(yōu)缺點：

2.4 自動碼率調(diào)節(jié)評價標準

在考慮能不能用一種新的算法之前，我們需要先決定，我們怎么樣來評估我們做的這個自動碼率調(diào)節(jié)，要評估它在什么情況下才算是好的，它的效果是可以接受的?，F(xiàn)在評估主要是從三個方面：清晰度，流暢度，平滑度。

簡單解釋一下，清晰度就是用戶直觀看到的碼率的清晰度，比如說是720P，還是1080P；另外，流暢度比較好理解，用戶只要不卡，它的觀看就是流暢的，如果它卡頓的話，卡的時間越長，那用戶可能就更多的會不再看你這個視頻了；再一個就是平滑度，如果你在非常頻繁的切換的話，用戶能夠很清晰的感知到你這個切換過程，也是對用戶的觀看體驗也是有個影響的。

我們的目標就是在盡量不產(chǎn)生卡頓的基礎上能夠最大化的盡量利用用戶的帶寬，同時盡量減少我們的切換次數(shù)。基于這樣一個標準，我們形成了一個公式：

這個公式考慮到了剛才說的三個方面的緯度，當然也會加一些調(diào)節(jié)因子。再者就是我們?nèi)绻胱錾暇€的話，需要考慮的一個重要方面就是成本控制。因為我們提高QoS的最終目的，就是希望用戶能夠更長時間觀看我們的視頻，這樣會為我們帶來更高的收益，但是如果我們完全不考慮帶寬來為用戶提高更高的碼率，我們整體的帶寬的成本也會變得越來越高，這樣可能導致我們所取得的收益可能并不足以覆蓋所付出的成本，所以如果要上線的話，成本控制也是需要考慮的一個重要方面。在這個評估模型中，它其實有很多方面都沒有考慮到，一個是沒有考慮到卡頓的次數(shù)；另外一個，它并不是用戶觀看體驗直接的體現(xiàn)，只是我們一個計算公式。

3、強化學習

強化學習目前是AI領域中運用非常廣泛的一個技術，主要是在預測，就是做決策方面比較擅長。它主要包括兩個部分，一個是Agent，即最終做決策的一個單位，另外一個就是Environment，這個環(huán)境也就是Agent所面臨的所有輸入。整個流程就是在每一步，Environment會給Agent一個輸入，這個輸入也就是狀態(tài)。在Agent取得這個狀態(tài)以后，會采取一定的動作。在采取這個動作之后，這個Agent會獲得一定的獎勵，也就是Reward，那這個Agent就會觀察我現(xiàn)在的狀態(tài)，我所采取的動作是什么，我所獲得的Reward是什么，這樣在經(jīng)過一系列的訓練之后，它能夠使得我之后再采取一些動作的時候，我所能獲得的獎勵就是最高的，就是這樣一個過程。

那么為什么要用強化學習完成自動碼率調(diào)節(jié)呢？

因為強化學習所解決的問題就是馬爾科夫過程的問題，ABS問題又正好是一個馬爾科夫過程的問題，因為ABS其實是根據(jù)我們當前的狀態(tài)來選擇下一個碼率，它和之前的狀態(tài)都是不相關的。如果我們采用強化學習來做選擇下一個碼率，我們把帶寬，Buffer，還有等等一些播放狀態(tài)來當作我的狀態(tài)，只需要把這些狀態(tài)輸入我的Agent，無需要對帶寬進行預測了，而且我們現(xiàn)在的技術已經(jīng)可以滿足，提供一些數(shù)據(jù)后，強化學習自動訓練，并且針對不同的場景可以使用不同模型，這樣的話，也無需進行調(diào)參。

4、基于強化學習的自動碼率調(diào)節(jié)

在做成基于強化學習的自動碼率調(diào)節(jié)后首先需要考慮一個問題，即這個過程是放到客戶端還是服務器端來做？

1） 客戶端實現(xiàn)碼率預測功能

架構非常簡單，我們只要把這個模型訓練好之后，拿到客戶端來做，由客戶端自己來決定下一個碼率就好了。

2）服務器端實現(xiàn)碼率預測功能

這就要實現(xiàn)一個BS架構，自動碼率調(diào)節(jié)功能是由客戶端和服務器端共同來做的，服務器端來決定選擇哪個碼率，然后將這個碼率再發(fā)送給客戶端。

另外一個問題，經(jīng)過模型訓練后，如何確定一個最優(yōu)模型呢？

模型訓練好了之后，需要進行一個評估，評估好了之后，我們會選擇我們評估效果最好的那個模型來使用，在這個過程我們會選擇用A/B Test的架構來選取最優(yōu)模型。A/B Test的結(jié)果是確定最終模型的關鍵；C/S架構更適合做A/B Test，因為服務器端是可以很容易控制的，我們在CS這樣一種架構上來做A/B Test是比較簡單方便的。

下面來看一個實時多模型的A/B Test架構圖：

客戶端和服務器端進行溝通的時候，我們可以先經(jīng)過一個算法的選擇器，可以用一個服務器來做分發(fā)，來實現(xiàn)A/B Test以更好的評估訓練出來的模型，在這個算法服務器后面，就是對應的一個一個的強化學習模型的服務器，通過一個算法分發(fā)器，就能夠決定一個模型它所針對哪些用戶。同時Selector也可以知道它所收集到的不同模型的數(shù)據(jù)是什么；然后通過這個A/B Test Selector服務器，將收集到的數(shù)據(jù)通過QoS Scorer服務器來進行最終的計算，這樣就實現(xiàn)了一個A/B Test 的過程。

在利用A/B Test來評估最優(yōu)模型的過程也會遇到很多的問題：

1）碼率預測模型的選擇

強化學習它有很多模型，因為碼率預測它的狀態(tài)是個連續(xù)的過程，所以我們選擇DRL，DRL對連續(xù)的輸入輸出都會有一個比較好的結(jié)果。

2） 選擇合理的訓練方式

首先，訓練數(shù)據(jù)的收集是需要客戶端來投遞的；其次是Reward的選擇，因為強化學習一個很重要因素就是需要給它一個Reward，那Reward的選擇會直接影響到后續(xù)訓練出來模型的效果；再就是On-Policy還是Off-Policy的訓練方式。

3）QoS評估

我們現(xiàn)在很常用的一些模型它沒有考慮卡頓次數(shù)的因素，所以需要考慮這個；再就是我們會增加一些用戶反饋的數(shù)據(jù)來直觀的表現(xiàn)出用戶是否喜歡我們這樣給他做的自動碼率調(diào)節(jié)，可能有的用戶并不喜歡。

4）成本控制

我們需要考慮的非常清楚，我們?yōu)橛脩籼峁└逦囊曨l，收益是否會大于支出。

5、Q&A

Q1：亞楠老師，有一位同學問到，請問你們這個是用在點播上的嗎？有應用在直播嗎？

A：我們現(xiàn)在是在點播上用，不過會計劃部署到直播端，線上現(xiàn)在也是有用戶在用，如果你是我們的灰度用戶，你可能會觀看到這樣一個效果。最后的效果也是我剛才介紹的一部分，這里面會有一個評分，評分最高就是用強化學習來做自動碼率調(diào)節(jié)的效果，相比于其他的得分是一些其他模型的得分，目前我們來看用強化學習來做這樣的事情還是可以的，相對于強化學習來說，自動碼率調(diào)節(jié)還算是一個非常簡單的事情。

Q2：亞楠老師可以具體的說一下QoS的評分嗎？

A：QoS評分我們現(xiàn)在會有很多種了，我現(xiàn)在翻到那頁PPT，我們現(xiàn)在的QoS評分，目前這個QoS評分是我們做得一個Reward，我們最終在做，我剛才給的那一幅圖上面，會加很多其他的因素，我這里的卡頓次數(shù)，還有用戶觀看的體驗的這樣一個得分，在這里定義的QoS是清晰度的得分，還有流暢度的得分，平滑度的得分，這三項結(jié)合到一起，然后我們自己調(diào)節(jié)的這樣一個模型。

Q3：輸出的碼率是連續(xù)的嗎？

A：輸出碼率是不連續(xù)的，因為自適應碼率它的碼率都是固定檔位的，它會有幾檔之分，它不是連續(xù)的碼率的。

Q4：在實戰(zhàn)中有沒有部署過mao的Pensieve，在相同的State&Action下，Performance是怎么樣的？

A：這是個好問題，我們這個工作就是和mao合作的，一開始是我們和他合作的，他們希望能夠用一些業(yè)界的數(shù)據(jù)來證明一下，那我們在做這個事情的時候，如果做研究的模型，直接拿出來用到我們線上的話，是有很多方面是需要進行改動的，調(diào)節(jié)的。那我們最開始的思想是借鑒的毛的這個Pensieve的一個思想，最后加入了很多我們的思考，以及針對我們在實際的工作中遇到的很多問題進行了解決。那基本思想就是Pensieve，我們是和他進行一個合作的。Performance，因為我們是在這個模型之上加入了很多我們自己的一些理解，還有一些其他因素這樣做的，具體的performance數(shù)據(jù)數(shù)據(jù)可以關注我們后續(xù)的技術分享。

Q5：客戶端集成模型，你們感覺它的性能是怎樣的？

A：客戶端集成模型我們也有評估，最終確定出來效果之后，我們覺得影響應該不會很大，特別是對PC端，當然對一些低端的安卓機可能會有一些影響，具體的一些低端的安卓機我們要不要用這樣一種在客戶端實現(xiàn)的方式，我們后面還需要繼續(xù)評估。對于一些比較高端的安卓機，還有蘋果機應該是沒有什么影響。復雜度，看你怎么說，因為這樣一個事情，除了網(wǎng)絡和Buffer以外，就是一些我們所考慮到的，比如說成本的因素，等等這樣一些因素，我們的維度是比較少的，并沒有很多，所以它的復雜度也并不是很高，這樣的話，對于我們的放到客戶端來做，其實是有優(yōu)勢的。我們現(xiàn)在之所以會首先選擇C/S架構，主要是為了先做A/B Test，做完A/B Test之后，我們能最終確定一個最優(yōu)的一個模型。

Q6：比如卡頓比各播放碼率分布在部署前后的變化，總帶寬的變化，下載速度的統(tǒng)計等這些是怎樣的？

A：卡頓比，這個數(shù)據(jù)都比較細了，我們可以說一下，首先是碼率分布的話，碼率的質(zhì)量是有一個很明顯的提升的，包括我們的720P和1080P的占比都會有一個非常明顯的提升，相對應的卡頓比的變化倒不是很明顯。我在這里之所以提高到，提了很多次這些成本控制，就是我們觀測到，因為我們的清晰度，就是高碼率的占比會比較大的時候，我的帶寬的增長其實是非常大的，所以這個帶寬的變化也是比較大的。下載速度，當然下載速度我們倒沒有特意的去評估，因為我們覺得，我們從我們評估的角度來看，卡頓比如果沒有增加的話，它的下載速度是能夠支撐他在下載的碼率。