云端虛擬視頻轉(zhuǎn)碼

　　應(yīng)用示例：OTT 視頻流 電視回看 OTT 內(nèi)容傳遞

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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