Jan Ozer:高畫質直播互動場景下的硬編碼如何選型?
前言
高畫質直播逐漸普及,硬編碼也成為大勢所趨。在 RTE 2022 大會上,來自 NETINT 的 Jan Ozer 透過一系列的對比測試結果,詳細分享瞭如何為高畫質直播互動場景進行硬編碼的技術選型。
* 本文內容基於演講內容進行整理,為方便閱讀略有刪改。關注「聲網開發者」公眾號回覆關鍵詞「1102」,即可領取完整版 PPT;點選文末圖片或閱讀原文,即可回看完整版演講影片。
大家好,我是 Jan Ozer。今天我們要討論的是高畫質直播場景中的編碼技術。我們將聚焦於高畫質(High-density)影片直播場景進行今天的分享。如大家所見,市場越來越青睞高資料量流媒體,硬體編碼也成為了大勢所趨。
有四種編碼方式供大家選擇:CPU、GPU、FPGA 和 ASIC,接下來我們來聊聊該如何選擇。
其實就是具體要考慮不同編碼方式的特性、成本(資本支出和運維支出)和能耗,很明顯能耗也會影響運維支出以及碳排放問題。
做任何選擇都要從找到你的工作點(operating point)開始,演講末尾會著重說明這一點。
我們關注的是高畫質影片直播流媒體,比如雲遊戲、互動影片、AR、VR 和元宇宙等,不涉及影片點播場景。
演講中只會談到影片點播的質量問題和 ASIC 在這方面的表現,但討論重點還是直播轉碼。
第一點:軟體編碼對高流量的直播轉碼來說較為低效,這個實驗會告訴你為什麼。
我們用三臺不同的電腦進行測試:戴爾 R640、技嘉 R272 和戴爾 R7525。核心數的配置分別是 48、80 和 64。然後,我們還給這三臺裝置安裝了 T408 轉碼卡進行測試。配置分別為 10、24 和 24。我們測量了這兩種方法的效能:安裝 T408 且使用 ASIC 的情況下,對比只用軟體,使用 X264 快速預設情況下各裝置的 FPS(每秒傳輸幀數)。測試效能包括:FPS,能耗,以及這三臺電腦在每個配置中每瓦特的 FPS。
我們發現,兩種情況下,使用 T408 的 FPS 要高 13 倍,耗電量相近。雖然必須給 T408 供電,但是因為原來計算機大部分電力都供給 CPU,而如果安裝了 T408,CPU 工作量會減少很多。所以兩種情況下,整體耗電量是差不多的。
也就是說一臺 NVME 伺服器,一臺安裝了 10 個或 24 個 T408 的伺服器效能相當於約 13.1 臺只用軟體進行編碼的電腦。
因此,軟體編碼意味著 7 到 8 倍的成本支出,13 倍的功耗。
使用 HEVC 的情況會更糟糕。因為它是很複雜的一種編解碼器。如果在只用軟體的情況下,執行會非常緩慢。
如上圖這組測試中,我們用搭載 ASICS 的 HEVC 和使用 X264 medium 預設的純軟體做比較。同樣,測試指標為 FPS,瓦特和每瓦特的 FPS。
可以看到,相比而言 T408 的 FPS 比純軟體高出 55%。而兩者的耗電量還是差不多。
結論表明,不論是從資本支出,還是運維支出的角度來看,純軟體編碼對直播流媒體應用來說都太昂貴了。
因此,我們來看一下用硬體替代的方案。選擇有 CPU、GPU、FPGA 和 ASIC。你會如何從它們中選擇呢?
讓我們先來梳理一下這些硬體選項:CPU,中央處理器;GPU,圖形處理器;FPGA 是現場可程式設計門陣列;ASIC 是專用積體電路。
通俗來講是什麼意思呢?
CPU 是驅動整個計算機的通用處理器。
GPU 是可以驅動圖形以及執行其他功能的通用處理器。
FPGA 是一種可程式設計的裝置,你可以用它來做很多事情。
ASIC,當它以壓縮影片為目的產生時,它所做的就是處理影片。
對應的產品例子有:英特爾 Intel Xeon Platinum 8280 處理器,22500 美元,英偉達 T4,2299 美元,AMD/Xilinx Alveo U30,大概 2000 美元。還有這次演講中會提到的 NETINT Quadra T1,它的價格約為 1500 美元。
如上圖所示,每一種硬體的最大功率也不同。CPU 的功率最大,而由於 ASIC 只需要處理影片,所以它的功率最小。
接下來,讓我們對這些硬體選項進一步分類。怎樣能把這些硬體新增到伺服器上呢?
CPU 通常放在主機板上。GPU 和 FPGA 放在 PCI 插槽中。像 Netint 的 Quadra 單元這種 ASIC 既可以放在 PCI 插槽中,也可以放在 U.2 插槽中。U.2 是一種非常有效的方式,可以在伺服器上新增多張轉碼卡。
不同的裝置之間,軟體整合是類似的。大多數都有 FFmpeg 和或 Gstreamer 功能,以及用於軟體開發的獨立 SDK。
而說到用於轉碼的晶片可用率:CPU 非常小。CPU 是一個通用裝置。因此該裝置中只有一小部分是專門用於影片轉碼的。GPU 要好一點。FPGA 也可以。但 ASIC 的晶片完全是為影片處理而設計的。這意味著它在功率和吞吐量方面的效率都更高。
關於編碼的吞吐量:因為 CPU 可用於影片轉碼的部分很少,所以從裝置的總體門數來看,總體吞吐量會相對較小。GPU 和 FPGA 好一點。ASIC 表現優秀。因為它就是為影片處理而生的。
綜上所述,按流的成本來計算的話,CPU 是最貴的。GPU 和 FPG A 會便宜一點,但 ASIC 通常才是最實惠的選擇。
參考上一張幻燈片裡各項的功耗,因為 CPU 的功耗非常高,流的輸出又非常低,它每個流的功耗會非常高。GPU 和 FPGA 每個流的功耗稍低一點,但最效率最高的還是 ASIC。
那麼,高畫質應用選其中哪一種呢?
CPU 並不適用於高畫質應用。因為它需要大量電力,且物理整合必須在主機板上。選 GPU 和 FPGA 會稍好一些。這兩種硬體都採用 PCI 形式,功耗更低。但 ASIC 會是最佳選擇。因為它的功耗最低,且它的外形尺寸最方便整合到伺服器中。
那麼,像 Youtube 這樣的產品會選擇哪種方案呢?
它們採用的是 Argos,google 自研的專用於影片轉/編碼處理單元。在採用 Argos 時,Youtube 選擇了 ASIC。因為它是處理影片最有效的方式。
我們認為對於其他公司來說,同樣是 ASIC 的 Quadra 可以成為他們的 Argos。這樣說是因為,大多數公司無法設計自己的 ASIC。其實沒有必要自己來,因為大家可以從 Netint 購買 ASIC 服務,比如 T408,或者 Quadra(接下來會詳細介紹)。
那麼,到底應該怎樣在這些備選方案中選擇呢?我會按如上圖的順序進行說明。首先明確各硬體功能,確保它可以滿足你的需求。然後瞭解影響質量和吞吐量的因素,再用各種內容型別進行測試。接下來,選擇你的最優點。等下我們會詳細討論這一塊。然後進行計算。計算每個流的成本和使用該最優點的每個流的質量。
如上圖,是你要檢查的硬體功能表,表中已標註了 NETINT Quadra 一項。可以看到,Quadra 支援 H.264、HEVC 和 AV1。在處理功能方面,Quadra 可以進行解碼、編碼、縮放和疊加,甚至還有人工智慧,第三方編碼器通常都不具備這項功能。
現在,在瞭解特定裝置上包括哪些功能後,你需要確保在使用該裝置生成檔案的命令流中包含這些功能。以 NETINT Quadra 的命令流為例,這條流用於解碼,即使用硬體解碼器。如果命令流裡不包含解碼這一條,而是直接進入原始檔,那你只能使用軟體來解碼,這會降低整體吞吐量。
這裡是用 NETINT Quadra 選擇 H.264 編解碼器。這裡是用 NETINT Quadra 進行縮放。第一個個 rung 是在源解析度下生成,所以沒有縮放。下面的 rung 按比例從 1080p 縮放到 720p。而命令流中沒有包含所有所需硬體功能,就會影響到最終的吞吐量。得到的吞吐量會比使用卡上所有可用硬體功能所得到的量要少。
接下來,我們來談談質量問題。在大多數直播轉碼中,我們通常會用相對較低的質量預設部署應用,以減少計算週期,實現吞吐量。如果你用 x.264/x.265 進行轉碼,你通常在高水平情況下使用中等預設,在低水平情況下使用超快或非常快的預設。而如果是 SVT-AV1,你必須使用 10-12 範圍內的預設,以達到完成實時操作所需的吞吐量。
如今,大多數硬體編碼器的質量都在這個範圍內,所以結果不會和那些使用更慢或更高質量預設的軟體編碼器相同,但會用於直播轉碼應用的軟體質量相同,該軟體用的是典型預設。
為什麼呢?因為硬體限制了操作。為了獲得適當的吞吐量,當你轉碼時,你需要硬體吞吐量,這就是為什麼質量被設定在這個範圍。我們稍後會詳述這個問題。
如圖,圖中展示了使用 X.264 編解碼器按預設產生的質量和編碼時間。最下面這根曲線代表編碼時間。可以看到,從程式設計時間佔比非常少的情況,一直到到非常慢預設這裡。曲線開始很低,然後驟升。藍色曲線代表整體 VMAF 質量。紅色曲線代表低幀質量,用來衡量瞬態質量的傾向。在這一點我們會得到相對低的資源和更低的質量。但這是直播轉碼時必須做的,以此來獲得吞吐量。這就是資源和質量的平衡。
而這一點,在中等預設下我們會獲得 99.5% 的質量,與我們在非常慢預設情況下,獲得的最高質量相同。而 96.1% 的低幀質量是在大約 12.5% 的編碼時間實現的,但其實在該時間條件下,你會致力於實現非常慢的,或極慢預設。
上述說明了資源和質量的平衡。這是真正的收益遞減。因為在你的編碼時間顯著增加時,質量增長並不是那麼顯著。因此,對於大多數不需要直播運維的影片點播編碼來講,不管預設是中等,較慢還是非常緩慢(通常不會用極慢預設,因為無論怎樣都不能拿到最好的質量),你投入了 3 倍的編碼時間,只能獲得微不足道的質量優勢。而對直播製作來說,問題在於我們一直在談論的吞吐量。
通常是 HEVC 使用超高速預設,H.264 非常快,結果不會超過中等質量。就 Quadra 而言,這裡是這些裝置的總體質量目標。之後我們會展開說明這裡的數字。
我想做個實驗,看看相比我們剛才看到的軟體預設和 NVIDIA T4, Quadra 的質量是多少。所以我對五個檔案進行了編碼:足球遊戲、鋼鐵之淚、俠盜飛車、子午線和奇幻的晚宴,然後用不同的階梯生成 85 至 95 的 VMAF。
我對俠盜飛車的檔案進行了編碼,剪輯成 6Mbps 的速度,拉低了所有平均數。所以雖然我的目標是 85 到 95,但因為我們生成了 6Mbps 的 GTAV,VMAF 的總體平均數會更低一些。稍後會在速率失真曲線上具體展現。
通常一些人會使用的最大值,1080p 。我使用的編碼引數:是我用 NVIDIA 生成的。這是我在網上找到的兩個檔案中學來的,你可以從網上找到,並瞭解他們推薦的方法。然後我測量了整體的 VMAF 和低幀 VMAF,剛才我有提到過,它可以衡量瞬態質量的傾向。我們來看看這些速率失真曲線。紅色代表 Quadra,綠色代表 NVIDIA,紫色代表 VeryFast 配置,藍色代表中等配置。這是 H.264 總體的 VMAF 質量。
可以看到 Quadra、NVIDIA 和 Medium 預設之間的分數非常接近, Quadra 比 Medium 和 NVIDIA 稍微高一點。而 Quadra 遙遙領先於 VeryFast 預設。
我們一般使用 H.264 的最低質量預設就是 VeryFast,因為可以得到較好的吞吐量,質量也不錯。可以看到,NVIDIA 和 NETIENT 的表現都比 VeryFast 好很多。
然後再來看看低幀分數,如上圖,同樣也有瞬態質量的傾向。可以看到 Quadra 的表現要好於 Medium 和 NVIDIA,而 Medium 處於兩者之間,較好於 NVIDIA。Quadra 遙遙領先於 VeryFast,後者更容易存在低幀率問題。
HEVC 也是一樣。Quadra 的分數較高於 Medium,優於 NVIDIA,同時遠超 VeryFast 預設。在低幀分數中,Quadra 比 Meduim 高的就比較多了,同時遠超 NVIDIA 和 VeryFast。
總結一下,在選擇你的 Operating point 時,要多加考慮。但最基本的事實是,Quadra 在 H.264 和 HEVC 中能提供中等以上的質量,吞吐量更高,能耗更小。
這給我們留下了一些提醒:我不是 NIVIDIA 編碼專家,這是我第一次嘗試用 T4 進行高容量轉碼。我盡力去把他們一一對應作比較。但是各位應該自己進行測試,如果有任何問題,應直接聯絡 NVIDIA,確保操作無誤。
接下來我們就談一談之前提到多次的最優點。
最優點就是各位在製作中使用的編碼引數,這些引數為應用提供了質量和吞吐量的最優結合。我們關注最優點時因為所有的供應商都會給出吞吐量資料和質量結果。但他們不會在質量和吞吐量中使用相同的配置。現在各位應該明白最優點的重要性了。
所以各位在比較硬體設施時,第一步就是確認影響質量和效能的配置選項。在 NETINT 中,影響質量和效能的關鍵配置是 Lookahead,即編碼幀之前幀。這樣編碼器就知道接下來會發生什麼,從而提升編碼質量,尤其是當場景正在或即將改變時,可以提高位元率效率。這會降低效能,減少吞吐量,當然也會增加 Lookahead 的延遲。
下面我們來看一看 Lookahead 的定性影響。這是莫斯科州立大學影片質量測量工具的結果圖。展示了逐幀比較兩個檔案的 VMAF 分數結果。紅色部分有 40 幀的 Lookahead 編碼區,而綠色部分則沒有 Lookahead 編碼區。可以看到沒有 Lookahead 的區域有非常多的低幀。這些都是瞬態質量問題的潛在區域。
所以 Lookahead 確實會影響你的低幀分數。這些分數說明了什麼呢?
就使用調和平均值計算的總體 VMAF 分數而言,我們可以看到有 2.3 VMAF 分的差值,這有明顯的差異。一些研究者認為觀看者可以辨認出 VMAF 3 分的差別。在低幀分數中,差值非常顯著,從 75 分降到了 59 分。觀看者肯定可以注意到兩個剪輯中的低幀區域。標準差可以衡量質量可變性,這裡有 1 分的差值,也是比較顯著的。但在吞吐量中,不使用 Lookahead 的部分與使用 40 幀 Lookahead 的高出了 50%。這樣你就能明白,為什麼公司可能在計算吞吐量時停用 Lookahead,而在計算質量時啟用 Lookahead。這也是我們在比較 NVIDIA 和 NETINT 時要研究的核心問題。
在 NETINT 中可以改變的另一個配置選項是率失真最佳化(RDO),預設基本上就是 RDO。RDO 可以提升質量,但會減少吞吐量。瞭解了最能影響質量和吞吐量的配置選項後,你可以建立各種測試來執行這些配置選項,從最複雜、質量最高的,到最簡單、質量最低的。(在 Jan 的演講中,詳細分享了一些 NETINT 的測試資料,感興趣的可以在文末掃碼觀看演講回放。)
總結一下,當你比較硬解碼器時,首先要明確最能影響質量和吞吐量的關鍵配置選項,測試多種配置來確定 OP。使用這些引數來測試多個檔案的質量和吞吐量。使用技術來輸出最佳的質量組合,包括平均幀和低幀、資本支出和運維支出,以及能耗。
(正文完)
點選此處即可檢視完整影片回顧
相關文章
- 動漫街道場景高畫質動態桌布
- 直播導播高畫質影片傳輸中的影片壓縮編碼原理解析
- FinBench:金融場景下的圖系統選型
- 如何編寫高質量的C#程式碼(一)C#
- 社交場景下iOS訊息流互動層實踐iOS
- 日本市場也不景氣,遊戲改編動畫的前路何在?遊戲動畫
- 桌面互動投影的使用場景有哪些?
- 影片與編解碼的技術邂逅,碰撞出的高畫質羅曼史
- 艾瑞諮詢&直播高研院:2022中國品質直播選型與應用白皮書
- 高併發場景下如何優化伺服器的效能?優化伺服器
- 直播系統程式碼,點選產生動畫效果並移動的特效動畫特效
- 基於RTS超低延時直播最佳化強互動場景體驗
- 影片直播場景下物件儲存的應用物件
- 我們應該如何編寫高質量的前端程式碼前端
- Animated Wallpapers for Mac高畫質動畫主題桌布Mac動畫
- 高階動畫繫結功能:角色與物品的互動動畫
- 原畫人場景原畫教程,畫場景的思路是怎麼樣的?
- 《質量效應 仙女座》如何成為絕佳編劇的反面教材(下):場景創作
- RFID電子標籤根據應用場景的不同如何選型?
- 編寫高質量程式碼的30條黃金守則-Day 01(首選隱式型別轉換)型別
- 如何做好直播間的粉絲互動
- ECCV 2024 | 新夢幻場景生成方法,高質量、視角一致、可編輯3D場景3D
- 如何一鍵批次下載淘寶商品主圖的高畫質原圖
- 技術分享| 如何搭建直播場景下的推拉流媒體伺服器伺服器
- 成品直播原始碼推薦,js點選讓視窗抖動動畫效果原始碼JS動畫
- 教育原始碼的重要任務——做好直播互動原始碼
- IINA:暢享高畫質影片,Mac最 佳選擇Mac
- polarbear北極熊高畫質動態桌布
- Mac灕江景色高畫質動態桌布Mac
- Living Wallpaper HD for Mac高畫質動態桌布Mac
- 如何編寫高質量的函式 -- 敲山震虎篇函式
- UWA:8K超高畫質新體驗應用場景白皮書(附下載)
- 如何做一場高質量的分享
- 細數《Sizeable》中場景互動的夢境靈感
- 《Arduino+Android互動智作:初入物聯網》高畫質書籤中文版UIAndroid
- 如何繪製三維動畫設計和製作場景更好動畫
- 用 Real-ESRGAN 拯救座機畫質,自制高畫質版動漫資源
- 618 Tech Talk|高併發場景下的資料訪問速度如何保障?