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

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

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

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

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

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

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

要解釋這個問題，必須重新回顧下常規的云游戲技術架構。下圖主要參考自英特爾音視頻白皮書、華為云游戲白皮書，并做了相應調整，基本與當前環境下，大部分云游戲架構的設計相符。

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

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

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

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

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

3D游戲渲染畫面

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

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

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

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

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

圖一：基礎設施層

圖二：基礎設施就緒后的工作負載

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

拆解軟硬一體的音視頻架構方案

基礎設施層

在基礎設施層，我們的首要關注對象就是硬件，尤其是對于音視頻服務來說，硬件提升對業務帶來的增益相當直接。

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

在 CPU 方面，英特爾已更新至強® 第三代可擴展處理器，相比第二代內存帶寬提升 1.60 倍，內存容量提升 2.66 倍，采用 PCIe Gen 4，PCI Express 通道數量至多增加 1.33 倍。其中，英特爾® 至強® Platinum 8380 處理器可以達到 8 通道、 40 個內核，主頻 2.30 GHz，英特爾支持冬奧會轉播 8k 轉播時，CPU 側的主要方案即是 Platinum 8380。

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

在視頻編解碼、 轉碼等流程中，因為應用程序需要執行大規模的整型和浮點計算，所以對 AVX-512 指令集的使用也相當關鍵。

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

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

當然，只有 GPU 硬件本身是不夠的，英特爾® Media SDK 幾乎是搭配 GPU 的必選項。英特爾® Media SDK 提供的是高性能軟件開發工具、庫和基礎設施，以便基于英特爾® 架構的硬件基礎設施上創建、開發、調試、測試和部署企業級媒體解決方案。

其構成可參考下圖：

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

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

工作負載層

從基礎設施過渡到工作負載，實際上有一張架構圖，更詳細的展示了相關技術棧的構成：

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

OneAPI 作為異構算力編程模型，是橋接基礎設施和上層負載的關鍵一層，這不必多言。而到了負載層，軟件則分成了藍色和紫色兩個色塊。藍色代表直接開源軟件，紫色則代表經過英特爾深度優化，再回饋(Upstream)給開源社區的開源軟件。

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

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

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

關于編解碼器的選型思考

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

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

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

更為人所熟知的可能是后來這個叫做 SVT-AV1 的開源項目，AV1 開源視頻編碼，由英特爾、谷歌、亞馬遜、思科、蘋果、微軟等共同研發，目的是提供相比 H.265 更高效的壓縮率，降低數據存儲和網絡傳輸的成本。

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

結束語

歸根結底，盡管“摩爾定律”還在繼續，但當下已過了靠吃“硬件紅利”就能搞定新應用場景的“甜蜜期”。

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

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

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

更多詳情可以前往英特爾官網獲取《英特爾互聯網行業音視頻創新實踐》白皮書!