翟海波,車剛健
(中興通訊股份有限公司,江蘇南京 210000)
伴隨云計算技術發(fā)展,上“云”已經(jīng)成為一種趨勢。虛擬化技術作為云計算最重要的技術,從某種角度來說它是云計算的基石[1]。桌面虛擬化[2]作為虛擬化的一個重要解決方案,目的是使資源能按需分配、統(tǒng)一調(diào)度和管理,具有低能耗、低成本、安全性高、易于升級和維護等優(yōu)點,能為企業(yè)節(jié)省運營成本和維護成本。
多媒體視頻重定向在桌面虛擬化中是一個巨大挑戰(zhàn),尤其是在服務器資源有限、帶寬受到限制的情況下會面臨很多問題,如視頻卡頓、畫面和聲音延遲以及音視頻不同步等。目前針對視頻重定向大都是基于本地視頻,而對于在線視頻大都停留在Flash 播放的視頻,但Flash 視頻依賴于控件,用戶需要事先安裝該控件。此外,Adobe 公司已經(jīng)宣布停止對Flash 更新,F(xiàn)lash 退出歷史舞臺是遲早的事。隨著HTML5 技術的發(fā)展,尤其是其對視頻標簽的支持,促使各大廠商紛紛加入,如優(yōu)酷、土豆、騰訊等,給桌面虛擬化帶來了新的機遇和挑戰(zhàn)。本文研究了一種基于HTML5的在線視頻重定向方案。
桌面虛擬化,簡單說就是服務器通過虛擬化技術創(chuàng)建很多虛機,通過桌面協(xié)議與云終端進行交互后畫面回顯的一種解決方案,用戶訪問的桌面就像是訪問傳統(tǒng)的本地桌面一樣。目前市場上主流解決方案有Cirtix 公司的XenDesktop[3-5]、Vmware 公司的Horizon View[6]、Microsoft 的MED-V[7]以及中興的云電腦等,它們分別使用ICA、PCOIP、RDP、ICE 協(xié)議完成服務器與云終端之間的交互。盡管從解決方案的制定到協(xié)議的交互存在著差異,但無論哪種虛擬化解決方案總體都遵循如圖1 所示的網(wǎng)絡拓撲結構。
Fig.1 Desktop virtualization network architecture圖1 桌面虛擬化網(wǎng)絡拓撲架構
2012 年12 月萬維網(wǎng)聯(lián)盟(W3C)正式宣布HTML 5[8]規(guī)范完成,其新增的video 標記實現(xiàn)了多媒體支持,借助Vid?eo API 可以自定義HTML 視頻控件,瀏覽器不必再使用插件方式播放視頻,避免了插件的影響。在HTML5 技術出現(xiàn)之前,大部分Web 視頻播放是通過瀏覽器插件如Adobe Flash 實現(xiàn)的,這要求客戶在觀看視頻之前安裝相應的組件。文獻[9]指出HTML 5 使命是將Web 帶入一個成熟的平臺,在這個平臺上,視頻、音頻、圖像、動畫以及更多的智能設備交互被標準化。目前國內(nèi)外主流瀏覽器的最新版本均支持HTML5的主要特性[10],如IE 9+,F(xiàn)irefox,Chrome、Opera 以及Safari 都支持
在桌面虛擬化應用中,視頻重定向技術指服務器上部署的虛擬機播放視頻通過某種技術手段在客戶端或云終端進行渲染。文獻[12-14]介紹了該技術手段包括通道技術、鉤子技術以及基于WDDM 驅(qū)動等,實現(xiàn)有兩種方式:①將服務端的多媒體視頻播放圖像重新進行視頻編碼處理,然后將視頻編碼數(shù)據(jù)傳輸?shù)娇蛻舳诉M行解碼播放顯示;②視頻重定向方式,通過捕獲服務端播放器需要播放的視頻編碼流,直接將視頻編碼流發(fā)送到客戶端進行解碼播放顯示。
文獻[15]通過開發(fā)BHO 插件,結合鉤子技術攔截網(wǎng)頁視頻文件獲取視頻參數(shù)。在網(wǎng)絡允許的情況下將獲取的url 信息直接發(fā)往客戶端進行播放;在網(wǎng)絡受限的情況下將HTTP 請求數(shù)據(jù)轉(zhuǎn)發(fā)到客戶端進行播放,但該方法僅適用于老的Flash 播放器。在各大視頻網(wǎng)站紛紛支持HTML 5視頻標簽的形勢下,未來HTML5 視頻重定向必定是研究熱點之一。
基于HTML 5 播放視頻研究與Flash 視頻重定向相比,HTML 5 視頻重定向采用了一種全新方式。HTML5 視頻播放架構采用Windows Media Fundation(簡稱WMF)[16],該架構將取代較早的Dshow 播放架構;WMF 架構是由一套組件串起來的,類似于Dshow 的filter。通過把這些component 組合,形成pipeline,就可完成多媒體應用程序所需的各種功能。與directshow[17]鏈接filter 一樣,在保持filter 功能獨立性的同時又提供靈活多變的組合功能。Media Foundation提供了Media Pipeline 和Souce Reader &Sink Writer 兩種編程模型,本文采用的是Media Pipeline 模式,其核心組件如圖2 所示。
Fig.2 Media Pipeline model圖2 Media Pipeline 模式
使用一個端到端Pipeline,類似DShow 中使用Graph?Builder、Filter 的模式。
Media Session:控制貫穿Pipeline 的數(shù)據(jù)流動和處理任務(如質(zhì)量控制、視音頻同步、響應格式改變),類似DShow中的GraphBuilder。
Media Sources:類似DShow 中的Source Filters,接收來自本地文件或網(wǎng)絡的數(shù)據(jù)并交給后面組件處理。此外還進行音視頻數(shù)據(jù)解復用并輸出。
Media Foundation Transforms(MFTs):類似DShow 中的Transform Filters,用來接收Media sources 的輸入,然后完成解碼、轉(zhuǎn)換輸出。
Media Sink:類似DShow 中的Render,該組件用來進行最終數(shù)據(jù)的渲染。
本文通過截獲源數(shù)據(jù)改變原有的視頻數(shù)據(jù)流向,從而實現(xiàn)視頻數(shù)據(jù)的重定向。在了解WMF 播放結構后,通過替換原有的Media Source 就能截獲到原始數(shù)據(jù)。通過替換MFTs,一方面可以將真實數(shù)據(jù)通過網(wǎng)絡轉(zhuǎn)發(fā)到云終端上進行播放,另一方面為了MF 架構能夠正常運轉(zhuǎn),可以偽造RGB[18]數(shù)據(jù)和PCM 靜音數(shù)據(jù)交由系統(tǒng)處理。修改后的架構如圖3 所示。
Fig.3 MF reconstruction playback architecture圖3 MF 重構播放架構
各部件主要功能如下:①自研的Media Sources 對網(wǎng)絡接收到的音視頻數(shù)據(jù)進行解析和解封裝;②自研的MFTs一方面對真實音視頻數(shù)據(jù)通過網(wǎng)絡發(fā)送到云終端,另一方面?zhèn)卧霷GB 視頻數(shù)據(jù)和PCM 靜音數(shù)據(jù)交由系統(tǒng)Media Sink 處理;③Media Sink 完成音視頻播放和渲染;④云終端接收音視頻數(shù)據(jù)并進行解碼渲染。
本文設計的關鍵點是對RGB 數(shù)據(jù)構造以及對PCM 靜音數(shù)據(jù)構造。其中PCM 靜音數(shù)據(jù)以全0 的方式進行構造,相對比較簡單,但構造RGB 數(shù)據(jù)需要考慮多方面因素,目的是能夠通過像素對比進行視頻窗口區(qū)域的捕獲,具體需要從以下兩方面考慮:
(1)構造的RGB 數(shù)據(jù)需要與源視頻比例保持一致;即源視頻寬W 和原視頻高H 滿足如下公式:
其中:W1、H1分別表示原視頻的寬度和高度;W2、H2分別表示構造RGB 流的寬度和高度;這里W2 和H2 要盡可能小,這樣可有效降低渲染帶來的CPU 消耗。
(2)構造的RGB 數(shù)據(jù)盡量與Web 頁面像素不同,以便于查找整個源視頻區(qū)域。
本文以接近黑色像素RGB(2,1,3)來偽造視頻數(shù)據(jù),這樣一方面可使MF 播放架構正常運轉(zhuǎn),即讀取音視頻數(shù)據(jù)、解復用、解碼、渲染等步驟正常運行;另一方面,通過區(qū)域像素提取方法判斷源視頻區(qū)域大小S源,然后再計算視頻有效區(qū)域S有效或遮擋區(qū)域S遮擋。無遮擋窗口和有遮擋窗口場景如圖4 所示,為兩種有效區(qū)域。
2.2.1 視頻區(qū)域無窗口遮擋場景
如圖4(a)所示,步驟如下:
(1)獲取瀏覽器窗口區(qū)域,根據(jù)RGB 像素值是否為(2,1,3)并結合當前連續(xù)像素點是否超過某個閾值(如10),判定該區(qū)域是否為視頻區(qū)域。
Fig.4 Video playback scene圖4 視頻播放場景
(2)獲取視頻區(qū)域大小后,在內(nèi)存構建一張bitmap 兼容位圖,并對該位圖空間進行二值化處理。由于不存在遮擋區(qū)域,所有內(nèi)存區(qū)域全部賦值為1,表示全部都是有效視頻區(qū)域,此時滿足公式(2)。
2.2.2 視頻區(qū)域有窗口遮擋場景
如圖4(b),該場景顯然比無窗口遮擋場景要復雜許多,計算有效視頻區(qū)域步驟如下:
(1)計算視頻區(qū)域S源,同無窗口遮擋計算。
(2)同樣需要構建一張bitmap 兼容位圖,并對空間進行二值化處理,只是由于遮擋區(qū)域的連續(xù)RGB 像素值不滿足(2,1,3),因此賦值為0;無遮擋區(qū)域賦值為1。滿足以下公式:
(3)分割整個視頻區(qū)域,如mxn進行分割,應滿足條件m (4)循環(huán)查找分割點位置的像素是否為RGB(2,1,3)像素;如果不是則向左移動找到最近的(2,1,3)或直到邊緣位置,即為遮擋區(qū)域的left 值;同理分別向上、向右和向下移動得到top,rigth 以及bottom 值,根據(jù)(left,top,right,bottom)即可得到遮擋區(qū)域S1,同理得到遮擋區(qū)域S2和S3。 (5)把S 源和S 遮擋區(qū)域發(fā)往終端,終端再對S 遮擋區(qū)域進行裁剪,即可得到真正的S 有效區(qū)域,即視頻觀看區(qū)域。 在接收到虛機內(nèi)部發(fā)過來的數(shù)據(jù)后,根據(jù)終端能力或配置選擇,以硬解或軟解的方式進行解碼顯示和音頻播放。播放控制(如暫停、快進等)是在虛機內(nèi)部通過JavaS?cript 腳本進行控制,其播放架構如圖5 所示。 Fig.5 Terminal playback architecture圖5 終端播放架構 終端根據(jù)虛機發(fā)過來的視頻源S源區(qū)域創(chuàng)建播放器窗口,收到視頻數(shù)據(jù)后分別通過開源組件gstreamer[19]、FFm?peg 完成視頻的硬解[20]和軟解,解碼完成后在播放窗口區(qū)域進行渲染完成視頻數(shù)據(jù)的播放,然后根據(jù)S遮擋區(qū)域進行裁剪;當收到音頻數(shù)據(jù)后將AAC 數(shù)據(jù)解碼成PCM 原始數(shù)據(jù)放入聲卡中完成音頻播放。此外,終端通過音視頻數(shù)據(jù)幀PTS 時間戳完成音視頻的同步操作[21]。實現(xiàn)步驟如下: (1)防止終端處于小網(wǎng)環(huán)境,客戶端需接收虛機組件通知的目的端口,由終端側向虛機側建立音視頻鏈路。 (2)接收虛機側發(fā)來的視頻創(chuàng)建VideoReDirectCreate消息(包括寬高、幀率等),完成硬解或軟件的初始化工作。 (3)接收虛機側發(fā)來的音頻創(chuàng)建AudioReDirectCreate消息(包括格式和采樣率等),完成硬解或軟解的初始化工作。 (4)接收視頻數(shù)據(jù)VideoReDirectData(包括視頻數(shù)據(jù)和視頻裁剪區(qū)域),完成視頻數(shù)據(jù)的解碼、繪制、裁剪等工作。 (5)接收音頻數(shù)據(jù)AudioReDirectData,完成解碼和播放以及音視頻同步。音視頻同步方式較多,本文采用以音頻PTS 為基準對視頻進行同步的方式。 本文以全屏在線播放一段1 080p 視頻進行實驗。虛機內(nèi)部CPU 占用率對比如圖6 所示。從對比結果看,使用本文方法的虛機CPU 資源降低約70%~80%,解決了虛機播放視頻卡頓問題,緩解了服務器資源緊張。 桌面虛擬化目前已逐漸應用到電信、教育、醫(yī)療與金融等領域。隨著應用的推廣,流媒體播放帶來的挑戰(zhàn)越來越大。本文研究了最新標準HTML5 在線視頻,通過重構Media Foundation 的方式截獲源數(shù)據(jù),改變原有視頻數(shù)據(jù)流向,通過圖片二值化算法找到視頻區(qū)域,從而實現(xiàn)基于HT?ML5 視頻數(shù)據(jù)的重定向。該方案不僅節(jié)省了服務器資源,而且用戶觀看在線視頻時就像訪問本地視頻一樣,畫質(zhì)較非重定向要清晰很多。 Fig.6 Experimental results圖6 實驗結果 最初IE 瀏覽器只有優(yōu)酷視頻網(wǎng)站進行了HTML5 改造,嵌入了HTML5 視頻標簽,本文以此為突破口研究其播放架構和重構WMF 播放構架。之后新浪視頻網(wǎng)站進行了HTML5 改造,本文提出的方法能在不作任何修改的情況下在新浪使用,說明只要HTML5 視頻網(wǎng)站遵循WMF 播放架構,本文提出的HTML 5 視頻重定向技術就能使用。實踐證明該方法通用性強,對研究HTML5 視頻重定向技術具有一定參考價值。2.3 云終端播放器設計
3 實驗結果
4 結語