QoS直接關(guān)系到用戶體驗(yàn)，如何提升QoS就成為視頻平臺(tái)技術(shù)實(shí)力的體現(xiàn)。本文來自Hulu全球高級(jí)研發(fā)經(jīng)理、視頻編解碼與傳輸領(lǐng)域資深專家傅徳良在LiveVideoStackCon 2017上的分享。盡管Hulu提供服務(wù)的網(wǎng)絡(luò)環(huán)境與國(guó)內(nèi)大相徑庭，但其相關(guān)QoS保障策略依然值得借鑒。

文 / 傅徳良

整理 / LiveVideoStack

概述：

大家好，我是Hulu北京的傅徳良，主要負(fù)責(zé)音視頻編解碼和視頻傳輸相關(guān)優(yōu)化的團(tuán)隊(duì)。非常高興在這里給大家分享一些Hulu 在流媒體服務(wù)質(zhì)量和用戶體驗(yàn)優(yōu)化方面的經(jīng)驗(yàn)。由于Hulu是一家美國(guó)公司，所以使用的技術(shù)路線跟國(guó)內(nèi)常見的技術(shù)路線并不完全相同，從技術(shù)上講，不存在誰更先進(jìn)或者優(yōu)秀的說法。不過既然是不同的技術(shù)路線，那么Hulu也就可能會(huì)做一些國(guó)內(nèi)廠商目前還沒有太多投入去做的一些事情。今天，主要跟大家分享一下Hulu在QoS優(yōu)化中的思路、在實(shí)踐中遇到的問題以及解決方案。首先簡(jiǎn)單介紹一下Hulu的視頻系統(tǒng)以及為什么要做QoS優(yōu)化？其次會(huì)分享對(duì)QoS優(yōu)化和用戶體驗(yàn)之間關(guān)系的基本理解，最后結(jié)合Hulu的技術(shù)實(shí)踐介紹在客戶端通過自適應(yīng)碼率調(diào)解的方法優(yōu)化QoS的基本思路和原理，以及構(gòu)建的一整套QoS優(yōu)化框架。

一：Hulu視頻系統(tǒng)簡(jiǎn)介

Hulu是一家由美國(guó)最大的幾家傳統(tǒng)媒體行業(yè)巨頭出資創(chuàng)建的在線視頻流媒體服務(wù)公司，其創(chuàng)建目標(biāo)是把更多的優(yōu)選內(nèi)容與全美國(guó)用戶更好地連接在一起。Hulu的終端是跨越全平臺(tái)的，涵蓋網(wǎng)頁端、移動(dòng)端還有電視端。跟國(guó)內(nèi)業(yè)態(tài)有所不同的是，除了瀏覽器，Android和iOS外，在美國(guó)還需要支持很多在國(guó)內(nèi)看來比較神奇的一些設(shè)備，例如以Roku，FireTV和AppleTV為代表的電視盒子和以PS（Sony PlayStation系列），XBox為代表的游戲主機(jī)。我們需要在所有的這些平臺(tái)上面都支持我們的Streaming服務(wù)，如大家所知，這些平臺(tái)相對(duì)來講都是比較異構(gòu)的，并不像國(guó)內(nèi)的設(shè)備，基本都是基于安卓平臺(tái)進(jìn)行開發(fā)的。因此為了實(shí)現(xiàn)對(duì)北美市場(chǎng)上所有平臺(tái)的支持，給技術(shù)層面帶來了不小的挑戰(zhàn)，尤其是對(duì)于QoS調(diào)優(yōu)和用戶體驗(yàn)調(diào)優(yōu)一致性上的挑戰(zhàn)更加艱巨。

Hulu提供的觀看內(nèi)容是比較豐富的，包括當(dāng)季的美劇、優(yōu)選電影、自制劇、體育節(jié)目、兒童節(jié)目等。2017年，Hulu的直播業(yè)務(wù)上線，美國(guó)數(shù)百個(gè)Broadcast電視臺(tái)可以在Hulu的應(yīng)用和網(wǎng)站上進(jìn)行播放，而且沒有UGC（User Generated Content），都是從較大的渠道獲取的有版權(quán)的視頻內(nèi)容。值得一提的是，在2017年的艾美獎(jiǎng)評(píng)選中，Hulu的自制劇也大獲成功，共斬獲10項(xiàng)大獎(jiǎng)，堪稱是本屆艾美獎(jiǎng)評(píng)選的最大贏家，《使女的故事》（The Handmaids Tale）還獲得了Outstanding Drama Series（最佳劇集獎(jiǎng)），這在全世界的在線流媒體行業(yè)中，都是一件具有里程碑意義的事情。可見，Hulu是有非常多優(yōu)選內(nèi)容的，那么如何把這些優(yōu)選內(nèi)容以最好的體驗(yàn)呈現(xiàn)給用戶，也就成為了工作中的關(guān)鍵。

Hulu商業(yè)模式

值得一提的是，Hulu的商業(yè)模式也比較特別，采用注冊(cè)用戶+廣告的模式。Hulu是由幾家傳統(tǒng)媒體公司創(chuàng)建的，商業(yè)模式跟整個(gè)美國(guó)電視行業(yè)的模式相似，如果你想要觀看Hulu，首先需要付費(fèi)，注冊(cè)成為我們的用戶。在此基礎(chǔ)上，可以選擇不同的，有廣告或無廣告的套餐。這種注冊(cè)用戶+廣告的模式使得Hulu在整個(gè)商業(yè)競(jìng)爭(zhēng)中處在一個(gè)十分特殊的位置，也使得技術(shù)層面上需要做出相應(yīng)的改變。在這種商業(yè)模式下，用戶的單位價(jià)值是比較高的，一方面，用戶繳納了注冊(cè)費(fèi)。另一方面，用戶還觀看了廣告，這些廣告也帶來了很多收入。 在此基礎(chǔ)上，如何使更多的用戶觀看Hulu的視頻，觀看更多的視頻，對(duì)Hulu來講特別重要。當(dāng)然，這個(gè)邏輯基本上對(duì)于所有的在線流媒體服務(wù)公司也都是成立的。由于內(nèi)容都是花費(fèi)大價(jià)值買來的，用戶的單位價(jià)值是較高的，因此Hulu有非常強(qiáng)烈的意愿把用戶體驗(yàn)做得更好。更好的用戶體驗(yàn)可以帶來更多的用戶，更大的視頻播放量，也就是更多的用戶訂閱數(shù)和更高的廣告營(yíng)收。所以說，用戶體驗(yàn)是極其重要的，那么通過哪些技術(shù)和方法能夠優(yōu)化用戶體驗(yàn)?zāi)?#xff1f;我們發(fā)現(xiàn)優(yōu)化流媒體服務(wù)質(zhì)量的方法是非常有效的一種手段。

二、流媒體服務(wù)質(zhì)量和用戶體驗(yàn)

QoS

這一節(jié)主要介紹Hulu對(duì)流媒體服務(wù)質(zhì)量的認(rèn)知，它和用戶體驗(yàn)之間有著怎樣的聯(lián)系。流媒體服務(wù)質(zhì)量常被稱為QoS(Quality of Service)，在傳輸領(lǐng)域，這其實(shí)是一個(gè)老詞。對(duì)于流媒體服務(wù)來講，QoS到底意味著什么？在我們的理解中，QoS其實(shí)是衡量音視頻播放質(zhì)量的一系列客觀指標(biāo)，可以劃分為三個(gè)重要維度：

第一個(gè)重要維度是連續(xù)性，也就是用戶在播放音視頻時(shí)的連貫性。其中最常見的指標(biāo)就是Rebuffer（卡頓），Failure rate（播放的失敗率）。顯而易見，這些事件的發(fā)生意味著播放更加的不連續(xù)。此外，還有Frame drop（掉幀）等指標(biāo)。

第二個(gè)重要維度是響應(yīng)速度，這個(gè)維度表征了用戶在進(jìn)行交互行為時(shí)，我們的Player以及整個(gè)應(yīng)用對(duì)于用戶的交互行為能否有及時(shí)的反饋，常見的一些指標(biāo)包括Loading time（加載速度），Seek（視頻跳轉(zhuǎn)時(shí)）帶來的延遲，以及廣告和內(nèi)容切換時(shí)的延遲等。

最后一個(gè)重要維度就是畫面質(zhì)量，常用的指標(biāo)有碼率，分辨率。一般來講，在同樣的Encoding參數(shù)下，我們認(rèn)為碼率越高，分辨率越高，用戶看到的畫面質(zhì)量也更高。

QoE

與QoS相對(duì)應(yīng)的是概念是QoE（Quality of Experience）。QoE與QoS的不同之處在于QoE是一系列衡量用戶對(duì)流媒體服務(wù)滿意程度的一種主觀的體現(xiàn)，雖然QoE也是由客觀指標(biāo)構(gòu)成，但實(shí)際上是用戶主觀滿意度的一種衡量。QoE的常見指標(biāo)包括了觀看時(shí)長(zhǎng)、觀看視頻數(shù)量、觀看完成度、用戶的退訂率等。通過比較，可以發(fā)現(xiàn)QoE與Business KPI更加的貼近，是我們最終想要優(yōu)化的目標(biāo)。但是由于QoE衡量用戶的主觀感受，因此會(huì)受到很多非技術(shù)因素的干擾。如果直接把QoE指標(biāo)運(yùn)用到實(shí)踐中進(jìn)行優(yōu)化，效率比較低，容易出現(xiàn)一些問題。Hulu內(nèi)部也曾對(duì)QoE的優(yōu)化進(jìn)行過一些嘗試，比如想要優(yōu)化視頻的觀看完成度，并在技術(shù)上做了很多魔改的東西。但是上線AB測(cè)試后，發(fā)現(xiàn)僅僅是略微有所變化，和周末上了一個(gè)新劇帶來的抖動(dòng)相比，基本可以忽略。這樣的一些問題就會(huì)使得相關(guān)的技術(shù)優(yōu)化變得難以實(shí)現(xiàn)。另一方面來看，QoS指標(biāo)要好很多，因?yàn)镼oS指標(biāo)客觀的反映了我們的服務(wù)質(zhì)量，如優(yōu)化Rebuffer的比例，從5%降到3%，相對(duì)來說這是比較客觀、穩(wěn)定且容易實(shí)現(xiàn)的一些指標(biāo)。從這些問題中，我們可以發(fā)現(xiàn)：QoE是我們希望優(yōu)化的目標(biāo)，QoS是比較可行的手段。那么能否把QoS和QoE連接起來，通過優(yōu)化QoS來實(shí)現(xiàn)優(yōu)化QoE？如果這個(gè)方式可行，就可以把工作重心放在對(duì)QoS的優(yōu)化上。

流媒體服務(wù)與用戶體驗(yàn)

幸運(yùn)的是，這個(gè)問題的答案非常樂觀的，學(xué)界的研究和業(yè)界的實(shí)踐充分證實(shí)了流媒體的服務(wù)質(zhì)量是可以顯著影響用戶體驗(yàn)的。

上圖簡(jiǎn)單羅列了幾個(gè)數(shù)據(jù)

（1）在播放卡頓或是加載時(shí)間太長(zhǎng)的時(shí)候，66%的用戶會(huì)直接退出當(dāng)前的播放。

（2）17%的用戶會(huì)因?yàn)榉?wù)質(zhì)量的問題退訂流媒體服務(wù)。

（3）嚴(yán)重卡頓會(huì)使用戶的滿意程度從接近滿分跌到幾乎為0。

這些研究和以及Hulu的技術(shù)實(shí)踐都充分論證了流媒體的服務(wù)質(zhì)量QoS能顯著的影響QoE，因此可以通過優(yōu)化QoS去達(dá)到優(yōu)化QoE的目的。

這張圖是美國(guó)一家相關(guān)公司對(duì)美國(guó)市場(chǎng)上流媒體服務(wù)的退訂原因進(jìn)行的調(diào)差問卷數(shù)據(jù)統(tǒng)計(jì)。我們能夠看到Technically Problems（即與OoS相關(guān)的因素），占到了17%的比重。值得一提的是， 服務(wù)太貴，視頻內(nèi)容不夠豐富， 廣告太多這三個(gè)指標(biāo)，雖然是比Technical Problem更為重要，但是這些指標(biāo)是相對(duì)難以優(yōu)化的。如果減少?gòu)V告投放，那么營(yíng)收必然會(huì)下降。如果購(gòu)買更多的內(nèi)容，肯定會(huì)帶來更多的支出。相比于QoS來講，在這些維度上想要做出優(yōu)化所付出的代價(jià)會(huì)更大，并且不能單純的通過技術(shù)途徑來有效的解決。從這里我們能夠看出：QoS優(yōu)化是有效率的，也是相對(duì)經(jīng)濟(jì)的一種方法。

三、流媒體服務(wù)質(zhì)量?jī)?yōu)化

前面主要介紹了為什么QoS優(yōu)化能做，有必要去做 , 接下來從三個(gè)方面介紹如何進(jìn)行QoS優(yōu)化。

首先介紹如何根據(jù)碼率自適應(yīng)的算法進(jìn)行流媒體服務(wù)質(zhì)量的優(yōu)化，然后根據(jù)Hulu的技術(shù)實(shí)踐，介紹在流媒體服務(wù)質(zhì)量?jī)?yōu)化中遇到的一些挑戰(zhàn)，以及我們自己設(shè)計(jì)的QoS優(yōu)化的一套體系。

碼率自適應(yīng)算法

碼率自適應(yīng)算法在國(guó)際上的應(yīng)用已經(jīng)比較廣泛了，不過出于各種各樣的原因，在國(guó)內(nèi)的應(yīng)用的還不是很廣泛，所以我就在這里多贅述幾句，介紹它的一些原理，希望能讓大家更好地認(rèn)識(shí)這項(xiàng)技術(shù)，也希望大家能更多地去運(yùn)用這一項(xiàng)技術(shù)。

碼率自適應(yīng)算法是隨著自適應(yīng)視頻傳輸這類協(xié)議的興起而出現(xiàn)的，我們常把它稱為ABR(Adaptive BitRate Streaming)或者M(jìn)BR(Multiple BitRate Streaming)。這類算法的基本思路是在客戶端根據(jù)用戶的網(wǎng)絡(luò)情況實(shí)時(shí)對(duì)用戶當(dāng)前播放的碼率進(jìn)行切換，這一點(diǎn)跟自適應(yīng)視頻傳輸協(xié)議是分不開的。在常見的自適應(yīng)視頻傳輸協(xié)議下，如HLS和Dash，音視頻都被切成了時(shí)域上較短的一個(gè)個(gè)片段，可能是2秒或是5秒，這樣的一種切分使得在客戶端靈活地對(duì)當(dāng)前的碼率進(jìn)行切換，變得可能和高效，也就可以做到在Player端無縫地對(duì)碼率進(jìn)行切換，這樣的自適應(yīng)視頻傳輸協(xié)議使得碼率自適應(yīng)算法變得可行而且有效率。Hulu既使用了HLS（因?yàn)樗翘O果支持的一套協(xié)議），同時(shí)也使用了Dash，實(shí)際上在全球整個(gè)業(yè)界范圍內(nèi)，Hulu可以說是最早大規(guī)模使用標(biāo)準(zhǔn)的Dash的協(xié)議來做流媒體服務(wù)的公司之一，因此也在這一領(lǐng)域積攢了大量經(jīng)驗(yàn)。

下面介紹一下為什么碼率自適應(yīng)算法是有必要的，假設(shè)說我們的用戶的帶寬分布如圖所示（單峰樣式）。

那么如果需要定一個(gè)固定碼率給用戶進(jìn)行Streaming，該怎么定呢？不論怎么定，其實(shí)都不會(huì)優(yōu)。現(xiàn)在圖上畫的已經(jīng)還算OK了，我的第一思路是在用戶最多的這個(gè)點(diǎn)確定固定碼率，但是會(huì)立刻遇到問題，有一半的用戶好像都有卡頓的風(fēng)險(xiǎn)，那怎么辦？保守一點(diǎn)，把固定碼率往低調(diào)一點(diǎn)，就長(zhǎng)成現(xiàn)在這個(gè)樣子，變成在平均值稍微低一點(diǎn)的地方切一刀。但是我們可以看到，這仍會(huì)使一些用戶存在卡頓的風(fēng)險(xiǎn)，并且另外一部分用戶的帶寬也沒有被充分地利用，其實(shí)它的碼率是可以更高的。所以說固定碼率不能夠達(dá)到最優(yōu)化用戶體驗(yàn)的一個(gè)目的，碼率自適應(yīng)的算法是必要的。其實(shí)我們仔細(xì)看這張圖，思考一下，會(huì)發(fā)現(xiàn)這張圖將問題簡(jiǎn)化了許多。首先，用戶的帶寬分布并不容易得到，得到了也可能不是單峰的，也可能是多峰的，這就使固定碼率的選擇更加艱難。另一方面，用戶的帶寬會(huì)隨時(shí)域變化，每年的不同時(shí)候：過節(jié)和不過節(jié)會(huì)不一樣、很多Show上映的時(shí)候和沒有Show上映的時(shí)候會(huì)不一樣、每天的不同時(shí)段會(huì)不一樣、白天的工作時(shí)間和晚上的Peak hour（高峰時(shí)間）肯定是不一樣的。在每一個(gè)用戶播放的同一個(gè)Session中時(shí)帶寬也會(huì)變化，因?yàn)榫W(wǎng)絡(luò)的情況是非常復(fù)雜的，可能不知道在什么地方就突然發(fā)生了一種競(jìng)爭(zhēng)或者擁塞。所以說這樣的一種時(shí)域上的抖動(dòng)，更是固定碼率的方法不能夠很好地去解決的，也就說明了碼率自適應(yīng)算法的必要性。常見的碼率自適應(yīng)算法有基于帶寬估計(jì)的方法，基于緩沖大小的方法和混合類的算法。

基于帶寬估計(jì)的碼率自適應(yīng)算法

基于帶寬估計(jì)的碼率自適應(yīng)算法比較直觀，通過實(shí)時(shí)估計(jì)用戶當(dāng)前可用帶寬大小，根據(jù)帶寬選取一個(gè)比較合適的碼率。如圖，黑色實(shí)線是用戶的帶寬，我們假設(shè)固定帶寬是1000kbps，在兩個(gè)陰影的區(qū)域，用戶就會(huì)遇到卡頓，因?yàn)樗?dāng)時(shí)的帶寬低于Streaming的碼率。基于帶寬估計(jì)的碼率自適應(yīng)調(diào)解算法會(huì)靈活的估計(jì)，估計(jì)當(dāng)前的帶寬的位置相應(yīng)地進(jìn)行選擇。

如上圖所示，它會(huì)從1000kbps切到500kbps切到1500kbps，通過這樣一種靈活的切換，我們就能夠使得一方面充分利用帶寬。另一方面，減少可能出現(xiàn)的卡頓。基于帶寬估計(jì)的碼率自適應(yīng)算法的優(yōu)勢(shì)是邏輯比較簡(jiǎn)單，帶寬估計(jì)加上一個(gè)比較就可以實(shí)現(xiàn)，參數(shù)也比較少，可以輕松的調(diào)節(jié)算法激進(jìn)或者保守一些。

基于帶寬估計(jì)的碼率自適應(yīng)算法的主要挑戰(zhàn)是帶寬的準(zhǔn)確實(shí)時(shí)估計(jì)實(shí)際上是有困難的，一方面由于客戶端沒有對(duì)網(wǎng)絡(luò)全局的一種認(rèn)識(shí)，它得到的只是一些片面，不太準(zhǔn)確的數(shù)據(jù)。另一方面，在客戶端進(jìn)行選擇時(shí)，資源和性能實(shí)際上是有些Constrain（限制）的，并不能說用一些Fancy（奇特）的機(jī)器學(xué)習(xí)方法在Client（客戶端）上進(jìn)行這樣的估計(jì)。

基于帶寬的碼率自適應(yīng)算法

帶寬估計(jì)不好做，怎么辦呢？在學(xué)界和工業(yè)界，有人提出了基于緩沖大小的一類方法。這類方法很有意思，直接把帶寬估計(jì)完全拋棄，核心思路就是Buffer的大小恒定在一定的范圍內(nèi)，每當(dāng)Buffer低于一定閾值的時(shí)候，就選擇一個(gè)更低的碼率進(jìn)行Streaming，Buffer很快就會(huì)慢慢的填充回來，重新回到合理的設(shè)定范圍之內(nèi)，當(dāng)Buffer太大的時(shí)候也是同樣。這類方法的好處是規(guī)避了帶寬估計(jì)這個(gè)相對(duì)麻煩的問題，另一個(gè)優(yōu)勢(shì)是可以比較穩(wěn)定地充分利用帶寬資源。這是因?yàn)樵趲捁烙?jì)時(shí)，一般我們都會(huì)留一些余量。假設(shè)估計(jì)的是1.5Mbps的帶寬網(wǎng)速，但我只會(huì)給它Streaming 1.2Mbps的一個(gè)流，這樣就比較保險(xiǎn)。由此帶來的問題就是說我的Buffer很可能會(huì)填充到最大值，這時(shí)就不能再繼續(xù)向服務(wù)器請(qǐng)求了。再請(qǐng)求的話，Buffer就會(huì)爆掉。基于緩沖大小的算法因?yàn)槭庆`活的調(diào)整，只要當(dāng)前帶寬不是特別高，都會(huì)保持在半滿的一種狀態(tài)，Buffer會(huì)不停的下載，與服務(wù)器之間的下載行為也是連續(xù)不斷的。因此基于緩沖大小的碼率自適應(yīng)方法能比較穩(wěn)定的充分利用帶寬資源。

基于緩沖大小的碼率自適應(yīng)算法也存在著一些問題，首先它的參數(shù)比較多，每一個(gè)比特率都要為其設(shè)定相應(yīng)的帶寬切換的閾值，這在工程實(shí)踐中是非常頭疼的。因?yàn)槊慨?dāng)碼率的設(shè)置由于種種原因發(fā)生一些變化，都需要進(jìn)行相應(yīng)的調(diào)整。而且如果Maximum Buffer Size比較小的話，這些閾值幾乎就變得沒法調(diào)節(jié)，甚至就會(huì)相互之間Overlap，根本不能用。另一個(gè)問題是這類算法會(huì)帶來比較多的碼率切換。假設(shè)當(dāng)前的帶寬是1.2Mbps，可用的碼率有兩個(gè)，一個(gè)是1Mbps，一個(gè)是1.5 Mbps。這類算法會(huì)使Streaming一直在1Mbps和1.5 Mbps之間進(jìn)行切換，直至基本用滿1.2Mbps的網(wǎng)絡(luò)。雖然整體上看，視頻畫面的質(zhì)量提高了，但帶來的切換是多次的。實(shí)際應(yīng)用中這種切換對(duì)于用戶是帶有負(fù)面效應(yīng)的，尤其是當(dāng)帶寬的Ladder ／ 檔次設(shè)置的比較粗，上下的兩節(jié)畫面適量的差別比較顯著的時(shí)候，會(huì)有很多次的切換。對(duì)于用戶來講，這種畫面質(zhì)量的增益是得不償失的。

混合算法

考慮到這兩種算法各有優(yōu)劣，現(xiàn)在大家會(huì)考慮混合類的算法，這類算法會(huì)綜合運(yùn)用帶寬估計(jì)和緩沖區(qū)大小的信息，明顯比上述的兩類算法的都要更優(yōu)一點(diǎn)。常見的一種方法是，當(dāng)Buffer Size比較大的時(shí)候，主要依賴基于帶寬估計(jì)的方法做決策，反之當(dāng)Buffer比較小的時(shí)候，就用Buffer Size的方法進(jìn)行調(diào)整，可以針對(duì)業(yè)務(wù)需求對(duì)各項(xiàng)權(quán)重進(jìn)行相應(yīng)的調(diào)整。

?

流媒體服務(wù)質(zhì)量?jī)?yōu)化的挑戰(zhàn)

接下來結(jié)合Hulu的技術(shù)實(shí)踐介紹我們?cè)趦?yōu)化時(shí)遇到的一些挑戰(zhàn)，雖然這些挑戰(zhàn)主要是我們從優(yōu)化ABR算法中總結(jié)出來的，但其實(shí)對(duì)于所有QoS類的優(yōu)化都適用，基本上是一些常見的痛點(diǎn)和通用的解決方法，這里遇到的挑戰(zhàn)主要在以下三個(gè)方面。一個(gè)是數(shù)據(jù)的規(guī)模特別大，每一個(gè)用戶在每一個(gè)播放Session中，都在產(chǎn)生QoS Data，怎么對(duì)這些數(shù)據(jù)進(jìn)行處理？怎么對(duì)數(shù)據(jù)進(jìn)行過濾？這實(shí)際上需要公司內(nèi)部有大數(shù)據(jù)相關(guān)的基礎(chǔ)架構(gòu)。第二個(gè)挑戰(zhàn)是線上的數(shù)據(jù)噪聲比較大，各種各樣的設(shè)備、各種各樣的網(wǎng)絡(luò)情況，各種各樣的軟件版本，比如說安卓各種各樣的型號(hào)和版本，這些都會(huì)使得QoS數(shù)據(jù)有很高的噪聲，導(dǎo)致真正想看到的趨勢(shì)和規(guī)律可能隱蔽在很重的噪聲下。所以如何屏蔽噪聲對(duì)算法研發(fā)造成的影響是一件頗具挑戰(zhàn)的事情。最后一個(gè)挑戰(zhàn)就是影響用戶的體驗(yàn)的維度較高，像我們剛才提到的，很多非技術(shù)因素都會(huì)導(dǎo)致用戶的體驗(yàn)發(fā)生變化。由于QoS的優(yōu)化最終還是為了優(yōu)化QoE，因此我們的實(shí)驗(yàn)和論證設(shè)計(jì)必須要仔細(xì)，否則我們想得到的增益就可能被一些隨機(jī)因素所埋沒。

流媒體服務(wù)質(zhì)量?jī)?yōu)化的實(shí)踐

針對(duì)于此，我們?cè)O(shè)計(jì)了一整套QoS優(yōu)化的系統(tǒng)，這套系統(tǒng)包括數(shù)據(jù)分析，線下實(shí)驗(yàn)和線上AB測(cè)試三個(gè)主要的模塊。

數(shù)據(jù)驅(qū)動(dòng)

數(shù)據(jù)驅(qū)動(dòng)是整個(gè)優(yōu)化工作的起點(diǎn)，它的目標(biāo)是通過分析線上實(shí)際的QoS數(shù)據(jù)，找到用戶在哪里的體驗(yàn)還不夠好，然后指明優(yōu)化工作的方向。比如我們想要優(yōu)化Rebuffer，可以看到哪些用戶的Rebuffer是最嚴(yán)重的、在哪些設(shè)備上我們應(yīng)優(yōu)先做出優(yōu)化、是不是在地域上面有某種形式的關(guān)系、他們使用的網(wǎng)絡(luò)條件、軟硬件的版本是否有什么特殊之處，諸如此類問題都是在數(shù)據(jù)驅(qū)動(dòng)里面需要去回答的問題。其實(shí)在工作的開始之初，對(duì)于數(shù)據(jù)驅(qū)動(dòng)我們并不太重視，也踩了很多的坑。開始時(shí)，我們的研究員或者開發(fā)人員的做法是直接殺到代碼里面去：“這塊邏輯是不是可以改的再優(yōu)一點(diǎn)，那塊能不能改的更優(yōu)一點(diǎn)，改完以后就直接進(jìn)行AB測(cè)試，看看有沒有性能，有性能的話就上線，沒性能的就不上線。”不過最后發(fā)現(xiàn)這樣其實(shí)是沒有效果的，雖然通過對(duì)代碼邏輯的分析，能夠找到對(duì)于某一些場(chǎng)景是能做出優(yōu)化的，但是由于沒有分析這些數(shù)據(jù)，我們不知道優(yōu)化的場(chǎng)景在實(shí)際用戶中占的比例到底有多大，到底是不是一個(gè)主要矛盾，或者說只是Design了一個(gè)不存在的問題的答案。這就使得我們整個(gè)優(yōu)化相對(duì)來講比較盲目，得到的結(jié)果是算法變的特別復(fù)雜，相關(guān)邏輯是以前2倍甚至是3倍，而增益卻非常的小。我們采用的解決方案就是通過使用數(shù)據(jù)驅(qū)動(dòng)的方法，在優(yōu)化的初期甚至是優(yōu)化開始前，就能夠知道優(yōu)化這樣子一個(gè)Scenario，它是我們現(xiàn)在問題的主要矛盾。對(duì)網(wǎng)絡(luò)的這種環(huán)境，這樣的一種Pattern進(jìn)行優(yōu)化是有意義的。我們能在工作開始之前就對(duì)想要得到的增益進(jìn)行估算，這就使得相關(guān)的工作可以做到有的放矢，具有邏輯性和計(jì)劃性.

在Hulu內(nèi)部，我們也做了很多工作。首先，剛才提到我們是跨越了所有的平臺(tái)，所以需要把所有平臺(tái)上的QoS Data全都整理清楚，讓它們的定義變得一致，讓它們的發(fā)送邏輯變得一樣，這樣才能在不同的設(shè)備之間進(jìn)行對(duì)比。這在Hulu的系統(tǒng)里面還是頗具挑戰(zhàn)的，因?yàn)槠脚_(tái)的數(shù)量確實(shí)很多。同時(shí)，我們還搭建了一整套的大數(shù)據(jù)的平臺(tái)，使得我們可以靈活的對(duì)數(shù)據(jù)進(jìn)行聚合，處理以及分析，借此搭建整個(gè)的數(shù)據(jù)驅(qū)動(dòng)的基礎(chǔ)。

線下論證

第二個(gè)重要組成模塊是線下論證，這個(gè)模塊的主要目的是實(shí)現(xiàn)算法的線下快速迭代。跟剛才提到的數(shù)據(jù)驅(qū)動(dòng)一樣，在直覺中，線下論證也是可以不存在的。最初的實(shí)踐中我們也確實(shí)沒有做這一步，后來卻發(fā)現(xiàn)線下論證必須要做，原因有兩個(gè)方面：一方面是線下論證的成本比線上論證低，主要是在時(shí)間上會(huì)節(jié)省很多。線上做一個(gè)AB測(cè)試至少要一周的時(shí)間才能夠看到有意義的結(jié)果，而線下的可以沒日沒夜的跑。并且線下論證成本低的另一個(gè)維度是不會(huì)對(duì)線上用戶造成任何影響，即使是比較Crazy的Idea，線下都可以測(cè)。如果是以前那種刀耕火種的年代，很多比較激進(jìn)的可能帶來負(fù)面效果的想法最終都會(huì)胎死腹中，并不能得到在線上實(shí)測(cè)的機(jī)會(huì)，原因就是害怕影響用戶的體驗(yàn)。另一方面，線下論證還能做一些線上實(shí)驗(yàn)做不到的事，主要在于可以控制變量、降低隨機(jī)干擾。在線下環(huán)境中，我們可以把不希望影響用戶體驗(yàn)的一些維度屏蔽掉，還可以對(duì)網(wǎng)絡(luò)環(huán)境進(jìn)行相應(yīng)的配置，這就使得整個(gè)對(duì)比比較單純，整個(gè)環(huán)境比較清爽。這樣的實(shí)驗(yàn)在線上我們是沒辦法實(shí)現(xiàn)的，因?yàn)榫€上影響的維度實(shí)在太多，有很多的維度我們甚至沒有真正有效的衡量手段。

為了做線下實(shí)驗(yàn)，我們搭建了一整套流媒體測(cè)試的離線平臺(tái)，主要分為三個(gè)重要組成部分。第一個(gè)重要組成部分是變量控制的實(shí)驗(yàn)環(huán)境，在這個(gè)實(shí)驗(yàn)環(huán)境里我們可以對(duì)不同的算法，如ABR算法或其它QoS改進(jìn)的算法，做一種可重復(fù)的實(shí)驗(yàn)。實(shí)驗(yàn)中的網(wǎng)絡(luò)環(huán)境是可以靈活控制的，可控制的參數(shù)包括像帶寬、丟包率、延遲等，且可以做到Session級(jí)別Bandwidth Trace的重現(xiàn)。例如我設(shè)計(jì)了一種帶寬變化的Pattern，它一開始是500kbps，5秒鐘之后掉到300kbps，過了3秒鐘又升到了1Mbps，類似于這樣的一種Pattern，我們可以把它直接Configure在我們的這個(gè)實(shí)驗(yàn)環(huán)境中，我們可以設(shè)置很多種的 Bandwith Trace，讓不同的算法在同樣的Bandwith Trace下進(jìn)行同一種實(shí)驗(yàn)，最終得到結(jié)果，所以說，這是為了更好的去模擬現(xiàn)實(shí)生活中的環(huán)境而進(jìn)行的工作。第二個(gè)重要組成部分是我們的產(chǎn)品代碼和真機(jī)的離線測(cè)試，在這套系統(tǒng)里面，我們使用的是線上真實(shí)的Player和Client端代碼，并且會(huì)使用真機(jī)做一些相關(guān)的測(cè)試，這就很大程度的規(guī)避了由于設(shè)備和試驗(yàn)中的一些問題對(duì)整個(gè)Performance造成的影響。因?yàn)槲覀冊(cè)趯?shí)踐中發(fā)現(xiàn)，有時(shí)并不一定是算法不對(duì)，但是在某個(gè)平臺(tái)上的模塊API的實(shí)現(xiàn)就是和別的平臺(tái)不一樣，就使得這個(gè)平臺(tái)上的一些效果打了折扣，甚至可能發(fā)生扭曲。我們這套環(huán)境使用了真機(jī)進(jìn)行測(cè)試，所以說它的保真度是很高的。最后一個(gè)重要組成部分是如圖所示的這個(gè)直觀的UI，在這個(gè)UI上把我們所有關(guān)心的指標(biāo)，如Buffer的狀態(tài)，當(dāng)前Player狀態(tài)機(jī)的一些狀態(tài)，還有當(dāng)前的帶寬，碼率，我們現(xiàn)在想要去Track 的各種各樣的延遲等，所有的信息都以可視化的方式展示在這里。我們所有的離線的Session都可以展現(xiàn)在這個(gè)平臺(tái)上，使得我們可以比較便捷的進(jìn)行調(diào)試。

線上實(shí)測(cè)

最后一個(gè)重要的組成模塊就是我們的線上實(shí)測(cè)部分。雖然我們前面做了很多數(shù)據(jù)分析和多線下的實(shí)驗(yàn)。但對(duì)于任何一個(gè)公司，線上實(shí)測(cè)這一步驟都是不應(yīng)缺失的。主要有幾個(gè)方面的原因，一方面，線上實(shí)測(cè)是驗(yàn)證性能最直接，最有效的方法，我們前面說的這些離線測(cè)試，數(shù)據(jù)分析，跟技術(shù)人員講起來，大家是Buy-in，說你這個(gè)看起來合理，應(yīng)該是有增益的。但對(duì)于一些非技術(shù)人員來講，只有在線上證明過，才是真正有增益的。另一方面只有通過線上的實(shí)測(cè)才能夠真正地獲取QoE的數(shù)據(jù)，線下實(shí)驗(yàn)說明這個(gè)算法能夠優(yōu)化Rebuffer，降低10%。但用戶是不是會(huì)因此看更多的內(nèi)容，只有通過線上實(shí)測(cè)，才能獲得相關(guān)的寶貴信息。最后一方面，線上實(shí)測(cè)實(shí)際上能夠帶來很多的數(shù)據(jù)，這些數(shù)據(jù)既能使我們的數(shù)據(jù)分析做得更好；也可以使得我們的線下實(shí)驗(yàn)更加的保真，比如說我們獲取了QoS和QoE的數(shù)據(jù)，就可以進(jìn)一步的推動(dòng)用戶數(shù)據(jù)分析中模型的建立。此外，如果線上實(shí)驗(yàn)和線下實(shí)驗(yàn)的結(jié)果在QoS上發(fā)現(xiàn)有些不同，就可以針對(duì)這種不同對(duì)我們的線下的實(shí)驗(yàn)進(jìn)一步的改進(jìn)。比如線下實(shí)驗(yàn)中可能有一些線上的Pattern沒考慮，那發(fā)現(xiàn)了這個(gè)不同之后，我們就可以把這種Pattern加回到線下實(shí)驗(yàn)中，使得接下來的實(shí)驗(yàn)更加準(zhǔn)確。這就是我們一整套的線下實(shí)驗(yàn)和線上實(shí)驗(yàn)以及數(shù)據(jù)分析優(yōu)化的系統(tǒng)。

優(yōu)化結(jié)果

最后簡(jiǎn)單說下結(jié)果，在Hulu內(nèi)部已經(jīng)用這套系統(tǒng)對(duì)核心的QoS指標(biāo)進(jìn)行了多輪的優(yōu)化。優(yōu)化的內(nèi)容包括了像碼率、Rebuffer、加載時(shí)間等Qos核心指標(biāo)，并且顯著提高了用戶的滿意度和相關(guān)黏性。比方說我們針對(duì)的QoE的指標(biāo)，包括了像觀看時(shí)長(zhǎng)，退訂率，觀看完成度等一類指標(biāo)都實(shí)現(xiàn)了大幅的優(yōu)化。用這樣一整套比較完善的系統(tǒng)來做優(yōu)化，我們某些平臺(tái)上的核心QoS指標(biāo)得到了大幅優(yōu)化，一些平臺(tái)上的Rebuffer甚至降低了50%以上。

LiveVideoStackCon 2018講師招募

LiveVideoStackCon 2018是音視頻技術(shù)領(lǐng)域的綜合技術(shù)大會(huì)，今年是在10月19-20日在北京舉行。大會(huì)共設(shè)立18個(gè)專題，預(yù)計(jì)邀請(qǐng)超過80位技術(shù)專家。如果你在某一領(lǐng)域獨(dú)當(dāng)一面，歡迎申請(qǐng)成為L(zhǎng)iveVideoStackCon 2018的講師，讓你的經(jīng)驗(yàn)幫到更多人，你可以通過speaker@livevideostack.com提交演講信息。了解大會(huì)更多詳情，點(diǎn)擊【閱讀原文】訪問LiveVideoStackCon 2018官網(wǎng)，報(bào)名即刻享受7折優(yōu)惠。

總結(jié)

以上是生活随笔為你收集整理的Hulu 视频QoS优化策略的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問題。

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