“立足當(dāng)下，著眼未來”，任何一位從業(yè)者都應(yīng)該謹(jǐn)遵這樣的格言。阿里云通過總結(jié)這么多年的流媒體傳輸服務(wù)，分析痛點(diǎn)、提出措施、改進(jìn)技術(shù)、認(rèn)真思考，帶來了MediaUni這樣一個面向未來的流媒體傳輸網(wǎng)絡(luò)。LiveVideoStackCon2023上海站邀請到了黃海宇為我們介紹阿里云在MediaUni上的設(shè)計(jì)與實(shí)踐。

大家好，我是阿里云視頻云的黃海宇，今天分享主題是MediaUni——面向未來的流媒體傳輸網(wǎng)絡(luò)設(shè)計(jì)與實(shí)踐。

下面我將會從應(yīng)用對流媒體傳輸網(wǎng)絡(luò)的要求、MediaUni定位與系統(tǒng)架構(gòu)、MediaUni技術(shù)剖析、基于MediaUni的應(yīng)用落地和流媒體傳輸網(wǎng)絡(luò)的未來5個方面展開介紹。

-01-

應(yīng)對流媒體傳輸網(wǎng)絡(luò)的要求

如圖所示，不同場景延時(shí)從左往右依次升高。最右側(cè)，超過30秒的延時(shí)，通常被認(rèn)為是一個可傳播的場景，例如視頻點(diǎn)播，行業(yè)內(nèi)會通過一張CDN點(diǎn)播網(wǎng)，服務(wù)這樣的傳輸需求。

3~10秒的延時(shí)區(qū)間多見于直播，會使用如RTMP、HTTPFLV和HLS等協(xié)議，進(jìn)行一些流式或小分片的傳輸，可滿足3~5秒的延時(shí)需求，通常適用于彈幕互動的場景。在行業(yè)內(nèi)，通常使用CDN直播網(wǎng)絡(luò)進(jìn)行這樣的傳輸服務(wù)。

最近興起的800毫秒到1秒左右的延時(shí)，通常可以滿足體育賽事直播中的傳輸延時(shí)需求，例如，在世界杯直播場景中，該延時(shí)的直播讓用戶不再會感受到進(jìn)球時(shí)刻的明顯差異。另外，通過淘寶等電商場景的實(shí)踐發(fā)現(xiàn)，該延時(shí)級別的直播，相對于3~10秒的普通直播，可以有效提升GMV。

視頻會議、直播連麥、語音聊天的延時(shí)通常在250毫秒到400毫秒之間，行業(yè)內(nèi)通常會采用如BGP帶寬或者三線帶寬，構(gòu)建一張低延時(shí)的音視頻通訊網(wǎng)絡(luò)，來進(jìn)行實(shí)時(shí)音視頻傳輸支持。

更低延時(shí)的場景，我們將其稱為可操控和可沉浸場景，延時(shí)在50~80毫秒，可操控的典型場景是平行駕駛，當(dāng)自動駕駛出現(xiàn)問題時(shí)，可以通過遠(yuǎn)程指令操控汽車、接管駕駛。而云游戲、云渲染則是典型的可沉浸場景。

從上面可以看到，延時(shí)的降低帶來了更多的業(yè)務(wù)場景和更多新的玩法。

以延時(shí)最低的云渲染場景為例，通過其頂層架構(gòu)圖，可以發(fā)現(xiàn)，用戶產(chǎn)生一系列的操作指令，通過傳輸網(wǎng)絡(luò)傳輸?shù)较嚓P(guān)的業(yè)務(wù)服務(wù)器，再控制渲染服務(wù)器進(jìn)行渲染，渲染后的數(shù)據(jù)會經(jīng)過流媒體服務(wù)器，再通過流媒體傳輸網(wǎng)絡(luò)進(jìn)行傳輸，最終達(dá)到用戶終端。

相比傳統(tǒng)的媒體傳輸，該架構(gòu)有兩個特點(diǎn)：第一，視頻來自于渲染而非拍攝，會涉及到大量的計(jì)算環(huán)節(jié)；第二，傳輸網(wǎng)絡(luò)不僅要傳輸媒體，還要傳輸控制指令，需要保證控制指令的低延時(shí)和可靠的交付。

成本和質(zhì)量是傳輸網(wǎng)絡(luò)繞不開的兩個話題。左圖展示了一個阿里云典型直播APP客戶的云上成本構(gòu)成，70%左右來自于傳輸，這意味著在當(dāng)下企業(yè)降本的大環(huán)境下，需要對傳輸提出更低成本的要求。右圖是另一個典型視頻APP的播放時(shí)長與卡頓率的關(guān)系數(shù)據(jù)，通過AB測試我們發(fā)現(xiàn)，隨著卡頓率的逐步降低，播放時(shí)長也會有明顯的提升。

綜合來看，應(yīng)用對流媒體傳輸網(wǎng)絡(luò)的要求來自于四個方面：第一，延時(shí)的降低可以催生更多業(yè)務(wù)場景；第二，低成本，媒體傳輸是視頻應(yīng)用成本的重要組成部分；第三，更高質(zhì)量的視頻可以提升用戶的觀看時(shí)長；第四，多維度，除了媒體傳輸之外，還需要支持互動消息的傳輸、控制信令的傳輸，同時(shí)也要支持與計(jì)算的緊密相連。

-02-

MediaUni定位與系統(tǒng)架構(gòu)

基于以上思考，阿里云設(shè)計(jì)并實(shí)現(xiàn)了MediaUni，其中Uni取自單詞unified，意為通過一張統(tǒng)一的網(wǎng)絡(luò)，服務(wù)各種業(yè)務(wù)場景。

MediaUni是阿里云全球?qū)崟r(shí)傳輸網(wǎng)絡(luò)GRTN的升級，是基于廣泛的異構(gòu)節(jié)點(diǎn)，構(gòu)建的全分布式、超低延時(shí)、多業(yè)務(wù)支撐的多元融合流媒體傳輸網(wǎng)絡(luò)。

MediaUni的核心理念在于融合，這主要出于如下三方面的思考。

第一、業(yè)務(wù)混跑帶來的資源利用率提升。云廠商的基本商業(yè)邏輯是：云是彈性服務(wù)，大家可以按需付費(fèi)，即買即用，那么，由于不同用戶使用的時(shí)間段是不同的，購買的固定資源則可分時(shí)服務(wù)到不同的廠商，使得云服務(wù)的資源利用率大于客戶自行購買的的資源利用率，從而降低成本。與普通的云計(jì)算不同，流媒體的一大特點(diǎn)是業(yè)務(wù)的聚集，例如，單一的互聯(lián)網(wǎng)娛樂直播，大部分都會發(fā)生在晚上8:00~11:00的晚高峰之間，而大部分的會議分布在白天上班時(shí)間，體育賽事則可能出現(xiàn)在任一時(shí)間段，如果我們僅僅支持其中一種業(yè)務(wù)，則無法達(dá)到資源復(fù)用的目的。

這背后的理論依據(jù)是概率論最基本的中心極限定理：大量獨(dú)立的隨機(jī)變量之和服從正態(tài)分布，隨機(jī)變量越多，他們的和將越聚集在平均值之和附近。對應(yīng)到流媒體傳輸業(yè)務(wù)，每個客戶對資源的使用就是一個隨機(jī)變量，他們對資源的總需求就是服務(wù)商需要保障的資源總量。為了達(dá)到更高的復(fù)用率，我們需要盡可能擴(kuò)大業(yè)務(wù)的規(guī)模與多樣性，從而達(dá)到綜合降本的目的。

第二、技術(shù)復(fù)用帶來的研發(fā)邊際成本降低。不管是音視頻點(diǎn)播的傳輸網(wǎng)絡(luò)，還是直播的傳輸網(wǎng)絡(luò)，還是實(shí)時(shí)音視頻通訊，都會涉及一些相同的技術(shù)，比如協(xié)議的優(yōu)化、QoS優(yōu)化、調(diào)度等，而在一張網(wǎng)上實(shí)現(xiàn)這些技術(shù)，可以帶來更好的技術(shù)復(fù)用，將單點(diǎn)技術(shù)做得更加深入，從而帶來更大的業(yè)務(wù)價(jià)值。

第三、云產(chǎn)品更加便捷與高效。從云廠商的角度來說，把各種傳輸能力進(jìn)行融合，意味著用戶在使用產(chǎn)品時(shí)會更加便捷，比如通過一張網(wǎng)的融合，用戶在阿里云上可以通過一鍵升級，將自己的普通直播（3~5秒延遲）升級為低延時(shí)互動直播（400毫秒）。

圖為MediaUni的架構(gòu)

可以看到，MediaUni構(gòu)建在阿里云廣泛的異構(gòu)資源上，包括3200+的邊緣計(jì)算節(jié)點(diǎn)，以及29個region，同時(shí)也包括超過180T的帶寬，涉及的計(jì)算資源類型包括CPU、GPU、ASIC。

這里有兩個很重要的系統(tǒng)，第一個是感知系統(tǒng)。感知系統(tǒng)需要具備三方面的感知能力：

①感知業(yè)務(wù)信息，在直播時(shí)有些應(yīng)用信息是在真正發(fā)生之后才知道的，例如，某個直播流觀看人數(shù)突然增多，我們必須有能力實(shí)時(shí)感知到，從而提供一些差異化的服務(wù)；

②感知資源信息，包括基礎(chǔ)資源的水位、CPU與內(nèi)存的狀態(tài)、帶寬的使用情況、以及網(wǎng)絡(luò)的延遲、丟包率等；

③感知服務(wù)質(zhì)量，例如各種業(yè)務(wù)的卡頓率、視頻首幀的延時(shí)、推拉流成功率等。

第二個是決策系統(tǒng)，這些感知信息在收集以后，會推送給決策系統(tǒng)，并基于成本與質(zhì)量的平衡，進(jìn)行調(diào)度決策：包括接入的調(diào)度、路由的選擇、實(shí)時(shí)的逃逸策略以及算力的調(diào)度等等。

MediaUni的整體架構(gòu)具有幾個明顯的特點(diǎn)：

一、可以支持多種協(xié)議。這些協(xié)議是在邊緣支持的，在邊緣節(jié)點(diǎn)進(jìn)行一層卸載，卸載以后中心會采用統(tǒng)一的內(nèi)部傳輸協(xié)議，這樣利于我們擴(kuò)展業(yè)務(wù)場景，同時(shí)又不影響內(nèi)部核心系統(tǒng)；

二、MediaUni支持混合組網(wǎng)。延時(shí)要求不高的場景，會采用樹狀組網(wǎng)，而對于音視頻通訊這樣延時(shí)要求高的場景，會采用對等組網(wǎng)的方式；

三、網(wǎng)絡(luò)之間的路由會基于源選擇動態(tài)路徑服務(wù)用戶；

四、全鏈路可編程。很多業(yè)務(wù)在同一張網(wǎng)上運(yùn)行以后，可能會存在業(yè)務(wù)之間相互影響的問題，為了減少系統(tǒng)的變更，我們支持了全鏈路的可編程，讓大部分業(yè)務(wù)需求能夠通過可編程的方式實(shí)現(xiàn)；

五、算網(wǎng)結(jié)合。計(jì)算部署在網(wǎng)絡(luò)節(jié)點(diǎn)上，能夠提高資源利用率，同時(shí)也降低為了計(jì)算而傳輸數(shù)據(jù)帶來的成本與延遲；

六、異構(gòu)網(wǎng)絡(luò)、計(jì)算資源支持。系統(tǒng)支持單線、多線、BGP多種網(wǎng)絡(luò)資源類型，也支持CPU、GPU、ASIC多種計(jì)算類型；

七、持續(xù)迭代的QoS。系統(tǒng)支持QoS算法的可插拔，并具備完善的AB測試能力，幫助QoS不斷迭代。

融合帶來諸多好處，但也會帶來額外的挑戰(zhàn)。首先是異構(gòu)資源的適配和納管。其次是基于不可靠的資源提供可靠的服務(wù)，這是這張網(wǎng)絡(luò)最大的挑戰(zhàn)，通常的音視頻通訊網(wǎng)絡(luò)，采用更加優(yōu)質(zhì)的資源以達(dá)到更低的延遲及穩(wěn)定性，對于統(tǒng)一的網(wǎng)絡(luò)，如何在更多的節(jié)點(diǎn)里面優(yōu)選出節(jié)點(diǎn)，進(jìn)行更好的服務(wù)則至關(guān)重要。

另外的挑戰(zhàn)來自于多業(yè)務(wù)混跑帶來快速迭代的需求，運(yùn)行的業(yè)務(wù)越多，系統(tǒng)更新也會越來越快，如何滿足系統(tǒng)的快速迭代以及緩解隨之而來的穩(wěn)定性沖擊，也是一個很大的挑戰(zhàn)。最后是標(biāo)準(zhǔn)化和智能化帶來的挑戰(zhàn)。

-03-

MediaUni技術(shù)剖析

下面簡要介紹MediaUni對不同場景的支持。

直播場景有幾個特點(diǎn)，一個是大規(guī)模會帶來高并發(fā)和成本敏感，另外一個是突發(fā)的直播事件。對此阿里云采取了以下措施：首先是混合組網(wǎng)。在3~10秒延遲的直播中采用樹狀組網(wǎng)，如果延遲需求達(dá)到400毫秒左右，將會采用對等組網(wǎng)。其次是熱流的秒級感知，當(dāng)一個流突然從冷流變成熱流時(shí)，將迅速動態(tài)擴(kuò)大服務(wù)資源。另外，目前行業(yè)內(nèi)直播業(yè)務(wù)仍以基于TCP的協(xié)議為主，我們對協(xié)議棧進(jìn)行了深度優(yōu)化，以達(dá)到更好的服務(wù)質(zhì)量。最后是質(zhì)量與成本可運(yùn)營，能夠根據(jù)業(yè)務(wù)的質(zhì)量、成本偏好進(jìn)行調(diào)節(jié)。

實(shí)時(shí)通訊場景有兩個特點(diǎn)，一個是低延時(shí)，一個是場景化。在低延時(shí)的實(shí)時(shí)通訊場景下，為了保障低延時(shí)，通常會采用各種QoS策略，但不同場景的QoS策略是千差萬別的。例如，視頻會議和普通的語音聊天傳輸，采用的QoS技術(shù)差別非常大，為此MediaUni采用動態(tài)組網(wǎng)、就近接入、可插拔QoS和秒級逃逸幾個技術(shù)來解決上述問題。

就近接入，意味著能夠快速感知用戶和節(jié)點(diǎn)之間的鏈路狀態(tài)，服務(wù)器可以很快做出一些QoS策略的調(diào)整。可插拔的QoS能夠幫助團(tuán)隊(duì)?wèi)?yīng)對各種不同場景化的QoS需求。阿里云的傳輸依靠大量邊緣節(jié)點(diǎn)，各個邊緣節(jié)點(diǎn)的可靠性不盡相同，所以需要對這些節(jié)點(diǎn)進(jìn)行更快速的感知，預(yù)防故障的發(fā)生以及服務(wù)質(zhì)量的下降。

云渲染場景伴隨超低延時(shí)和控制信令傳輸兩個特點(diǎn)。這里采用就近接入和就近異構(gòu)計(jì)算兩種方式，選擇距離用戶最近的計(jì)算節(jié)點(diǎn)和傳輸節(jié)點(diǎn)進(jìn)行接入，并采用異構(gòu)的計(jì)算方式服務(wù)用戶。

數(shù)據(jù)傳輸場景，通常延時(shí)低、可靠性高，而且數(shù)據(jù)傳輸量相對較少。通過協(xié)議復(fù)用與擴(kuò)展，支持?jǐn)?shù)據(jù)的傳輸，同時(shí)采用多徑和FEC技術(shù)，提升數(shù)據(jù)傳輸可靠性，減少重傳。

針對不可靠資源的高質(zhì)量是傳輸網(wǎng)絡(luò)面臨的巨大挑戰(zhàn)，也是關(guān)鍵技術(shù)。

傳輸網(wǎng)絡(luò)的不可靠主要來源于兩個方面，一是資源的不可靠：一方面邊緣節(jié)點(diǎn)的可用性不盡相同，另一方面大部分的傳輸都基于公網(wǎng)，而公網(wǎng)建立在IP之上，是一張盡力而為的網(wǎng)絡(luò)，經(jīng)常會遇到網(wǎng)絡(luò)抖動，如何去對抗網(wǎng)絡(luò)質(zhì)量的抖動也是一個很大的挑戰(zhàn)。

二是流媒體傳輸?shù)臉I(yè)務(wù)特點(diǎn)，包括長鏈接和熱點(diǎn)突發(fā)。為了保障低延遲，流媒體的傳輸通常采用長鏈接方式，需在建立連接時(shí)就分配系統(tǒng)資源，但視頻的特點(diǎn)是音視頻碼率會動態(tài)波動，例如世界杯，開始時(shí)視頻的碼率可能只有一兆，但是進(jìn)球時(shí)可能會波動到四兆、五兆甚至更高；另一方面，熱點(diǎn)事件突發(fā)時(shí)會對資源的需求迅速擴(kuò)大，這都意味著用戶業(yè)務(wù)對資源有很大彈性的要求。

針對上述問題，我們進(jìn)行了兩方面的優(yōu)化。一方面是弱網(wǎng)對抗。從生產(chǎn)端到傳輸端，再到播放端，會有很多的優(yōu)化策略，例如，在前處理時(shí)進(jìn)行降噪、通過阿里云窄帶高清技術(shù)降低碼率、支持多流、SVC等；傳輸側(cè)相應(yīng)的策略有動態(tài)路由、協(xié)議棧優(yōu)化、FEC、多徑等；播放側(cè)會有jitterbuffer、neteq、后處理等方式。

另一方面的優(yōu)化是感知與逃逸。因?yàn)闃?gòu)建在不可靠的資源上，所以非常需要實(shí)時(shí)感知資源的狀態(tài)以及業(yè)務(wù)的狀態(tài)，再通過智能的決策做秒級的逃逸。

在感知與逃逸的關(guān)鍵技術(shù)方面，以下分享一些細(xì)節(jié)。

我們設(shè)計(jì)了多維感知評分系統(tǒng)。通常的流媒體傳輸只感知服務(wù)節(jié)點(diǎn)的可用性，為了能夠支持多種業(yè)務(wù)，同時(shí)提供更好質(zhì)量，我們引入了評分的概念，對每一個節(jié)點(diǎn)進(jìn)行評分，同時(shí)也對節(jié)點(diǎn)之間的鏈路進(jìn)行評分。 評分來自于三個方面：首先是節(jié)點(diǎn)的日志，包括資源的信息、資源的水位和軟件運(yùn)行的狀態(tài)；其次是端邊探測系統(tǒng)，我們不能夠僅僅相信服務(wù)端的日志，因?yàn)榭赡艽嬖诜?wù)質(zhì)量或服務(wù)可用性問題，一些客戶沒有訪問到服務(wù)就失敗了，從而導(dǎo)致幸存者偏差，為此我們構(gòu)建了幾十萬的端設(shè)備，用于不斷探測系統(tǒng)，探測的結(jié)果也是評分的重要依據(jù)；最后，是業(yè)務(wù)層的一些質(zhì)量數(shù)據(jù)，比如卡頓率、首幀，以及拉流成功率這類核心的服務(wù)質(zhì)量指標(biāo)，也將作為評分的一大依據(jù)。

在多維感知系統(tǒng)得到這些評分之后，會輸出每個節(jié)點(diǎn)以及每條鏈路的評分，并根據(jù)評分結(jié)果，把相應(yīng)的信息傳輸?shù)街悄軟Q策系統(tǒng)。智能決策系統(tǒng)會依據(jù)業(yè)務(wù)類型、服務(wù)等級、資源的成本以及水位這三方面信息作出決策，包括節(jié)點(diǎn)的管控、用戶接入的調(diào)度、路由動態(tài)切換以及無損切換等。由于音視頻采用長鏈接，其可調(diào)度性較差，當(dāng)發(fā)生故障或感知到質(zhì)量下滑后，需要對原有的長鏈接進(jìn)行遷移，其中包括處理任務(wù)的無損遷移和傳輸鏈路上鏈接的無損遷移。

這里面有三個難點(diǎn)，一是感知的速度，我們采用了兩種手段，一方面做業(yè)務(wù)分級，對系統(tǒng)資源利用率非常大的數(shù)據(jù)，會使用高優(yōu)先級通道傳輸；另一方面進(jìn)行節(jié)點(diǎn)上的計(jì)算，將很多計(jì)算，包括評分，放在節(jié)點(diǎn)上完成，這樣傳輸?shù)臄?shù)據(jù)會大幅減少，從而提升傳輸速度。第二個難點(diǎn)是如何實(shí)現(xiàn)無損切換，要保證音視頻的無感切換需要進(jìn)行幀級別的續(xù)接，同時(shí)也要處理時(shí)間戳連續(xù)性、分布式系統(tǒng)調(diào)用異常等細(xì)節(jié)。第三個難點(diǎn)是如何做決策，因?yàn)閾碛写罅康男畔ⅲ煌臉I(yè)務(wù)對質(zhì)量的要求又不盡相同，如何進(jìn)行智能決策，同時(shí)又滿足成本的需求，就存在著很大的挑戰(zhàn)。

經(jīng)過技術(shù)上的迭代優(yōu)化，阿里云成功實(shí)現(xiàn)在節(jié)點(diǎn)故障時(shí)的秒級切換，并保障了在質(zhì)量惡化時(shí)的分鐘級逃逸。

另一個關(guān)鍵技術(shù)是協(xié)議棧的應(yīng)用層聯(lián)動，這里主要針對TCP場景。

TCP場景一直都有一個優(yōu)化手段叫做單邊加速，這是因?yàn)榉?wù)器的協(xié)議棧由自己控制，可以修改內(nèi)核進(jìn)行優(yōu)化，但是客戶側(cè)的TCP協(xié)議棧由客戶端操作系統(tǒng)提供，不能進(jìn)行修改，而最近幾年出現(xiàn)的Quic，可以在應(yīng)用層進(jìn)行擁塞控制以及協(xié)議棧優(yōu)化，但由于TCP仍然是流媒體傳輸?shù)闹饕獏f(xié)議，我們進(jìn)行了深度的優(yōu)化。傳統(tǒng)的單邊加速采用通用的加速方法，修改傳輸?shù)膿砣刂撇呗裕珎鬏攲优c應(yīng)用層相互獨(dú)立，4層的TCP協(xié)議不能感知到7層的應(yīng)用信息，同時(shí)7層也感知不到4層的網(wǎng)絡(luò)傳輸變化。產(chǎn)生這樣的問題，主要是因?yàn)?層在設(shè)計(jì)上是一個通用協(xié)議，不區(qū)分流媒體，也不區(qū)分文件。為此，我們將4層和7層的信息打通，實(shí)現(xiàn)4層和7層的聯(lián)動以及7層和4層的聯(lián)動。

右圖上面為流媒體傳輸引擎Tengine-Live，處于應(yīng)用層，能夠獲得相應(yīng)的業(yè)務(wù)信息、碼率信息，同時(shí)也會控制一些丟包的策略。在傳輸時(shí)可以通過4層的通道，把業(yè)務(wù)的偏好、帶寬的需求、碼率波動以及帶寬的大小，傳遞給操作系統(tǒng)，而操作系統(tǒng)則根據(jù)傳輸?shù)牟煌A段采取不同的應(yīng)對措施。

具體來說，操作系統(tǒng)可以根據(jù)應(yīng)用層的信息選擇擁塞控制算法類型，如我們自研的類Cubic算法和類BBR算法，也可以進(jìn)行子算法的選擇，同時(shí)，操作系統(tǒng)還可以根據(jù)應(yīng)用層傳入的具體信息對算法進(jìn)行微調(diào)，例如，可以根據(jù)碼率的大小選擇首窗窗口，可以根據(jù)播放的階段來均衡策略的激進(jìn)性，也可以對算法的參數(shù)進(jìn)行調(diào)節(jié)。

相應(yīng)的傳輸信息也會通過4層到7層的通道，把底層擁塞控制里面的實(shí)時(shí)帶寬、網(wǎng)絡(luò)擁塞狀態(tài)、網(wǎng)絡(luò)RTT丟包率等信息傳遞給應(yīng)用層，如果應(yīng)用層發(fā)現(xiàn)底層網(wǎng)絡(luò)已經(jīng)嚴(yán)重?fù)砣瑒t可以采取更激進(jìn)的丟包策略。

該技術(shù)上線以后，實(shí)現(xiàn)了播放首幀降低12.1毫秒、卡頓率降低32.5毫秒、拉流成功率提升0.101%的顯著效果。

全鏈路可編程，是為了應(yīng)對多鏈路混跑所帶來的挑戰(zhàn)，多業(yè)務(wù)混跑會使得需求爆炸性增長，需要一種盡量減少侵入的方式來滿足需求的快速迭代。

為此我們開發(fā)了全鏈路可編程系統(tǒng)，對流媒體傳輸和流媒體處理都進(jìn)行了可編程擴(kuò)展，把C代碼進(jìn)行原子能力的抽象，抽象到相應(yīng)Lua的API，通過調(diào)用這些API，可以組合出各種不同的業(yè)務(wù)能力，以滿足播放行為、時(shí)間戳、QoS算法迭代以及轉(zhuǎn)碼動態(tài)規(guī)則調(diào)整等需求。Lua代碼實(shí)現(xiàn)以后，會通過配置中心傳輸?shù)搅髅襟w的傳輸網(wǎng)絡(luò)和處理網(wǎng)絡(luò)，以滿足新功能或優(yōu)化快速迭代的需求。

這里有幾點(diǎn)需要注意：高性能，對于傳輸節(jié)點(diǎn)來說，Lua的性能非常重要，因?yàn)閭鬏敼?jié)點(diǎn)的吞吐量非常大，我們大量使用 Lua FFI 而非 Lua Cfunction，減少 Lua 棧數(shù)據(jù)交互操作，同時(shí)也對其中的熱點(diǎn)進(jìn)行性能優(yōu)化；安全性，需要嚴(yán)格控制Lua的可操作范圍，避免對系統(tǒng)造成影響；此外，靈活性是我們采用可編程的目的，實(shí)現(xiàn)中也考慮了動態(tài)下發(fā)，支持灰度、AB 實(shí)驗(yàn)、熱更新，可插拔等能力，以提高可編程的靈活性。

-04-

基于MediaUni的應(yīng)用落地

在卡塔爾世界杯期間，我們支持了超低延時(shí)的直播，將端到端直播延時(shí)降低到一秒以內(nèi)。此外，我們還帶來了更好的播放體驗(yàn)，卡頓率顯著下降，從3.19%降低至2.13%。

在一些云渲染的場景，通過就近傳輸和就近處理，我們實(shí)現(xiàn)端到端延時(shí)降低到58毫秒。目前，這項(xiàng)技術(shù)已經(jīng)應(yīng)用在央博的云廟會，以及去年雙11淘寶未來城中。

云上藝考則綜合使用了多項(xiàng)能力。在遠(yuǎn)程監(jiān)考場景，當(dāng)老師對一個學(xué)生感興趣時(shí)，可以單擊進(jìn)入電視直播模式，達(dá)到400毫秒延時(shí)的直播。如果老師有問題需要和學(xué)生進(jìn)行溝通，開啟連麥，也可以做到400毫秒之內(nèi)的通信。同時(shí)，媒體處理服務(wù)可以對這些流進(jìn)行實(shí)時(shí)的合流，形成一個老師面對多個學(xué)生的畫面。另外，基于數(shù)據(jù)傳輸?shù)哪芰Γ瑧?yīng)用層可以實(shí)現(xiàn)口播的功能，將數(shù)據(jù)通過網(wǎng)絡(luò)傳給學(xué)生，進(jìn)行考場規(guī)則的宣讀與顯示。

-05-

流媒體傳輸網(wǎng)絡(luò)的未來

流媒體傳輸網(wǎng)絡(luò)的未來主要有4個方向，分別是更低延時(shí)、更智能、更開放和算網(wǎng)融合。

隨著AIGC的發(fā)展，越來越多的視頻內(nèi)容，不再局限于拍攝產(chǎn)生，而可以通過AIGC來生成。當(dāng)如此多內(nèi)容通過AIGC的方式生產(chǎn)時(shí)，更低的延時(shí)毫無疑問會帶來更多的玩法。

無論是前面提到的調(diào)度系統(tǒng)，還是4層7層聯(lián)動的策略，都有很多的智能邏輯在里面。從更大的范圍講，傳輸系統(tǒng)內(nèi)部存在大量參數(shù)與邏輯組合，這些組合目前是經(jīng)驗(yàn)性的，或者是通過AB測試選擇出來的，但對這些參數(shù)與組合的衡量結(jié)果是確定的，通過衡量視頻核心的播放參數(shù)，可以構(gòu)成一個監(jiān)督學(xué)習(xí)系統(tǒng)。如何根據(jù)反饋，調(diào)整網(wǎng)絡(luò)里面復(fù)雜的參數(shù)，更智能無疑是更好的解決辦法。

在視頻領(lǐng)域，兩個最重要的方向就是視頻的處理和視頻的傳輸。視頻處理已擁有很多國際標(biāo)準(zhǔn)，例如H.265、H.266、AV1。但在視頻傳輸上，標(biāo)準(zhǔn)并沒有這么被廣泛定義或者使用，例如，音視頻底層的RTP這樣的傳輸協(xié)議標(biāo)準(zhǔn)，只規(guī)定了非常基礎(chǔ)的包格式，而在大部分偏向應(yīng)用的場景下，例如RTMP、HLS等標(biāo)準(zhǔn)都是由一些公司自己制定的，這些標(biāo)準(zhǔn)并沒有進(jìn)行很好的統(tǒng)一，隨著AIGC的到來，整條視頻鏈路的分工更加細(xì)化，行業(yè)需要更多的標(biāo)準(zhǔn)幫助不同工具、服務(wù)的提供方進(jìn)行數(shù)據(jù)交互。阿里云也在積極參與一些協(xié)議的標(biāo)準(zhǔn)化，促進(jìn)協(xié)議更加開放。

最后一點(diǎn)是算網(wǎng)融合，正如剛才所說，AIGC的出現(xiàn)，會讓更多的視頻通過計(jì)算的方式產(chǎn)生，這個時(shí)候就需要更多地把計(jì)算能力融合到網(wǎng)絡(luò)能力中，通過算網(wǎng)融合，綜合調(diào)度，進(jìn)一步降低整體的資源消耗，同時(shí)也帶給用戶更高質(zhì)量的服務(wù)。