摘要：如何保障實時音視訊服務體驗的實踐？我們為什麼需要一張媒體網路？我們如何改善實時音視訊體驗方面的實踐？
本文分享自華為雲社群《解密華為雲原生媒體網路如何保障實時音視訊服務質量》，原文作者：音視訊大管家。
大家好，我是來自華為雲的黃挺，目前負責華為雲視訊架構設計的相關工作。今天我會給大家分享華為雲原生媒體網路是如何保障實時音視訊服務體驗的實踐。
我會從以上幾個部分進行分享，首先，解釋一下我們為什麼需要一張媒體網路；其次，會介紹一下華為雲原生媒體網路的整體架構設計，最後，會分享我們在如何改善實時音視訊體驗方面的實踐。
01為什麼需要一張媒體網路
1.1 內容表達視訊化，各個行業都有視訊分發的需求
為什麼我們需要一張媒體網路呢？我主要總結了三大原因。第一個原因，我們看到內容表達視訊化是目前一個很明顯的趨勢，有很多行業都對視訊分發有非常旺盛的需求。舉一個我親身經歷的小例子，在今年過年的時候，我的家人想把手上帶了多年的戒指取下來，因為戴的時間比較久了，手指變粗了不少，取不下來。最開始我們第一反應是去商場找營業員幫忙取下來，後來我抱著試一試的心態，在抖音上搜尋“取戒指”三個字。在搜尋結果中找到了一個非常簡單的辦法，視訊時間不長，照著做很快就把戒指取下來了，而且對戒指沒有損害，手指也不痛。大家感興趣可以去搜尋看看。這其實就是知識內容表達視訊化的一個表現，這個趨勢在很多領域都已經出現了，除了短視訊，比如現在的電商直播，線上教育，雲遊戲等行業也都出現了內容表達視訊化發展趨勢。
1.2 新媒體表達形式出現，對音視訊技術要求越來越高
第二個原因，我們看到未來會出現很多新的媒體表達形式。比如VR和最近比較火熱的自由視角，這些新的表達形式的出現，都會給使用者帶來更加沉浸式的體驗。但它對音視訊技術的要求是全方位的提升，主要包括頻寬、時延、渲染複雜度等等。可以看到左邊這張圖，以VR為例，如果帶上VR頭盔去觀看視訊，要做到極致的視網膜體驗，需要的位元速率非常大，通過簡單的測算大概需要達到2Gbps的位元速率。而且影響VR體驗的因素相較於平面視訊也變得更多了：重新整理率、視場角、解析度、MTP低時延、姿態跟蹤、眼動跟蹤等等。
1.3 網際網路對使用者沒有承諾服務質量
我們一般會從需求側和供給側兩個維度來進行分析一個產品。前面兩個算是需求側的分析，接下來我們看一下供給側的分析。實時音視訊服務一個非常重要的供給側就是網際網路的基礎設施。我們都知道網際網路對使用者的服務質量基本上是沒有承諾的。怎麼理解呢？首先，建設網際網路的成本非常昂貴，比如，需要在海底拉光纜，這個鋪設成本是非常昂貴的，這裡包括人力的，物力的，另外一部分是無線頻譜的成本，比如3G、4G、5G的頻譜。所以網際網路的建設一定是需要考慮共享，共享就需要使用複用和交換技術。怎麼理解交換呢？看下下面這個簡單的示意圖。假設我們要建4個網路節點A、B、C、D；如果沒有交換，兩兩互聯需要6根線。但是如果使用了交換，則只需要4根線就可以了。所以從成本考慮，需要交換的技術；我們知道交換一般有兩類技術，一類是Circuit switching ，另一類是Packet switching，Circuit switching的特點是容量預留，但是資源存在浪費，因為一旦預留，就算沒有資料傳輸，頻寬資源也是被佔用。而Packet switching技術則是鏈路資源共享的，所以可以做到更低成本的交換。而當時網際網路設計考慮到成本的因素，選擇了Packet switching這個技術進行演進；因為選擇了Packet switching，再加上best effort盡力而為的轉發模式，所以帶來了一系列丟包、重複報文、時延、亂序等問題。所以我們總結，丟包、重複、時延、亂序是這一代網際網路的固有屬性。
這裡大家可以思考一個問題，為什麼網際網路在最開始設計的時候，並沒有考慮在網路層解決這個問題。或者換一個更大的問題，如果今天重新設計網際網路，我們會怎麼做？會不會嘗試讓網際網路去解決這些問題。第二個思考的問題就是，在大家的日常應用開發過程中是怎麼解決丟包、重複、時延、亂序的問題。
1.4 對我們的啟發
通過前面的分析帶給我們一些啟發，首先我們認為需要構建一張媒體網路，通過這張網路來彌補供給側和需求側之間的鴻溝，供給側就是網際網路的基礎設施，需求側就是飛速發展的音視訊業務。第二點：通過這張網路來滿足不同行業對音視訊分發的旺盛需求。第三點，通過這張網路來應對未來出現的新技術的挑戰。
02華為雲原生媒體網路架構介紹
前面解釋了為什麼我們需要一張媒體網路。接下來我會介紹一下華為雲原生媒體網路架構。
2.1 華為雲原生媒體網路
大家可以認為華為雲原生媒體網路是雲原生視訊服務的一個技術底座，基於這張雲原生的媒體網路會構建上面一系列從生產到處理到分發到播放的雲原生視訊服務，比如CDN、直播、RTC等等，通過這些雲原生的視訊服務來支撐上面千行百業的客戶。我們這張雲原生媒體網路主要包括7大特點：扁平化、Mesh化、智慧化、低時延、靈活性、多樣性和端邊雲協同。
2.2 廣覆蓋：支援多種接入方式，實現全球互聯互通
接下來我會介紹一下華為雲原生媒體網路，三個比較重要的架構設計目標。因為我們的服務物件遍佈全球，所以首先就要是一張全球部署的網路。這張網路主要解決三大問題：第一就是需要支援多種接入方式，其次是節點的互聯互通；第三是要考慮一個高可用設計冗餘覆蓋。
首先，因為我們是一個paas類服務，所以客戶很多，來自不同的行業，以雲會議為例，很多客戶對雲會議的安全性和質量要求非常高，所以他希望能夠從他的企業園區通過專線來接入這張網路。但有的客戶，希望他的使用者能夠隨時隨地的接入這張網路來分發業務，比如一些網際網路客戶，這個時候就需要支援網際網路的接入方式。另外，因為我們大量業務的流量在邊緣終結所以國內我們主要通過電信、聯通、移動單線接入，節省服務頻寬成本；國內通過三線機房或者BGP資源，解決跨運營商網路資源交換的問題；在海外，我們會優先選擇網路資源比較豐富的IXP節點接入；通過華為雲基礎網路設施或者優質的網際網路資源實現跨國的互聯。另外我們在部署規劃的時候就要考慮高可用設計，高可用設計常見的手段是增加冗餘，我們在規劃的時候考慮了站點冗餘和頻寬冗餘。我們會保證覆蓋區域使用者至少有3個站點可以提供對應質量要求的服務。另外，我們在做資源規劃的時候，會按照業務需要的頻寬的2倍以上進行規劃，應對部分突發。
2.3 全行業：滿足娛樂、通訊、行業視訊等不同業務要求
因為我們是一個Paas類服務，我們不能因為滿足了一類客戶的需求，就影響其他客戶的特性，而且要儘量快速的滿足不同客戶的需求。這對技術提出了3個方面的要求：首先因為需要滿足不同行業的不同業務需求，所以業務應用開發的敏捷性就非常重要，我們需要讓新功能能快速上線到全球任意邊緣節點，同時為了降低新特性上線的風險，我們需要支援新特性在不同edge的灰度上線。我們把這種開發方式叫做Living on the edge。
第二個技術要求，也是我們非常重要的設計原則——Edge Services是獨立自治的。Edge Services就是我們圍繞著媒體網路的網路節點，部署的一系列微服務，我們統稱為Edge Services。每個Edge Services都必須是獨立自治的，因為我們是一張分散式的媒體網路，肯定不希望某一個節點故障（比如網路故障），就會對我們造成全網業務的影響。所以每個Edge Services必須是獨立。什麼是自治呢？當邊緣和控制中心網路出現一些暫時的故障，那我的架構上一定要保證Edge Services內部能夠自治，也就是說它本地的服務還是可以提供的。我們可以看到左邊簡單列了四個微服務，其中區域性排程就是為了減少對全域性排程的依賴，當邊緣和控制中心網路出現一些暫時的故障，邊緣依舊可以提供服務。另外，我們在Edge Services內部的架構主要採用微服務進行劃分。它的核心目的是幫助我們能夠快速靈活的上線一些特性，例如我們在edge service內部有協議適配的微服務，這樣當我們需要支援新的終端，適配一些協議的時候，可以快速上線一個新協議的適配微服務，這樣可以快速上線，而且不會影響已經上線的終端的支援。
第三個技術要求是Overlay網路需要能夠靈活的定義它的路由。舉個例子，例如華為雲會議，它需要支援大量高規格的政府級會議，而這個對安全性和質量要求就非常高，我們需要讓進入我們媒體網路的這張會議的所有報文都走我們華為雲的骨幹網，避免使用網際網路資源傳輸。還有一些客戶對價格比較敏感，對於這類客戶我們就會盡量使用價效比較高的網路資源來轉發他的報文。這就需要有一個可程式設計的overlay網路實現靈活的網路路由和轉發。
2.4 全流程：提供媒體生產、處理、分發、播放全流程服務
第三個比較重要的設計目標是，我們的架構需要能夠提供端到端的，從生產到處理到分發到播放的全流程服務。我們把客戶主要分為兩類，一類是雲原生，很多網際網路客戶，在誕生之初，就是在雲上的，所以可以很方便的使用我們的雲上服務。但是有些客戶，需要從傳統的線下轉型到線上，為了服務於這樣的客戶，我們的生產和處理系統是基於華為統一的Huawei Cloud Stack統一技術棧，支援線上上線下靈活、快速部署，同時我們還提供了方便的SDK，它能夠跨終端、低功耗的來幫助客戶覆蓋更多的終端。最後一個技術要求是整個實時媒體處理流水線是能夠做到靈活編排，動態管理的。舉個例子，我們去年和鬥魚聯合創新的專案，幫助鬥魚把在端側的特效演算法上移到了Edge services。這樣直接給鬥魚帶來了三個好處，第一個好處是開發工作量變少了，原來的特效演算法需要適配不同的終端，不同的晶片。第二個好處是特效演算法的迭代速度變快了，只需要把特效演算法在Edge services更新部署，客戶就能夠體驗到。第三好處是覆蓋的終端機型變多了，因為傳統在端側去開發的特效，其實有很多低端機是沒法體驗到的，如果把它放在我們的Edge services上，就可以快速去滿足很多低端機型的要求。
2.5 架構分層設計：適應網際網路的特徵
最後分享一下我們一個非常重要的的架構分層的設計思想。我們借鑑了計算機網路系統的設計思想。可以想象一下，如果沒有現在這套計算機網路分層系統，我們的應用開發是怎樣的體驗。可能我需要去list整個網路拓撲的節點，需要去尋找最優的路徑，把我的訊息從a發到目的地b，在這個過程中還要去處理各種網路的異常，比如丟包、重傳、亂序等等，這顯然是對應用開發非常不友好的。
計算機網路系統設計就是解決這些問題。首先就是layering分層的思想，底層有鏈路層，遮蔽不同鏈路傳輸技術的差異性，比如我們支援5G之後上層的應用是不用修改的。在往上就是網路層，它主要有2大功能，轉發和路由，所以不需要每個應用自己去定義轉發路徑。在往上是End to End layer。這是對上面傳輸層、表達層。應用層的一個統稱。而分層的目的就是模組化，降低耦合度，每一層聚焦解決每一層的問題。
而我們雲原生媒體網路架構分層也是借鑑了這個思想，我們在網路層進行增強設計，改善報文轉發的時延和到達率。我們通過在End to End layer的自研實時傳輸協議來讓上層的實時音視訊應用開發更加簡單。這樣我們的應用開發就可以更加聚焦業務邏輯。同時我們抽象出媒體處理模組，這樣音視訊相關的編解碼技術，前後處理技術，就可以獨立演進，快速創新。
2.6 架構分層設計-Network Layer
在介紹我們在網路層和End to End layer的一些關鍵設計之前，首先來看一下網路層有什麼問題。網際網路在設計之初有一個非常重要的質量屬性，就是互聯互通的高可用性，我們知道網際網路是由上萬個ISP組成的，任何一個ISP故障，網路還是可以正常的通訊。其中BGP協議就是一個非常重要的設計，他主要考慮了聯通性，但是並沒有去做一些服務質量的感知。我們可以看到左邊這個圖，使用者A要發一個訊息給使用者B，跨運營商，它很有可能會經過網際網路穿越很多個不同的ISP，這就會帶來很多問題，比如會加重丟包重傳，而且這些關鍵問題很多是非技術因素，比如很多運營商針對某一個網路的網路策略不一定是質量最優，它可能是成本最優，比如有一些冷土豆或熱土豆的路由策略。
第二個原因，有可能運營商今天晚上要做一個裝置升級，需要運維人員操作一些配置變更，而配置變更過程中有可能出現人為出錯造成鏈路故障，還有可能就是這些區域有一個熱門事件，可能會造成擁塞。
為了解決這個問題，我們決定對網路層進行增強，這裡我們主要有2個技術手段；一個是underlay，一個是overlay。
1）首先是underlay，我們通過華為雲全球網路基礎設施，改善網路的接入和互聯質量，一旦進入我們的underlay網路就可以避免和網際網路其他流量競爭頻寬，既改善了質量，又保障了安全性。
2）其次是overlay部分，我們除了自建骨幹網，還會部署一些overlay的節點，實現基於不同Qos目標優化報文傳輸路徑和高效轉發，而不是讓報文任意轉發。我們在網路層的設計原則也是非常經典的控制面與資料面分離的設計思想，簡單來說，控制面負責路由，控制整個網路的執行，資料面負責轉發。
我們為了讓資料轉發能夠更加簡單，也採用了網路中非常經典的一個設計思想：源路由演算法的思想，核心目的也是為了降低轉發裝置的複雜度。具體來說，就是當一個報文進入我們網路的第一轉發節點的時候，系統就會把報文要經過的所有轉發節點資訊，包括目的節點都封裝在報文頭中，這樣每個轉發節點收到報文後，只需要解析報文頭，就知道下一跳要傳送到哪裡，這樣可以大大降低轉發裝置的複雜度。
另外還有1個非常重要的設計原則，就是我們對網路層不做可靠性承諾要求，雖然我們不保障可靠性，但是我們依舊會利用冗餘糾錯、多路徑傳輸等技術改善報文轉發的時延和到達率。這也是我們為什麼把這層叫做網路層的原因，他依舊關注的是路由和轉發。只是做了一些增強。
2.7 架構分層設計-End to End layer
網路層的增強能夠幫助我們去實現更低時延的轉發以及更高的到達率。再往上是我們的End to End layer，這裡大家可以先思考一個問題，前文提到網際網路有這麼多固有屬性，丟包，亂序，重傳，看上去對開發者非常不友好。但是網際網路的發展卻非常的繁榮，有一代代網際網路的應用email、web、IM、audio、video各類業務出現，這又是什麼原因？
這裡分享下我的思考，非常重要的一點就是協議，在End to End Layer出現了很多重要的協議，大大降低了我們應用開發者的技術的門檻，比如我們從TCP到HTTP到QUIC等，每一代的網際網路的應用發展背後都有一個協議的出現。End to End layer核心設計目標就是要定義一個好的協議和開發框架，讓應用開發變得簡單。
怎麼做到這一點呢？可以看到左邊這個圖，中間部分是我們的自研實時傳輸協議大致的功能圖，我們會在它的北向提供一個統一的介面。通過這一套北向介面可以讓我們既能夠開發實時音視訊業務，又能開發可靠的訊息類的業務，同時我們再看一下它的南向，通過協議棧遮蔽了底層使用UDP或是ADNP協議的差異性，這樣應用開發也會變得更加簡單。
協議棧設計的目的是為了讓應用開發變得簡單。所以我們還抽象了兩個模組，NQE和QOS，通過這兩個模組提供回撥的方法把網路的資訊能夠快速反饋給上層應用，比如編碼模組。編碼模組就可以快速的自適應網路的條件，來調整它的編碼引數。
另外一個非常重要的設計原則就是高效。因為我們知道，前面提到了在未來有很多的端是IoT端，IoT端有一個很大的特性，就是對功耗的要求非常高，我們希望在協議棧設計之初就要考慮這個問題。所以我們不希望輕易的在這一層去增加額外的一些沒必要的拷貝，這裡遵循的是ALF的設計原則，這個原則也是非常經典的。RTP當時設計的時候也是遵循了這個設計原則。
另外，我們的協議棧設計也參考了quic的設計思想。支援多路複用、網路多路徑、華為LinkTurbo、優先順序管理等功能。這裡分享一下我們的一個小經驗，就是在開發自由視角和VR這類業務，對頻寬的要求非常高，這個時候我們就會開啟多路徑的功能，可以獲得比較大的體驗上的改進。
2.8 華為雲原生媒體網路目標架構
最後我對整個媒體網路的目標架構做一個簡單的總結。
1）簡單來講就是把複雜問題簡單化，分而治之，通過分層的設計來讓每一層能夠相互解耦，快速演進；
2）每一個Edge services都是獨立自治的，來提高整個服務的可用性；
3）通過把Edge services按照微服務進行劃分，能夠讓到我們更加靈活的去適應客戶的需求，實現按照微服務級別的快速上線。
03實時音視訊服務質量保障實踐
第三部分我會分享一下我們在實時音視訊服務質量保障上的一些實踐，這裡主要是一些演算法設計上的思考，前文主要是架構上的一些思考。
3.1 視訊、音訊、網路是影響體驗的關鍵系統因素
如上圖所示，我們做了一個影響體驗的相關維度的分析。從客觀指標到主觀指標，再到QoE的關係做了一個簡單的對映圖。我們通過分析，發現影響實時音視訊服務體驗質量核心的三個系統性因素是視訊，音訊和網路，接下來我就分別針對這三部分的演算法實踐進行介紹。
3.2 視訊編碼技術
首先我們來看一下視訊編碼。我們把視訊編碼技術按照設計目標進行了一個簡單的分類，第一類，它的設計目標是如何科學的減少視訊編碼的冗餘，降低編碼失真對人眼主觀感受造成影響。因為我們的實時音視訊業務還是主要面向人的，所以有一些非常經典的優化思路，比如：從人出發，分析人眼的視覺特點，基於這些特點來優化編碼演算法，圖中簡單列了幾大類和編碼相關度比較高的人眼視覺特點。
還有一種優化思路，就是從源出發，也就是從內容出發，我們會分析不同場景內容的特點優化編碼演算法，比如計算機生成影像的特點有低噪、大平坦區域等等。
第二個設計目標是如何科學的增加冗餘來抵抗弱網傳輸對人員主觀感知的影響。這邊簡單列了幾類增加冗餘的編碼，比如極端的全I幀編碼、幀內重新整理的模式以及長期參考幀和SVC編碼。在一些空間視訊的業務裡面，我們為了改善在空間定位的時延，會使用一些全I幀編碼結合一些普通編碼來使用，減少空間定位的時延。我們在雲遊戲裡為了減少大I幀的突發，會採用幀內重新整理的編碼方式。在實時音視訊服務中，長期參考幀和SVC是比較常見的編碼方式。
3.3 PVC感知編碼
下面介紹一下我們具體的一些編碼技術。我們雲視訊團隊聯合華為2012中央媒體技術院，從分析人眼視覺系統出發，改進了PVC感知編碼演算法。我們的演算法經歷了幾輪迭代。最新的感知編碼2.0演算法實現了1Mbps位元速率提供了1080P 30幀高清畫質的體驗；演算法的主要改進思路是：首先通過預分析和編碼反饋資訊，對場景和區域進行區分，實時通話場景主要的高敏感區域包括：人臉區域和靜態區域。針對不同場景和區域，採用不同的編碼引數和位元速率分配策略，例如非高敏感區域分配較低的位元速率；2.0演算法在1.0的基礎上，我們在碼控方面加入了AI的技術，相較於之前，固定的位元速率和解析度組合，新的方法，我們基於AI的感知碼控，獲取不同場景下最優的位元速率和解析度組合，達到低頻寬下更優的主觀效果。
3.4 SCC編碼
第二編碼技術是SCC編碼，它主要應用於計算機生成影像的編碼，比如在教育或者會議裡的螢幕共享場景，我們的演算法相較於x265 ultrafast檔位，它編碼的壓縮效能提升了65%，在相同的計算資源的情況下，我們的編碼速度提升了50%。針對螢幕共享的場景，我們也解決了它特有的一些問題。在共享的時候，經常會共享一些圖文，比如word或者ppt。這一類相對是比較靜止的，這個時候編碼引數一般會採用低幀率，儘量保證它畫質的編碼方式，但很多時候共享圖文之後會切換到共享視訊。如果不能很好的去感知這一點，我們觀看視訊的體驗就是不連續的畫面，類似於gif。
為了解決這一問題，我們採用了基於視訊時空域的複雜度分析，來自適應視訊編碼幀率的辦法。這樣在靜態的圖文畫面下能夠有一個高品質的影像，切換到視訊共享時，也能夠保證流暢性。
我們解決的第二個問題是從YUV444下采樣到YUV420場景帶來的色彩度的失真問題，因為我們知道很多時候螢幕共享靜態的圖文，對色彩度的要求是比較高的。但是把它從YUV444下采樣到YUV420的時候，UV域的訊號會出現很大的衰減，左圖是沒有使用新演算法之前的效果，右圖是應用了新演算法之後的效果，明顯可以看到右圖字型會更加清晰，色彩度的失真會更加小，這裡的核心是使用了低複雜度色彩校正的演算法。
3.5 自適應長期參考幀編碼
前面兩個編碼技術是降冗餘，而自適應長期參考幀編碼技術是科學的提升冗餘。為了更好的理解，我們先把複雜問題簡單化，理解一下什麼是固定長期參考幀，我們看到左邊上面的圖，紅色的是I幀，綠色是長期參考幀，藍色是正常的P幀。通過這樣的一個參考幀的方式，打斷了原來正常的Ipppp前向參考的依賴關係，這樣當它的P2或者P3丟失的時候，後面P5的解碼是不會受影響的，還是可以繼續解碼，這就會改善它的流暢性。但是還是有不足的，比如這種綠色的長期參考幀P5丟失了，因為之後的P幀都依賴它，所以都無法解碼。第二個問題就是固定，因為長參考幀的關係，它會帶來一定的冗餘，就會導致相同頻寬下的質量會有所下降，所以我們希望在網路好的時候，能夠儘量讓冗餘變小一點，來改善畫質，所以我們就提出了自適應長期參考幀的辦法。
自適應長期參考幀的核心思路就是兩點，第一個是增加反饋機制，在解碼端增加一個反饋機制，告訴編碼端這個長期參考幀我收到了，編碼端知道這個幀收到之後，後面就參考這幀進行編碼。第二個是增加一個動態mark長期參考幀的機制，也就是我會根據網路的QOS情況去動態優化長期參考幀編碼的步長，在網路好的時候步長調短一點，網路差的時候調長一點。
但是在增加反饋機制之後會帶來一個問題，當在一些網路模型RTT比較長的時候，我的反饋週期會比較長。而且反饋報文還可能會丟失，需要再次反饋，這樣就會導致長期參考幀的步長變得非常長，一旦步長變長之後，它的編碼質量就會進行下降，甚至會下降到業務無法接受的地步，在我們優化演算法的時候也考慮到這一點，當長期參考幀的步長太長，我們會強制P幀去參考離它最近的長期參考幀，而不會完全去依靠反饋機制。這樣做會帶來兩個比較好的優化效果，一個是在突發丟包場景下它的畫面流暢性變好了，同時它有一個比較好的網路自適應的能力，能夠兼顧流暢性和畫質。
3.6 網路傳輸技術：求互動性與質量的最優解
前面是視訊編碼技術的一些分享，接下來看一下我們在網路傳輸上的實踐。我們對網路傳輸的定義，核心目標就是要求互動性和質量的最優解。我們知道網路傳輸技術，主要抵抗丟包，抵抗時延，抵抗抖動。常見的技術比如ARQ、FEC、不對等保護，還有抖動估計、快取伸縮等等，除了做到抗抖動抗丟包，還需要有擁塞控制，擁塞控制的核心目的就是讓 “傳送速率”儘可能去逼近“可用速率“，同時儘可能保持低延遲，如果傳送速率和網路可用頻寬不匹配，會造成丟包、抖動或者頻寬利用率低。還有一個非常重要的就是信源通道聯動，我們前面看到的動態長期參考幀就是通過通道的資訊動態調整編碼引數的一種實現方式，基於這個聯動，才能夠更好的去改善我們的體驗。
3.7 基於強化學習，提升頻寬預測精度，改進QoE體驗質量
無論是擁塞控制，還是信源通道聯動，在這個過程中頻寬預測的演算法都是非常重要的。傳統的做法是利用人工的經驗，通過一些決策樹演算法，針對不同網路模型下的頻寬做一些預測，但是在複雜場景下，這種做法的效果不是特別理想，所以我們希望通過強化學習的方式來改進這一點。
主要思路是基於接收端反饋的網路QoS，主要反饋四個資訊：接收速率、傳送速率、丟包率和時延抖動，基於這些資訊，通過強化學習的方法來提高頻寬的預測準確率。演算法優化後，我們的高清佔比得到了30%的提升，卡頓率下降了20%。
3.8 音訊3A技術：改善音訊清晰度
最後我會分享一下在音訊方面的技術實踐。好的3A演算法對於語音清晰度體驗至關重要。我們把AI技術應用到3A演算法中來改善語音的體驗。
首先，我們把AI應用在回聲消除上，回聲消除是整個3A裡非常重要的一個步驟。傳統演算法在穩態的環境下做的回聲消除，已經比較成熟，一般都處理的比較好，但是當環境出現一些變化，比如我拿著手機擴音打電話，在家裡，從房間走到陽臺，這個時候環境出現了變化，回聲消除就會遇到很多挑戰，通過AI的方式能夠比較好的處理這些問題。特別是針對雙講的場景，我們新的演算法很好的解決了漏回聲和丟字的問題。
其次就是降噪，傳統的噪聲，比如像風扇、空調這種穩態的噪聲，相對來說比較好抑制，而我們基於AI的降噪演算法不僅能較好的處理平穩噪聲，在應對例如鍵盤、滑鼠敲擊的聲音或者是喝水、咳嗽這種突發的噪聲的場景下，我們也可以快速的進行噪聲抑制。
另外一個3A中比較重要的環節就是自動增益，在通話場景下，自動增益主要是通過基於對人聲的識別來進行增益。這個時候，對人聲的檢測VAD是非常重要的，這一塊我們也是通過AI的技術來提升了人聲檢測的精確度，改善自動增益的效果。
3.9 音訊丟包恢復技術：降低丟包對音訊體驗的影響
另一個和視訊技術有些差異的是音訊的丟包恢復的技術，左邊這個圖也是一個比較經典的丟包恢復的技術地圖，它主要分為兩類，一類是基於主動的丟包恢復，一類是基於被動的丟包恢復。
主動丟包恢復技術主要包括常見的FEC、ARQ等。被動恢復主要有三種方法，插值法，插入法還有重新生成法。演算法優化思路和視訊一樣，都是從研究人出發，視訊是研究人眼到視覺特點，那麼音訊是研究人的發聲機制，基頻的資訊一定程度反映了聲帶的振動頻率情況。而包絡的資訊，則一定程度反映了嘴型的情況，基於這兩個資訊結合AI的聲碼器技術可以做到100毫秒左右的音訊報文丟失的恢復水平。我們知道一箇中文字的發聲一般是150毫秒到200毫秒，傳統的PLC基於訊號的恢復方式，一般可以做到50ms音訊訊號的恢復，現在我們基於AI的方式是可以做到100ms音訊訊號的恢復。
3.10 案例1：華為暢連，全球首款全場景音視訊通話產品
最後分享兩個案例。我們的產品不僅要服務外部客戶，也要對內支撐華為很多其他的產品服務。我一直開玩笑說，支援內部客戶其實是更難的，而且比支援內部客戶更難的是支援華為的內部客戶，他們的要求是非常高的，現在我們支援了華為手機的暢連服務，暢連是全球首款全場景（除了支援手機，還會支援華為的大屏、華為的平板、華為的筆記本、手錶、手環的通訊）的實時音視訊通話類產品，我們幫助暢連實現了在1Mbps位元速率條件下，提供高品質1080p30幀的通話效果。
3.11 案例2：網路研討會：會議+直播融合體驗，開大會更簡單
比支援一個華為內部客戶更難的是支援兩個。我們支援的第二個內部客戶就是華為雲會議，華為雲會議的網路研討會的場景也是基於我們的實時音視訊服務開發的，我們現在可以做到的單場網路研討會同時支援三千方的觀眾，其中有一百方是互動的，在今年下半年我們的雲會議產品會做到單場網路研討會同時支援一萬方的觀眾，五百方互動。
04總結
最後我對今天分享的內容做一個總結。首先，我們可以明顯的看到視訊業務正在驅動整個網際網路技術發展，包括音視訊編碼/傳輸技術，以及邊緣計算和邊緣網路等技術。所以我們需要一個服務或者系統來彌補網際網路基礎設施（供給側）和快速發展的視訊業務（需求側）之間的鴻溝。
第二點，今天的分享僅僅只是開始，隨著實時音視訊技術應用場景的增加，資料的驅動，會使得我們的雲原生媒體網路架構和各類演算法持續優化。
最後，希望華為雲原生視訊服務能夠和大家一起，攜手走進視訊“新時代”。
謝謝大家。