云端虛擬視頻轉碼

　　應用示例：OTT 視頻流 電視回看 OTT 內容傳遞

　　云端視頻轉碼越來(lái)越多地被使用，其中一種情況是電視回看或追趕，內容提供商接收來(lái)自多個(gè)制作者的內容，并將其處理為可供訂閱者在次日觀(guān)看。此類(lèi)提供商每天可接收數百小時(shí)的內容，這些內容需要轉碼為多種不同的格式，以便傳遞到許多設備。結果是需要轉碼數千小時(shí)的視頻。

　　例如，提供商正在從多個(gè)制作者那里接收 200 小時(shí)的內容。根據所支持的設備不同，提供商可能會(huì )將此內容制作成多達 100 種不同的轉 碼輸出，以解決其允許的任何消費者設備對編解碼器、分辨率、比特率等的不同需求。

　　為了使這個(gè)例子更簡(jiǎn)單，我們假設，現在提供商將執行 10 種不同的 1080p30 H.264 輸出。運行在標準的 1RU 雙 Intel® Xeon® E5-2650V2 處理器服務(wù)器上，服務(wù)器中每個(gè) CPU 能夠處理大約 60 幀/秒的 X.264 轉碼(在 3.2GHz Intel® Core™ i7-4770R 上以默認 CRF 快速模式 下的33fps 數據推斷得出);沒(méi)有虛擬化運行時(shí)，則每個(gè)服務(wù)器達到 120 幀/秒。但在云環(huán)境下，轉碼器將在虛擬機中運行，因此，我們 需要將此數字降低約10%，即每服務(wù)器總計約 108 幀/秒。

　　如果以 30 幀/秒轉碼 200 小時(shí)的內容，系統需要轉碼 2.16 億幀才能實(shí)現 10 種輸出。速率為 108 幀/秒時(shí)，雙 Intel® Xeon® E5-2650v2 服務(wù)器將需要 556 小時(shí)來(lái)執行此任務(wù)。而這對電視回看功能不是真正地有效。使用戴爾 R720T 等雙 E5-2650V2 2RU 服務(wù)器時(shí)，上述工 作量需要 24 個(gè)服務(wù)器(>1 機架)以 100% 最快速全天候不間斷運行，才能確保內容能夠在 24 小時(shí)內傳遞給消費者。以最快速全天候 不間斷運行肯定會(huì )導致數據中心故障，因此需要更多的服務(wù)器來(lái)分攤負荷，以確?？煽啃?。含有 2x Intel® Xeon® E5-2650V2 處理器的戴 爾 R720T 在有/無(wú) 4x Artesyn SharpStreamer™ 卡時(shí)的比較：

　　另一種方法是在此類(lèi)系統中使用 Artesyn SharpStreamer™ 卡。 在帶有 4 個(gè) Intel® Core™ i7-4650U CPU 且每個(gè) CPU 節點(diǎn)分 別能夠傳遞 120-240 幀/秒的 1080p 轉碼的條件下，提供商就可以進(jìn)一步提高每個(gè)服務(wù)器的效率。在這種配置下，配合 CPU 內核上的軟件，一臺含有雙 Intel® Xeon® E5-2650V2 和四個(gè) Sharp Streamer 卡的服務(wù)器可有效地達到約 4000 幀/秒。為了與 Intel® Xeon® E5-2650V2 軟件解決方案做比較，我們將專(zhuān)注于在 平衡質(zhì)量模式(Intel MediaSDK 目標使用 = 4)下每節點(diǎn) 180 幀/ 秒的中間值，因此四張 PCIe 卡以 2880 幀/秒進(jìn)行處理。這個(gè)解 決方案能夠通過(guò)單個(gè)服務(wù)器在 21 小時(shí)內將 200 小時(shí)的內容處理 為 10 種單獨的輸出，服務(wù)器數量?jì)H需另一方案的 1/24，功率降 低至 1/11，成本更是減少至 1/5 以下。

　　而 10x 1080p30 轉碼可能不是此種部署的真正代表，可以想象得 出，提供商將需要提供更多計算，例如，一個(gè) 1080p30 大致相 當于單個(gè) 720p60。還應注意，200 小時(shí)僅代表許多內容提供商接收的總小時(shí)數的一部分。

　　實(shí)時(shí)/線(xiàn)性 ABR 廣播轉碼器需求

　　對于消費者而言，一天內的直播電視觀(guān)看習慣隨時(shí)改變。如今，IPTV 提供商必須做到不僅能傳遞至他們機頂盒中的已知實(shí)體，而且需要適應消費者觀(guān)看他們內容所使用的大量設備，例如平板電腦、手機、第三方電視(如 Roku™、Apple TV 和亞馬遜的 Fire TV)。廣播電視提供商提供在線(xiàn)電視門(mén)戶(hù)網(wǎng)站時(shí)也面臨類(lèi)似 的挑戰。結果就是 IPTV 提供商現在需要能夠以最小延遲實(shí)時(shí)生成大量不同的轉碼格式。

　　為了適應網(wǎng)絡(luò )擁塞，大多數提供商已轉向自適應比特率技術(shù)，例 如蘋(píng)果的 HLS、Silverlight、PlayReady 等，其允許消費者設備決 定是否需要切換到不同的配置文件，以確保內容能夠連續播放。在多數情況下，消費者愿意容忍視頻質(zhì)量的瞬間降低，但重新緩 沖通常會(huì )導致消費者改變頻道或改變提供商。自適應流試圖通過(guò) 將視頻切割為某一時(shí)間段(例如，2-4 秒)的多個(gè)區塊，并使客 戶(hù)端能夠在偽播放列表(稱(chēng)作清單)中使用這些區塊，來(lái)幫助消 費者設備適應網(wǎng)速和帶寬的變化。

　　此清單為客戶(hù)端提供相關(guān)數據，展示什么配置文件適用于特定時(shí)間索引以及要請求的必要文件是什么。消費者設備請求其所需的 配置文件，并監控下載時(shí)間，如果時(shí)間不能滿(mǎn)足維持播放率所需 的時(shí)間，設備將請求較低級的配置文件并監控，最終可能需要重新緩沖，但是，已經(jīng)配置好的設備將能夠在需要重新緩沖前及時(shí) 為播放器獲得下載的配置文件，除非網(wǎng)絡(luò )出現嚴重問(wèn)題。

　　自適應流的缺點(diǎn)是需要創(chuàng )建不同的配置文件。在多數情況下，提供商不僅需要為其目標設備處理多種自適應流技術(shù)，還需要適應各種 設備所支持的不同分辨率、編解碼器配置文件、比特率等。這將導 致單個(gè)信道需要很多轉碼。最糟糕的情況是，允許訪(fǎng)問(wèn)內容的每個(gè)設備類(lèi)型在線(xiàn)且訪(fǎng)問(wèn)每個(gè)信道的內容。信道越多，發(fā)生這種情況的 可能性就越小，但提供商需要在規劃網(wǎng)絡(luò )時(shí)知道峰值數。

　　通常情況下，全天將有一套通用轉碼集，大部分不是所有設備都需要，它們可以根據需要打包到各種所需的自適應流配置文件中。另 一套轉碼集用于傳遞特定設備所需的特殊呈現形式，但此轉碼集更 加動(dòng)態(tài)，具體取決于觀(guān)看習慣。例如，許多人在醒來(lái)時(shí)使用帶有機頂盒的電視機或其它設備，然后轉到更加便攜的設備，例如便攜式 計算機、手機等。

　　關(guān)于眾多信道間的趨勢：將在一組信道上有波峰，而其它信道上有波谷。使用基于 Intel® XeonTM 的服務(wù)器上的虛擬化時(shí)，系統能夠根 據需要帶來(lái)更多的在線(xiàn)轉碼器，并配置它們以制作各種目標設備所需的呈現形式，方法是實(shí)施多比特率轉碼器，該轉碼器為傳入視頻 解碼、調整到所需分辨率并在發(fā)送到分割器以將流分割為分斷文件 之前編碼為特定格式，然后發(fā)送到包裝程序，按照消費者設備所要求的自適應比特率標準打包到所需包裝。

　　對于高效的多比特率轉碼器，視頻解碼應出現一次，并用作所有編碼輸出的單個(gè)參考;而編碼器稍加優(yōu)化即可降低各種輸出分辨 率的縮放費用以及這些分辨率上的動(dòng)作搜索。

　　來(lái)自編碼器的每個(gè)輸出都是圖片組 (GOP) 和排列的順序(編碼與 顯示)，這一點(diǎn)很重要。因此，在提交到包裝程序之前，來(lái)自分割器的結果片段都是正確排列。

　　此類(lèi)運行軟件轉碼器的多比特率轉碼器服務(wù)器所面臨的挑戰，是 確保所需的所有不同的呈現形式都在單個(gè)服務(wù)器上生成。如果所 需呈現形式超出服務(wù)器能力，系統將需要為傳入視頻復制解碼器，以便原始基帶視頻無(wú)需通過(guò)系統之間(否則會(huì )進(jìn)一步增加延 遲)，這要求每個(gè)流上有相當大的網(wǎng)絡(luò )帶寬(對于 1080p30 8bit YUV 內容，約為 500Mbps)。另外，這兩個(gè)系統將需要保持同 步，以確保輸出呈現形式為 GOP 和排列的順序，這是成功分割 的關(guān)鍵。

　　使用已啟用 Artesyn SharpStreamer 卡的系統時(shí)，所提供的密度允許 實(shí)現更多呈現形式，而且允許單個(gè)服務(wù)器上能適應更多信道。戴爾 RT720p Dual Intel® Xeon® E5-2650V2 處理器系統有可能輸出六個(gè)單 獨的 1080p30 流，配備四個(gè) SharpStreamer 卡的相同系統能適應多 達 96 個(gè)單獨的 1080p30 流，每個(gè)服務(wù)器的轉碼能力提高 16 倍。

　　在 SharpStreamer 加速的平臺上，功率要求也縮小七倍：以前需要16 個(gè)服務(wù)器共 7604W，現在只需 1056W 即可處理 96 個(gè)流。

　　啟用 SharpStreamer 卡的系統允許提供商快速使網(wǎng)絡(luò )適應消費者設備的按需需求。

　　總結：此方案的優(yōu)勢

　　使用上述兩種方案時(shí)，通過(guò)虛擬網(wǎng)絡(luò )中的視頻加速可實(shí)現眾多優(yōu)勢。

　　優(yōu)勢一：降低資本設備支出

　　加速方案的優(yōu)勢主要來(lái)自服務(wù)器在數據中心所占用空間的減少和管理這些資源的簡(jiǎn)化。網(wǎng)絡(luò )功能虛擬化使提供商能夠動(dòng)態(tài)地改變所需資源 類(lèi)型和級別，并且這適用于上述使用情況下作為 VNF 的視頻轉碼。

　　優(yōu)勢二：省電并降低間接費用

         優(yōu)勢三：可擴展性

　　當網(wǎng)絡(luò )要求增加或減少視頻轉碼時(shí)，也能以較低成本擴大或縮小資源，這是因為可通過(guò)附加卡達到視頻轉碼數量，從而減少服務(wù)器數量。如上所述，網(wǎng)絡(luò )中服務(wù)器的數量減少，有利于大幅降低運營(yíng)成本。因此，如同服務(wù)提供商通過(guò)增加服務(wù)來(lái)提供優(yōu)質(zhì)的 OTT 視頻服務(wù)，附 加卡能逐漸提高所需的密度級別，但資本設備支出沒(méi)有目前的傳統方法那么高昂。

　　優(yōu)勢四：使用簡(jiǎn)單，通過(guò)云端通用 X86 處理即可實(shí)現

　　基于 x86 的方法用來(lái)解決云端視頻處理問(wèn)題，對設備供應商而言具有重要優(yōu)勢，原因在于英特爾技術(shù)提供熟悉且簡(jiǎn)單易用的 API 來(lái)加速 開(kāi)發(fā)和上市時(shí)間。Intel® Media SDK 可實(shí)現從純軟件模式到媒體加速模式的轉變，同時(shí)具備運行 Windows、Linux、QuickSync video 和 API 庫的能力，甚至能以更高密度的容量為視頻應用傳遞最大的每機架單位流數。