云端虛擬視頻轉(zhuǎn)碼
應(yīng)用示例:OTT 視頻流 電視回看 OTT 內(nèi)容傳遞
本文引用地址:http://www.ex-cimer.com/article/276377.htm云端視頻轉(zhuǎn)碼越來(lái)越多地被使用,其中一種情況是電視回看或追趕,內(nèi)容提供商接收來(lái)自多個(gè)制作者的內(nèi)容,并將其處理為可供訂閱者在次日觀看。此類(lèi)提供商每天可接收數(shù)百小時(shí)的內(nèi)容,這些內(nèi)容需要轉(zhuǎn)碼為多種不同的格式,以便傳遞到許多設(shè)備。結(jié)果是需要轉(zhuǎn)碼數(shù)千小時(shí)的視頻。
例如,提供商正在從多個(gè)制作者那里接收 200 小時(shí)的內(nèi)容。根據(jù)所支持的設(shè)備不同,提供商可能會(huì)將此內(nèi)容制作成多達(dá) 100 種不同的轉(zhuǎn) 碼輸出,以解決其允許的任何消費(fèi)者設(shè)備對(duì)編解碼器、分辨率、比特率等的不同需求。
為了使這個(gè)例子更簡(jiǎn)單,我們假設(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ù)推斷得出);沒(méi)有虛擬化運(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í)來(lái)執(zhí)行此任務(wù)。而這對(duì)電視回看功能不是真正地有效。使用戴爾 R720T 等雙 E5-2650V2 2RU 服務(wù)器時(shí),上述工 作量需要 24 個(gè)服務(wù)器(>1 機(jī)架)以 100% 最快速全天候不間斷運(yùn)行,才能確保內(nèi)容能夠在 24 小時(shí)內(nèi)傳遞給消費(fèi)者。以最快速全天候 不間斷運(yùn)行肯定會(huì)導(dǎo)致數(shù)據(jù)中心故障,因此需要更多的服務(wù)器來(lái)分?jǐn)傌?fù)荷,以確保可靠性。含有 2x Intel® Xeon® E5-2650V2 處理器的戴 爾 R720T 在有/無(wú) 4x Artesyn SharpStreamer™ 卡時(shí)的比較:
另一種方法是在此類(lèi)系統(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)核上的軟件,一臺(tái)含有雙 Intel® Xeon® E5-2650V2 和四個(gè) Sharp Streamer 卡的服務(wù)器可有效地達(dá)到約 4000 幀/秒。為了與 Intel® Xeon® E5-2650V2 軟件解決方案做比較,我們將專(zhuān)注于在 平衡質(zhì)量模式(Intel MediaSDK 目標(biāo)使用 = 4)下每節(jié)點(diǎn) 180 幀/ 秒的中間值,因此四張 PCIe 卡以 2880 幀/秒進(jìn)行處理。這個(gè)解 決方案能夠通過(guò)單個(gè)服務(wù)器在 21 小時(shí)內(nèi)將 200 小時(shí)的內(nèi)容處理 為 10 種單獨(dú)的輸出,服務(wù)器數(shù)量?jī)H需另一方案的 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)碼器需求
對(duì)于消費(fèi)者而言,一天內(nèi)的直播電視觀看習(xí)慣隨時(shí)改變。如今,IPTV 提供商必須做到不僅能傳遞至他們機(jī)頂盒中的已知實(shí)體,而且需要適應(yīng)消費(fèi)者觀看他們內(nèi)容所使用的大量設(shè)備,例如平板電腦、手機(jī)、第三方電視(如 Roku™、Apple TV 和亞馬遜的 Fire TV)。廣播電視提供商提供在線電視門(mén)戶網(wǎng)站時(shí)也面臨類(lèi)似 的挑戰(zhàn)。結(jié)果就是 IPTV 提供商現(xiàn)在需要能夠以最小延遲實(shí)時(shí)生成大量不同的轉(zhuǎn)碼格式。
為了適應(yīng)網(wǎng)絡(luò)擁塞,大多數(shù)提供商已轉(zhuǎn)向自適應(yīng)比特率技術(shù),例 如蘋(píng)果的 HLS、Silverlight、PlayReady 等,其允許消費(fèi)者設(shè)備決 定是否需要切換到不同的配置文件,以確保內(nèi)容能夠連續(xù)播放。在多數(shù)情況下,消費(fèi)者愿意容忍視頻質(zhì)量的瞬間降低,但重新緩 沖通常會(huì)導(dǎo)致消費(fèi)者改變頻道或改變提供商。自適應(yīng)流試圖通過(guò) 將視頻切割為某一時(shí)間段(例如,2-4 秒)的多個(gè)區(qū)塊,并使客 戶端能夠在偽播放列表(稱(chēng)作清單)中使用這些區(qū)塊,來(lái)幫助消 費(fèi)者設(shè)備適應(yīng)網(wǎng)速和帶寬的變化。
此清單為客戶端提供相關(guān)數(shù)據(jù),展示什么配置文件適用于特定時(shí)間索引以及要請(qǐng)求的必要文件是什么。消費(fèi)者設(shè)備請(qǐng)求其所需的 配置文件,并監(jiān)控下載時(shí)間,如果時(shí)間不能滿足維持播放率所需 的時(shí)間,設(shè)備將請(qǐng)求較低級(jí)的配置文件并監(jiān)控,最終可能需要重新緩沖,但是,已經(jīng)配置好的設(shè)備將能夠在需要重新緩沖前及時(shí) 為播放器獲得下載的配置文件,除非網(wǎng)絡(luò)出現(xiàn)嚴(yán)重問(wèn)題。
自適應(yīng)流的缺點(diǎn)是需要?jiǎng)?chuàng)建不同的配置文件。在多數(shù)情況下,提供商不僅需要為其目標(biāo)設(shè)備處理多種自適應(yīng)流技術(shù),還需要適應(yīng)各種 設(shè)備所支持的不同分辨率、編解碼器配置文件、比特率等。這將導(dǎo) 致單個(gè)信道需要很多轉(zhuǎn)碼。最糟糕的情況是,允許訪問(wèn)內(nèi)容的每個(gè)設(shè)備類(lèi)型在線且訪問(wèn)每個(gè)信道的內(nèi)容。信道越多,發(fā)生這種情況的 可能性就越小,但提供商需要在規(guī)劃網(wǎng)絡(luò)時(shí)知道峰值數(shù)。
通常情況下,全天將有一套通用轉(zhuǎn)碼集,大部分不是所有設(shè)備都需要,它們可以根據(jù)需要打包到各種所需的自適應(yīng)流配置文件中。另 一套轉(zhuǎn)碼集用于傳遞特定設(shè)備所需的特殊呈現(xiàn)形式,但此轉(zhuǎn)碼集更 加動(dòng)態(tài),具體取決于觀看習(xí)慣。例如,許多人在醒來(lái)時(shí)使用帶有機(jī)頂盒的電視機(jī)或其它設(shè)備,然后轉(zhuǎn)到更加便攜的設(shè)備,例如便攜式 計(jì)算機(jī)、手機(jī)等。
關(guān)于眾多信道間的趨勢(shì):將在一組信道上有波峰,而其它信道上有波谷。使用基于 Intel® XeonTM 的服務(wù)器上的虛擬化時(shí),系統(tǒng)能夠根 據(jù)需要帶來(lái)更多的在線轉(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)打包到所需包裝。
對(duì)于高效的多比特率轉(zhuǎn)碼器,視頻解碼應(yīng)出現(xiàn)一次,并用作所有編碼輸出的單個(gè)參考;而編碼器稍加優(yōu)化即可降低各種輸出分辨 率的縮放費(fèi)用以及這些分辨率上的動(dòng)作搜索。
來(lái)自編碼器的每個(gè)輸出都是圖片組 (GOP) 和排列的順序(編碼與 顯示),這一點(diǎn)很重要。因此,在提交到包裝程序之前,來(lái)自分割器的結(jié)果片段都是正確排列。
此類(lèi)運(yùn)行軟件轉(zhuǎn)碼器的多比特率轉(zhuǎn)碼器服務(wù)器所面臨的挑戰(zhàn),是 確保所需的所有不同的呈現(xiàn)形式都在單個(gè)服務(wù)器上生成。如果所 需呈現(xiàn)形式超出服務(wù)器能力,系統(tǒng)將需要為傳入視頻復(fù)制解碼器,以便原始基帶視頻無(wú)需通過(guò)系統(tǒng)之間(否則會(huì)進(jìn)一步增加延 遲),這要求每個(gè)流上有相當(dāng)大的網(wǎng)絡(luò)帶寬(對(duì)于 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 加速的平臺(tái)上,功率要求也縮小七倍:以前需要16 個(gè)服務(wù)器共 7604W,現(xiàn)在只需 1056W 即可處理 96 個(gè)流。
啟用 SharpStreamer 卡的系統(tǒng)允許提供商快速使網(wǎng)絡(luò)適應(yīng)消費(fèi)者設(shè)備的按需需求。
總結(jié):此方案的優(yōu)勢(shì)
使用上述兩種方案時(shí),通過(guò)虛擬網(wǎng)絡(luò)中的視頻加速可實(shí)現(xiàn)眾多優(yōu)勢(shì)。
優(yōu)勢(shì)一:降低資本設(shè)備支出
加速方案的優(yōu)勢(shì)主要來(lái)自服務(wù)器在數(shù)據(jù)中心所占用空間的減少和管理這些資源的簡(jiǎn)化。網(wǎng)絡(luò)功能虛擬化使提供商能夠動(dòng)態(tài)地改變所需資源 類(lèi)型和級(jí)別,并且這適用于上述使用情況下作為 VNF 的視頻轉(zhuǎn)碼。
優(yōu)勢(shì)二:省電并降低間接費(fèi)用
優(yōu)勢(shì)三:可擴(kuò)展性
當(dāng)網(wǎng)絡(luò)要求增加或減少視頻轉(zhuǎn)碼時(shí),也能以較低成本擴(kuò)大或縮小資源,這是因?yàn)榭赏ㄟ^(guò)附加卡達(dá)到視頻轉(zhuǎn)碼數(shù)量,從而減少服務(wù)器數(shù)量。如上所述,網(wǎng)絡(luò)中服務(wù)器的數(shù)量減少,有利于大幅降低運(yùn)營(yíng)成本。因此,如同服務(wù)提供商通過(guò)增加服務(wù)來(lái)提供優(yōu)質(zhì)的 OTT 視頻服務(wù),附 加卡能逐漸提高所需的密度級(jí)別,但資本設(shè)備支出沒(méi)有目前的傳統(tǒng)方法那么高昂。
優(yōu)勢(shì)四:使用簡(jiǎn)單,通過(guò)云端通用 X86 處理即可實(shí)現(xiàn)
基于 x86 的方法用來(lái)解決云端視頻處理問(wèn)題,對(duì)設(shè)備供應(yīng)商而言具有重要優(yōu)勢(shì),原因在于英特爾技術(shù)提供熟悉且簡(jiǎn)單易用的 API 來(lái)加速 開(kāi)發(fā)和上市時(shí)間。Intel® Media SDK 可實(shí)現(xiàn)從純軟件模式到媒體加速模式的轉(zhuǎn)變,同時(shí)具備運(yùn)行 Windows、Linux、QuickSync video 和 API 庫(kù)的能力,甚至能以更高密度的容量為視頻應(yīng)用傳遞最大的每機(jī)架單位流數(shù)。
評(píng)論