|
作者：雅特生科技公司軟件產(chǎn)品營銷高級總監(jiān) Jim Darroch、英特爾公司軟件設(shè)計(jì)師 Richard Dunphy、戴爾公司全球電信策略規(guī)劃師 Franklin Flint 視頻應(yīng)用對密度和高品質(zhì)處理的需求與日俱增，將廣播和通信網(wǎng)絡(luò)推向了極限。增加更多的設(shè)備來處理這些視頻流，從經(jīng)濟(jì)角度來講是不可行的。而且，運(yùn)營商、服務(wù)提供商和內(nèi)容提供商注意到了在云端使用標(biāo)準(zhǔn)服務(wù)器的優(yōu)勢，想要擺脫 特殊設(shè)備或?qū)Ｓ糜布５壳皹?biāo)準(zhǔn)服務(wù)器尚未針對云端視頻轉(zhuǎn)碼進(jìn)行優(yōu)化。 因此，最佳解決方案是加速視頻云：標(biāo)準(zhǔn)服務(wù)器中的 PCI Express 視頻加速卡。 加速視頻云不但提供大量基于標(biāo)準(zhǔn)服務(wù)器的資源，還具備更高性能和更高密度視頻處理的額外優(yōu)勢，以滿足當(dāng)今用戶的需求。 本文介紹了加速視頻云需求背后的市場驅(qū)動(dòng)力，并討論了 OpenStack 等技術(shù)和其它開源平臺在轉(zhuǎn)向 SDN/NFV 網(wǎng)絡(luò)架 構(gòu)背景下的含義。然后，在總結(jié)部分例舉了現(xiàn)實(shí)生活中的應(yīng)用來說明性能和經(jīng)濟(jì)優(yōu)勢。 目前云端處理視頻流量的能力 消費(fèi)者是改變廣播網(wǎng)絡(luò)格局的主要驅(qū)動(dòng)力。用戶習(xí)慣正在從傳統(tǒng)的廣播轉(zhuǎn)變?yōu)殡娨曇曨l消費(fèi)(請參閱以下圖表頂部的“線性”部分)，再到動(dòng)態(tài)、按需提供、移動(dòng)的視頻觀看(請參閱以下圖表底部的“多屏幕”部分)。 這給網(wǎng)絡(luò)帶來重負(fù)，因此，網(wǎng)絡(luò)正在快速擴(kuò)展自身能力，以便同時(shí)處理傳統(tǒng)電纜/線性/廣播視頻分布和更動(dòng)態(tài)的多屏幕視頻。相較于運(yùn)營商喜好，多屏幕視頻更多地受到消費(fèi)者喜好的推動(dòng)。視頻的帶寬消耗不容忽視，按其網(wǎng)絡(luò)份額大小進(jìn)行判斷時(shí)尤其如此。 例如，Sandvine 的《全球互聯(lián)網(wǎng)現(xiàn)象報(bào)告》(2014 年 6 月)表明，在高峰時(shí)期，實(shí)時(shí)娛樂占到下行字節(jié)的 63% 以上。 隨著多服務(wù)運(yùn)營商(MSO)和電信服務(wù)提供商使用云技術(shù)來為 媒體市場提供足夠處理資源、流資源和存儲(chǔ)資源的比例不斷增 大，運(yùn)營商的業(yè)務(wù)格局也轉(zhuǎn)向視頻。但是，目前的云端視頻性能水平離最理想水平還相差甚遠(yuǎn)。 本文將使用 Intel?(英特爾)、戴爾和雅特生科技的最新技術(shù)， 通過虛擬轉(zhuǎn)碼解決方案來探索在云端承載視頻的更好方法，最終實(shí)現(xiàn)更高密度、更高部署靈活性。 解決方案 —— 加速視頻云 典型的云實(shí)施基于多個(gè)完全相同的服務(wù)器，這些服務(wù)器可根據(jù)需要 用于不同的任務(wù)，滿足應(yīng)用指定的不同規(guī)模和空間占用要求。處理器是大量云計(jì)算資源中的 NFV(網(wǎng)絡(luò)功能虛擬化基礎(chǔ)架構(gòu))節(jié)點(diǎn)。 但是對于視頻，用于視頻流的服務(wù)器比用于網(wǎng)頁瀏覽的服務(wù)器支持的用戶容量少得多。因此，需要向云服務(wù)器增加視頻處理和轉(zhuǎn)碼資 源。 運(yùn)營商在云端使用標(biāo)準(zhǔn)服務(wù)器的比例不斷增大，而且無需特殊設(shè)備， 加上視頻應(yīng)用對密度和高品質(zhì)處理的需求與日俱增，因此最佳的解 決方案是加速視頻云。加速視頻云不但提供大量基于標(biāo)準(zhǔn)服務(wù)器的資源，還具備更高性能和更高密度視頻處理的額外優(yōu)勢，以滿足當(dāng) 今用戶的需求。 使用標(biāo)準(zhǔn)服務(wù)器的期望 在過去 10 年，就資本和運(yùn)營支出兩方面而言，云數(shù)據(jù)中心解決方案的開發(fā)已創(chuàng)造出極具成本效益的業(yè)務(wù)模式。通過使用現(xiàn)成的商用 (COTS) 硬件并開發(fā)可使用智能協(xié)調(diào)器進(jìn)行控制的高度可靠和可擴(kuò) 展軟件，傳統(tǒng)的數(shù)據(jù)中心已成為企業(yè)和過頂 (OTT) 互聯(lián)網(wǎng)解決方案 提供商的標(biāo)準(zhǔn)。由于長期要求可靠性、可管理性和可用性(優(yōu)先級別更高)，此模式的優(yōu)勢在電信網(wǎng)絡(luò)中尚未實(shí)現(xiàn)。 在 ETSI 網(wǎng)絡(luò)功能虛擬化工作組(后文詳述)的幫助下，運(yùn)營商和 服務(wù)提供商開始嘗試在電信網(wǎng)絡(luò)中采用成熟的云技術(shù)，并嘗試解決此網(wǎng)絡(luò)的特殊要求。 現(xiàn)在，解決方案提供商也正在開發(fā) NFV 解決方案，為運(yùn)營商提供云網(wǎng)絡(luò)解決方案。 除了降低通向新市場的成本外，此方案還有很多優(yōu)勢。利用 COTS 硬件和軟件規(guī)模的優(yōu)勢，網(wǎng)絡(luò)設(shè)計(jì)、部署、管理和支持需要的資源 將減少。使用行之有效的解決方案進(jìn)行維護(hù)將會(huì)更輕松。另外，可在整個(gè)網(wǎng)絡(luò)中更快地測試、試驗(yàn)和推出虛擬平臺中運(yùn)行的新服務(wù)， 為運(yùn)營商提供了一種回報(bào)更快的路徑，并能更迅速取悅使用新技術(shù) 的消費(fèi)者。虛擬網(wǎng)絡(luò)還具有更大的可擴(kuò)展性。可推動(dòng)改進(jìn)整個(gè)數(shù)據(jù)中心的功耗、管理和支持，例如，戴爾平臺和服務(wù)已經(jīng)能夠?yàn)檫\(yùn)營 商提供理想的性能、密度、運(yùn)營成本和支持之間的平衡。 這些網(wǎng)絡(luò)數(shù)據(jù)中心的核心運(yùn)行組件是標(biāo)準(zhǔn)服務(wù)器。就資本和運(yùn)營支 出兩方面而言，標(biāo)準(zhǔn)服務(wù)器的設(shè)計(jì)目的是提供引人注目的財(cái)務(wù)狀 況。它們經(jīng)常被優(yōu)化以實(shí)現(xiàn)高可靠性、高性能和高密度，并可在數(shù)據(jù)中心或電信中心辦公室環(huán)境下運(yùn)行。例如，由兩個(gè) Intel? Xeon? E5 處理器驅(qū)動(dòng)的戴爾 PowerEdge? R720 2U COTS 服務(wù)器，提 供有交流或直流電源輸入、標(biāo)準(zhǔn)配置或符合 NEBS 級別 3 和 ETSI 標(biāo)準(zhǔn)的可選配置選配件，以滿足電信基礎(chǔ)架構(gòu)部署位置的各種要求。為了達(dá)成本白皮書的目的和解決方案，戴爾與雅特生密切合 作，推薦使用符合 NEBS L-3 標(biāo)準(zhǔn)的 PowerEdge? R720 運(yùn)營商級版本，它能滿足運(yùn)營商網(wǎng)絡(luò)的嚴(yán)苛要求;同時(shí)，戴爾還提供可在 現(xiàn)代高架地板數(shù)據(jù)中心使用的標(biāo)準(zhǔn)版本。通過結(jié)合本白皮書中提出 的加速視頻云方法論與戴爾 PowerEdge? R720，即可實(shí)現(xiàn)使用標(biāo) 準(zhǔn)服務(wù)器和大幅增加網(wǎng)絡(luò)視頻處理性能這兩個(gè)優(yōu)勢。 2013 年，使用英特爾第四代酷睿生產(chǎn)線，Intel? 推出 Iris Pro 處理 器圖形，它增加了 MPEG2 編碼器功能，通過增加更多的動(dòng)態(tài)預(yù)測 引擎提高視頻質(zhì)量，內(nèi)置 128MB DRAM，為 GPU 提供了高帶寬的內(nèi)存容量(70GB/s，而雙通道 DDR3 存儲(chǔ)接口為 25GB/s)。 在轉(zhuǎn)碼方面，高速視頻同步技術(shù)比其它架構(gòu)擁有更多優(yōu)勢。傳統(tǒng)的硬件固定功能提供低功率和高性能的解決方案，但如果需要更新編 碼，則無法快速變化。而軟件編解碼器以功率和性能為代價(jià)，提供 充分的靈活性。 通過利用硬件實(shí)現(xiàn)不變編解碼器的功能，利用 GPU 中的計(jì)算單元 上運(yùn)行的軟件實(shí)現(xiàn)可變編解碼器的功能，高速視頻同步技術(shù)能夠?qū)?現(xiàn)平衡的解決方案，功率低且性能高，同時(shí)保持日后改進(jìn)編解碼器所需的靈活性。 高速視頻同步解決方案由兩個(gè)主要元素構(gòu)成。“ENC” 由提供有效 動(dòng)作搜索的硬件加速(也稱作媒體采樣器)和在可編程的執(zhí)行單元 陣列上運(yùn)行的軟件構(gòu)成。“PAK” 重新使用來自多格式編解碼器引擎 的邏輯，提供完整的硬件單元進(jìn)行像素重建、量化、熵編碼等。 混合 2 級視頻編碼器 這種硬件和軟件組合允許高速視頻同步技術(shù)大大降低英特爾架構(gòu)上轉(zhuǎn)碼的功率要求，同時(shí)提高了性能。 這些數(shù)據(jù)塊通過多格式編解碼器引擎和視頻后期處理(例如，Deinterlacing、DeNoise 和一些其它過濾器)與硬件解碼加速相結(jié) 合，提供四級轉(zhuǎn)碼管道，且所有級能夠同時(shí)運(yùn)行，以實(shí)現(xiàn)高密度的直播/線性同時(shí)轉(zhuǎn)碼，速度比實(shí)時(shí)或離線轉(zhuǎn)碼要快數(shù)倍。 借助靈活的編碼器管道，Intel? 定位用于提高每一代的性能和視頻 質(zhì)量。在 Intel? 第二代酷睿和 Intel? 第四代酷睿之間，“平衡”(視頻質(zhì)量和性能)模式的性能大大提升，同時(shí)此模式的視頻質(zhì)量也得到提高。總的來說，Intel? 第四代酷睿中的 QSV 提高了各級 視頻質(zhì)量，超過了前代產(chǎn)品。 資源層，提供一套標(biāo)準(zhǔn)資源元素(包含計(jì)算、存儲(chǔ)和網(wǎng)絡(luò))。 對于需要消耗資源的應(yīng)用程序以及管理/協(xié)調(diào)應(yīng)用程序而言，這些資源是可見的，是硬件層物理實(shí)現(xiàn)的抽象概念 共享服務(wù)——硬件和上述資源接口之間的粘連層。這是虛擬 化存在的地方——虛擬機(jī)管理程序，可訪問虛擬機(jī) (VM) 和客 體操作系統(tǒng)，是所管理的所有計(jì)算單元之間的一個(gè)共享服務(wù) OpenStack 面板 —— 管理層，允許云服務(wù)提供商將資源分配 到用戶應(yīng)用程序(并提供收費(fèi)等輔助功能) 共享服務(wù)和(最重要的)資源元素駐留在“標(biāo)準(zhǔn)硬件”上 OpenStack 的目標(biāo)是提供一套管理集資源，完全獨(dú)立于基礎(chǔ)硬件。此方案有眾多優(yōu)勢——服務(wù)可隨著網(wǎng)絡(luò)條件和服務(wù)需求變化而轉(zhuǎn)換到其它服務(wù)器。 對于多數(shù)應(yīng)用程序，這一抽象效果很好。但是，有些應(yīng)用程序?qū)τ?jì)算或存儲(chǔ)或網(wǎng)絡(luò)資源有特殊要求，必須連接到更具體的硬件實(shí)例。 其中一個(gè)示例就是視頻轉(zhuǎn)碼。 有關(guān)“標(biāo)準(zhǔn)”硬件的注釋——“標(biāo)準(zhǔn)”并不意味著全能。各物理資源必 須提供認(rèn)可級別的性能(可以是 CPU、網(wǎng)絡(luò)帶寬、存儲(chǔ)能力或“特 殊”硬件要求)。 這些資源出現(xiàn)在管理面板中，可根據(jù)需要分配到用戶應(yīng)用程序。應(yīng) 用程序必須提供運(yùn)行所需的資源“配置文件”;面板允許服務(wù)提供商 將匹配的資源分配到應(yīng)用程序。 對于視頻轉(zhuǎn)碼，通過面板可提供大量視頻經(jīng)過優(yōu)化的資源。為每個(gè) 用戶/應(yīng)用程序建立策略以管理對轉(zhuǎn)碼功能的使用，這由面板強(qiáng)制 執(zhí)行。策略派生自服務(wù)級別，它極其靈活，能力具有彈性，例如： 臨時(shí)允許超額容量 以溢價(jià)成本提供超額容量 對于想要實(shí)施網(wǎng)絡(luò)功能虛擬化(NFV，此術(shù)語表示將網(wǎng)絡(luò)應(yīng)用與它們的基礎(chǔ)硬件分離)的運(yùn)營商/服務(wù)提供商，OpenStack 受到他們 的極大關(guān)注。換句話說，OpenStack 就是“適用于電信應(yīng)用的云基 礎(chǔ)架構(gòu)”。 SDN/NFV 標(biāo)準(zhǔn)化 ETSI 建立了行業(yè)標(biāo)準(zhǔn)化工作組 (ISG) 來研究是否需要 NFV 標(biāo)準(zhǔn)。 雖然 OpenStack 來自企業(yè)界，但集中協(xié)調(diào)虛擬化的資源這種概念 將是形成 NFV 標(biāo)準(zhǔn)的關(guān)鍵組成部分。OpenStack 或其運(yùn)營商級 版本可能會(huì)作為關(guān)鍵技術(shù)出現(xiàn)。 從基礎(chǔ)架構(gòu)上至管理和協(xié)調(diào)，ETSI NFV ISG 已經(jīng)在 NFV 的結(jié)構(gòu) 上建立了信息化工作。就其本身而論，這是對推薦做法的描述， 而不是如何實(shí)施 NFV 的任何標(biāo)準(zhǔn)，或來自多個(gè)供應(yīng)商的、很多用 戶使用的和許多服務(wù)提供商運(yùn)行的設(shè)備和軟件實(shí)際上將如何交互 操作的任何標(biāo)準(zhǔn)。但幾乎可以肯定的是，NFV ISG 將繼續(xù)工作兩 年，目標(biāo)是建立 NFV 的規(guī)范標(biāo)準(zhǔn)。 ISG 本身是由全球著名的服務(wù)提供商、設(shè)備制造商和獨(dú)立軟件供 應(yīng)商組成。可以公平地說，NFV 擁有廣泛且堅(jiān)定的行業(yè)支持，將 會(huì)成功推薦出標(biāo)準(zhǔn)方案來實(shí)施包括視頻在內(nèi)的眾多應(yīng)用。 多視頻處理資源的 SDN/NFV 控制 協(xié)調(diào)很多用戶可用的多個(gè)異構(gòu)視頻資源不是一項(xiàng)簡單的任務(wù)。事 實(shí)證明，OpenStack 在企業(yè)云環(huán)境下可擴(kuò)展性極大，期望形成的任何 NFV 標(biāo)準(zhǔn)都將擁有相同的可擴(kuò)展性。 但是，作為應(yīng)用程序的視頻與企業(yè)云應(yīng)用程序差異很大，應(yīng)該認(rèn) 真考慮。視頻傳輸是資源消耗的“完美風(fēng)暴”： 需要使用大容量存儲(chǔ)才能維持視頻內(nèi)容的數(shù)據(jù)庫視頻流從源格式到最終傳輸格式的轉(zhuǎn)碼(比特率、視頻格式、 屏幕尺寸等)需要消耗大量計(jì)算資源到最終用戶的流量傳遞幾乎是實(shí)時(shí)的;可用帶寬必須匹配轉(zhuǎn)碼器生成的流量 因此，協(xié)調(diào)器必須知道可用于視頻轉(zhuǎn)碼的資源，以及通過網(wǎng)絡(luò)獲得視頻數(shù)據(jù)包所需的帶寬。這是一個(gè)網(wǎng)絡(luò)邊緣問題(最終傳遞到 消費(fèi)者設(shè)備)。這對于中間處理也是一個(gè)問題，中間處理是將原 始的、集中化的內(nèi)容(通常來自制作者或播送者)轉(zhuǎn)碼，并推送到位于網(wǎng)絡(luò)邊緣(盡可能靠近最終消費(fèi)者)的多個(gè)實(shí)例。 另外一個(gè)考慮是假設(shè) OpenStack 控制(“協(xié)調(diào)”)虛擬資源——本 質(zhì)上，虛擬機(jī) (VM) ——通過其管理程序?qū)蛹右詫?shí)現(xiàn)，該層從底層硬件抽象出應(yīng)用程序執(zhí)行環(huán)境。服務(wù)器可支持多個(gè) VM，資源被 認(rèn)為在規(guī)模上有彈性。 視頻再次遇到了問題。如果轉(zhuǎn)碼從主機(jī) CPU 轉(zhuǎn)到一個(gè)加速器上，那 么 OpenStack 協(xié)調(diào)器需要知道加速器可用(且支持視頻功能)。更糟 糕的是，加速器架構(gòu)通常不使用 VM 技術(shù)，而是在 CPU 主操作系統(tǒng)上直接運(yùn)行(常用術(shù)語“裸機(jī)”描述非 VM 模式)。 OpenStack 如何協(xié)調(diào)直接映射到硬件的“執(zhí)行”資源?幸運(yùn)地是，這個(gè) 問題有解決方案：OpenStack 有一個(gè)插件(稱為 “Ironic”)用于協(xié)調(diào) 裸機(jī)資源。其 Northbound API 與管理 VM 的接口完全相同，但 Southbound 接口知道它管理單一的硬件資源。 將來，ETSI NFV 工作組將標(biāo)準(zhǔn)化這樣做所需的接口和基礎(chǔ)架構(gòu)。同 時(shí)，OpenStack 和 SDN 的互補(bǔ)技術(shù)將彌補(bǔ)此間隙。OpenStack 允許 協(xié)調(diào)資源時(shí)，SDN 利用 OpenFlow 協(xié)議配置網(wǎng)絡(luò)交換機(jī)，以提供與 要傳輸?shù)囊曨l流量一致的互連能力。OpenDaylight 等 SDN 控制器可協(xié)助協(xié)調(diào)流量。 另一種方法是，簡單地提供將視頻處理為“永遠(yuǎn)在線”所需的“最壞情 況”計(jì)算和網(wǎng)絡(luò)資源。因?yàn)樗峁┑馁Y源大部分時(shí)間不使用，這將導(dǎo) 致網(wǎng)絡(luò)的能力過剩(以及由此產(chǎn)生的成本)。 在 Hulu 模式中，視頻每天以批量“離線”的方式被處理和傳輸。“大眾 消費(fèi)事件”的情況甚至更加極端，例如大型體育賽事，其現(xiàn)場直播必 須緩存和實(shí)時(shí)處理。 通過組合使用 NFV (OpenStack) 和 SDN，資源僅在使用時(shí)被消費(fèi)和 付費(fèi)。資源可用性的彈性意味著，可以滿足意想不到級別的需求，而且無需事先過度配置。 這里所使用的 OpenStack、OpenFlow、OpenDaylight 等現(xiàn)有技術(shù)， 均為開源項(xiàng)目，開發(fā)人員可免費(fèi)使用以實(shí)施這些服務(wù)。 轉(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è)備不同，提供商可能會(huì)將此內(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)行肯定會(huì)導(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ì)量的瞬間降低，但重新緩 沖通常會(huì)導(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)是需要?jiǎng)?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)碼集更 加動(dòng)態(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)用以及這些分辨率上的動(dòng)作搜索。 來自編碼器的每個(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)之間(否則會(huì)進(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ò)功能虛擬化使提供商能夠動(dòng)態(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ù)。 |
