音視頻應(yīng)用近年來呈現(xiàn)出迅猛的發(fā)展趨勢，成為互聯(lián)網(wǎng)流量的主要載體，其玩法豐富，形態(tài)多樣，眾多繁雜的媒體傳輸協(xié)議也應(yīng)運而生。LiveVideoStackCon 2022北京站邀請到快手傳輸算法負責(zé)人周超，結(jié)合快手在媒體傳輸上的優(yōu)化與實踐，基于快手KTP、KLP、LAS等協(xié)議和標(biāo)準(zhǔn)，為我們介紹了媒體傳輸協(xié)議的演進與面臨的挑戰(zhàn)；還分享了最新的媒體傳輸標(biāo)準(zhǔn)CMTP，探索未來更多可能。

-01-

音視頻大時代下媒體傳輸協(xié)議的繁華

本次分享會從媒體傳輸協(xié)議的現(xiàn)狀、快手在媒體傳輸協(xié)議優(yōu)化上的實踐和對未來的展望三部分展開。

近幾年，音視頻技術(shù)發(fā)展迅速，疊加網(wǎng)絡(luò)、AI技術(shù)，音視頻已無處不在，應(yīng)用場景涵蓋點播、直播、電商、實時互動、游戲、醫(yī)療和教育等多個方向。

從用戶體驗角度來看，音視頻應(yīng)用都需要在延遲、流暢度和清晰度之間尋找一個平衡點，對應(yīng)到網(wǎng)絡(luò)傳輸，本質(zhì)就是需要在延遲、傳輸可靠性和帶寬利用率之間找到一個平衡點。

基于此，音視頻應(yīng)用可以大致劃分為三大類，即泛VoD、泛RTC和泛Live。

泛VoD偏重于點播類應(yīng)用，對延遲不敏感，更注重傳輸可靠性和帶寬利用率。泛RTC應(yīng)用則對延遲非常敏感，在保證延時的前提下，才會追求傳輸?shù)目煽啃院蛶捓寐?。泛Live應(yīng)用介于兩者之間，對每個維度都有一定要求，并且不同的Live垂類場景，對三者（可靠性、延遲、帶寬利用率）之間的平衡關(guān)系也有一定差異。

從架構(gòu)上來看，泛VoD可以大致分為四個步驟。視頻在采集和導(dǎo)入之后，疊加魔法表情等玩法，然后經(jīng)過轉(zhuǎn)碼壓縮上傳到云端。在服務(wù)端進行審核和前處理等大量工作后，一般會進行二次轉(zhuǎn)碼，以進一步提高壓縮率并生成多個質(zhì)量的副本。最后，由CDN分發(fā)給用戶，進行下載、解碼、渲染和播放。

在生產(chǎn)端，創(chuàng)作者能否快速成功的發(fā)布作品，將直接影響他們的創(chuàng)作熱情。

在消費側(cè)，用戶則更關(guān)注視頻的清晰度和流暢度，這兩個維度都需要可靠傳輸以及足夠高的帶寬利用率。提到可靠傳輸，最常見的就是HTTP協(xié)議和QUIC協(xié)議。此外，在消費側(cè)，為了應(yīng)對海量用戶的差異性網(wǎng)絡(luò)，一般會采用多碼率自適應(yīng)技術(shù)，例如DASH、HLS等。

泛Live應(yīng)用架構(gòu)與泛VoD較為類似。主播和觀眾都希望獲得低延遲、高清晰度和高流暢度的體驗。但直播流實時產(chǎn)生，對傳輸?shù)钠椒€(wěn)性要求較高，對帶寬利用率和延遲方面會做一定的妥協(xié)。例如，當(dāng)網(wǎng)絡(luò)出現(xiàn)劇烈波動時，允許出現(xiàn)丟幀和丟包。業(yè)內(nèi)直播主要采用RTMP協(xié)議，近年來也在嘗試QUIC協(xié)議，例如RTMP over QUIC的方案。在消費側(cè)，通常也會采用多碼率自適應(yīng)技術(shù)。然而，常見的DASH和HLS技術(shù)，都是基于分片的架構(gòu)，在直播場景中會帶來較大的延遲。目前，為了降低直播延遲，許多廠商也在嘗試基于WebRTC的快直播方案。

泛RTC場景的目標(biāo)非常明確，就是要實現(xiàn)超低延遲的互動。在滿足低延遲的前提下，再提升清晰度和流暢度。目前使用最多的方案是WebRTC，很多公司也基于WebRTC進行了二次開發(fā)，形成自己的方案。

總體而言，每類應(yīng)用場景目前都有各自比較成熟的協(xié)議，其穩(wěn)定性高、各廠商支持好，但也存在靈活性差、跨層優(yōu)化難和業(yè)務(wù)不感知等問題。

-02-

快手在媒體傳輸優(yōu)化上的實踐

在快手的傳輸體系中，底層算法是最核心的部分，包括常見的擁塞算法、多碼率自適應(yīng)算法、弱網(wǎng)對抗算法等等。在此基礎(chǔ)之上，我們設(shè)計了豐富的傳輸協(xié)議，例如KTP、LAS、AAS、KLP等。KTP是快手自研的第一個私有傳輸協(xié)議，用于直播推流、作品發(fā)布和RTC等業(yè)務(wù)場景；LAS是快手自研低延遲直播多碼率自適應(yīng)協(xié)議，目前已形成行標(biāo)，幾乎所有云廠商都支持；KLP是快手自研的直播拉流協(xié)議，用于提升直播拉流的傳輸效率；AAS是點播場景下的多碼率自適應(yīng)協(xié)議，包含短視頻和長視頻場景。

KTP在設(shè)計之初，就希望一個協(xié)議能同時支持支持點播、直播和RTC等多個業(yè)務(wù)場景，解決協(xié)議繁多、維護和優(yōu)化成本高的問題。在架構(gòu)上，KTP總體分為兩層：底層是傳輸控制層，通過對協(xié)議的設(shè)計，支持在傳輸延時、可靠性和帶寬利用率之間取得動態(tài)平衡。在其之上是業(yè)務(wù)感知層，感知業(yè)務(wù)特性，根據(jù)不同業(yè)務(wù)的特征，采取最佳的策略與算法。

通過實際測試對比發(fā)現(xiàn)，在直播推流場景，KTP在60%丟包率時，依然可以保持清晰、流暢的推流體驗（左圖），而RTMP在15%丟包率時，會發(fā)生嚴重卡頓，處于不可用狀態(tài)（右圖）。

在作品發(fā)布場景上，基于KTP的通用上傳服務(wù)，已經(jīng)用戶快手各個作品發(fā)布/文件傳輸?shù)膱鼍埃@著提升了作品發(fā)布成功率，從最初的70%～80%提升到99%以上。此外，即便在用戶網(wǎng)絡(luò)越來越復(fù)雜、作品大小越來越大的情況下，其發(fā)布耗時也一直處于下降的狀態(tài)。

最后，在RTC場景，KTP支撐著快手內(nèi)部所有的RTC業(yè)務(wù)，例如PK、連麥、會議、StreamLake等等?；谙冗M的算法與架構(gòu)，基于KTP的RTC解決方案，在體驗和性能等多個維度上，都顯著領(lǐng)先競品。

此外，在2021年ACM Multimedia的低延遲傳輸挑戰(zhàn)賽中，快手也以巨大的優(yōu)勢取得了第一名的好成績。

協(xié)議是橋梁，支撐各種功能與業(yè)務(wù)需求，但其傳輸性能主要取決于底層算法。例如網(wǎng)絡(luò)領(lǐng)域的核心算法之一的擁塞控制算法，在過去幾十年一直是研究的熱點與難點，直接影響著協(xié)議的傳輸性能、帶寬利用率、弱網(wǎng)抗性等?？焓忠恢背掷m(xù)在算法領(lǐng)域深耕，例如自研的擁塞控制算法IA2C，性能遠超BBR；基于強化學(xué)習(xí)的NNCC，在帶寬利用率上取得新的突破；最近正在準(zhǔn)備上線的下一代擁塞算法AQDC，在帶寬利用率和延遲上，均取得顯著收益。

KTP廣泛用于作品發(fā)布、直播推流和RTC等場景，并取得了很好的收益。但由于歷史原因，在下行鏈路上，KTP并未很好的做支持和優(yōu)化。于是，在2020年，我們復(fù)用了KTP的底層傳輸控制，并在此基礎(chǔ)上，增加了適用于直播拉流特性的策略與算法，形成了KLP協(xié)議。KLP在海外上線的時候，取得了非常好的效果。

在消費側(cè)，為了應(yīng)對用戶差異性的網(wǎng)絡(luò)特性，一般會采用多碼率自適應(yīng)技術(shù)，來平衡流暢度和清晰度，例如國際標(biāo)準(zhǔn)DASH和HLS，其大致原理為將視頻文件轉(zhuǎn)碼成多個檔位，每個檔位進行分片處理，消費側(cè)依據(jù)實時網(wǎng)絡(luò)狀況選擇不同的分片，最終拼接成一個完整的視頻。這兩個標(biāo)準(zhǔn)成熟度高，但最初都是為點播設(shè)計，直接用于直播場景，會帶來較大的延遲。

在經(jīng)過充分的調(diào)研和討論后，快手決定自己建立一套低延遲的直播多碼率標(biāo)準(zhǔn)，也就是LAS，目前LAS已經(jīng)正式成為行標(biāo)，也被業(yè)界廣泛采用，相關(guān)細節(jié)可參考官網(wǎng)介紹（https://las-tech.org.cn/#/）。

在點播多碼率上，我們同時考慮了短視頻和長視頻之間的差異，形成了快手點播多碼率自適應(yīng)標(biāo)準(zhǔn)——AAS。在協(xié)議描述上，參考了MPD和DASH的設(shè)計，最核心的是快手自研究的多碼率算法，包括傳統(tǒng)基于模型的算法、基于深度學(xué)習(xí)的ABR等，這些算法在不同場景，均取得了非常好的效果。

此外，在2022年ACM Multimedia的短視頻傳輸挑戰(zhàn)賽中，快手也以巨大的優(yōu)勢取得第一名的好成績。

目前，快手的網(wǎng)絡(luò)傳輸主要依托于自研的一系列協(xié)議，但仍存在一系列問題，例如下行場景覆蓋不足、業(yè)務(wù)耦合、生態(tài)封閉、無法賦能行業(yè)、三方CDN不能全場景支持等。

-03-

下一代媒體傳輸協(xié)議：CMTP

基于之前多個協(xié)議成功的經(jīng)驗和算法積累，我們期望設(shè)計一套全新的協(xié)議CMTP，可適用于所有場景，并能解決覆蓋不足、生態(tài)封閉等問題。總體而言，CMTP具有以下四個特性：架構(gòu)通用、全場景、高擴展性和特性豐富。

在架構(gòu)上，CMTP分為五層：

UDP/TCP層：底層IO使用的網(wǎng)絡(luò)協(xié)議，默認采用UDP，UDP靈活性高，易擴展，可以支持多種算法與策略，對于UDP Block的情況，則采用TCP。

傳輸控制層：支持UDP和TCP兩種模式?；赨DP規(guī)范了協(xié)議字段、組包拆包方式、會話管理等，支持ARQ、FEC、擁塞控制、0-RTT、加密、多路復(fù)用等功能。基于TCP也規(guī)范了協(xié)議字段、組包拆包方式等，并支持加密、多路復(fù)用等功能。

傳輸表示層：規(guī)范了傳輸控制層所需要提供的接口和功能，包括媒體會話、媒體流的定義，以及媒體數(shù)據(jù)、控制信令的表示方式等，同時支持協(xié)議優(yōu)選。

應(yīng)用感知層：以組件化的方式組織，感知業(yè)務(wù)的不同需求，并通過對應(yīng)的組件提供專屬優(yōu)化功能，包含直播組件(Live)、點播組件(VoD)、實時通信組件(RTC)和通用組件。各個組件功能獨立，可插拔、替換或新增，從而保證其足夠強的擴展性、兼容性和業(yè)務(wù)適應(yīng)性。

通用接口層：規(guī)范了對外的標(biāo)準(zhǔn)接口和配置，包括客戶端和服務(wù)端接口，元信息和通用配置的格式等。

目前CMTP已經(jīng)在快手落地，也取得了顯著的收益。此外，很多廠商也已經(jīng)支持CMTP，并與快手一起推進標(biāo)準(zhǔn)化。未來，希望有更多團隊加入我們，共同建設(shè)良好的CMTP生態(tài)。

審核編輯 ：李倩