本文根據楊寬（阿里巴巴淘系技術 音視頻技術專家）於 2021 年 6 月 26 日舉辦的 ECUG Meetup 第 1 期 | 2021 音視頻技術最佳實踐·杭州站上的分享整理而成。本文長達 5500 餘字，主要結構如下：
- 傳統直播技術痛點
- 低延遲架構演進
- 互動體驗升級
- 關鍵技術
獲取「講師完整版 PPT」 ，請添加 ECUG 小助手微信（微信ID：ECUGCON）並備註「ECUG PPT」。其餘講師的分享也將於後續陸續放出，敬請期待。
掃碼添加 ECUG 小助手
以下爲分享正文：
大家下午好！首先自我介紹一下，工作以來主要是在音視頻相關領域，安防監控，互動直播、CDN 等，目前在淘寶做直播低延遲架構和 QoS 相關工作。
一、傳統直播技術痛點
大家看，這是線上的一些直播場景。第一張圖主要是服飾的場景，下面有觀衆與主播的評論交互。在傳統直播的場景下，可能觀衆看的是 5-10 秒以後的畫面，當觀衆評論提問的時候，主播可能已經不介紹這款商品了，所以會有一個延遲的 Gap，交流就比較困難。第二個場景是珠寶的場景，介紹完鐲子以後可能會換下一款，但是觀衆可能看的還是上一款鐲子。第三個是寵物直播場景。
傳統直播的主要痛點有三個：
第一，延遲高，5-10 秒的延遲；
第二，主播和觀衆互動不及時；
第三，直播和連麥場景切換複雜。
二、低延遲架構演進
這是傳統的一個直播架構。中間是 CDN 的分發網絡，最左邊是自建的 SFU 和 MCU 集羣。最右邊是支持的一些系統，比如說日誌、監控、配置、調度，最下面的圖是推拉流的 SDK。最上面是一個直播中心，有截圖，轉碼，錄製，切片等服務。
傳統的直播分發網絡是一個樹狀的結構。因爲直播的量很大，樹型結構分發可以控制成本。上行協議主要是 RTMP/WebRTC/私有 RTC，推到自建集羣，然後通過 rtmp 推到 CDN。下行協議主要是 HTTP-FLV/RTMP/HLS。
這是我們和 CDN 共建做的低延遲直播架構的改造，改造的點主要是 CDN 和觀衆播放器之間採用了 RTC 相關的技術，把延遲從 7 秒降到 1.5 秒左右。在業務上不僅延遲降低了，方便觀衆和主播間的交流。而且在線上分行業AB顯示，在促進電商成交轉化方面也取得了不錯的效果。
這個架構大概是我們 2019 年開始和 CDN，視頻雲, 企業智能，XG 實驗室共建的架構，也是目前正在開始大規模使用的。可以看到，中間 CDN 框架那邊全部走的是 RTC 的鏈路，不再是樹型的結構，是去中心化的架構。L1 和 L1 之間可以互通。如果 L1 和 L1 之間的通信有問題，可以走 L2 中轉。MCU 合流服務可以像客戶端一樣直接連接到 RTC 的網絡上，把需要處理的流拉下來，處理完之後再重新推給 RTC 網絡。
主播通過 RTC 可以和網絡直接通信，如果需要它做一些實時流的處理的話，比如說加一些 AI 的特效，可以通過實時流處理，處理完之後直接推給 RTC 整個網絡。觀衆也是通過 RTC 鏈路直接和這張網交互。
整個全鏈路 RTC 架構有幾個比較好的點。它是一個直播、通話、連麥、會議共用的一張網。不同的業務高峯使用的時間段不一樣。比如說直播，一般晚上觀看的人數比較多。會議基本上是白天開會。這樣不同業務就可以錯峯地使用這張網。
因爲 CDN 一般是根據每天峯值帶寬來計費，這樣白天可以跑通話會議的業務，晚上會有一些直播的帶寬上來。通過錯峯，不同的業務錯峯來降低整體的成本。雙向實時通信這塊兒，因爲 RTC 既可以推流也可以拉流，在同一個鏈接裏可以走多路流，這是不限制的。比如說，推一路流，拉十路流，都是可以的。
三、互動體驗升級
基於直播場景的互動體檢，主要對兩大部分進行了升級。
第一點，提高互動效率。消費者通過直播間和直播交流的時候，原來老的系統觀衆看到的畫面是 5-10 秒前的畫面，所以主播和觀衆互動的時候時間點是對不上的。升級以後的延遲優化爲 1 秒左右，使消費者和主播互動更及時。
第二點，指標優化。從延遲上說，可以做到 1 秒以內，在通話會議場景可以做到 200 毫秒左右。秒開率相對於原有的傳統直播系統能提升 32%，卡頓率降低 79%，卡頓 vv 降低 44%。
這裏要講一下互動連麥直播原來的架構和目前架構的區別。
可以看到，原來的架構主播是通過 RTC 自建集羣來轉發 RTC 的流，保證低延遲，然後連麥。觀衆是通過 CDN 來拉流觀看，中間走的是 rtmp 鏈路。如果是主播和主播之間的連麥，基本上是主播自己拉到對方的流，然後合流推到 CDN，然後再分發給觀衆看，這樣的一個流程。如果是主播和觀衆連麥，觀衆本來是在 CDN 這條鏈路上。在傳統的鏈路上，中間有一個延遲差，這個延遲差大概是 6-7 秒左右。通過 RTC 發起連麥的時候，通過 RTC 來連到自建集羣，然後和主播互相通信的時候，畫面是有延遲差的，這樣體驗就非常不好，有一些等待切換的邏輯在裏面。
在新架構下，可以做到自建集羣和 CDN 是完全融合爲一體。也就是說，CDN 內部也是走的全鏈路 RTC，不管是主播和主播的通信，還是觀衆和主播的通信，完全走的是 RTC 的鏈路。RTC 鏈路可以通過一些傳輸優化保障，還有一些其他技術的優化，能夠保障它所有的體驗是統一的，比如說延遲、卡頓、流暢性等等。
下面是一個 MCU，就是合流服務器。如果主播或者說觀衆的設備是低端機的話，它的性能不太好，所以需要通過 MCU 來合流，這個合流服務器也是類似於客戶端的方式來接入這張網。然後通過把流拉下來，合完之後再推出去，因爲我們延遲優化的很低，基本上能做到無感的切換。
這個架構模糊了觀衆、主播以及其他一些服務的角色。作爲 RTC 的這張網來說，其實都是一個統一的接入者角色，既可以推流，也可以拉流。協議的話，都統一爲私有的 RTC 協議。我們 RTC 的私有協議可以做到一個 RTT 就可以快速地拉流建連。場景這塊兒，目前直播場景、連麥場景、會議場景以及通話場景，可以做到無縫切換。通過配置系統，針對不同的場景會啓用不同的策略。
還有一個好處是，從自建集羣加 CDN 統一爲了一個集羣，節省了自建集羣的成本。整體的延遲也是比較低的。業務融合網絡，剛纔介紹了一部分，不同的業務可以跑在同一張網上，因爲業務主要使用的時間段不一樣，我們可以通過錯峯使用來降低整體的帶寬成本。
四、關鍵技術
我們這邊和 CDN 是共建的關係。RTC Module 提供 RTC 相關的核心處理能力，以模塊化的方式嵌入到系統。
內部的模塊大概有以下這些：RTP/RTCP、BWE、QOS、PACE、PACKER、trickle/jitter、frame buffer、SRTP、setting 等等。BWE，主要是一些擁塞控制算法，QOS 這塊會有一些 QOS 的策略，像重傳，SVC，FEC 以及大小流相關的。trickle/jitter 主要作用是去抖和組幀。PACKER，有一些場景需要從視頻幀或者音頻幀打包成 RTP 格式。SRTP 主要是提供加解密的模塊。目前支持 grtn 私有協議和 webrtc 標準協議的交互。
在管理層，主要是有以下四種：
- 回調管理
- 訂閱管理
- session 管理
- 推拉流管理
回調管理在系統和 RTC 核心處理層之間，通過一些回調函數來處理它們之間的交互，做到這兩層之間的隔離。
基礎能力總結一下，主要是五點：
第一，多協議的框架。支持 webrtc、grtn 協議。通過 grtn 私有協議接入的話，可以保證整體接入效果。還有其他一些私有擴展功能，比 webrtc 標準的交互效率會高很多。rtmp 和 http-flv 在這塊兒上也是支持的。
第二，音視頻 Pub/Sub 原子能力，方便使用擴展。
第三，Data Channel 單獨 Pub/Sub 管理，業務靈活定製。Data Channel 目前主要應用在控制信令和一些雲遊戲的場景。比如說觀衆和主播會通過 Data Channel 通道發一些控制信令，控制一些攝像機的動作或者說遊戲里人物的控制。設計的時候也考慮了它的靈活性，也是提供單獨的 Pub/Sub 的能力，可以單獨使用。也就是說，如果在一個 URL 下只單獨做一個數據的通道，這也是沒問題的。Data Channel 通道的特點，我們會提供單獨的傳輸保障。延遲可以控制在全國範圍內大概 100-200 毫秒左右。如果是同一地域的話，基本上是一個 RTT。線上的話，平均大概的 RTT 是 20 毫秒左右。
還有一個運營場景是一些直播間的消息，如果通過傳統的消息系統基本上是秒級訂閱，或者是推拉的模式。我們現在可以做到百毫秒延遲以內。業務這塊可以靈活定製，比如說可以單獨掛消息通道的服務器，通過這個服務器各個端可以單獨訂閱這個消息通道。做一些業務的活動，還有一些實時消息的下發，可以做單獨的靈活定製。
第四，媒體和信令通道統一，可靠信令。信令我們會保證它的可靠到達。大家都知道，UDP 在公網上是很容易丟的，所以我們有一些保證它快速可達的策略，會有一些快速的重傳邏輯以及冗餘的邏輯。
第五，全網靈活切流能力，Url/Stream 級別。大家都知道，連麥的場景下，主播推直播間的流，他和別人連麥的時候，原來的方式是走 RTC 的自建集羣，RTC 自建集羣會處理切流的動作。因爲所有的主播流都會走自建集羣，他在切流的時候，因爲數據源可控，可以做到切流的時候不會影響後面所有的播放。在全鏈路 RTC 的時候，其實是一個分佈式的系統，主播和主播要連麥的時候，接入點不同，整體是分佈式的系統，切流能力就會保證他在切換過程中，能夠保證全網的觀衆在同一時刻切到合流的畫面。可以做到 Url 和 Stream 級別，也就是說不同的 Stream 也可以自由切換。
傳統的直播鏈路中間是走 TCP，因爲 TCP 在內核層，系統會提供一些策略，定製優化很難。我們現在用全鏈路 RTC，用的是 UDP，UDP 是不可靠的。全鏈路 QoS 策略這塊就顯得很重要。
音視頻系統有一個特點，從採集到前處理到編碼，到傳輸然後到解碼、渲染，其實是一個串行的過程，中間任何一個環節有問題都會影響整體的體驗。
指標的話，有成功率、卡頓率、秒開、延遲等等一系列指標。
場景有直播、連麥、通話、會議，會議也要做，去做直播電商內部多人的互動。我們做 QoS 要考慮多場景，要考慮 RTC 整體的傳輸鏈路，還有一些核心指標的優化。
目前用到的算法，主要是BBR 和 GCC 算法。這兩個算法最開始是從 WebRTC 模塊化拿來使用。後來我們幾乎重寫、重構了，提升了性能。並且針對直播的場景，深度定製優化。直播強調吞吐量，和會議場景的算法強調流暢還是有些區別的。
另外，我們會針對不同的算法，在不同的業務場景去做大規模的AB。根據數據系統蒐集上來的不同指標、延遲等，來動態調整它的參數，不斷優化改進。帶寬分配算法，比如說服務器有音頻 帶寬、重傳帶寬、視頻帶寬，還有 SVC 的一些分層帶寬，還有小流。這些帶寬怎麼分配，在什麼樣的場景下用什麼樣的策略，帶寬分配算法要解決這些問題。
策略控制這塊兒，主要有 FEC、ARQ、SVC 等等。RED 是爲了保證音頻的低延遲，JitterBuffer 也做了一些優化，Pacer 也針對直播大的吞吐量做了改進。比如說我們會做用多包發送的策略，以及中間鏈路的整體改進，還有 NetEq、延遲控制等等。
分階段延遲優化我大致說一下。
做延遲優化的話，如果只是一個簡單的場景，比如說一些數據量比較少的場景，這是比較簡單的，但是我們的用戶量，包括主播的用戶量、觀衆的用戶量，每天上億的觀看，如何保證全網平均延遲降下來，這個挑戰是很大的。
延遲這塊我們是這麼思考的：直播系統主要分爲推流端和播放器，中間走的是傳輸網絡，需要針對每個階段單獨優化。傳輸網絡部分，在網絡比較好的情況，延遲還是比較可控的，如果網絡不好，會啓用一些 QoS 的策略。採集、前處理、編碼，編碼這塊又分硬編、軟編，還有一些自研的編碼器。
發送緩存，也會動態的有一些策略。接收側的話，延遲比較大的主要是接收緩存，接收緩存這塊兒，如果和上行的網絡之間有丟包、抖動，接收緩存都會動態調整，把整個延遲加上去，爲了對抗前面的一些問題。解碼這塊，包括解碼速度、解碼緩存以及不同的解碼器，比如說硬解、軟解之類的。還有一些後處理，解碼數量後處理的一些算法處理延遲。最後是渲染的延遲。
不同的平臺是不一樣的，IOS、Android、PC。比如 IOS 平臺前處理、編碼是怎麼樣的，大致的延遲分佈是什麼樣的，都要有數據報表，在線上採集出來，去做針對性的優化。Android，PC 也是同樣的。
每個階段會有針對性的優化，比如說編碼這塊，我們會和算法團隊一起優化，也會分不同平臺進行編碼部分的處理。編碼這塊兒也會放在線上，根據數據埋點系統分不同的平臺，分不同的編碼器，不同的版本做展示。
第二點，中間鏈路部分，主要是應用一些 QoS 的策略。還有一些調度，調度是和 CDN 合作的。規劃出根據不同鏈路之間的網絡質量、成本，規劃出一條最短的傳輸路徑。是質量、成本的一個綜合策略。再加上 QoS 策略，保證傳輸的這塊的延遲。
第三點，用戶量比較大，會統計分析每一階段的大盤延遲分佈，每天都會不同的報表展示。
數據系統部分主要介紹四個：
第一，全鏈路跟蹤質量展示分析。根據這個系統可以跟蹤每一條鏈路中間經過的每一跳的服務器，它們之間的鏈路狀況是怎麼樣的，包括錯誤碼以及碼率，這是一個全鏈路的分析。從每個用戶到主播這條鏈路，根據唯一的一個 ID 就能查到這條鏈路上每一跳的質量，這樣就可以針對線上不同的問題進行詳細地分析。
第二，分段延遲分析展示。這個系統會根據不同的平臺、不同的主播、不同的階段，比如說編碼、解碼、緩存、渲染、傳輸等階段延遲的情況。
第三，配置 AB 系統。不管是端上的推流端還是播放器端，都有大量的配置，比如說一些時延性的算法，一些業務的策略，可以做到根據不同的業務進行分析，對比效果。舉個例子，要證明一下我們優化的延遲對電商成交有沒有正向效果。我們會選比如珠寶類的一些直播，還有一些衣服類的直播等等，根據不同的行業去做 AB，到底提升效果是怎麼樣的。
第四，RTC 質量大盤。針對不同的地域、不同的域名會有一個整體的質量展示。包括推流質量、拉流質量，以及一些中間鏈路的質量等等。
以上是我今天的分享內容，謝謝大家！
關於淘系技術
淘系技術部隸屬於阿里巴巴新零售技術事業羣，是阿里巴巴新零售技術的王牌軍，旗下包含淘寶技術、天貓技術、農村淘寶技術、閒魚、iHome等團隊和業務，支撐淘寶、天貓核心電商以及淘寶直播、閒魚、躺平、阿里汽車、阿里房產等創新業務，服務9億用戶，賦能各行業1000萬商家，是一支是具有商業和技術雙重基因的螺旋體。
我們致力於成爲全球最懂商業的技術創新團隊，打造消費者和商家一體化的新零售智能商業平臺，創新商業賽道，作爲核心技術團隊保障了11次雙十一購物狂歡節的成功。
隨着新零售業務的持續探索與快速發展，我們不斷吸引用戶增長、機器學習、視覺算法、音視頻通信、數字媒體、端側智能等領域全球頂尖專業人才加入，讓科技引領面向未來的商業創新和進步。
關於七牛雲、ECUG 和 ECUG Meetup
七牛雲：七牛雲成立於 2011 年，作爲國內知名的雲計算及數據服務提供商，七牛雲持續在海量文件存儲、CDN 內容分發、視頻點播、互動直播及大規模異構數據的智能分析與處理等領域的核心技術進行深度投入，致力於以數據科技全面驅動數字化未來，賦能各行各業全面進入數據時代。
ECUG：全稱爲 Effective Cloud User Group（實效雲計算用戶組），成立於 2007 年的 CN Erlounge II，由許式偉發起，是科技領域不可或缺的高端前沿團體。作爲行業技術進步的一扇窗口，ECUG 匯聚衆多技術人，關注當下熱點技術與尖端實踐，共同引領行業技術的變革。
ECUG Meetup ：ECUG、七牛雲聯合打造的技術分享系列活動，定位於開發者以及技術從業者的線下聚會，目標是爲開發者打造一個高質量的學習與社交平臺，期待每一位參會者之間知識的共創、共建和相互影響，產生新知推動認知發展以及技術進步，通過交流促進行業共同進步，爲開發者以及技術從業者打造更好的交流平臺與發展空間。