域名預(yù)訂/競(jìng)價(jià)，好“米”不錯(cuò)過(guò)

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

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

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

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

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

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

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

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

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

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

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

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

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

3D游戲渲染畫面

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

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

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

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

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

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

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

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

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

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

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

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

在 CPU 方面，英特爾已更新至強(qiáng)® 第三代可擴(kuò)展處理器，相比第二代內(nèi)存帶寬提升 1.60 倍，內(nèi)存容量提升 2.66 倍，采用 PCIe Gen 4，PCI Express 通道數(shù)量至多增加 1.33 倍。其中，英特爾® 至強(qiáng)® Platinum 8380 處理器可以達(dá)到 8 通道、 40 個(gè)內(nèi)核，主頻 2.30 GHz，英特爾支持冬奧會(huì)轉(zhuǎn)播 8k 轉(zhuǎn)播時(shí)，CPU 側(cè)的主要方案即是 Platinum 8380。這里貼一張?jiān)敿?xì)參數(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 另外一個(gè)值得關(guān)注的特點(diǎn)，在于其配套軟件層面，主要是 AVX-512 指令集。AVX-512 指令集發(fā)布于 2013 年，屬于擴(kuò)展指令集。老的指令集只支持一條指令操作一個(gè)數(shù)據(jù)，但隨著場(chǎng)景需求的變化，單指令多數(shù)據(jù)操作成為必選項(xiàng)，AVX 系列逐漸成為主流。目前，AVX-512 指令集的主要使用意義在于使程序可同時(shí)執(zhí)行 32 次雙精度、64 次單精度浮點(diǎn)運(yùn)算，或操作八個(gè) 64 位和十六個(gè) 32 位整數(shù)。理論上可以使浮點(diǎn)性能翻倍，整數(shù)計(jì)算性能增加約 33%，且目前只在 Skylake、 Ice Lake 等三代 CPU 上提供支持，因此也較為獨(dú)特。

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

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

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

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

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

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

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

工作負(fù)載層

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

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

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

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

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

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

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

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

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

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

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

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

結(jié)束語(yǔ)

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

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

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

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

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

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

申請(qǐng)創(chuàng)業(yè)報(bào)道，分享創(chuàng)業(yè)好點(diǎn)子。點(diǎn)擊此處，共同探討創(chuàng)業(yè)新機(jī)遇！