|
作者：雅特生科技公司軟件產(chǎn)品營銷高級總監(jiān) Jim Darroch、英特爾公司軟件設(shè)計師 Richard Dunphy、戴爾公司全球電信策略規(guī)劃師 Franklin Flint 視頻應(yīng)用對密度和高品質(zhì)處理的需求與日俱增，將廣播和通信網(wǎng)絡(luò)推向了極限。增加更多的設(shè)備來處理這些視頻流，從經(jīng)濟角度來講是不可行的。而且，運營商、服務(wù)提供商和內(nèi)容提供商注意到了在云端使用標準服務(wù)器的優(yōu)勢，想要擺脫 特殊設(shè)備或?qū)Ｓ糜布�。但目前標準服�?wù)器尚未針對云端視頻轉(zhuǎn)碼進行優(yōu)化。 因此，最佳解決方案是加速視頻云：標準服務(wù)器中的 PCI Express 視頻加速卡。 加速視頻云不但提供大量基于標準服務(wù)器的資源，還具備更高性能和更高密度視頻處理的額外優(yōu)勢，以滿足當今用戶的需求。 本文介紹了加速視頻云需求背后的市場驅(qū)動力，并討論了 OpenStack 等技術(shù)和其它開源平臺在轉(zhuǎn)向 SDN/NFV 網(wǎng)絡(luò)架 構(gòu)背景下的含義。然后，在總結(jié)部分例舉了現(xiàn)實生活中的應(yīng)用來說明性能和經(jīng)濟優(yōu)勢。 目前云端處理視頻流量的能力 消費者是改變廣播網(wǎng)絡(luò)格局的主要驅(qū)動力。用戶習慣正在從傳統(tǒng)的廣播轉(zhuǎn)變?yōu)殡娨曇曨l消費(請參閱以下圖表頂部的“線性”部分)，再到動態(tài)、按需提供、移動的視頻觀看(請參閱以下圖表底部的“多屏幕”部分)。 這給網(wǎng)絡(luò)帶來重負，因此，網(wǎng)絡(luò)正在快速擴展自身能力，以便同時處理傳統(tǒng)電纜/線性/廣播視頻分布和更動態(tài)的多屏幕視頻。相較于運營商喜好，多屏幕視頻更多地受到消費者喜好的推動。視頻的帶寬消耗不容忽視，按其網(wǎng)絡(luò)份額大小進行判斷時尤其如此。 例如，Sandvine 的《全球互聯(lián)網(wǎng)現(xiàn)象報告》(2014 年 6 月)表明，在高峰時期，實時娛樂占到下行字節(jié)的 63% 以上。 隨著多服務(wù)運營商(MSO)和電信服務(wù)提供商使用云技術(shù)來為 媒體市場提供足夠處理資源、流資源和存儲資源的比例不斷增 大，運營商的業(yè)務(wù)格局也轉(zhuǎn)向視頻。但是，目前的云端視頻性能水平離最理想水平還相差甚遠。 本文將使用 Intel?(英特爾)、戴爾和雅特生科技的最新技術(shù)， 通過虛擬轉(zhuǎn)碼解決方案來探索在云端承載視頻的更好方法，最終實現(xiàn)更高密度、更高部署靈活性。 解決方案 —— 加速視頻云 典型的云實施基于多個完全相同的服務(wù)器，這些服務(wù)器可根據(jù)需要 用于不同的任務(wù)，滿足應(yīng)用指定的不同規(guī)模和空間占用要求。處理器是大量云計算資源中的 NFV(網(wǎng)絡(luò)功能虛擬化基礎(chǔ)架構(gòu))節(jié)點。 但是對于視頻，用于視頻流的服務(wù)器比用于網(wǎng)頁瀏覽的服務(wù)器支持的用戶容量少得多。因此，需要向云服務(wù)器增加視頻處理和轉(zhuǎn)碼資 源。 運營商在云端使用標準服務(wù)器的比例不斷增大，而且無需特殊設(shè)備， 加上視頻應(yīng)用對密度和高品質(zhì)處理的需求與日俱增，因此最佳的解 決方案是加速視頻云。加速視頻云不但提供大量基于標準服務(wù)器的資源，還具備更高性能和更高密度視頻處理的額外優(yōu)勢，以滿足當 今用戶的需求。 使用標準服務(wù)器的期望 在過去 10 年，就資本和運營支出兩方面而言，云數(shù)據(jù)中心解決方案的開發(fā)已創(chuàng)造出極具成本效益的業(yè)務(wù)模式。通過使用現(xiàn)成的商用 (COTS) 硬件并開發(fā)可使用智能協(xié)調(diào)器進行控制的高度可靠和可擴 展軟件，傳統(tǒng)的數(shù)據(jù)中心已成為企業(yè)和過頂 (OTT) 互聯(lián)網(wǎng)解決方案 提供商的標準。由于長期要求可靠性、可管理性和可用性(優(yōu)先級別更高)，此模式的優(yōu)勢在電信網(wǎng)絡(luò)中尚未實現(xiàn)。 在 ETSI 網(wǎng)絡(luò)功能虛擬化工作組(后文詳述)的幫助下，運營商和 服務(wù)提供商開始嘗試在電信網(wǎng)絡(luò)中采用成熟的云技術(shù)，并嘗試解決此網(wǎng)絡(luò)的特殊要求。 現(xiàn)在，解決方案提供商也正在開發(fā) NFV 解決方案，為運營商提供云網(wǎng)絡(luò)解決方案。 除了降低通向新市場的成本外，此方案還有很多優(yōu)勢。利用 COTS 硬件和軟件規(guī)模的優(yōu)勢，網(wǎng)絡(luò)設(shè)計、部署、管理和支持需要的資源 將減少。使用行之有效的解決方案進行維護將會更輕松。另外，可在整個網(wǎng)絡(luò)中更快地測試、試驗和推出虛擬平臺中運行的新服務(wù)， 為運營商提供了一種回報更快的路徑，并能更迅速取悅使用新技術(shù) 的消費者。虛擬網(wǎng)絡(luò)還具有更大的可擴展性。可推動改進整個數(shù)據(jù)中心的功耗、管理和支持，例如，戴爾平臺和服務(wù)已經(jīng)能夠為運營 商提供理想的性能、密度、運營成本和支持之間的平衡。 這些網(wǎng)絡(luò)數(shù)據(jù)中心的核心運行組件是標準服務(wù)器。就資本和運營支 出兩方面而言，標準服務(wù)器的設(shè)計目的是提供引人注目的財務(wù)狀 況。它們經(jīng)常被優(yōu)化以實現(xiàn)高可靠性、高性能和高密度，并可在數(shù)據(jù)中心或電信中心辦公室環(huán)境下運行。例如，由兩個 Intel? Xeon? E5 處理器驅(qū)動的戴爾 PowerEdge? R720 2U COTS 服務(wù)器，提 供有交流或直流電源輸入、標準配置或符合 NEBS 級別 3 和 ETSI 標準的可選配置選配件，以滿足電信基礎(chǔ)架構(gòu)部署位置的各種要求。為了達成本白皮書的目的和解決方案，戴爾與雅特生密切合 作，推薦使用符合 NEBS L-3 標準的 PowerEdge? R720 運營商級版本，它能滿足運營商網(wǎng)絡(luò)的嚴苛要求;同時，戴爾還提供可在 現(xiàn)代高架地板數(shù)據(jù)中心使用的標準版本。通過結(jié)合本白皮書中提出 的加速視頻云方法論與戴爾 PowerEdge? R720，即可實現(xiàn)使用標 準服務(wù)器和大幅增加網(wǎng)絡(luò)視頻處理性能這兩個優(yōu)勢。 2013 年，使用英特爾第四代酷睿生產(chǎn)線，Intel? 推出 Iris Pro 處理 器圖形，它增加了 MPEG2 編碼器功能，通過增加更多的動態(tài)預(yù)測 引擎提高視頻質(zhì)量，內(nèi)置 128MB DRAM，為 GPU 提供了高帶寬的內(nèi)存容量(70GB/s，而雙通道 DDR3 存儲接口為 25GB/s)。 在轉(zhuǎn)碼方面，高速視頻同步技術(shù)比其它架構(gòu)擁有更多優(yōu)勢。傳統(tǒng)的硬件固定功能提供低功率和高性能的解決方案，但如果需要更新編 碼，則無法快速變化。而軟件編解碼器以功率和性能為代價，提供 充分的靈活性。 通過利用硬件實現(xiàn)不變編解碼器的功能，利用 GPU 中的計算單元 上運行的軟件實現(xiàn)可變編解碼器的功能，高速視頻同步技術(shù)能夠?qū)?現(xiàn)平衡的解決方案，功率低且性能高，同時保持日后改進編解碼器所需的靈活性。 高速視頻同步解決方案由兩個主要元素構(gòu)成。“ENC” 由提供有效 動作搜索的硬件加速(也稱作媒體采樣器)和在可編程的執(zhí)行單元 陣列上運行的軟件構(gòu)成�！癙AK” 重新使用來自多格式編解碼器引擎 的邏輯，提供完整的硬件單元進行像素重建、量化、熵編碼等。 混合 2 級視頻編碼器 這種硬件和軟件組合允許高速視頻同步技術(shù)大大降低英特爾架構(gòu)上轉(zhuǎn)碼的功率要求，同時提高了性能。 這些數(shù)據(jù)塊通過多格式編解碼器引擎和視頻后期處理(例如，Deinterlacing、DeNoise 和一些其它過濾器)與硬件解碼加速相結(jié) 合，提供四級轉(zhuǎn)碼管道，且所有級能夠同時運行，以實現(xiàn)高密度的直播/線性同時轉(zhuǎn)碼，速度比實時或離線轉(zhuǎn)碼要快數(shù)倍。 借助靈活的編碼器管道，Intel? 定位用于提高每一代的性能和視頻 質(zhì)量。在 Intel? 第二代酷睿和 Intel? 第四代酷睿之間，“平衡”(視頻質(zhì)量和性能)模式的性能大大提升，同時此模式的視頻質(zhì)量也得到提高。總的來說，Intel? 第四代酷睿中的 QSV 提高了各級 視頻質(zhì)量，超過了前代產(chǎn)品。 資源層，提供一套標準資源元素(包含計算、存儲和網(wǎng)絡(luò))。 對于需要消耗資源的應(yīng)用程序以及管理/協(xié)調(diào)應(yīng)用程序而言，這些資源是可見的，是硬件層物理實現(xiàn)的抽象概念 共享服務(wù)——硬件和上述資源接口之間的粘連層。這是虛擬 化存在的地方——虛擬機管理程序，可訪問虛擬機 (VM) 和客 體操作系統(tǒng)，是所管理的所有計算單元之間的一個共享服務(wù) OpenStack 面板 —— 管理層，允許云服務(wù)提供商將資源分配 到用戶應(yīng)用程序(并提供收費等輔助功能) 共享服務(wù)和(最重要的)資源元素駐留在“標準硬件”上 OpenStack 的目標是提供一套管理集資源，完全獨立于基礎(chǔ)硬件。此方案有眾多優(yōu)勢——服務(wù)可隨著網(wǎng)絡(luò)條件和服務(wù)需求變化而轉(zhuǎn)換到其它服務(wù)器。 對于多數(shù)應(yīng)用程序，這一抽象效果很好。但是，有些應(yīng)用程序?qū)τ嬎慊虼鎯蚓W(wǎng)絡(luò)資源有特殊要求，必須連接到更具體的硬件實例。 其中一個示例就是視頻轉(zhuǎn)碼。 有關(guān)“標準”硬件的注釋——“標準”并不意味著全能。各物理資源必 須提供認可級別的性能(可以是 CPU、網(wǎng)絡(luò)帶寬、存儲能力或“特 殊”硬件要求)。 這些資源出現(xiàn)在管理面板中，可根據(jù)需要分配到用戶應(yīng)用程序。應(yīng) 用程序必須提供運行所需的資源“配置文件”;面板允許服務(wù)提供商 將匹配的資源分配到應(yīng)用程序。 對于視頻轉(zhuǎn)碼，通過面板可提供大量視頻經(jīng)過優(yōu)化的資源。為每個 用戶/應(yīng)用程序建立策略以管理對轉(zhuǎn)碼功能的使用，這由面板強制 執(zhí)行。策略派生自服務(wù)級別，它極其靈活，能力具有彈性，例如： 臨時允許超額容量 以溢價成本提供超額容量 對于想要實施網(wǎng)絡(luò)功能虛擬化(NFV，此術(shù)語表示將網(wǎng)絡(luò)應(yīng)用與它們的基礎(chǔ)硬件分離)的運營商/服務(wù)提供商，OpenStack 受到他們 的極大關(guān)注。換句話說，OpenStack 就是“適用于電信應(yīng)用的云基 礎(chǔ)架構(gòu)”。 SDN/NFV 標準化 ETSI 建立了行業(yè)標準化工作組 (ISG) 來研究是否需要 NFV 標準。 雖然 OpenStack 來自企業(yè)界，但集中協(xié)調(diào)虛擬化的資源這種概念 將是形成 NFV 標準的關(guān)鍵組成部分。OpenStack 或其運營商級 版本可能會作為關(guān)鍵技術(shù)出現(xiàn)。 從基礎(chǔ)架構(gòu)上至管理和協(xié)調(diào)，ETSI NFV ISG 已經(jīng)在 NFV 的結(jié)構(gòu) 上建立了信息化工作。就其本身而論，這是對推薦做法的描述， 而不是如何實施 NFV 的任何標準，或來自多個供應(yīng)商的、很多用 戶使用的和許多服務(wù)提供商運行的設(shè)備和軟件實際上將如何交互 操作的任何標準。但幾乎可以肯定的是，NFV ISG 將繼續(xù)工作兩 年，目標是建立 NFV 的規(guī)范標準。 ISG 本身是由全球著名的服務(wù)提供商、設(shè)備制造商和獨立軟件供 應(yīng)商組成�？梢怨降卣f，NFV 擁有廣泛且堅定的行業(yè)支持，將 會成功推薦出標準方案來實施包括視頻在內(nèi)的眾多應(yīng)用。 多視頻處理資源的 SDN/NFV 控制 協(xié)調(diào)很多用戶可用的多個異構(gòu)視頻資源不是一項簡單的任務(wù)。事 實證明，OpenStack 在企業(yè)云環(huán)境下可擴展性極大，期望形成的任何 NFV 標準都將擁有相同的可擴展性。 但是，作為應(yīng)用程序的視頻與企業(yè)云應(yīng)用程序差異很大，應(yīng)該認 真考慮。視頻傳輸是資源消耗的“完美風暴”： 需要使用大容量存儲才能維持視頻內(nèi)容的數(shù)據(jù)庫視頻流從源格式到最終傳輸格式的轉(zhuǎn)碼(比特率、視頻格式、 屏幕尺寸等)需要消耗大量計算資源到最終用戶的流量傳遞幾乎是實時的;可用帶寬必須匹配轉(zhuǎn)碼器生成的流量 因此，協(xié)調(diào)器必須知道可用于視頻轉(zhuǎn)碼的資源，以及通過網(wǎng)絡(luò)獲得視頻數(shù)據(jù)包所需的帶寬。這是一個網(wǎng)絡(luò)邊緣問題(最終傳遞到 消費者設(shè)備)。這對于中間處理也是一個問題，中間處理是將原 始的、集中化的內(nèi)容(通常來自制作者或播送者)轉(zhuǎn)碼，并推送到位于網(wǎng)絡(luò)邊緣(盡可能靠近最終消費者)的多個實例。 另外一個考慮是假設(shè) OpenStack 控制(“協(xié)調(diào)”)虛擬資源——本 質(zhì)上，虛擬機 (VM) ——通過其管理程序?qū)蛹右詫崿F(xiàn)，該層從底層硬件抽象出應(yīng)用程序執(zhí)行環(huán)境。服務(wù)器可支持多個 VM，資源被 認為在規(guī)模上有彈性。 視頻再次遇到了問題。如果轉(zhuǎn)碼從主機 CPU 轉(zhuǎn)到一個加速器上，那 么 OpenStack 協(xié)調(diào)器需要知道加速器可用(且支持視頻功能)。更糟 糕的是，加速器架構(gòu)通常不使用 VM 技術(shù)，而是在 CPU 主操作系統(tǒng)上直接運行(常用術(shù)語“裸機”描述非 VM 模式)。 OpenStack 如何協(xié)調(diào)直接映射到硬件的“執(zhí)行”資源?幸運地是，這個 問題有解決方案：OpenStack 有一個插件(稱為 “Ironic”)用于協(xié)調(diào) 裸機資源。其 Northbound API 與管理 VM 的接口完全相同，但 Southbound 接口知道它管理單一的硬件資源。 將來，ETSI NFV 工作組將標準化這樣做所需的接口和基礎(chǔ)架構(gòu)。同 時，OpenStack 和 SDN 的互補技術(shù)將彌補此間隙。OpenStack 允許 協(xié)調(diào)資源時，SDN 利用 OpenFlow 協(xié)議配置網(wǎng)絡(luò)交換機，以提供與 要傳輸?shù)囊曨l流量一致的互連能力。OpenDaylight 等 SDN 控制器可協(xié)助協(xié)調(diào)流量。 另一種方法是，簡單地提供將視頻處理為“永遠在線”所需的“最壞情 況”計算和網(wǎng)絡(luò)資源。因為所提供的資源大部分時間不使用，這將導(dǎo) 致網(wǎng)絡(luò)的能力過剩(以及由此產(chǎn)生的成本)。 在 Hulu 模式中，視頻每天以批量“離線”的方式被處理和傳輸�！按蟊� 消費事件”的情況甚至更加極端，例如大型體育賽事，其現(xiàn)場直播必 須緩存和實時處理。 通過組合使用 NFV (OpenStack) 和 SDN，資源僅在使用時被消費和 付費。資源可用性的彈性意味著，可以滿足意想不到級別的需求，而且無需事先過度配置。 這里所使用的 OpenStack、OpenFlow、OpenDaylight 等現(xiàn)有技術(shù)， 均為開源項目，開發(fā)人員可免費使用以實施這些服務(wù)。 轉(zhuǎn)碼越來越多地被使用，其中一種情況是電視回看或追趕，內(nèi)容提供商接收來自多個制作者的內(nèi)容，并將其處理為可供訂閱者在次日觀看。此類提供商每天可接收數(shù)百小時的內(nèi)容，這些內(nèi)容需要轉(zhuǎn)碼為多種不同的格式，以便傳遞到許多設(shè)備。結(jié)果是需要轉(zhuǎn)碼數(shù)千小時的視頻。 例如，提供商正在從多個制作者那里接收 200 小時的內(nèi)容。根據(jù)所支持的設(shè)備不同，提供商可能會將此內(nèi)容制作成多達 100 種不同的轉(zhuǎn) 碼輸出，以解決其允許的任何消費者設(shè)備對編解碼器、分辨率、比特率等的不同需求。 為了使這個例子更簡單，我們假設(shè)，現(xiàn)在提供商將執(zhí)行 10 種不同的 1080p30 H.264 輸出。運行在標準的 1RU 雙 Intel? Xeon? E5-2650V2 處理器服務(wù)器上，服務(wù)器中每個 CPU 能夠處理大約 60 幀/秒的 X.264 轉(zhuǎn)碼(在 3.2GHz Intel? Core? i7-4770R 上以默認 CRF 快速模式 下的33fps 數(shù)據(jù)推斷得出);沒有虛擬化運行時，則每個服務(wù)器達到 120 幀/秒。但在云環(huán)境下，轉(zhuǎn)碼器將在虛擬機中運行，因此，我們 需要將此數(shù)字降低約10%，即每服務(wù)器總計約 108 幀/秒。 如果以 30 幀/秒轉(zhuǎn)碼 200 小時的內(nèi)容，系統(tǒng)需要轉(zhuǎn)碼 2.16 億幀才能實現(xiàn) 10 種輸出。速率為 108 幀/秒時，雙 Intel? Xeon? E5-2650v2 服務(wù)器將需要 556 小時來執(zhí)行此任務(wù)。而這對電視回看功能不是真正地有效。使用戴爾 R720T 等雙 E5-2650V2 2RU 服務(wù)器時，上述工 作量需要 24 個服務(wù)器(>1 機架)以 100% 最快速全天候不間斷運行，才能確保內(nèi)容能夠在 24 小時內(nèi)傳遞給消費者。以最快速全天候 不間斷運行肯定會導(dǎo)致數(shù)據(jù)中心故障，因此需要更多的服務(wù)器來分攤負荷，以確�？煽啃�。含有 2x Intel? Xeon? E5-2650V2 處理器的戴 爾 R720T 在有/無 4x Artesyn SharpStreamer? 卡時的比較： 另一種方法是在此類系統(tǒng)中使用 Artesyn SharpStreamer? 卡。 在帶有 4 個 Intel? Core? i7-4650U CPU 且每個 CPU 節(jié)點分 別能夠傳遞 120-240 幀/秒的 1080p 轉(zhuǎn)碼的條件下，提供商就可以進一步提高每個服務(wù)器的效率。在這種配置下，配合 CPU 內(nèi)核上的軟件，一臺含有雙 Intel? Xeon? E5-2650V2 和四個 Sharp Streamer 卡的服務(wù)器可有效地達到約 4000 幀/秒。為了與 Intel? Xeon? E5-2650V2 軟件解決方案做比較，我們將專注于在 平衡質(zhì)量模式(Intel MediaSDK 目標使用 = 4)下每節(jié)點 180 幀/ 秒的中間值，因此四張 PCIe 卡以 2880 幀/秒進行處理。這個解 決方案能夠通過單個服務(wù)器在 21 小時內(nèi)將 200 小時的內(nèi)容處理 為 10 種單獨的輸出，服務(wù)器數(shù)量僅需另一方案的 1/24，功率降 低至 1/11，成本更是減少至 1/5 以下。 而 10x 1080p30 轉(zhuǎn)碼可能不是此種部署的真正代表，可以想象得 出，提供商將需要提供更多計算，例如，一個 1080p30 大致相 當于單個 720p60。還應(yīng)注意，200 小時僅代表許多內(nèi)容提供商接收的總小時數(shù)的一部分。 實時/線性 ABR 廣播轉(zhuǎn)碼器需求 對于消費者而言，一天內(nèi)的直播電視觀看習慣隨時改變。如今，IPTV 提供商必須做到不僅能傳遞至他們機頂盒中的已知實體，而且需要適應(yīng)消費者觀看他們內(nèi)容所使用的大量設(shè)備，例如平板電腦、手機、第三方電視(如 Roku?、Apple TV 和亞馬遜的 Fire TV)。廣播電視提供商提供在線電視門戶網(wǎng)站時也面臨類似 的挑戰(zhàn)。結(jié)果就是 IPTV 提供商現(xiàn)在需要能夠以最小延遲實時生成大量不同的轉(zhuǎn)碼格式。 為了適應(yīng)網(wǎng)絡(luò)擁塞，大多數(shù)提供商已轉(zhuǎn)向自適應(yīng)比特率技術(shù)，例 如蘋果的 HLS、Silverlight、PlayReady 等，其允許消費者設(shè)備決 定是否需要切換到不同的配置文件，以確保內(nèi)容能夠連續(xù)播放。在多數(shù)情況下，消費者愿意容忍視頻質(zhì)量的瞬間降低，但重新緩 沖通常會導(dǎo)致消費者改變頻道或改變提供商。自適應(yīng)流試圖通過 將視頻切割為某一時間段(例如，2-4 秒)的多個區(qū)塊，并使客 戶端能夠在偽播放列表(稱作清單)中使用這些區(qū)塊，來幫助消 費者設(shè)備適應(yīng)網(wǎng)速和帶寬的變化。 此清單為客戶端提供相關(guān)數(shù)據(jù)，展示什么配置文件適用于特定時間索引以及要請求的必要文件是什么。消費者設(shè)備請求其所需的 配置文件，并監(jiān)控下載時間，如果時間不能滿足維持播放率所需 的時間，設(shè)備將請求較低級的配置文件并監(jiān)控，最終可能需要重新緩沖，但是，已經(jīng)配置好的設(shè)備將能夠在需要重新緩沖前及時 為播放器獲得下載的配置文件，除非網(wǎng)絡(luò)出現(xiàn)嚴重問題。 自適應(yīng)流的缺點是需要創(chuàng)建不同的配置文件。在多數(shù)情況下，提供商不僅需要為其目標設(shè)備處理多種自適應(yīng)流技術(shù)，還需要適應(yīng)各種 設(shè)備所支持的不同分辨率、編解碼器配置文件、比特率等。這將導(dǎo) 致單個信道需要很多轉(zhuǎn)碼。最糟糕的情況是，允許訪問內(nèi)容的每個設(shè)備類型在線且訪問每個信道的內(nèi)容。信道越多，發(fā)生這種情況的 可能性就越小，但提供商需要在規(guī)劃網(wǎng)絡(luò)時知道峰值數(shù)。 通常情況下，全天將有一套通用轉(zhuǎn)碼集，大部分不是所有設(shè)備都需要，它們可以根據(jù)需要打包到各種所需的自適應(yīng)流配置文件中。另 一套轉(zhuǎn)碼集用于傳遞特定設(shè)備所需的特殊呈現(xiàn)形式，但此轉(zhuǎn)碼集更 加動態(tài)，具體取決于觀看習慣。例如，許多人在醒來時使用帶有機頂盒的電視機或其它設(shè)備，然后轉(zhuǎn)到更加便攜的設(shè)備，例如便攜式 計算機、手機等。 關(guān)于眾多信道間的趨勢：將在一組信道上有波峰，而其它信道上有波谷。使用基于 Intel? XeonTM 的服務(wù)器上的虛擬化時，系統(tǒng)能夠根 據(jù)需要帶來更多的在線轉(zhuǎn)碼器，并配置它們以制作各種目標設(shè)備所需的呈現(xiàn)形式，方法是實施多比特率轉(zhuǎn)碼器，該轉(zhuǎn)碼器為傳入視頻 解碼、調(diào)整到所需分辨率并在發(fā)送到分割器以將流分割為分斷文件 之前編碼為特定格式，然后發(fā)送到包裝程序，按照消費者設(shè)備所要求的自適應(yīng)比特率標準打包到所需包裝。 對于高效的多比特率轉(zhuǎn)碼器，視頻解碼應(yīng)出現(xiàn)一次，并用作所有編碼輸出的單個參考;而編碼器稍加優(yōu)化即可降低各種輸出分辨 率的縮放費用以及這些分辨率上的動作搜索。 來自編碼器的每個輸出都是圖片組 (GOP) 和排列的順序(編碼與 顯示)，這一點很重要。因此，在提交到包裝程序之前，來自分割器的結(jié)果片段都是正確排列。 此類運行軟件轉(zhuǎn)碼器的多比特率轉(zhuǎn)碼器服務(wù)器所面臨的挑戰(zhàn)，是 確保所需的所有不同的呈現(xiàn)形式都在單個服務(wù)器上生成。如果所 需呈現(xiàn)形式超出服務(wù)器能力，系統(tǒng)將需要為傳入視頻復(fù)制解碼器，以便原始基帶視頻無需通過系統(tǒng)之間(否則會進一步增加延 遲)，這要求每個流上有相當大的網(wǎng)絡(luò)帶寬(對于 1080p30 8bit YUV 內(nèi)容，約為 500Mbps)。另外，這兩個系統(tǒng)將需要保持同 步，以確保輸出呈現(xiàn)形式為 GOP 和排列的順序，這是成功分割 的關(guān)鍵。 使用已啟用 Artesyn SharpStreamer 卡的系統(tǒng)時，所提供的密度允許 實現(xiàn)更多呈現(xiàn)形式，而且允許單個服務(wù)器上能適應(yīng)更多信道。戴爾 RT720p Dual Intel? Xeon? E5-2650V2 處理器系統(tǒng)有可能輸出六個單 獨的 1080p30 流，配備四個 SharpStreamer 卡的相同系統(tǒng)能適應(yīng)多 達 96 個單獨的 1080p30 流，每個服務(wù)器的轉(zhuǎn)碼能力提高 16 倍。 在 SharpStreamer 加速的平臺上，功率要求也縮小七倍：以前需要16 個服務(wù)器共 7604W，現(xiàn)在只需 1056W 即可處理 96 個流。 啟用 SharpStreamer 卡的系統(tǒng)允許提供商快速使網(wǎng)絡(luò)適應(yīng)消費者設(shè)備的按需需求。 總結(jié)：此方案的優(yōu)勢 使用上述兩種方案時，通過虛擬網(wǎng)絡(luò)中的視頻加速可實現(xiàn)眾多優(yōu)勢。 優(yōu)勢一：降低資本設(shè)備支出 加速方案的優(yōu)勢主要來自服務(wù)器在數(shù)據(jù)中心所占用空間的減少和管理這些資源的簡化。網(wǎng)絡(luò)功能虛擬化使提供商能夠動態(tài)地改變所需資源 類型和級別，并且這適用于上述使用情況下作為 VNF 的視頻轉(zhuǎn)碼。 優(yōu)勢二：省電并降低間接費用 優(yōu)勢三：可擴展性 當網(wǎng)絡(luò)要求增加或減少視頻轉(zhuǎn)碼時，也能以較低成本擴大或縮小資源，這是因為可通過附加卡達到視頻轉(zhuǎn)碼數(shù)量，從而減少服務(wù)器數(shù)量。如上所述，網(wǎng)絡(luò)中服務(wù)器的數(shù)量減少，有利于大幅降低運營成本。因此，如同服務(wù)提供商通過增加服務(wù)來提供優(yōu)質(zhì)的 OTT 視頻服務(wù)，附 加卡能逐漸提高所需的密度級別，但資本設(shè)備支出沒有目前的傳統(tǒng)方法那么高昂。 優(yōu)勢四：使用簡單，通過云端通用 X86 處理即可實現(xiàn) 基于 x86 的方法用來解決云端視頻處理問題，對設(shè)備供應(yīng)商而言具有重要優(yōu)勢，原因在于英特爾技術(shù)提供熟悉且簡單易用的 API 來加速 開發(fā)和上市時間。Intel? Media SDK 可實現(xiàn)從純軟件模式到媒體加速模式的轉(zhuǎn)變，同時具備運行 Windows、Linux、QuickSync video 和 API 庫的能力，甚至能以更高密度的容量為視頻應(yīng)用傳遞最大的每機架單位流數(shù)。 |
