高并發(fā)音視頻架構(gòu)創(chuàng)新實踐

　　來源：info 作者：王一鵬

　　如果說，在以音視頻為載體傳輸信息、進行交互的技術(shù)領(lǐng)域，始終飄著一朵“烏云”，那么這朵“烏云”的名字，很可能既不是低延時，也不是高可靠，而是不斷變化的應(yīng)用場景。

　　從Web 2.0 到移動端基礎(chǔ)設(shè)施全面建成，我們完成了文字信息的全面數(shù)字化;而從 2016 “直播元年”至今，圖像、語音信息的全面數(shù)字化則仍在推進中。最簡單的例證是，對于早期的流媒體直播而言，1080P 是完全可接受的高清直播;但對于今天的流媒體而言，在冬奧會這樣的直播場景下，8k 可能是個剛性需求，相比于 1080P，像素數(shù)量增長 16 倍。

　　而且，今天的流媒體業(yè)務(wù)，對視頻流的要求不僅停留在分辨率上，也表現(xiàn)在幀率上。以阿里文娛 2019 年底推出的“幀享”解決方案為例，它將畫面幀率推至 120 FPS，同時對動態(tài)渲染的要求也很高。過往人們總說，幀率超過 24 FPS，人眼就無法識別，因此高幀率沒有實際意義。但高幀率是否能提升觀看效果，與每幀信息量密切相關(guān)，近幾年游戲開發(fā)技術(shù)的進步，以及以李安為代表的一眾電影導(dǎo)演，已經(jīng)徹底打破這一誤解。

　　對于 RTC 來說，問題情境和對應(yīng)的軟件架構(gòu)又截然不同。早期大家看賽事直播，20s 的延遲完全可以接受。但在 RTC 場景下，人與人的即時互動讓使用者對延遲的忍耐度急劇降低，從 WebRTC 方案到自研傳輸協(xié)議，相關(guān)嘗試從未停止。

　　當(dāng)我們以為，所謂的場景問題，終于可以被抽象為有限的幾個技術(shù)問題，并將延遲壓入 100ms 以內(nèi)，可靠性提升至 99.99%，新的場景又出現(xiàn)了。全景直播、VR 全球直播，云游戲……其中又以云游戲最為典型——云游戲簡直是過去那些音視頻場景性能要求的集大成者：有的游戲要求延時低至 50ms 以內(nèi);有的要求 FPS 60 以上;分辨率不消說，肯定是越高越好。同時云游戲場景夾雜著大量的動態(tài)渲染任務(wù)，無一不在消耗著服務(wù)器資源，增大著全鏈路的傳輸延時。

　　那么，如果從云游戲場景的性能要求出發(fā)，進而擴展至整個超視頻時代的架構(gòu)體系，該以怎樣的思路來進行架構(gòu)設(shè)計呢?只關(guān)注軟件，可能不太行的通;硬件成為必須納入考慮的一環(huán)。

　　以軟件為中心并非最佳選擇

　　要解釋這個問題，必須重新回顧下常規(guī)的云游戲技術(shù)架構(gòu)。下圖主要參考自英特爾音視頻白皮書、華為云游戲白皮書，并做了相應(yīng)調(diào)整，基本與當(dāng)前環(huán)境下，大部分云游戲架構(gòu)的設(shè)計相符。

　　在這一架構(gòu)內(nèi)，至云游戲終端前，所有服務(wù)都在云端、公共網(wǎng)絡(luò)上完成，保證用戶無需下載游戲或是為了玩游戲購置高性能終端。游戲玩家的終端，主要負(fù)責(zé)對網(wǎng)絡(luò)包進行處理、對渲染后的游戲畫面進行解碼、顯示，并相應(yīng)地輸入指令，回傳給服務(wù)器。

　　而在服務(wù)器端，鏈路相對復(fù)雜。云游戲管理平臺是服務(wù)的起點，上下兩條鏈路，都是云游戲的周邊技術(shù)服務(wù)，與業(yè)務(wù)場景強相關(guān)，包括云游戲的直播錄制、游戲日志 / 記錄存儲等。前者對時延忍耐度較高，可以走正常的流媒體服務(wù)體系，使用 CDN 分發(fā)音視頻內(nèi)容;后者屬于正常的游戲服務(wù)器設(shè)計范疇，正常提供服務(wù)即可。

　　關(guān)鍵在于中間一層，也就是云游戲容器集群。這一部分要實現(xiàn)的設(shè)計基礎(chǔ)目標(biāo)是保障 1s 至少完成 24 張游戲畫面(24 幀)的計算、動態(tài)渲染和編碼傳輸，部分高要求場景需要幀率達到 60 FPS，同時保證時延盡可能得低。

　　這部分的技術(shù)挑戰(zhàn)非常大，以至于若僅以軟件為中心思考，很難做出真正突破。從相關(guān)指標(biāo)的演進歷史來看，僅僅在 4 年前，移動端游戲本地渲染的基礎(chǔ)目標(biāo)還是 30 FPS，如今雖然能實現(xiàn) 60 FPS 甚至更高，但討論的場景也從本地渲染切換成了云端渲染。在軟件上，除非出現(xiàn)學(xué)術(shù)層面的突破，否則很難保證性能始終保持這樣跨度的飛躍。

　　此外，渲染本來就是嚴(yán)重倚仗硬件的工作，渲染速度和質(zhì)量的提升，主要依賴于 GPU 工藝、性能以及配套軟件的提升。

　　3D游戲渲染畫面

　　而更為復(fù)雜的游戲性能以及整體時延的控制，則對整個處理、傳輸鏈路提出了要求。僅以時延為例，它要求在編碼、計算、渲染、傳輸?shù)热魏我粋�環(huán)節(jié)的處理時間都控制在較低范圍內(nèi)。同樣是在 3 - 4 年前，有業(yè)界專家分享，他們對 RPG 類云游戲的傳輸時延容忍度是 1000 ms，但事實證明，玩家并不能忍受長達 1s 的輸入延遲。反觀今日，無論是通過公有云 + GA 方案，還是通過自建實時傳輸網(wǎng)絡(luò)方案，即便是傳輸普通音視頻流的 RTC 服務(wù)也只能保證延時 100ms 以內(nèi)，而云游戲的計算量和帶寬需求數(shù)倍于普通音視頻服務(wù)。

　　以上僅僅是冰山一角。對于架構(gòu)設(shè)計而言，除了高性能、高可用、可擴展性三類設(shè)計目標(biāo)外，成本也是必須要考慮的平衡點——需要 1000 臺服務(wù)器的架構(gòu)，和需要 100 臺服務(wù)器的架構(gòu)，壓根不是一個概念。2010 年前后，云游戲基本不存在 C 端商業(yè)化可能，雖然整體時延和性能指標(biāo)可以滿足當(dāng)時的要求，但代價是一臺服務(wù)器只能服務(wù)一個玩家，單個玩家服務(wù)成本上萬。云游戲“元老” Onlive 公司的失敗，在當(dāng)時非常能說明問題。

　　而到了 2020 年，行業(yè)硬件的整體性能提升后，一臺服務(wù)器可支持 20 - 50 路并發(fā)，性能提升了幾十倍。

　　那么，如果我們將硬件變成架構(gòu)設(shè)計的核心考慮要素，會是什么樣的呢?大致如下圖所示(為了不讓圖示過于復(fù)雜，我們只保留了云游戲核心服務(wù)鏈路，以作代表)。

　　可以看到，僅在云服務(wù)器部分，就有大量的硬件和配套軟件需要參與進來，要關(guān)注的性能點也相對復(fù)雜。而這僅僅是云游戲一個應(yīng)用場景下的音視頻架構(gòu)，當(dāng)我們將場景抽象并擴展，最終覆蓋到整個超視頻時代的時候，以下這張來自英特爾技術(shù)團隊的架構(gòu)圖，可能更加符合實際。英特爾將音視頻體系架構(gòu)在軟件和硬件層面分別進行了展示：一部分叫做 Infrastructure(基礎(chǔ)設(shè)施層)，如圖一所示;另一部分則稱其為 Infrastructure Readiness (基礎(chǔ)設(shè)施就緒)，指的是基礎(chǔ)設(shè)施就緒后，建立在其上的工作負(fù)載，如圖二所示。兩張圖的首尾有一定重合，表示其頭尾相接。

　　圖一：基礎(chǔ)設(shè)施層

　　圖二：基礎(chǔ)設(shè)施就緒后的工作負(fù)載

　　可以看到，基礎(chǔ)設(shè)施層主要包括硬件、配套云服務(wù)、云原生中間件以及各類開源基礎(chǔ)軟件。而在工作負(fù)載層面，是大量的軟件工作，包括核心的框架、SDK 以及開源軟件貢獻(UpStream)。這也是為什么英特爾以硬件聞名，卻維持著超過一萬人的軟件研發(fā)團隊。

　　拆解軟硬一體的音視頻架構(gòu)方案

　　基礎(chǔ)設(shè)施層

　　在基礎(chǔ)設(shè)施層，我們的首要關(guān)注對象就是硬件，尤其是對于音視頻服務(wù)來說，硬件提升對業(yè)務(wù)帶來的增益相當(dāng)直接。

　　但相比于十年前，當(dāng)前的硬件產(chǎn)品家族的復(fù)雜度和豐富度都直線上升，其核心原因無外乎多變的場景帶來了新的計算需求，靠 CPU 吃遍天下的日子已經(jīng)一去不復(fù)返了。以前面展示的英特爾硬件矩陣為例，在音視頻場景下，我們主要關(guān)注 CPU、GPU、IPU，受限于文章篇幅，網(wǎng)卡一類的其他硬件不在重點討論范圍內(nèi)。

　　在 CPU 方面，英特爾已更新至強® 第三代可擴展處理器，相比第二代內(nèi)存帶寬提升 1.60 倍，內(nèi)存容量提升 2.66 倍，采用 PCIe Gen 4，PCI Express 通道數(shù)量至多增加 1.33 倍。其中，英特爾® 至強® Platinum 8380 處理器可以達到 8 通道、 40 個內(nèi)核，主頻 2.30 GHz，英特爾支持冬奧會轉(zhuǎn)播 8k 轉(zhuǎn)播時，CPU 側(cè)的主要方案即是 Platinum 8380。這里貼一張詳細參數(shù)列表供你參考(https://www.intel.cn/content/www/cn/zh/products/sku/212287/intel-xeon-platinum-8380-processor-60m-cache-2-30-ghz/specifications.html)：

　　英特爾 CPU 另外一個值得關(guān)注的特點，在于其配套軟件層面，主要是 AVX-512 指令集。AVX-512 指令集發(fā)布于 2013 年，屬于擴展指令集。老的指令集只支持一條指令操作一個數(shù)據(jù)，但隨著場景需求的變化，單指令多數(shù)據(jù)操作成為必選項，AVX 系列逐漸成為主流。目前，AVX-512 指令集的主要使用意義在于使程序可同時執(zhí)行 32 次雙精度、64 次單精度浮點運算，或操作八個 64 位和十六個 32 位整數(shù)。理論上可以使浮點性能翻倍，整數(shù)計算性能增加約 33%，且目前只在 Skylake、 Ice Lake 等三代 CPU 上提供支持，因此也較為獨特。

　　在視頻編解碼、 轉(zhuǎn)碼等流程中，因為應(yīng)用程序需要執(zhí)行大規(guī)模的整型和浮點計算，所以對 AVX-512 指令集的使用也相當(dāng)關(guān)鍵。

　　而 GPU 方案在云游戲場景中，通常更加引人矚目，英特爾® 服務(wù)器 GPU 是基于英特爾 Xe 架構(gòu)的數(shù)據(jù)中心的第一款獨立顯卡處理單元。英特爾® 服務(wù)器 GPU 基于 23W 獨立片上系統(tǒng)(SoC)設(shè)計，有 96 個獨立執(zhí)行單元、128 位寬流水線、8G 低功耗內(nèi)存。

　　所謂片上系統(tǒng) SoC，英文全稱是 System on Chip，也就是系統(tǒng)級芯片，SoC 包括但不僅限于 CPU、GPU。就在今年，前 Mac 系統(tǒng)架構(gòu)團隊負(fù)責(zé)人、蘋果 M1 芯片的“功臣” Jeff Wilcox 宣布離開蘋果，擔(dān)任英特爾院士(Intel Fellow)、設(shè)計工程事業(yè)群(Design Engineering Group)CTO，并負(fù)責(zé)客戶端 SoC 架構(gòu)設(shè)計，也在行業(yè)內(nèi)引起了眾多關(guān)注。

　　當(dāng)然，只有 GPU 硬件本身是不夠的，英特爾® Media SDK 幾乎是搭配 GPU 的必選項。英特爾® Media SDK 提供的是高性能軟件開發(fā)工具、庫和基礎(chǔ)設(shè)施，以便基于英特爾® 架構(gòu)的硬件基礎(chǔ)設(shè)施上創(chuàng)建、開發(fā)、調(diào)試、測試和部署企業(yè)級媒體解決方案。

　　其構(gòu)成可參考下圖：

　　IPU 是為了分擔(dān) CPU 工作負(fù)載而誕生的專用芯片，2021 年 6 月，英特爾數(shù)據(jù)平臺事業(yè)部首席技術(shù)官 Guido Appenzeller 表示：“IPU 是一種全新的技術(shù)類別，是英特爾云戰(zhàn)略的重要支柱之一。它擴展了我們的智能網(wǎng)卡功能，旨在應(yīng)對當(dāng)下復(fù)雜的數(shù)據(jù)中心，并提升效率。”

　　具體落地在音視頻場景里，IPU 要負(fù)責(zé)處理編碼后的音視頻流的傳輸，從而解放 CPU 去更多關(guān)注業(yè)務(wù)邏輯。所以，CPU + GPU + IPU 的組合，不僅是在關(guān)注不同場景下的需求滿足問題，實際上也在關(guān)注架構(gòu)成本問題。

　　工作負(fù)載層

　　從基礎(chǔ)設(shè)施過渡到工作負(fù)載，實際上有一張架構(gòu)圖，更詳細的展示了相關(guān)技術(shù)棧的構(gòu)成：

　　在這張架構(gòu)圖中，橫向是從源碼流輸入到分發(fā)的整個流程，期間包含了編碼、分析等處理動作;而縱向則展示了要服務(wù)于這條音視頻處理流程，需要搭配的硬件和軟件體系。

　　OneAPI 作為異構(gòu)算力編程模型，是橋接基礎(chǔ)設(shè)施和上層負(fù)載的關(guān)鍵一層，這不必多言。而到了負(fù)載層，軟件則分成了藍色和紫色兩個色塊。藍色代表直接開源軟件，紫色則代表經(jīng)過英特爾深度優(yōu)化，再回饋(Upstream)給開源社區(qū)的開源軟件。

　　在藍色部分，OpenVino 是個很有意思的工具套件，它圍繞深度學(xué)習(xí)推理做了大量的性能優(yōu)化，并且可以兼容 TensorFlow、Caffe、MXNet 和 Kaldi 等深度學(xué)習(xí)模型訓(xùn)練框架。當(dāng)音視頻體系需要加入 AI 技術(shù)棧以服務(wù)超分辨率等關(guān)鍵需求時，OpenVino 會起到關(guān)鍵作用。

　　紫色部分的 x.264/x.265 是一個典型。作為音視頻行業(yè)最主流的編碼標(biāo)準(zhǔn)，英特爾使其開源的主要貢獻者，而且 AVX-512 指令集也專門圍繞 x.264/x.265 做了優(yōu)化和性能測試。

　　另一個值得關(guān)注的核心是編碼器，它橫跨了藍色區(qū)域和紫色區(qū)域，既有行業(yè)通用的 ffmpeg，也有英特爾自研的 SVT，二者同樣引人關(guān)注。

　　關(guān)于編解碼器的選型思考

　　在流媒體時代，著名開源多媒體框架 ffmpeg 是業(yè)界在做編解碼處理時，絕對的參考對象。說白了，很多編解碼器就是 ffmpeg 的深度定制版本。到了 RTC 時代，出于更加嚴(yán)苛的及時交互需求，自研編解碼器盡管難度頗高，但也在研發(fā)能力過硬的企業(yè)中形成了不小的趨勢。

　　可歸根結(jié)底，在推進以上工作時，軟件始終是思考的出發(fā)點，從業(yè)者們多少有些忽略對硬件的適配。

　　SVT 的全稱是 Scalable Video Technology ，是開源項目 Open Visual Cloud 的重要組成部分，針對英特爾多個 CPU 進行了高度優(yōu)化，因此在英特爾硬件體系上，性能表現(xiàn)非常突出。SVT 設(shè)計最樸素的初衷，是針對現(xiàn)代 CPU 的多個核進行利用率方面的提升，比如依仗硬件上的多核設(shè)計并行對多個幀同時處理，或?qū)σ粡垐D像分塊進而并行處理，大大加快處理速度，避免多核 CPU 空轉(zhuǎn)。

　　更為人所熟知的可能是后來這個叫做 SVT-AV1 的開源項目(GitHub 地址：https://github.com/AOMediaCodec/SVT-AV1)，AV1 開源視頻編碼，由英特爾、谷歌、亞馬遜、思科、蘋果、微軟等共同研發(fā)，目的是提供相比 H.265 更高效的壓縮率，降低數(shù)據(jù)存儲和網(wǎng)絡(luò)傳輸?shù)某杀尽?/p>

　　而就在今年上半年，英特爾發(fā)布了其用于 CPU 的開源編解碼器 SVT-AV1 的 1.0 版，相比 0.8 版本，性能上有著巨大提升。

　　結(jié)束語

　　歸根結(jié)底，盡管“摩爾定律”還在繼續(xù)，但當(dāng)下已過了靠吃“硬件紅利”就能搞定新應(yīng)用場景的“甜蜜期”。

　　今天，我們需要了解的是以 CPU 、GPU、加速器和 FPGA 等硬件為核心的復(fù)合架構(gòu)，也被稱之為由標(biāo)量、矢量、矩陣、空間組成的 SVMS 架構(gòu)。這一概念由英特爾率先提出，并迅速成為業(yè)內(nèi)最主要的硬件架構(gòu)策略。

　　位于硬件之上的開發(fā)者工具也存在同樣的趨勢，英特爾的 oneAPI 就是一個典型作品。只是對于開發(fā)者工具來說，目前最主要的工作不是性能提升，而是生態(tài)和整合。

　　從硬件到基礎(chǔ)軟件，再到開發(fā)者工具，整個基礎(chǔ)設(shè)施層呈現(xiàn)高度復(fù)雜化的架構(gòu)演進趨勢，既是對架構(gòu)師工作的嚴(yán)峻挑戰(zhàn)，也給了所有架構(gòu)師更大的發(fā)揮空間。對于架構(gòu)師來說，如何為自己的企業(yè)算清楚成本，在追求高性能、高可用的同時，將硬件一并納入考慮并高度重視，才是重中之重。

　　更多詳情可以前往英特爾官網(wǎng)獲取《英特爾互聯(lián)網(wǎng)行業(yè)音視頻創(chuàng)新實踐》白皮書!

　　*圖片由info提供授權(quán)支持