編者按：直播已深入每家每戶，以淘寶的直播為例，在粉絲與主播的連麥互動中如何實現無感合屏或切屏？LiveVideoStackCon 2022音視頻技術大會上海站邀請到了阿里雲GRTN核心網技術負責人肖凱，為我們分享GRTN核心網的運作機制、運用方面以及QOE的網絡模型在業務板塊的實踐優化。
文/肖凱
整理/LiveVideoStack
大家好，歡迎大家來到 LiveVideoStackCon 2022音視頻技術大會上海站，我是來自阿里雲的肖凱，現在負責阿里雲的GRTN的傳輸引擎的開發以及組網架構。今天講解主要分兩個版塊，一方面簡單介紹一下GRTN的理念和提供的能力。另一塊就是阿里雲的GRTN在接待客戶的過程中，是怎樣去優化QOE的指標。
今天的分享主要分為幾塊：GRTN簡介、阿里雲做QoE的優化經驗、賽馬系統、和阿里雲的一些可編程的能力。
1、GRTN簡介
GRTN實際上現在是一張全SFU的網絡，我是從 15年開始做直播這一塊，伴隨阿里雲直播系統一路做到現在的通信級的傳輸分發網絡。
現在的阿里雲的GRTN基於覆蓋全球的2800多個邊緣節點，我們把這些節點和網絡資源運用起來，做成了一張通信級的SFU的傳輸網絡。
這些節點，包括解決跨洲的網絡問題，都有專門的線路，整個系統都是從直播演進過來，過去很多的 CDN直播網絡一般都是樹狀的結構。但阿里雲的GRTN是一張樹狀和網狀結合的動態網絡，目前阿里雲GRTN支撐的屏到屏延遲是100毫秒左右，滿足雲遊戲或者雲渲染這樣的場景。
GRTN的能力很簡單，它提供的是內容的傳輸和分發。任何一個用戶使用RTP協議，把媒體推到阿里雲GRTN的節點，它就可以在全球的任何地方就近地從GRTN把內容拉出去，GRTN會解決動態組網、就近接入等問題。
2、GRTN當前業務模式
GRTN的當前的業務模式，目前很多客戶接的都是阿里雲的RTS 1.0，即在阿里雲官網能夠看到的RTS業務。
RTS 1.0是阿里雲從18年左右開始研發的，它的核心理念是為了幫助客戶在有限改造的前提下，接入GRTN，把延遲降下去。傳統的直播FLV延遲大概在5秒， HLS更多，延遲達到20s 左右。RTS就是對推流側或者播放側進行改造，最重要的還是播放側協議換成RTP，能夠做到延遲在1秒左右，這個技術在19年左右淘寶直播已經全量落地。
RTS 1.0結束之後，阿里雲就進入到了RTS 2.0的時代。RTS 2.0里，我們對實時流媒體這個場景的預期是沒有RTC和直播的區分，可以讓所有的業務都建立在全鏈路RTP的協議上。全鏈路使用通信級的傳輸，是GRTN的技術理念。目前的RTS 2.0，它是具有通信級的服務能力的。
RTS 2.0的傳輸延遲在國內基本是在100毫秒左右，即為節點的傳輸耗時，剩下的延遲就可以放在編碼側或者放在播放側，用來抗抖動。這樣的場景一般用在一對一的通視頻通信，或者多人會議，包括連麥直播一體化。
那在GRTN上怎麼把一對一通信做出來呢？
阿里雲GRTN的對外服務包括兩種模式，一種是阿里雲的SDK，通過使用GRTN的私有協議，另一方面，阿里雲也支持瀏覽器，GRTN的生態是完全開放。用戶可以使用瀏覽器，以標準的SDP信令交互的方式與GRTN的對接，把媒體推進來，再通過GRTN選擇性地把媒體拉出去。兩個客戶端跟GRTN可以選擇通過單PC或者多PC的模式交換音頻、視頻或自定義的消息，通過GRTN實現通信級的傳輸，這就是一對一通信。
這個模型並不僅限於通信，還包括雲渲染，雲遊戲的模型。
在一對一通信的基礎上，GRTN支持多人會議，如圖所示，這裡有4個參會方，這裡會講解多人會議在GRTN上需要怎樣的能力。
在參會人比較多的時候，通常而言選擇性的訂閱對端的視頻、音頻是一個很麻煩的問題，因為涉及到Audio Ranking。很多業務方為了做這種多人會議，不得不把音頻放到一個專門的Ranking Server上去做。GRTN提供了大規模的Audio Ranking能力，也就是說任何一個端在GRTN上消費音頻，都可以做到為它進行Audio Ranking。這個人訂閱了什麼，GRTN就在這個人訂閱的音頻中進行Audio Ranking，不涉及Ranking server, 不增加延遲。
GRTN的另一個重要能力是切流。GRTN可以為任何觀眾實現他的媒體的替換，在雲合流的連麥場景，這是一個很核心的能力，在一個瀏覽器上，觀眾通過GRTN在看一個人的畫面，然後通過切流的指令，就讓這個觀眾在完全無感的情況下實現畫面的切換。
這就是GRTN的切流能力，這個能力可以為GRTN上某一個主播的所有觀眾實現媒體畫面的實時切換，可以從a畫面切到b畫面，從a主播切到b主播，觀眾是完全無感的。
接下來我們看如何用切流能力實現雲端連麥合流？在連麥這個場景上，如果是客戶端的連麥，那就是ab兩個主播進行連麥，觀眾在看a主播的過程中他們一連麥，觀眾看的畫面就實時變成了a和b合屏的畫面。這種場景能夠簡單的實現，通過端合流，即a主播在端上直接把自己的畫面更改，觀眾看的內容相應進行變化。但是存在一些場景端合流是無法做到的，例如端的性能不夠，這樣場景下就需要通過雲合流。
如圖所示，一個主播流的畫面推送到GRTN之後，有一個觀眾在看主播的畫面，當這個主播和別的粉絲發生了連麥，連麥之後有一個業務方的合屏伺服器，合屏伺服器會把兩個媒體合成一個。在這個時候就需要實現客戶端的畫面切換，而且全部都要切過去，這個時候我們提供的能力是切流指令，即前面所講的切流的能力。切流指令傳輸到GRTN之後，GRTN將主播所有觀眾的畫面無感地切換成合屏流的畫面。
這個能力目前是實現淘寶直播在GRTN上直播連麥完全一體化的基礎解決方案。
這是一個通用的方案，在後面隨著GRTN和後續RTS 2.0服務的對外輸出，這個能力會直接對外開放。
在這裡和大家簡單介紹一下淘寶直播的情況，淘寶直播實際上已經實現全量在通過GRTN進行，任何一場直播里觀眾和主播之間的延遲基本上都在1秒以內的。這個目前是GRTN在 RTS 2.0上的一個典型的場景。
3、QOE概述及優化難點
QOE的一些優化實際上就是基於阿里雲的外部客戶的數據，為什麼講QOE而不是QOS？因為我們在接待客戶的過程中發現，QOE通常都是客戶本身制定的一系列的指標，比如說滲透率、觀播時長、業務轉換率，這些指標不是把QOS某個指標做好了，QOE就能變好。
例如GRTN在接客戶時，發現我們的首幀卡頓、百秒卡頓時長、延遲、畫質全方位的領先，RTS的QOS一定是全方位的比FLV要好，也就不用說比HLS了。但在面對不同的客戶的時候，有的客戶他說他的QOE正了，有的客戶說他的QOE有問題，因為在客戶從傳統的FLV過渡到RTS以及RTS 2.0之後，他們會因為客戶端的適配沒有做好，或者說業務場景的磨合沒有做好，遇到了一些問題。例如 WebRTC來進行通信，播放器的buffer的機制可以做得非常的激進，但是當在直播場景時，觀眾的體驗可能比你的激進的延遲控制更加重要，所以在直播場景下更多的是要去做一個平衡。
在這個過程中，我們發現有時候客戶把QOS全做正了，但是QOE卻還需要花很多的時間去處理，所以在把QOE做正的過程中，要用的什麼方法？
這是在QOE里阿里雲要持續投入的。想要做好QOE一定要有業務輸入，沒有業務的輸入，沒有業務的反饋，QOE肯定是做不正的，所以阿里雲有一個持續的基於業務的數據驅動技術投入這個板塊。
這裡最重要的一點就是客戶端的數據，在做QOE的過程中，我認為服務端是沒有資格說QOE的，只有客戶端和業務才有資格說自己的QOE這么正。所以在這個過程中，GRTN的方法是先得到業務方的脫敏數據，然後去做QOE（最後會有一個數據的展示）。
4、GRTN QOE 優化理念
GRTN優化QOE的一個理念是，GRTN做到了無感的鏈路切換。
GRTN內部是一個全SFU網絡，上游的網絡隨時切換，對觀眾來說是完全無感的。同時還有強實時的主備鏈路。在很多直播、通信場景下，會有重保的概念，或是強實時的雙路保障。如果節點之間出現問題，能夠立馬把它切到另外的節點鏈路上，這樣觀眾完全無感。
還有GRTN節點和客戶端之間的mobility的方案，例如某個節點可能網絡有問題，或者客戶端的網絡發生了WiFi到4G的切換，那麼使用一個mobility的方案瞬間能夠切換節點，同時GRTN的下游消費者完全不受影響。
GRTN另一個優化QOE的方法，就是可編程策略。可編程實際上是我們近一年做出來的一個成果。傳統的QOS優化能力，例如啟用BBR還是啟用GCC或者是別的擁塞控制算法，會發一堆的配置下去，配置裡面全是開關。但是現在GRTN，可以在邊緣直接用可編程的策略執行模塊，類似CDN有可編程的能力，包括邊緣腳本之類，GRTN也類似，但是做的比較徹底。現在的能力是可以在節點直接下發策略，運行語言，可以直接對發幀和發包邏輯做控制，可以介入到重傳邏輯中，直接編程GRTN的對每一個客戶端的行為，即通過策略配置系統直接把代碼發下來。無需軟體發版升級，因為像2800多個節點，是無法高頻升級軟體版本的，但是利用GRTN可編程能力可以實現一天幾個策略疊代，結合客戶端的數據，能夠實現數據的打通。這樣發策略下來，客戶端拿到QOE的數據反饋給GRTN，GRTN的調優人員就知道如何去進一步的優化。
如圖是GRTN的一個多場景的隨機配置，也是基於阿里雲線上海量的業務數據來進行的。例如阿里雲線上的配置管理系統會把配置集下發，這是做AB的基礎能力。後面配置管理系統會將n組配置實時發到全網所有的邊緣節點，針對的是某一個域名。針對這個域名，同時給他發出三組配置下去進行隨機，可能會配一定的權重。例如阿里雲認為conf_1 是個高風險的配置，一個高風險的新型的功能，發出去之後，把conf_1指配全網1%的業務量去做 AB。發到節點之後，當任何一個消費者來到GRTN消費內容時，將對它進行一個隨機加權的選擇，它有一定的概率使用conf_1，也有一定的概率使用後面兩種。
第一步的請求完成之後，我們讓多組配置同時在線上運行，但是運行完後怎麼拿到結果呢？
簡單的方法就是客戶記錄我們的trace_id，GRTN有一個trace_id的理念，這個ID對應客戶端的這一次播放，任何兩次播放的ID都不一樣。
另一種方法是客戶端把一個session ID帶在它的請求參數裡面，這樣一個客戶端就在GRTN有一個session ID跟trace_id對應，這次播放用的什麼conf ，我們也能夠給它記錄到。同時這次播放，根據session ID，我們就可以從客戶端的埋點查到它的QOE結果。
5、GRTN 賽馬系統
接下來對它做關聯，播放器在GRTN上完成播放之後，播放器這邊開始埋日誌，他們埋的核心日誌就包括首幀耗時、百秒渲染卡頓，也包括任何一個播放端的播放時長。在業務方記下來的日誌中，它知道這個session id對應的這一次播放播了多久，它的各項指標怎樣。在GRTN就知道發的trace_id是哪個，然後針對這一次播放，緩衝深度配了多少，以及丟包率目前統計下來是什麼情況。
這兩個數據（服務端日誌和客戶端日誌）把客戶的日誌收上來，拋送給我們之後，這邊就把session ID和trace_id在GRTN的數據分析體系裡面做一個綜合，就得到了一個結果：任何一次播放它對應的服務端的網絡情況是什麼，它對應的客戶端的首幀耗時、百秒渲染卡頓、播放時長是什麼。GRTN就通過這兩種數據綜合把客戶端的數據和服務端的一個行為做到了關聯。
關聯做到之後，下一步就做賽馬系統。在任何一次配置的時候，就像現在阿里雲給客戶做調優的時候，我們會事先跟客戶說一下要為你做調優。
例如說在這樣一次配置中，以客戶線上的業務為例，conf_1是一個高風險的功能，conf_2是對現有功能比如BBR的參數的調優，conf_3啟用的可能是GCC。把配置發到節點，客戶在進行播放之後，針對上兩步把他的客戶端和服務端的數據拿到之後，採集到GRTN這邊，數據上傳來之後，再對AB的結果做一個綜合的分析。這個時候在研發人員的眼裡就已經明確的知道下發的各組配置它的效果到底如何，區別是什麼。研發調優人員就能夠知道怎麼去做進一步的調優，同時反饋哪一組配置可以被淘汰，再基於好的配置對它進行進一步的調優。所以這也就是賽馬系統的價值——能夠基於客戶端的數據和服務端的數據進行綜合的持續的疊代。
如圖是賽馬系統，它作為一個整體，有GRTN的節點網，服務客戶端上報數據和GRTN的日誌系統打通，做到相互配合。
6、GRTN QOE 優化案例
這是GRTN的一個優化樣例，也就是賽馬系統的評分。當時我們做實驗有4組，normal就是平時日常運行常量的配置，radical就是一組非常激進的配置，reference就是用來跟radical進行對比的參照。如圖做了一個六維的展示，也按照我們的想法對它進行了綜合打分。
更詳細的結果是這個表，剛才提到的conf_id配下去之後，運行完之後，接下來得到成功率、秒開這樣的一些數據。這就是GRTN目前展示出來的賽馬系統能夠看到的數據。
成功率、秒開、都屬於QOS的範疇，最後的平均播放時長，是屬於QOE的範疇。我們測試下來得到的radical這一組的數據是最好的，它在播放時長上可能有1秒鐘左右的優勢，積累了24小時的數據，大概幾十萬的量級，我們認為這個量級的播放是可以用於支撐AB的數據。GRTN最開始在手淘場景做這個系統，手淘的業務量比較大的，所以我們從一開始拿手淘的線上的全部量級去運行。現在是直接可以拿外部客戶的數據去運行，做成賽馬系統，將阿里雲可編程的能力，客戶端的數據採集，包括賽馬，做成一個閉環。
現在優化的方法，想要優化某種策略，就發一組配置下去。例如發一組配置，運行一個晚高峰，到了第二天就能拿到數據結果，這樣的一個過程實際上對疊代的優勢是非常大的。
例如今年3月份左右，我們給某個客戶在調優播放時長的時候，通過分析客戶端的一些行為，包括通過測試對數據進行分析，發現客戶的音視頻同步可能有點問題。怎麼去解決這個問題呢？我們認為通過服務端的發幀策略的調整能夠幫助客戶端更好地實現音視頻同步。我們用可編程把這個策略做好發出去，在第二天這個效果是非常好的。我們發現發下去之後，這組配置的觀眾播放時長升高了，這其實就是QOE的一個優化。
在這個基礎上就完成了第一輪的疊代，我們認為這個路線是對的。接下來就是在這條路線上，怎麼把參數進一步的調優。在最開始對發幀的策略進行調整之後，我們只是做了一個粗調，覺得大概可以彌補客戶端的某些缺陷。實現了之後，接下來做進一步的不同的配置，不同的參數之間去做調優。
以上就是我的分享，謝謝大家。
▼識別二維碼或猛戳下圖訂閱課程▼
掃描圖中二維碼或點擊閱讀原文
了解大會更多信息