本文來自快手科技算法科學(xué)家，快手傳輸算法團(tuán)隊負(fù)責(zé)人周超博士在LiveVideoStackCon 2020線上峰會的分享，介紹了快手基于流式直播多碼率的實(shí)踐與優(yōu)化，以及LAS (Live Adaptive Streaming)標(biāo)準(zhǔn)的架構(gòu)、原理、自適應(yīng)算法與未來規(guī)劃。

近日，快手正式對外發(fā)布基于流式的直播多碼率自適應(yīng)標(biāo)準(zhǔn)LAS（Live Adaptive Streaming），用于提供低延遲、平滑、流暢的直播多碼率體驗(yàn)。據(jù)悉，快手同時開源了LAS的端到端解決方案，包括服務(wù)端、客戶端、業(yè)界領(lǐng)先的多碼率自適應(yīng)算法等，幫助業(yè)界實(shí)現(xiàn)零門檻接入和使用LAS。

直播清晰度對用戶的體驗(yàn)至關(guān)重要，通過提升視頻的碼率、分辨率，能夠確保視頻清晰度顯著提升。快手用戶規(guī)模大、分布廣泛，用戶間網(wǎng)絡(luò)差異性大，單一的視頻質(zhì)量（碼率、分辨率）或固定的檔位下發(fā)策略難以適應(yīng)不同的網(wǎng)絡(luò)需求。

2019年底數(shù)據(jù)顯示，快手的直播DAU超過了1億，快手的游戲直播日活用戶數(shù)達(dá)到5100萬，游戲直播是眾多直播場景中比較特殊的一個例子。相對于傳統(tǒng)直播（秀場類），因?yàn)橛螒虍嬅娴膹?fù)雜性，游戲直播對碼率的需求更高。這也是催生快手做直播多碼率的一大動機(jī)：單一的碼率很難滿足不同用戶的網(wǎng)絡(luò)條件。

直播技術(shù)的痛點(diǎn)和行業(yè)解決思路

站在用戶的角度，直播體驗(yàn)面臨的最大痛點(diǎn)可以分為三類：卡頓、模糊、延遲大。

對于這些問題，單獨(dú)優(yōu)化某一個指標(biāo)并不難，難點(diǎn)在于彼此之間互相制約。例如通過降低碼率能降低卡頓率，提升觀看直播的流暢度，但降低碼率損失了清晰度的體驗(yàn)，會引起直播畫面模糊。此外，延遲對于直播體驗(yàn)也至關(guān)重要，例如秀場的互動直播，主播能及時響應(yīng)粉絲的評論或送禮等行為，都能極大的改善用戶體驗(yàn)。而延遲越低，客戶端緩存的數(shù)據(jù)也越少，對網(wǎng)絡(luò)抖動的抗性也越差，從而增加了卡頓的風(fēng)險。

目前的直播架構(gòu)主要分為兩類，一類是是基于流式架構(gòu)，例如HTTP-FLV、WebRTC等。這類基于流式的直播架構(gòu)，可以實(shí)現(xiàn)幀級傳輸，從而獲得低延遲的直播體驗(yàn)。此外，對于這些架構(gòu)和協(xié)議，CDN支持好，易部署，并且被長時間大規(guī)模的商用驗(yàn)證過，穩(wěn)定性高。其缺點(diǎn)是不支持多碼率，無法根據(jù)用戶的網(wǎng)絡(luò)動態(tài)自適應(yīng)選擇最佳的碼率檔位。

多碼率自適應(yīng)是在抖動網(wǎng)絡(luò)下保證觀看流暢度最有效的手段之一。目前多碼率自適應(yīng)方案，主要包括MPEG-DASH和HLS，并且這二者都是基于分片傳輸?shù)摹Ｔ谧畛踉O(shè)計時，也主要用于點(diǎn)播場景，延遲問題考慮得相對較少，直接用于直播場景時容易引起延遲過大，影響直播體驗(yàn)。目前國內(nèi)暫無大規(guī)模的使用DASH或HLS進(jìn)行直播，實(shí)際大規(guī)模使用時，其穩(wěn)定性也有待考量。雖然目前MPEG-DASH和HLS都在討論低延遲方案，例如LHLS，但這些方案還沒完全標(biāo)準(zhǔn)化，離落地尚需時日。

魚和熊掌兼得的自研思路

已有的解決方案或多或少的存在一些瑕疵，難以滿足快手的業(yè)務(wù)需求。因此，我們選擇自研之路，設(shè)計了一套基于流式的直播多碼率自適應(yīng)方案，其目標(biāo)是在支持直播碼率自適應(yīng)的同時，實(shí)現(xiàn)流式直播的低延遲。

總體而言，快手的直播多碼率解決方案包含兩大特性：一是基于流式傳輸，從而保證低延時；二是支持多碼率，從而依據(jù)每個用戶的網(wǎng)絡(luò)狀態(tài)，自適應(yīng)選擇最佳的視頻清晰度。該方案需要解決的三個核心問題為：When——什么時候切換碼率；Which——切換到哪一檔；How——在流式傳輸下，如何實(shí)現(xiàn)無縫切換。

快手直播的系統(tǒng)架構(gòu)如上圖所示，主播推流到快手自建源站，源站負(fù)責(zé)收流、轉(zhuǎn)碼后，由CDN回源拉取不同碼率檔位的視頻流，進(jìn)而依據(jù)用戶的請求，將合適的視頻流分發(fā)給用戶。在基于流式的直播多碼率架構(gòu)下，對轉(zhuǎn)碼、CDN和播放器需要有一些規(guī)范的要求。

對于轉(zhuǎn)碼，不同于MPEG-DASH或HLS，我們的方案不需要進(jìn)行切片操作，只需要在轉(zhuǎn)碼時保證不同的轉(zhuǎn)碼流的I幀的pts嚴(yán)格對齊。因?yàn)樵谧龃a率切換時，需要依據(jù)I幀的pts進(jìn)行對齊，否則，在解碼渲染時可能會出現(xiàn)跳幀的現(xiàn)象。

對于CDN，也是多碼率服務(wù)端的核心邏輯，主要包括以下功能的支持：

緩存：傳統(tǒng)CDN的緩存使用字節(jié)數(shù)（Bytes），在多碼率場景下，對于不同的視頻碼率，相同字節(jié)數(shù)所對應(yīng)的時長不一樣，而多碼率的操作都是基于時間的，因此，我們要求存儲單位統(tǒng)一為時間。這個時間長度的計算，可以依據(jù)視頻，也可以依據(jù)音頻 ，詳細(xì)的實(shí)現(xiàn)可以參考我們的標(biāo)準(zhǔn)文檔。

拉流：CDN需要支持三種拉流模式，即默認(rèn)位置拉流（傳統(tǒng)拉流）、絕對位置拉流（明確吐流位置）、相對位置拉流（設(shè)置吐流時長）。

在具體實(shí)現(xiàn)時，考慮遲到視頻幀的解碼參考關(guān)系，CDN在吐流時，需要從關(guān)鍵幀開始，具體分為三種情況：

默認(rèn)位置拉流，一般發(fā)生在啟播時，依據(jù)默認(rèn)長度計算當(dāng)前期望的絕對位置，找到最近的I幀開始吐流。

絕對位置拉流，一般發(fā)生在碼率切換時，需要找到pts不大于絕對位置的I幀開始吐流，避免渲染跳變。

相對位置拉流，一般發(fā)生在啟播時，根據(jù)相對位置計算絕對位置，再找到最近的I幀開始吐流。

上圖是基于流式的直播多碼率自適應(yīng)的流程示意圖。在啟播時，采用相對位置拉流的模式，默認(rèn)拉取高清檔位的視頻流。此時，可以結(jié)合業(yè)務(wù)的需求，通過合理的設(shè)置相對位置來控制直播延遲。在直播過程中，當(dāng)因?yàn)榫W(wǎng)絡(luò)等原因?qū)е滦枰獜母咔辶髑袚Q到標(biāo)清流，從而保證播放的流暢性時，可以采用絕對位置的拉流方式。具體過程為：首先斷開高清流，然后播放器依據(jù)當(dāng)前的狀態(tài)，得到期望吐流的絕對位置 ，比發(fā)送絕對位置的拉流請求。通過I幀的pts嚴(yán)格對齊，保證了無縫切換。

基于流式傳輸?shù)募軜?gòu)保證了低延遲的效果，直播的流暢度和清晰度，則需要通過多碼率自適應(yīng)算法來實(shí)現(xiàn)。為了平衡這一對矛盾的目標(biāo)，我們采用基于buffer的模式，背后的出發(fā)點(diǎn)在于當(dāng)buffer數(shù)據(jù)較多時，意味著帶寬沒有被充分利用起來，需要切換到更高檔位以獲得更高的清晰度，反之亦然。此外，頻繁的碼率切換，對用戶的主觀體驗(yàn)也不友好，因此，我們還需要考慮碼率切換的平滑性。

這里值得強(qiáng)調(diào)一點(diǎn)的是，整個建模過程都依賴與網(wǎng)絡(luò)帶寬的估計。在基于分片的多碼率框架下，每個分片獨(dú)立下載，其平均下載速度可以近似作為當(dāng)前帶寬的均值。然而，在基于流式傳輸?shù)倪^程中，源數(shù)據(jù)實(shí)時產(chǎn)生，觀測到的下載速度近似等于請求的視頻流的碼率，難以反應(yīng)真實(shí)的帶寬。在我們的方案中，帶寬通過實(shí)時收集固定時間間隔的微粒度下載速度采樣點(diǎn)并濾波來獲得。

在實(shí)際求解時，除了考慮當(dāng)前時刻的決策外，還需要考慮當(dāng)前的決策對未來的影響，從而達(dá)到全局最優(yōu)。經(jīng)過一些矩陣的巧妙設(shè)計，極大簡化了求解過程，也方便了工程實(shí)現(xiàn)。算法的具體實(shí)現(xiàn)已開源。

LAS標(biāo)準(zhǔn)發(fā)布期待行業(yè)伙伴參與共建

快手直播多碼率的解決方案方案從開始調(diào)研，實(shí)現(xiàn)再到全量，經(jīng)歷了方案和架構(gòu)選擇、工程實(shí)現(xiàn)、算法優(yōu)化等諸多問題，目前已經(jīng)在快手直播業(yè)務(wù)實(shí)現(xiàn)全量，并且取得了很不錯的收益。我們將整套方案重新梳理并形成標(biāo)準(zhǔn)文檔LAS（Live Adaptive Streaming），將這些經(jīng)驗(yàn)分享出來，希望能為大家?guī)硪恍椭AS標(biāo)準(zhǔn)主要內(nèi)容包括以下幾個方面：

媒體呈現(xiàn)描述：描述了基于流式的直播多碼率自適應(yīng)標(biāo)準(zhǔn)的基本語義元素

LAS請求描述：描述了基于流式的直播多碼率自適應(yīng)標(biāo)準(zhǔn)，不同場景下請求的生成方式

LAS服務(wù)描述：描述了基于流式的直播多碼率自適應(yīng)標(biāo)準(zhǔn)，服務(wù)端/云端支持的處理邏輯

LAS客戶端描述：LAS客戶端的具體實(shí)現(xiàn)，不作為LAS標(biāo)準(zhǔn)的范疇。LAS僅給出推薦的實(shí)現(xiàn)架構(gòu)與自適應(yīng)算法策略

詳細(xì)的文檔、架構(gòu)、部署方式、測試數(shù)據(jù)等，可以參考LAS的官方網(wǎng)站（https://las-tech.org.cn），這里不再贅述。

最后，我們還與HLS做了詳細(xì)的測試對比，包括不同的網(wǎng)絡(luò)環(huán)境、不同的GOP大小、不同的延遲模式等。其中，LAS不同的延時模式，通過啟播拉流時，采用相對位置拉流并設(shè)定不同的相對位置來實(shí)現(xiàn)。詳細(xì)的測試數(shù)據(jù)可以參考LAS的官網(wǎng)。

LAS基于流式架構(gòu)，實(shí)現(xiàn)幀級傳輸，與HLS等基于分片的多碼率架構(gòu)相比，能顯著降低延遲。在自適應(yīng)算法上，與分片傳輸?shù)牟呗韵啾龋诹魇降膫鬏斶壿嫊欢ǔ潭仍黾幼赃m應(yīng)算法的難度（例如在流式傳輸中，因?yàn)樵磾?shù)據(jù)實(shí)時產(chǎn)生，觀測到的平均帶寬值近似等于當(dāng)前請求的視頻碼率，無法反應(yīng)真實(shí)的帶寬），但流式架構(gòu)更加靈活，并且能顯著降低分片架構(gòu)中存在的傳輸ON-OFF現(xiàn)象，從而降低了碼率切換過于頻繁的問題。上圖展示的LAS與HLS對比各項指標(biāo)的平均結(jié)果，可以看出，與HLS相比，LAS能在獲得更低的卡頓率、更高的碼率和更低的延遲，從而為用戶提供更低延遲，更流暢、更清晰的直播體驗(yàn)。

LAS已經(jīng)開源，涵蓋服務(wù)端、客戶端和自適應(yīng)算法。目前，阿里云、騰訊云、百度云、金山云、網(wǎng)宿云等云廠商均支持LAS，企業(yè)可直接接入使用。此外，業(yè)內(nèi)知名開源流媒體服務(wù)器SRS也已支持LAS，基于SRS 4.0及更高版本，企業(yè)客戶也可搭建自己的LAS服務(wù)端以滿足個性化的需求。在客戶端，我們已經(jīng)開源了LAS Web的實(shí)現(xiàn)，包括協(xié)議、架構(gòu)和自適應(yīng)算法。

未來，LAS還將進(jìn)一步優(yōu)化升級，主要包括以下幾個方面：

跨平臺：未來我們希望可以實(shí)現(xiàn)跨平臺的支持，例如移動端的支持和開源。

多協(xié)議：在協(xié)議層面，目前開源的版本是基于HTTP-FLV的實(shí)現(xiàn)，未來希望可以支持更多協(xié)議，例如WebRTC、QUIC等。

全鏈路：LAS目前主要是針對拉流端的多碼率自適應(yīng)方案，未來希望涵蓋推流、轉(zhuǎn)碼，打造一套全鏈路的解決方案。

自適應(yīng)算法：自適應(yīng)算法是LAS高效性的保障。我們有完善的測試環(huán)境，AB系統(tǒng)。

最后，歡迎業(yè)界同行加入LAS，共同完善LAS標(biāo)準(zhǔn)和LAS開源社區(qū)。