Hulu 视频QoS优化策略
QoS直接關系到用戶體驗，如何提升QoS就成為視頻平臺技術實力的體現。本文來自Hulu全球高級研發經理、視頻編解碼與傳輸領域資深專家傅徳良在LiveVideoStackCon 2017上的分享。盡管Hulu提供服務的網絡環境與國內大相徑庭，但其相關QoS保障策略依然值得借鑒。
文 / 傅徳良
整理 / LiveVideoStack
概述：
大家好，我是Hulu北京的傅徳良，主要負責音視頻編解碼和視頻傳輸相關優化的團隊。非常高興在這里給大家分享一些Hulu 在流媒體服務質量和用戶體驗優化方面的經驗。由于Hulu是一家美國公司，所以使用的技術路線跟國內常見的技術路線并不完全相同，從技術上講，不存在誰更先進或者優秀的說法。不過既然是不同的技術路線，那么Hulu也就可能會做一些國內廠商目前還沒有太多投入去做的一些事情。今天，主要跟大家分享一下Hulu在QoS優化中的思路、在實踐中遇到的問題以及解決方案。首先簡單介紹一下Hulu的視頻系統以及為什么要做QoS優化？其次會分享對QoS優化和用戶體驗之間關系的基本理解，最后結合Hulu的技術實踐介紹在客戶端通過自適應碼率調解的方法優化QoS的基本思路和原理，以及構建的一整套QoS優化框架。
一：Hulu視頻系統簡介
Hulu是一家由美國最大的幾家傳統媒體行業巨頭出資創建的在線視頻流媒體服務公司，其創建目標是把更多的優選內容與全美國用戶更好地連接在一起。Hulu的終端是跨越全平臺的，涵蓋網頁端、移動端還有電視端。跟國內業態有所不同的是，除了瀏覽器，Android和iOS外，在美國還需要支持很多在國內看來比較神奇的一些設備，例如以Roku，FireTV和AppleTV為代表的電視盒子和以PS（Sony PlayStation系列），XBox為代表的游戲主機。我們需要在所有的這些平臺上面都支持我們的Streaming服務，如大家所知，這些平臺相對來講都是比較異構的，并不像國內的設備，基本都是基于安卓平臺進行開發的。因此為了實現對北美市場上所有平臺的支持，給技術層面帶來了不小的挑戰，尤其是對于QoS調優和用戶體驗調優一致性上的挑戰更加艱巨。
Hulu提供的觀看內容是比較豐富的，包括當季的美劇、優選電影、自制劇、體育節目、兒童節目等。2017年，Hulu的直播業務上線，美國數百個Broadcast電視臺可以在Hulu的應用和網站上進行播放，而且沒有UGC（User Generated Content），都是從較大的渠道獲取的有版權的視頻內容。值得一提的是，在2017年的艾美獎評選中，Hulu的自制劇也大獲成功，共斬獲10項大獎，堪稱是本屆艾美獎評選的最大贏家，《使女的故事》（The Handmaids Tale）還獲得了Outstanding Drama Series（最佳劇集獎），這在全世界的在線流媒體行業中，都是一件具有里程碑意義的事情。可見，Hulu是有非常多優選內容的，那么如何把這些優選內容以最好的體驗呈現給用戶，也就成為了工作中的關鍵。
Hulu商業模式
值得一提的是，Hulu的商業模式也比較特別，采用注冊用戶+廣告的模式。Hulu是由幾家傳統媒體公司創建的，商業模式跟整個美國電視行業的模式相似，如果你想要觀看Hulu，首先需要付費，注冊成為我們的用戶。在此基礎上，可以選擇不同的，有廣告或無廣告的套餐。這種注冊用戶+廣告的模式使得Hulu在整個商業競爭中處在一個十分特殊的位置，也使得技術層面上需要做出相應的改變。在這種商業模式下，用戶的單位價值是比較高的，一方面，用戶繳納了注冊費。另一方面，用戶還觀看了廣告，這些廣告也帶來了很多收入。 在此基礎上，如何使更多的用戶觀看Hulu的視頻，觀看更多的視頻，對Hulu來講特別重要。當然，這個邏輯基本上對于所有的在線流媒體服務公司也都是成立的。由于內容都是花費大價值買來的，用戶的單位價值是較高的，因此Hulu有非常強烈的意愿把用戶體驗做得更好。更好的用戶體驗可以帶來更多的用戶，更大的視頻播放量，也就是更多的用戶訂閱數和更高的廣告營收。所以說，用戶體驗是極其重要的，那么通過哪些技術和方法能夠優化用戶體驗呢？我們發現優化流媒體服務質量的方法是非常有效的一種手段。
二、流媒體服務質量和用戶體驗
QoS
這一節主要介紹Hulu對流媒體服務質量的認知，它和用戶體驗之間有著怎樣的聯系。流媒體服務質量常被稱為QoS(Quality of Service)，在傳輸領域，這其實是一個老詞。對于流媒體服務來講，QoS到底意味著什么？在我們的理解中，QoS其實是衡量音視頻播放質量的一系列客觀指標，可以劃分為三個重要維度：
第一個重要維度是連續性，也就是用戶在播放音視頻時的連貫性。其中最常見的指標就是Rebuffer（卡頓），Failure rate（播放的失敗率）。顯而易見，這些事件的發生意味著播放更加的不連續。此外，還有Frame drop（掉幀）等指標。
第二個重要維度是響應速度，這個維度表征了用戶在進行交互行為時，我們的Player以及整個應用對于用戶的交互行為能否有及時的反饋，常見的一些指標包括Loading time（加載速度），Seek（視頻跳轉時）帶來的延遲，以及廣告和內容切換時的延遲等。
最后一個重要維度就是畫面質量，常用的指標有碼率，分辨率。一般來講，在同樣的Encoding參數下，我們認為碼率越高，分辨率越高，用戶看到的畫面質量也更高。
QoE
與QoS相對應的是概念是QoE（Quality of Experience）。QoE與QoS的不同之處在于QoE是一系列衡量用戶對流媒體服務滿意程度的一種主觀的體現，雖然QoE也是由客觀指標構成，但實際上是用戶主觀滿意度的一種衡量。QoE的常見指標包括了觀看時長、觀看視頻數量、觀看完成度、用戶的退訂率等。通過比較，可以發現QoE與Business KPI更加的貼近，是我們最終想要優化的目標。但是由于QoE衡量用戶的主觀感受，因此會受到很多非技術因素的干擾。如果直接把QoE指標運用到實踐中進行優化，效率比較低，容易出現一些問題。Hulu內部也曾對QoE的優化進行過一些嘗試，比如想要優化視頻的觀看完成度，并在技術上做了很多魔改的東西。但是上線AB測試后，發現僅僅是略微有所變化，和周末上了一個新劇帶來的抖動相比，基本可以忽略。這樣的一些問題就會使得相關的技術優化變得難以實現。另一方面來看，QoS指標要好很多，因為QoS指標客觀的反映了我們的服務質量，如優化Rebuffer的比例，從5%降到3%，相對來說這是比較客觀、穩定且容易實現的一些指標。從這些問題中，我們可以發現：QoE是我們希望優化的目標，QoS是比較可行的手段。那么能否把QoS和QoE連接起來，通過優化QoS來實現優化QoE？如果這個方式可行，就可以把工作重心放在對QoS的優化上。
流媒體服務與用戶體驗
幸運的是，這個問題的答案非常樂觀的，學界的研究和業界的實踐充分證實了流媒體的服務質量是可以顯著影響用戶體驗的。
上圖簡單羅列了幾個數據
（1）在播放卡頓或是加載時間太長的時候，66%的用戶會直接退出當前的播放。
（2）17%的用戶會因為服務質量的問題退訂流媒體服務。
（3）嚴重卡頓會使用戶的滿意程度從接近滿分跌到幾乎為0。
這些研究和以及Hulu的技術實踐都充分論證了流媒體的服務質量QoS能顯著的影響QoE，因此可以通過優化QoS去達到優化QoE的目的。
這張圖是美國一家相關公司對美國市場上流媒體服務的退訂原因進行的調差問卷數據統計。我們能夠看到Technically Problems（即與OoS相關的因素），占到了17%的比重。值得一提的是， 服務太貴，視頻內容不夠豐富， 廣告太多這三個指標，雖然是比Technical Problem更為重要，但是這些指標是相對難以優化的。如果減少廣告投放，那么營收必然會下降。如果購買更多的內容，肯定會帶來更多的支出。相比于QoS來講，在這些維度上想要做出優化所付出的代價會更大，并且不能單純的通過技術途徑來有效的解決。從這里我們能夠看出：QoS優化是有效率的，也是相對經濟的一種方法。
三、流媒體服務質量優化
前面主要介紹了為什么QoS優化能做，有必要去做 , 接下來從三個方面介紹如何進行QoS優化。
首先介紹如何根據碼率自適應的算法進行流媒體服務質量的優化，然后根據Hulu的技術實踐，介紹在流媒體服務質量優化中遇到的一些挑戰，以及我們自己設計的QoS優化的一套體系。
碼率自適應算法
碼率自適應算法在國際上的應用已經比較廣泛了，不過出于各種各樣的原因，在國內的應用的還不是很廣泛，所以我就在這里多贅述幾句，介紹它的一些原理，希望能讓大家更好地認識這項技術，也希望大家能更多地去運用這一項技術。
碼率自適應算法是隨著自適應視頻傳輸這類協議的興起而出現的，我們常把它稱為ABR(Adaptive BitRate Streaming)或者MBR(Multiple BitRate Streaming)。這類算法的基本思路是在客戶端根據用戶的網絡情況實時對用戶當前播放的碼率進行切換，這一點跟自適應視頻傳輸協議是分不開的。在常見的自適應視頻傳輸協議下，如HLS和Dash，音視頻都被切成了時域上較短的一個個片段，可能是2秒或是5秒，這樣的一種切分使得在客戶端靈活地對當前的碼率進行切換，變得可能和高效，也就可以做到在Player端無縫地對碼率進行切換，這樣的自適應視頻傳輸協議使得碼率自適應算法變得可行而且有效率。Hulu既使用了HLS（因為它是蘋果支持的一套協議），同時也使用了Dash，實際上在全球整個業界范圍內，Hulu可以說是最早大規模使用標準的Dash的協議來做流媒體服務的公司之一，因此也在這一領域積攢了大量經驗。
下面介紹一下為什么碼率自適應算法是有必要的，假設說我們的用戶的帶寬分布如圖所示（單峰樣式）。
那么如果需要定一個固定碼率給用戶進行Streaming，該怎么定呢？不論怎么定，其實都不會優。現在圖上畫的已經還算OK了，我的第一思路是在用戶最多的這個點確定固定碼率，但是會立刻遇到問題，有一半的用戶好像都有卡頓的風險，那怎么辦？保守一點，把固定碼率往低調一點，就長成現在這個樣子，變成在平均值稍微低一點的地方切一刀。但是我們可以看到，這仍會使一些用戶存在卡頓的風險，并且另外一部分用戶的帶寬也沒有被充分地利用，其實它的碼率是可以更高的。所以說固定碼率不能夠達到最優化用戶體驗的一個目的，碼率自適應的算法是必要的。其實我們仔細看這張圖，思考一下，會發現這張圖將問題簡化了許多。首先，用戶的帶寬分布并不容易得到，得到了也可能不是單峰的，也可能是多峰的，這就使固定碼率的選擇更加艱難。另一方面，用戶的帶寬會隨時域變化，每年的不同時候：過節和不過節會不一樣、很多Show上映的時候和沒有Show上映的時候會不一樣、每天的不同時段會不一樣、白天的工作時間和晚上的Peak hour（高峰時間）肯定是不一樣的。在每一個用戶播放的同一個Session中時帶寬也會變化，因為網絡的情況是非常復雜的，可能不知道在什么地方就突然發生了一種競爭或者擁塞。所以說這樣的一種時域上的抖動，更是固定碼率的方法不能夠很好地去解決的，也就說明了碼率自適應算法的必要性。常見的碼率自適應算法有基于帶寬估計的方法，基于緩沖大小的方法和混合類的算法。
基于帶寬估計的碼率自適應算法
基于帶寬估計的碼率自適應算法比較直觀，通過實時估計用戶當前可用帶寬大小，根據帶寬選取一個比較合適的碼率。如圖，黑色實線是用戶的帶寬，我們假設固定帶寬是1000kbps，在兩個陰影的區域，用戶就會遇到卡頓，因為它當時的帶寬低于Streaming的碼率。基于帶寬估計的碼率自適應調解算法會靈活的估計，估計當前的帶寬的位置相應地進行選擇。
如上圖所示，它會從1000kbps切到500kbps切到1500kbps，通過這樣一種靈活的切換，我們就能夠使得一方面充分利用帶寬。另一方面，減少可能出現的卡頓。基于帶寬估計的碼率自適應算法的優勢是邏輯比較簡單，帶寬估計加上一個比較就可以實現，參數也比較少，可以輕松的調節算法激進或者保守一些。
基于帶寬估計的碼率自適應算法的主要挑戰是帶寬的準確實時估計實際上是有困難的，一方面由于客戶端沒有對網絡全局的一種認識，它得到的只是一些片面，不太準確的數據。另一方面，在客戶端進行選擇時，資源和性能實際上是有些Constrain（限制）的，并不能說用一些Fancy（奇特）的機器學習方法在Client（客戶端）上進行這樣的估計。
基于帶寬的碼率自適應算法
帶寬估計不好做，怎么辦呢？在學界和工業界，有人提出了基于緩沖大小的一類方法。這類方法很有意思，直接把帶寬估計完全拋棄，核心思路就是Buffer的大小恒定在一定的范圍內，每當Buffer低于一定閾值的時候，就選擇一個更低的碼率進行Streaming，Buffer很快就會慢慢的填充回來，重新回到合理的設定范圍之內，當Buffer太大的時候也是同樣。這類方法的好處是規避了帶寬估計這個相對麻煩的問題，另一個優勢是可以比較穩定地充分利用帶寬資源。這是因為在帶寬估計時，一般我們都會留一些余量。假設估計的是1.5Mbps的帶寬網速，但我只會給它Streaming 1.2Mbps的一個流，這樣就比較保險。由此帶來的問題就是說我的Buffer很可能會填充到最大值，這時就不能再繼續向服務器請求了。再請求的話，Buffer就會爆掉。基于緩沖大小的算法因為是靈活的調整，只要當前帶寬不是特別高，都會保持在半滿的一種狀態，Buffer會不停的下載，與服務器之間的下載行為也是連續不斷的。因此基于緩沖大小的碼率自適應方法能比較穩定的充分利用帶寬資源。
基于緩沖大小的碼率自適應算法也存在著一些問題，首先它的參數比較多，每一個比特率都要為其設定相應的帶寬切換的閾值，這在工程實踐中是非常頭疼的。因為每當碼率的設置由于種種原因發生一些變化，都需要進行相應的調整。而且如果Maximum Buffer Size比較小的話，這些閾值幾乎就變得沒法調節，甚至就會相互之間Overlap，根本不能用。另一個問題是這類算法會帶來比較多的碼率切換。假設當前的帶寬是1.2Mbps，可用的碼率有兩個，一個是1Mbps，一個是1.5 Mbps。這類算法會使Streaming一直在1Mbps和1.5 Mbps之間進行切換，直至基本用滿1.2Mbps的網絡。雖然整體上看，視頻畫面的質量提高了，但帶來的切換是多次的。實際應用中這種切換對于用戶是帶有負面效應的，尤其是當帶寬的Ladder ／ 檔次設置的比較粗，上下的兩節畫面適量的差別比較顯著的時候，會有很多次的切換。對于用戶來講，這種畫面質量的增益是得不償失的。
混合算法
考慮到這兩種算法各有優劣，現在大家會考慮混合類的算法，這類算法會綜合運用帶寬估計和緩沖區大小的信息，明顯比上述的兩類算法的都要更優一點。常見的一種方法是，當Buffer Size比較大的時候，主要依賴基于帶寬估計的方法做決策，反之當Buffer比較小的時候，就用Buffer Size的方法進行調整，可以針對業務需求對各項權重進行相應的調整。
?
流媒體服務質量優化的挑戰
接下來結合Hulu的技術實踐介紹我們在優化時遇到的一些挑戰，雖然這些挑戰主要是我們從優化ABR算法中總結出來的，但其實對于所有QoS類的優化都適用，基本上是一些常見的痛點和通用的解決方法，這里遇到的挑戰主要在以下三個方面。一個是數據的規模特別大，每一個用戶在每一個播放Session中，都在產生QoS Data，怎么對這些數據進行處理？怎么對數據進行過濾？這實際上需要公司內部有大數據相關的基礎架構。第二個挑戰是線上的數據噪聲比較大，各種各樣的設備、各種各樣的網絡情況，各種各樣的軟件版本，比如說安卓各種各樣的型號和版本，這些都會使得QoS數據有很高的噪聲，導致真正想看到的趨勢和規律可能隱蔽在很重的噪聲下。所以如何屏蔽噪聲對算法研發造成的影響是一件頗具挑戰的事情。最后一個挑戰就是影響用戶的體驗的維度較高，像我們剛才提到的，很多非技術因素都會導致用戶的體驗發生變化。由于QoS的優化最終還是為了優化QoE，因此我們的實驗和論證設計必須要仔細，否則我們想得到的增益就可能被一些隨機因素所埋沒。
流媒體服務質量優化的實踐
針對于此，我們設計了一整套QoS優化的系統，這套系統包括數據分析，線下實驗和線上AB測試三個主要的模塊。
數據驅動
數據驅動是整個優化工作的起點，它的目標是通過分析線上實際的QoS數據，找到用戶在哪里的體驗還不夠好，然后指明優化工作的方向。比如我們想要優化Rebuffer，可以看到哪些用戶的Rebuffer是最嚴重的、在哪些設備上我們應優先做出優化、是不是在地域上面有某種形式的關系、他們使用的網絡條件、軟硬件的版本是否有什么特殊之處，諸如此類問題都是在數據驅動里面需要去回答的問題。其實在工作的開始之初，對于數據驅動我們并不太重視，也踩了很多的坑。開始時，我們的研究員或者開發人員的做法是直接殺到代碼里面去：“這塊邏輯是不是可以改的再優一點，那塊能不能改的更優一點，改完以后就直接進行AB測試，看看有沒有性能，有性能的話就上線，沒性能的就不上線。”不過最后發現這樣其實是沒有效果的，雖然通過對代碼邏輯的分析，能夠找到對于某一些場景是能做出優化的，但是由于沒有分析這些數據，我們不知道優化的場景在實際用戶中占的比例到底有多大，到底是不是一個主要矛盾，或者說只是Design了一個不存在的問題的答案。這就使得我們整個優化相對來講比較盲目，得到的結果是算法變的特別復雜，相關邏輯是以前2倍甚至是3倍，而增益卻非常的小。我們采用的解決方案就是通過使用數據驅動的方法，在優化的初期甚至是優化開始前，就能夠知道優化這樣子一個Scenario，它是我們現在問題的主要矛盾。對網絡的這種環境，這樣的一種Pattern進行優化是有意義的。我們能在工作開始之前就對想要得到的增益進行估算，這就使得相關的工作可以做到有的放矢，具有邏輯性和計劃性.
在Hulu內部，我們也做了很多工作。首先，剛才提到我們是跨越了所有的平臺，所以需要把所有平臺上的QoS Data全都整理清楚，讓它們的定義變得一致，讓它們的發送邏輯變得一樣，這樣才能在不同的設備之間進行對比。這在Hulu的系統里面還是頗具挑戰的，因為平臺的數量確實很多。同時，我們還搭建了一整套的大數據的平臺，使得我們可以靈活的對數據進行聚合，處理以及分析，借此搭建整個的數據驅動的基礎。
線下論證
第二個重要組成模塊是線下論證，這個模塊的主要目的是實現算法的線下快速迭代。跟剛才提到的數據驅動一樣，在直覺中，線下論證也是可以不存在的。最初的實踐中我們也確實沒有做這一步，后來卻發現線下論證必須要做，原因有兩個方面：一方面是線下論證的成本比線上論證低，主要是在時間上會節省很多。線上做一個AB測試至少要一周的時間才能夠看到有意義的結果，而線下的可以沒日沒夜的跑。并且線下論證成本低的另一個維度是不會對線上用戶造成任何影響，即使是比較Crazy的Idea，線下都可以測。如果是以前那種刀耕火種的年代，很多比較激進的可能帶來負面效果的想法最終都會胎死腹中，并不能得到在線上實測的機會，原因就是害怕影響用戶的體驗。另一方面，線下論證還能做一些線上實驗做不到的事，主要在于可以控制變量、降低隨機干擾。在線下環境中，我們可以把不希望影響用戶體驗的一些維度屏蔽掉，還可以對網絡環境進行相應的配置，這就使得整個對比比較單純，整個環境比較清爽。這樣的實驗在線上我們是沒辦法實現的，因為線上影響的維度實在太多，有很多的維度我們甚至沒有真正有效的衡量手段。
為了做線下實驗，我們搭建了一整套流媒體測試的離線平臺，主要分為三個重要組成部分。第一個重要組成部分是變量控制的實驗環境，在這個實驗環境里我們可以對不同的算法，如ABR算法或其它QoS改進的算法，做一種可重復的實驗。實驗中的網絡環境是可以靈活控制的，可控制的參數包括像帶寬、丟包率、延遲等，且可以做到Session級別Bandwidth Trace的重現。例如我設計了一種帶寬變化的Pattern，它一開始是500kbps，5秒鐘之后掉到300kbps，過了3秒鐘又升到了1Mbps，類似于這樣的一種Pattern，我們可以把它直接Configure在我們的這個實驗環境中，我們可以設置很多種的 Bandwith Trace，讓不同的算法在同樣的Bandwith Trace下進行同一種實驗，最終得到結果，所以說，這是為了更好的去模擬現實生活中的環境而進行的工作。第二個重要組成部分是我們的產品代碼和真機的離線測試，在這套系統里面，我們使用的是線上真實的Player和Client端代碼，并且會使用真機做一些相關的測試，這就很大程度的規避了由于設備和試驗中的一些問題對整個Performance造成的影響。因為我們在實踐中發現，有時并不一定是算法不對，但是在某個平臺上的模塊API的實現就是和別的平臺不一樣，就使得這個平臺上的一些效果打了折扣，甚至可能發生扭曲。我們這套環境使用了真機進行測試，所以說它的保真度是很高的。最后一個重要組成部分是如圖所示的這個直觀的UI，在這個UI上把我們所有關心的指標，如Buffer的狀態，當前Player狀態機的一些狀態，還有當前的帶寬，碼率，我們現在想要去Track 的各種各樣的延遲等，所有的信息都以可視化的方式展示在這里。我們所有的離線的Session都可以展現在這個平臺上，使得我們可以比較便捷的進行調試。
線上實測
最后一個重要的組成模塊就是我們的線上實測部分。雖然我們前面做了很多數據分析和多線下的實驗。但對于任何一個公司，線上實測這一步驟都是不應缺失的。主要有幾個方面的原因，一方面，線上實測是驗證性能最直接，最有效的方法，我們前面說的這些離線測試，數據分析，跟技術人員講起來，大家是Buy-in，說你這個看起來合理，應該是有增益的。但對于一些非技術人員來講，只有在線上證明過，才是真正有增益的。另一方面只有通過線上的實測才能夠真正地獲取QoE的數據，線下實驗說明這個算法能夠優化Rebuffer，降低10%。但用戶是不是會因此看更多的內容，只有通過線上實測，才能獲得相關的寶貴信息。最后一方面，線上實測實際上能夠帶來很多的數據，這些數據既能使我們的數據分析做得更好；也可以使得我們的線下實驗更加的保真，比如說我們獲取了QoS和QoE的數據，就可以進一步的推動用戶數據分析中模型的建立。此外，如果線上實驗和線下實驗的結果在QoS上發現有些不同，就可以針對這種不同對我們的線下的實驗進一步的改進。比如線下實驗中可能有一些線上的Pattern沒考慮，那發現了這個不同之后，我們就可以把這種Pattern加回到線下實驗中，使得接下來的實驗更加準確。這就是我們一整套的線下實驗和線上實驗以及數據分析優化的系統。
優化結果
最后簡單說下結果，在Hulu內部已經用這套系統對核心的QoS指標進行了多輪的優化。優化的內容包括了像碼率、Rebuffer、加載時間等Qos核心指標，并且顯著提高了用戶的滿意度和相關黏性。比方說我們針對的QoE的指標，包括了像觀看時長，退訂率，觀看完成度等一類指標都實現了大幅的優化。用這樣一整套比較完善的系統來做優化，我們某些平臺上的核心QoS指標得到了大幅優化，一些平臺上的Rebuffer甚至降低了50%以上。
LiveVideoStackCon 2018講師招募
LiveVideoStackCon 2018是音視頻技術領域的綜合技術大會，今年是在10月19-20日在北京舉行。大會共設立18個專題，預計邀請超過80位技術專家。如果你在某一領域獨當一面，歡迎申請成為LiveVideoStackCon 2018的講師，讓你的經驗幫到更多人，你可以通過speaker@livevideostack.com提交演講信息。了解大會更多詳情，點擊【閱讀原文】訪問LiveVideoStackCon 2018官網，報名即刻享受7折優惠。
總結
以上是生活随笔為你收集整理的Hulu 视频QoS优化策略的全部內容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： 基于镜头的编码
- 下一篇： LiveVideoStackCon讲师热