潘涵洋　于　翔　葉德建

(復(fù)旦大學(xué)軟件學(xué)院　上海 201203) (網(wǎng)絡(luò)信息安全審計與監(jiān)控教育部工程研究中心　上海 201203)

?

一種基于細(xì)分行業(yè)云的OTT流媒體視頻終端軟件設(shè)計

潘涵洋于翔葉德建*

(復(fù)旦大學(xué)軟件學(xué)院上海 201203) (網(wǎng)絡(luò)信息安全審計與監(jiān)控教育部工程研究中心上海 201203)

摘要針對流媒體視頻服務(wù)細(xì)分行業(yè)的云化趨勢，基于細(xì)分行業(yè)云平臺為OTT業(yè)務(wù)提供的支持，設(shè)計具有模塊化架構(gòu)的OTT流媒體視頻終端軟件，給出其與云平臺交互進(jìn)行迭代更新以及流媒體視頻質(zhì)量保障播控機(jī)制的實(shí)現(xiàn)方案。應(yīng)用和測試結(jié)果表明，該終端軟件在實(shí)現(xiàn)功能需求的前提下對終端系統(tǒng)資源的使用較少，其流媒體視頻質(zhì)量監(jiān)控方法較之傳統(tǒng)方法更適用于Android平臺和HLS(Http Live Streaming)協(xié)議且具有良好的精確性、調(diào)控效果和性能表現(xiàn)，可實(shí)際用于云平臺對終端的管控。

關(guān)鍵詞流媒體視頻終端軟件細(xì)分行業(yè)云OTT AndroidHLS

0引言

OTT業(yè)務(wù)等流媒體視頻業(yè)務(wù)作為重要的互聯(lián)網(wǎng)應(yīng)用，近年來業(yè)務(wù)規(guī)模持續(xù)增長，其中以智能電視和機(jī)頂盒為終端的網(wǎng)絡(luò)流量占用預(yù)計在2018年達(dá)到消費(fèi)者總流量的11%以上[1]。隨著業(yè)務(wù)量的上升其運(yùn)營中必然將遇到越來越多前所未見的問題，靠傳統(tǒng)的客戶運(yùn)維模式難以解決；同時，運(yùn)營商在運(yùn)營過程中還需要面對保障視頻服務(wù)質(zhì)量、視頻廣告推送、包括機(jī)頂盒在內(nèi)的多種智能終端管控等具有行業(yè)特色的業(yè)務(wù)需求。針對細(xì)分行業(yè)的業(yè)務(wù)特性、充分利用云計算的優(yōu)勢增加產(chǎn)品附加價值、提升用戶黏度、促進(jìn)行業(yè)轉(zhuǎn)型，構(gòu)建細(xì)分行業(yè)的業(yè)務(wù)云是必然趨勢。

細(xì)分行業(yè)云為流媒體視頻業(yè)務(wù)的發(fā)展提供了更有力的支撐，流媒體視頻終端軟件作為直接影響最終用戶體驗(yàn)的服務(wù)提供者與之對接，其設(shè)計和實(shí)現(xiàn)上勢必需要調(diào)整。而現(xiàn)有國內(nèi)關(guān)于以O(shè)TT為代表的流媒體視頻業(yè)務(wù)細(xì)分行業(yè)的云化研究成果較少。文獻(xiàn)[2]根據(jù)廣電OTT業(yè)務(wù)提出了流媒體支撐系統(tǒng)平臺的設(shè)計，但并未提到云計算技術(shù)的使用，也沒有對以機(jī)頂盒為終端的終端軟件設(shè)計進(jìn)行說明。國外類似的流媒體視頻業(yè)務(wù)細(xì)分行業(yè)云系統(tǒng)則有Comcast公司的X1平臺，其終端采用了自行開發(fā)操作系統(tǒng)的專用機(jī)頂盒，在靈活性上有所欠缺，且對于云平臺的使用集中在錄播存儲之上，缺乏對終端管控的描述。

針對這樣的研究現(xiàn)狀和應(yīng)用場景，本文分析了細(xì)分行業(yè)云對OTT業(yè)務(wù)提供的技術(shù)支撐，由此在具有相對較高開放性、設(shè)備兼容性以及廣泛市場的Android平臺上設(shè)計了與之對接的OTT流媒體視頻終端軟件，并描述了其部分關(guān)鍵實(shí)現(xiàn)。該設(shè)計除引入日志收集用于云端分析、與云平臺交互進(jìn)行更新等終端管控機(jī)制外，同時基于HLS協(xié)議的特性在應(yīng)用軟件層面設(shè)計了適用于Android平臺終端的流媒體視頻質(zhì)量監(jiān)測和調(diào)控方法，為通過云平臺對OTT終端進(jìn)行管控從而進(jìn)一步推進(jìn)OTT業(yè)務(wù)的發(fā)展提供了一種技術(shù)方案。

1細(xì)分行業(yè)云支持

從云平臺架構(gòu)本身的特性來看，流媒體視頻服務(wù)細(xì)分行業(yè)云為OTT業(yè)務(wù)提供了計算和存儲能力的線性可擴(kuò)展性支持。通過虛擬化技術(shù)對物理機(jī)CPU和內(nèi)存資源進(jìn)行統(tǒng)一管理并使用鏡像生成虛擬機(jī)，云平臺可快速添加應(yīng)用結(jié)點(diǎn)達(dá)到服務(wù)能力的線性擴(kuò)展[3]。這意味著云平臺可以承受更多的終端請求和日志反饋壓力，對終端管控而言這一能力不可或缺。另外通過使用對象存儲技術(shù)，流媒體視頻服務(wù)細(xì)分行業(yè)云可以對大至視頻文件、小至文本文件的文件資源進(jìn)行具有高可靠性的分布式存儲和快速訪問，其中包括對終端軟件安裝包的存儲管理，這對于終端軟件的高頻度迭代更新具有幫助作用。

而流媒體視頻服務(wù)細(xì)分行業(yè)云作為業(yè)務(wù)云，除上述基礎(chǔ)設(shè)施層面外，在業(yè)務(wù)層面又為OTT業(yè)務(wù)提供了多種具有行業(yè)特色的服務(wù)，包括：

(1) 云推送

運(yùn)營商可通過基于XMPP協(xié)議的云推送服務(wù)向指定終端或終端組精確推送包含文字、視頻等內(nèi)容的實(shí)時或定時推送信息，可作為信息公開的手段有助于與終端用戶的溝通從而提高用戶體驗(yàn)質(zhì)量，也便于開展廣告業(yè)務(wù)。

(2) 云轉(zhuǎn)碼

可使用云轉(zhuǎn)碼服務(wù)對片源進(jìn)行在線和離線轉(zhuǎn)碼存儲在云端，便于引入多碼率切換機(jī)制達(dá)到視頻的流暢播放，也可針對不同的終端分辨率和解碼能力進(jìn)行轉(zhuǎn)碼，為實(shí)現(xiàn)多屏互動功能做準(zhǔn)備。

(3) 視頻服務(wù)用戶體驗(yàn)質(zhì)量保障

監(jiān)控視頻服務(wù)用戶體驗(yàn)質(zhì)量是終端管控的重要內(nèi)容。影響流媒體視頻服務(wù)用戶體驗(yàn)質(zhì)量的主要因素為視頻播放的啟動時間長短、視頻播放過程中視頻緩沖區(qū)下溢造成的卡頓以及視頻源本身的清晰度[4]。云平臺可使用基于內(nèi)存緩存的實(shí)時計算框架對帶寬資源進(jìn)行統(tǒng)一調(diào)度，根據(jù)歷史數(shù)據(jù)和終端信息為終端視頻播放請求進(jìn)行初始視頻碼率和CDN的選擇從而達(dá)到啟動時間長度和視頻源清晰度的平衡，并在播放過程中根據(jù)終端實(shí)時反饋的視頻數(shù)據(jù)下載速率等情況進(jìn)行CDN切換、碼率切換等指令的下發(fā)，從而減少卡頓，進(jìn)一步保障用戶體驗(yàn)質(zhì)量。

(4) 個性化推薦

云端大數(shù)據(jù)分析平臺可以通過對用戶行為數(shù)據(jù)的分析為用戶做出個性化的服務(wù)內(nèi)容推薦，優(yōu)化用戶體驗(yàn)，從而提升用戶黏度。

上述服務(wù)對于終端用戶具有直接價值。此外，在運(yùn)營中細(xì)分行業(yè)云還可通過終端日志的收集進(jìn)行及時的故障排查，下發(fā)控制指令進(jìn)行終端參數(shù)的調(diào)整，通過基于云平臺的迭代更新進(jìn)行終端故障的快速修復(fù)，并可通過大數(shù)據(jù)分析結(jié)果為運(yùn)營策略提供一定的指導(dǎo)。

由上可知細(xì)分云平臺的支持除了良好的可擴(kuò)展性便于擴(kuò)大業(yè)務(wù)規(guī)模外，也使終端有能力提供更好的用戶體驗(yàn)質(zhì)量和更加豐富和個性化的服務(wù)，其對終端的管控能力有助于OTT服務(wù)提供商進(jìn)行業(yè)務(wù)運(yùn)維和系統(tǒng)更新。為了與細(xì)分行業(yè)云平臺對接，OTT終端軟件除了流媒體視頻直播、點(diǎn)播等基本功能外還需要實(shí)現(xiàn)以下功能需求：一是集成推送客戶端，可以處理多種媒體推送內(nèi)容的下載、解析和繪制；二是在播放器中集成對流媒體視頻質(zhì)量的監(jiān)測和控制機(jī)制；三是需要進(jìn)行日志收集，為云平臺的大數(shù)據(jù)分析提供原始數(shù)據(jù)；四是需要能夠接收和處理云平臺發(fā)出的控制指令，而非僅作為請求端向云平臺請求媒體資源或進(jìn)行消息上報。

2模塊設(shè)計

根據(jù)上述分析本文基于Android平臺設(shè)計了具有模塊化架構(gòu)的OTT流媒體視頻終端軟件，其模塊組成以及模塊間依賴關(guān)系如圖1所示。

圖1　OTT流媒體視頻終端軟件模塊化架構(gòu)示意圖

下面對幾個主要的功能模塊的設(shè)計進(jìn)行說明。

2.1界面繪制模塊

終端軟件圖形界面的設(shè)計模式主要分為兩種：一是使用基于平臺提供的控件進(jìn)行界面繪制，通過為控件注冊監(jiān)聽函數(shù)實(shí)現(xiàn)用戶交互效果；二是基于網(wǎng)頁進(jìn)行開發(fā)，通過網(wǎng)頁腳本實(shí)現(xiàn)交互和跳轉(zhuǎn)。本文在設(shè)計中選用第一種模式，主要基于以下考慮：首先，終端桌面入口程序需要迅速在開機(jī)后展示界面，使用控件進(jìn)行界面繪制較之網(wǎng)頁載入更為快速，且在沒有網(wǎng)絡(luò)接入的情況下仍能提供良好的用戶體驗(yàn)，使用戶可以繼續(xù)使用無需網(wǎng)絡(luò)接入的部分功能；其次，在終端設(shè)備由服務(wù)運(yùn)營商提供的情況下可選擇統(tǒng)一的終端平臺，無需過多考慮界面的跨平臺問題，因此網(wǎng)頁開發(fā)在此方面不具有明顯優(yōu)勢；另外，由于后端云平臺的支持，采用控件制作界面也可在后續(xù)開發(fā)中方便地進(jìn)行快速迭代更新，使用更換網(wǎng)頁的方式進(jìn)行更新與之相比優(yōu)勢也不甚明顯；最后，運(yùn)營商所關(guān)心的提升附加值功能包括滾動字幕、廣告推送等需要在可切換的底層功能界面之上進(jìn)行動態(tài)疊加繪制，且推送內(nèi)容因具體用戶而異，使用網(wǎng)頁開發(fā)難以達(dá)到理想的效果。因而本文使用控件進(jìn)行界面繪制，并在首頁界面中對時間、地點(diǎn)、天氣等需要訪問云平臺服務(wù)的控件進(jìn)行了封裝，便于迭代更新中的開發(fā)重用。

2.2流媒體視頻播控模塊

流媒體視頻業(yè)務(wù)是OTT運(yùn)營的價值基礎(chǔ)，在設(shè)計中需要考慮如何有效監(jiān)測流媒體視頻質(zhì)量并且加以管控。直接使用Android平臺自帶的播放器對視頻源進(jìn)行播放其封閉性過高，難以獲得播放過程中出現(xiàn)的卡頓等視頻質(zhì)量問題，更無法在問題出現(xiàn)時進(jìn)行播放策略的調(diào)控、減輕對用戶體驗(yàn)的負(fù)面影響；而使用第三方的軟解碼庫自行編寫播放器又失去了機(jī)頂盒作為流媒體視頻應(yīng)用專用設(shè)備具有的硬件解碼優(yōu)勢。為此本文在原有終端播放器之上實(shí)現(xiàn)了流媒體視頻播控模塊，其主要設(shè)計思想即在播放器與實(shí)際視頻源服務(wù)器之間插入一個代理層，主要實(shí)現(xiàn)兩方面功能：一是自行下載流媒體視頻數(shù)據(jù)，可在下載過程中有效地對下載速度和碼率選擇進(jìn)行檢測和控制；二是可以檢測播放器對流媒體視頻數(shù)據(jù)的請求情況，通過比較代理下載進(jìn)度和請求進(jìn)度判斷出可能出現(xiàn)的播放緩沖下溢情況，并與云平臺協(xié)作調(diào)整下載策略。其詳細(xì)設(shè)計和關(guān)鍵實(shí)現(xiàn)將在第4節(jié)中進(jìn)行具體說明。

2.3配置管理模塊

終端軟件在工作過程中需要使用到大量參數(shù)，包括后端云平臺各服務(wù)接口的地址、日志上報的等級和周期、用戶賬號信息等。為了能對這些參數(shù)進(jìn)行靈活配置，便于終端的遠(yuǎn)程管理以及運(yùn)行過程中避免重復(fù)獲取參數(shù)降低效率，在終端軟件中設(shè)計了配置管理模塊，該模塊包括主要包括本地持久化以及控制和訪問接口。在開機(jī)過程中，終端軟件會在系統(tǒng)初始化完畢后嘗試從本地配置文件中讀取相關(guān)信息，若讀取成功則將信息緩存在內(nèi)存之中便于其他模塊訪問，若讀取失敗或信息不存在則對可從系統(tǒng)獲取的參數(shù)進(jìn)行讀取并寫入文件，對其他參數(shù)則提供默認(rèn)值。通過配置管理模塊獲取參數(shù)的模塊還可注冊監(jiān)聽器，當(dāng)參數(shù)經(jīng)由配置管理模塊的控制接口被修改時配置管理模塊會通知使用該參數(shù)的相應(yīng)模塊，使其作出諸如使參數(shù)立即生效等必要的響應(yīng)。

2.4推送客戶端模塊

為了與云平臺推送服務(wù)進(jìn)行對接，推送客戶端模塊在設(shè)計中使用了XMPP協(xié)議進(jìn)行終端在云平臺推送服務(wù)器上的注冊、登錄和消息收發(fā)。在收到消息后推送客戶端模塊會在對其進(jìn)行解析后根據(jù)具體消息類型與其他模塊進(jìn)行協(xié)同處理。首先，云推送服務(wù)中的滾動字幕、首頁留言等文字信息推送內(nèi)容可以直接包含在消息之中，推送客戶端模塊即將其交由上層推送內(nèi)容繪制模塊進(jìn)行調(diào)度和繪制。其次，云推送服務(wù)中的視頻推送內(nèi)容則以資源地址的形式包含在消息之中，需要交由流媒體視頻播控模塊進(jìn)行下載和播放。最后，云平臺控制指令例如配置參數(shù)調(diào)整和診斷指令同樣也可由此模塊進(jìn)行接收識別，再交由配置管理模塊進(jìn)行處理。同時該模塊內(nèi)包含保護(hù)機(jī)制，在與云平臺推送服務(wù)器連接中斷時可以自動檢測重連。

2.5第三方軟件管理模塊

為用戶提供第三方軟件可以在一定程度上提升用戶黏度，帶來更多的附加價值，為此在OTT流媒體視頻終端軟件中還設(shè)計了第三方軟件管理模塊。該模塊首先通過集成市場類應(yīng)用為用戶精選推薦應(yīng)用；其次通過提取應(yīng)用包名關(guān)鍵詞的方式對終端上已安裝的應(yīng)用進(jìn)行分類，便于用戶的查找使用；最后在首頁還提供進(jìn)入第三方軟件的快捷方式，基于日志收集模塊統(tǒng)計的用戶對各第三方軟件的使用頻度作智能設(shè)置，也可讓用戶自行編輯，使用戶得到更好的使用體驗(yàn)。

2.6日志收集模塊

日志收集模塊是流媒體視頻終端軟件與細(xì)分行業(yè)云對接的重要部分，該模塊向其他模塊提供接口記錄日志信息，其主要分類如表1所示。

表1　日志信息分類

當(dāng)其他模塊調(diào)用日志收集模塊的相關(guān)接口時，日志收集模塊會判斷當(dāng)前日志的對應(yīng)開關(guān)是否打開或是否達(dá)到從配置管理模塊中獲取的日志最低收集等級，如滿足收集條件則將其打上時間戳放入消息隊列進(jìn)行異步發(fā)送，否則將其丟棄。如果日志收集模塊本身出現(xiàn)無法向云平臺上報的情況，則記錄此異常，并僅將滿足從配置管理模塊中獲取的日志保存等級和數(shù)量的最近若干條告警信息寫入本地文件，等待下次可上報時發(fā)送。

3開機(jī)更新和啟動流程設(shè)計

終端軟件的迭代更新主要在開機(jī)啟動流程中進(jìn)行，該過程如圖2所示。

圖2　終端軟件開機(jī)啟動流程

首先終端軟件初始化服務(wù)檢測機(jī)頂盒的聯(lián)網(wǎng)情況，如一段時間內(nèi)不能連接到網(wǎng)絡(luò)則終端軟件跳出提示框以及機(jī)頂盒系統(tǒng)設(shè)置入口，提醒用戶檢查終端網(wǎng)絡(luò)配置是否正確；在網(wǎng)絡(luò)連接的情況下則接著進(jìn)入認(rèn)證流程，通過加密連接向云平臺發(fā)送賬戶信息，如無法訪問到認(rèn)證接口或認(rèn)證失敗則終端軟件跳出提示框以及軟件設(shè)置入口，提醒用戶檢查軟件參數(shù)配置是否正確；如認(rèn)證成功則返回云平臺將返回軟件更新信息，即后端云平臺更新服務(wù)接口，以及直播頻道列表獲取接口等動態(tài)參數(shù)信息；終端軟件通過訪問后端云平臺更新服務(wù)接口獲得當(dāng)前最新的軟件版本號以及對象存儲服務(wù)提供的軟件安裝包臨時訪問地址；終端軟件在進(jìn)行軟件版本比較等操作后，如不需要更新則直接從各接口獲取動態(tài)參數(shù)，初始化各模塊進(jìn)入首頁，如需要更新則直接訪問云端對象存儲服務(wù)下載新版軟件安裝包，通過輔助應(yīng)用對軟件作靜默更新和重新啟動。初始化服務(wù)啟動時同時會啟動后臺保護(hù)線程，當(dāng)初始化過程中出現(xiàn)異?；蛘叱跏蓟瓿珊蟪霈F(xiàn)網(wǎng)絡(luò)連接斷開等異常情況時后臺保護(hù)線程會進(jìn)行檢測，嘗試?yán)^續(xù)未完成的初始化操作或重做必要操作。

4流媒體視頻質(zhì)量保障播控機(jī)制設(shè)計

流媒體視頻質(zhì)量的保障主要在于監(jiān)測和調(diào)控兩方面。本系統(tǒng)中使用的流媒體視頻協(xié)議為HLS協(xié)議，由于其基于HTTP協(xié)議，故具有服務(wù)易于部署、自動支持多種路由器和防火墻等優(yōu)勢[5]。下面即針對該協(xié)議以及Android平臺的特性分別對監(jiān)測和調(diào)控方法的設(shè)計進(jìn)行說明，并描述關(guān)鍵實(shí)現(xiàn)。

4.1監(jiān)測方法

現(xiàn)有的終端視頻質(zhì)量實(shí)時監(jiān)測方法大致可分為兩類：第一類是通過測量傳輸速率等網(wǎng)口數(shù)據(jù)反映流媒體視頻質(zhì)量，如文獻(xiàn)[6]中對丟包率及延遲因子的計算；第二類則深入播放器內(nèi)部進(jìn)行媒體數(shù)據(jù)的收集分析，如文獻(xiàn)[7]中在Flash等瀏覽器播放插件中加入監(jiān)測模塊。對HLS協(xié)議而言，其底層多基于TCP協(xié)議的可靠傳輸，故用第一類方法測量丟包等網(wǎng)口指標(biāo)對其并不適用，且網(wǎng)口數(shù)據(jù)將包含第三方應(yīng)用在后臺進(jìn)行的數(shù)據(jù)傳輸，其測量結(jié)果并不準(zhǔn)確；另外對Android平臺而言，其內(nèi)置播放器封閉性較高，如照搬現(xiàn)有的第二類監(jiān)測方法則需要對Android系統(tǒng)本身進(jìn)行定制或者使用第三方軟解碼播放器對其源碼進(jìn)行修改，不利于在終端應(yīng)用軟件層面實(shí)施。

為此本文在終端軟件的流媒體視頻播控模塊中自行實(shí)現(xiàn)了HLS協(xié)議中的索引文件解析和視頻塊管理功能，從而監(jiān)測可主要通過播放進(jìn)度與下載進(jìn)度的比較以及下載速率與視頻碼率的比較實(shí)現(xiàn)。當(dāng)播放進(jìn)度超過下載進(jìn)度，即播放器需要解碼的數(shù)據(jù)在本地尚不存在時，播放器緩沖區(qū)為空，將造成卡頓，影響用戶體驗(yàn)質(zhì)量；當(dāng)平均下載速率小于視頻碼率時，若播放器緩沖區(qū)不為空則可在一定程度上延遲可能的卡頓，但若平均下載速率持續(xù)小于視頻碼率則最終緩沖區(qū)數(shù)據(jù)將耗盡而產(chǎn)生下溢，導(dǎo)致播放卡頓。

4.2調(diào)控方法

針對HLS協(xié)議以及其他基于HTTP的自適應(yīng)流媒體協(xié)議，相關(guān)的流媒體視頻質(zhì)量調(diào)控方法主要基于協(xié)議中支持的多碼率選擇機(jī)制實(shí)現(xiàn)。文獻(xiàn)[8]就提出了一種多碼率情況下通過初始CDN和碼率選擇以及播放過程中動態(tài)切換CDN和碼率達(dá)到視頻流暢播放的解決方案。然而國內(nèi)現(xiàn)狀無法照搬多碼率動態(tài)調(diào)控方案：現(xiàn)有多碼率片源較少，即便存在多碼率片源也大多只區(qū)分高清標(biāo)清或者為PC、平板即手機(jī)終端分別轉(zhuǎn)碼；而文獻(xiàn)[9]表明動態(tài)碼率切換必須逐步過渡才能防止用戶觀看的不適感，因此在云轉(zhuǎn)碼機(jī)制尚未與內(nèi)容提供商對接的情況下現(xiàn)有片源難以實(shí)施該調(diào)控方法。目前電視貓、泰捷視頻等第三方視頻資源集成終端軟件也僅提供了初始碼率的選擇，且僅在播放失敗時通過切換視頻源的方式進(jìn)行調(diào)控。

為此本文在調(diào)控方法中引入多線程下載機(jī)制作為補(bǔ)充，可以在單一碼率或最低碼率仍然有視頻卡頓的情況下調(diào)整下載速率。文獻(xiàn)[10]已經(jīng)說明了當(dāng)一個應(yīng)用同時開啟N個TCP連接，與其他k個TCP連接共享網(wǎng)絡(luò)帶寬時，該應(yīng)用得到的帶寬為總帶寬的N/(N+k)。故當(dāng)流媒體視頻應(yīng)用與其他網(wǎng)絡(luò)應(yīng)用共享網(wǎng)絡(luò)帶寬時，開啟多個線程、每個線程各開一個TCP連接進(jìn)行并發(fā)下載較之僅使用一個TCP連接進(jìn)行下載可以達(dá)到較為可觀的更快的媒體數(shù)據(jù)下載速率。除流媒體視頻應(yīng)用外，占用網(wǎng)絡(luò)帶寬資源較大的網(wǎng)絡(luò)應(yīng)用通常是P2P文件傳輸?shù)葢?yīng)用，這些網(wǎng)絡(luò)應(yīng)用并不如流媒體視頻應(yīng)用那般對實(shí)時性有較高的要求；此外，網(wǎng)頁瀏覽等常見應(yīng)用事實(shí)上也因?yàn)槭褂昧薃JAX和推送等技術(shù)存在多個TCP連接同時通信的情況。因此在流媒體視頻應(yīng)用中使用多TCP連接并發(fā)下載是可行且合理的。

4.3關(guān)鍵實(shí)現(xiàn)

上述監(jiān)測和調(diào)控方法在流媒體視頻播控模塊中通過下載控制子模塊和本地服務(wù)器子模塊得到了實(shí)現(xiàn)，其與云平臺和底層播放器的交互如圖3所示。當(dāng)用戶請求播放某一HLS視頻源時，流媒體視頻播控模塊將首先檢查播放器當(dāng)前是否處于播放狀態(tài)中，如是則先停止播控模塊的多線程任務(wù)以及播放器視頻播放。之后由流媒體視頻播控模塊向云平臺請求索引文件，由云端視頻質(zhì)量保障服務(wù)根據(jù)終端軟硬件參數(shù)、歷史播放情況等信息進(jìn)行初始CDN、最高碼率和最大并發(fā)下載線程數(shù)的選擇，生成對應(yīng)的索引文件。流媒體視頻播控模塊根據(jù)索引文件訪問對象存儲或目標(biāo)CDN下載媒體數(shù)據(jù)，開始初始緩沖，并監(jiān)測下載速度、評估網(wǎng)絡(luò)帶寬情況。對于直播流盡快下載最近的若干個視頻塊并開始周期性檢查是否有新的視頻塊可下載，對點(diǎn)播流則盡快下載開頭的視頻塊，下載的視頻塊均放置在終端本地服務(wù)器內(nèi)。初始緩沖完成后，流媒體視頻播控模塊根據(jù)已下載視頻塊在本地服務(wù)器的訪問位置生成本地索引文件，即生成了一個以本地服務(wù)器為視頻源服務(wù)器的HLS視頻流，此時再調(diào)用播放器對該流進(jìn)行播放。如此，則原來被Android平臺播放器封裝的下載流程完全被流媒體視頻播控模塊接管，可以自行根據(jù)當(dāng)前網(wǎng)絡(luò)帶寬評估情況調(diào)整下載策略；同時由于使用原播放器進(jìn)行播放，還能繼續(xù)利用終端機(jī)頂盒的硬解碼優(yōu)勢。當(dāng)播放器向本地服務(wù)器請求某一視頻塊時，本地服務(wù)器在返回媒體數(shù)據(jù)的同時根據(jù)視頻塊播放時長開啟定時器預(yù)測請求下一視頻塊的時間；若定時器被觸發(fā)時預(yù)定被請求的視頻塊仍未出現(xiàn)在本地索引文件中供播放器請求，則可認(rèn)為播放器可能將出現(xiàn)下溢。而本地索引文件中已出現(xiàn)的視頻塊也可能因多次下載失敗在本地服務(wù)器中實(shí)際并不存在，則播放器可能會重復(fù)播放前一視頻塊，造成用戶體驗(yàn)質(zhì)量的下降，這種情況也能為本地服務(wù)器所感知。這些可能的下溢情況以及下載速度等信息都可經(jīng)由日志模塊上報到云平臺，使云平臺可以動態(tài)下發(fā)指令調(diào)整播放策略；同時流媒體視頻播控模塊也可在本地直接進(jìn)行碼率的選擇和多線程并發(fā)下載數(shù)的調(diào)整，及時防止或補(bǔ)救視頻質(zhì)量下降對用戶體驗(yàn)質(zhì)量的不良影響。

圖3　流媒體視頻質(zhì)量保障播控機(jī)制交互設(shè)計

流媒體視頻質(zhì)量保障播控機(jī)制的工作流程中包含多個線程間的交互，如圖4所示。各主要工作線程職責(zé)如下：

(1) 準(zhǔn)備線程

用于視頻流的初始化，判斷視頻流種類并據(jù)此啟動其他線程。在內(nèi)存中建立用于視頻塊信息存儲的雙鏈表，通過標(biāo)記鏈表中的位置，記錄視頻塊已下載情況、當(dāng)前本地索引文件中包含的視頻塊等。

(2) 遠(yuǎn)程索引文件更新線程

僅用于直播流，周期性檢查是否有新的視頻塊；當(dāng)有新的視頻塊可供下載時將其加入鏈表，并通知下載控制線程。

(3) 本地索引文件更新線程

僅用于直播流，當(dāng)有新的視頻塊被下載到本地服務(wù)器時更新本地索引文件的內(nèi)容。通常處于掛起狀態(tài)，由下載控制線程喚醒。

(4) 下載控制線程

根據(jù)云平臺下發(fā)的控制指令中包含的配置參數(shù)確定下載模式，包括是否采用多線程并發(fā)下載。通常處于掛起狀態(tài)，當(dāng)遠(yuǎn)程索引文件更新線程將其喚醒后根據(jù)下載模式啟動一個或多個線程下載新的視頻塊，同時評估實(shí)際下載速率，與碼率對比，在多線程下載模式下為下一次選取啟動線程數(shù)提供參考，并將實(shí)際下載速率交由日志收集模塊上報至云平臺。當(dāng)某一視頻塊對應(yīng)下載線程全部結(jié)束后根據(jù)鏈表中記錄的信息判斷其是否下載完成，如成功則喚醒本地索引文件更新線程，否則進(jìn)行有限次重試下載，如依舊失敗則仍將該視頻塊信息寫入本地索引文件，防止視頻塊序號混亂。

(5) 下載線程

實(shí)際對視頻塊進(jìn)行下載的線程，由下載控制線程啟動。根據(jù)下載情況對鏈表中相應(yīng)視頻塊信息進(jìn)行修改。

(6) 清理線程

在直播流中用于周期性清理已播放的視頻塊，即鏈表中處于本地索引文件包含范圍之前的視頻塊，并在當(dāng)前視頻流停止播放后清理所有本地臨時文件。

圖4　流媒體視頻質(zhì)量保障播控機(jī)制多線程交互

5應(yīng)用與測試

本文在基于Android操作系統(tǒng)的海美迪機(jī)頂盒上進(jìn)行了終端軟件的開發(fā)實(shí)現(xiàn)并進(jìn)行測試，該款機(jī)頂盒的具體軟硬件參數(shù)如表2所示。該終端軟件已實(shí)際投入一百個以上終端的OTT業(yè)務(wù)運(yùn)營中。

表2　機(jī)頂盒軟硬件參數(shù)

實(shí)驗(yàn)測得該機(jī)頂盒在空閑狀態(tài)，即除資源使用情況測量軟件外沒有其他非系統(tǒng)軟件運(yùn)行的情況下，其CPU使用率約在7%以下，內(nèi)存使用率約在39%以下。

圖5顯示了該終端軟件從啟動開始到穩(wěn)定運(yùn)行共5分鐘過程中的CPU和內(nèi)存使用情況。用戶操作包括終端軟件啟動完成后從首頁進(jìn)入直播功能，之后每15秒左右進(jìn)行一次換臺操作，其中視頻流的平均碼率為600 Kb/s。其間終端軟件同時也在進(jìn)行云平臺推送的滾動字幕的疊加繪制，日志上報等后臺服務(wù)也處于正常運(yùn)行狀態(tài)?？梢钥吹絻H在前20秒終端軟件進(jìn)行初始化時其對系統(tǒng)的CPU使用負(fù)荷較大，達(dá)到了約45%，之后則穩(wěn)定在16%以下，對內(nèi)存的使用則一直穩(wěn)定在41%以下。由于終端軟件作為機(jī)頂盒桌面入口程序在機(jī)頂盒啟動時率先運(yùn)行且運(yùn)行在前臺，具有一定的獨(dú)占性，故此處認(rèn)為其啟動時對終端系統(tǒng)資源的使用可接受。

圖5　終端軟件開機(jī)啟動系統(tǒng)資源占用

圖6顯示了終端軟件穩(wěn)定運(yùn)行時的平均資源使用情況與機(jī)頂盒空閑狀態(tài)，即除資源使用測量軟件外沒有其他非系統(tǒng)軟件運(yùn)行情況下的對比。估計可得終端軟件對內(nèi)存的占用在存儲空間的2%即20 MB左右，且CPU占用率的絕對大小不高，可認(rèn)為其穩(wěn)定運(yùn)行時對終端系統(tǒng)資源的使用較少。

圖6　終端軟件穩(wěn)定運(yùn)行系統(tǒng)資源占用與空閑狀態(tài)對比

圖7顯示了終端軟件中流媒體視頻播控模塊監(jiān)測方法對視頻塊下載速率的監(jiān)測結(jié)果與傳統(tǒng)網(wǎng)口監(jiān)測結(jié)果的對比。網(wǎng)口監(jiān)測結(jié)果只能通過周期性采樣獲得采樣周期內(nèi)的平均下載速率，無法獲知視頻塊開始和結(jié)束下載的時間點(diǎn)。圖中播控模塊內(nèi)監(jiān)測清楚地反映出了HLS視頻流開始播放時快速下載若干視頻塊填充緩沖區(qū)以及后期間歇性下載新視頻塊的播放器行為，而以4秒為周期的網(wǎng)口采樣監(jiān)測只能反映下載速率變化的大致趨勢，更為頻繁的采樣將過度消耗系統(tǒng)資源。

圖7　播控模塊下載速率監(jiān)測結(jié)果與網(wǎng)口監(jiān)測結(jié)果對比

圖8顯示了終端軟件中流媒體播控模塊基于多線程下載的視頻質(zhì)量調(diào)控方法與原生播放器的對比。在與約25個其他TCP網(wǎng)絡(luò)應(yīng)用競爭20 Mbps網(wǎng)絡(luò)瓶頸的情況下，原生播放器調(diào)控方法由于下載速率較視頻塊碼率整體偏低而逐漸耗盡緩沖區(qū)數(shù)據(jù)導(dǎo)致長時間卡頓，圖中可看到11到17號視頻塊被播放器跳過以彌補(bǔ)視頻卡頓導(dǎo)致的直播播放進(jìn)度的落后。而引入多線程下載調(diào)控機(jī)制、最大下載線程數(shù)設(shè)置為3的播控模塊則整體上維持了較高的下載速率，達(dá)到流暢的播放效果。

圖8　播控模塊下載速率調(diào)控與原生播放器對比

為進(jìn)一步測試流媒體視頻播控模塊在視頻流穩(wěn)定播放時對系統(tǒng)資源的使用情況以及流媒體視頻質(zhì)量保障播控機(jī)制的實(shí)際可操作性，本文又基于終端軟件設(shè)計中的流媒體視頻播控模塊開發(fā)了單獨(dú)的播放器測試應(yīng)用。圖9顯示了使用該測試應(yīng)用進(jìn)行平均碼率約為600 Kb/s的直播視頻流播放時，多線程下載機(jī)制使用的最大下載線程數(shù)對應(yīng)的CPU占用率。內(nèi)存占用率由于其隨最大下載線程數(shù)變化和播放時間推進(jìn)未產(chǎn)生明顯差異故未在圖中畫出。從視頻流穩(wěn)定播放的角度對測試結(jié)果數(shù)據(jù)進(jìn)行考察，可以看到CPU在視頻剛開始播放時使用較多，之后隨著視頻流的穩(wěn)定播放逐漸下降到穩(wěn)定水準(zhǔn)，這一現(xiàn)象符合視頻啟動時快速填充解碼緩沖區(qū)的過程，也表明視頻穩(wěn)定播放過程中流媒體視頻播控模塊對系統(tǒng)資源的使用狀況穩(wěn)定可接受。另一方面，測試數(shù)據(jù)也顯示流媒體視頻播控模塊對系統(tǒng)資源的使用并未隨著最大下載線程數(shù)的增大而發(fā)生顯著變化，表明經(jīng)由云平臺向終端軟件發(fā)送下載線程數(shù)設(shè)置指令以實(shí)時調(diào)整視頻數(shù)據(jù)下載速率的視頻質(zhì)量控制方法并不受到終端系統(tǒng)資源的限制，具有實(shí)際可操作性。

圖9　流媒體視頻播控模塊CPU占用率與最大下載線程數(shù)關(guān)系

6結(jié)語

流媒體視頻細(xì)分行業(yè)云的驗(yàn)證離不開相應(yīng)終端軟件的對接實(shí)現(xiàn)。本文設(shè)計的OTT流媒體視頻終端軟件在實(shí)現(xiàn)主要功能的前提下具有較少的系統(tǒng)資源占用，其流媒體質(zhì)量監(jiān)控方法具有一定的精確性和有效性，可實(shí)際用于機(jī)頂盒終端的云管控。在OTT業(yè)務(wù)的后續(xù)運(yùn)營過程中本終端軟件的配置參數(shù)可根據(jù)細(xì)分行業(yè)云的大數(shù)據(jù)分析結(jié)果進(jìn)行調(diào)控，便于用戶體驗(yàn)質(zhì)量的提升，有利于業(yè)務(wù)的進(jìn)一步發(fā)展。

參考文獻(xiàn)

[1] Cisco Systems,Incorporated.Cisco visual networking index:forecast and methodology,2013-2018 [R/OL].Cisco Systems,Incorporated,2014.http://www.cisco.com/c/en/us/solutions/collateral/service-provider/ip-ngn-ip-next-generation-network/white_paper_c11-481360.html.

[2] 辛靜，劉曉娟，魏嬌嬌．廣電OTT流媒體支撐系統(tǒng)平臺設(shè)計[J]．計算機(jī)應(yīng)用與軟件，2015，32(1)：167-170．

[3] 趙少卡，李立耀，凌曉，等．基于OpenStack的清華云平臺構(gòu)建與調(diào)度方案設(shè)計[J]．計算機(jī)應(yīng)用，2013，33(12)：3335-3338，3349．

[4] Conviva,Incorporated.Internet TV:bringing control to chaos[R/OL].Conviva,Incorporated,2015.http://www.conviva.com/conviva-intelligent-control-whitepaper.

[5] 金達(dá)，葉慶偉，狄紅衛(wèi)．基于HLS 的流媒體播放系統(tǒng)的設(shè)計與實(shí)現(xiàn)[J]．信息技術(shù)，2013(10)：49-52．

[6] Welch J,Clark J.RFC 4445-A Proposed Media Delivery Index (MDI)[S/OL].IneoQuest Technologies,Cisco Systems,2006.https://tools.ietf.org/html/rfc4445.

[7] Ganjam A R,Huebsch R J,Lakshminarayanan K K,et al.Monitoring the performance of a content player:US,8874725[P].2014-10-28.

[8] Jiang J,Sekar V,Zhang H.Improving fairness,efficiency,and stability in HTTP-based adaptive video streaming with FESTIVE[J].IEEE/ACM Transactions on Networking,2014,22(1):326-340.

[9] Mok Rkp,Chan Eww,Luo X,et al.Inferring the QoE of HTTP video streaming from user-viewing activities:Proceedings of the first ACM SIGCOMM workshop on Measurements up the stack,Toronto,August 15-19,2011[C].New York:ACM,2011.

[10] Hacker T,Athey B,Noble B.The end-to-end performance effects of parallel tcp sockets on a lossy wide-area network:Vehicle Navigation and Information Systems Conference,1993 [C].IEEE-CS/ACM,2002.

收稿日期：2015-02-11。上海市科委科技發(fā)展基金攻關(guān)項(xiàng)目(12511503002)。潘涵洋，碩士生，主研領(lǐng)域：網(wǎng)絡(luò)多媒體。于翔，碩士生。葉德建,副教授。

中圖分類號TP3

文獻(xiàn)標(biāo)識碼A

DOI:10.3969/j.issn.1000-386x.2016.07.005

DESIGN OF AN OTT STREAMING MEDIA TERMINAL APPLICATION BASED ON SEGMENTED INDUSTRY CLOUD

Pan HanyangYu XiangYe Dejian*

(SoftwareSchool,FudanUniversity,Shanghai201203,China) (EngineeringResearchCenterofCyberSecurityAuditingandMonitoring,MinistryofEducation,Shanghai201203,China)

AbstractAiming at the trend of cloud-computing in segmented industry of streaming media video services,this paper presents a design of OTT streaming media video terminals application with modular architecture based on the support for OTT business provided by segmented industry cloud platform,and submits the implementation schemes of the application and cloud platform interactively iterating and updating and the broadcasting control mechanism of quality assurance for streaming media video.Application and test results show that this terminal application expends less resources of terminal system on the premise of realising functional requirements,its quality monitoring and control method for streaming media video is more suitable for Android platform and HLS protocol compared with traditional methods,and has good accuracy,regulatory effect and performance.This application can be put into practical use of management and control of terminals on cloud platform.

KeywordsStreaming media video terminal applicationSegmented industry cloudOver the top (OTT)AndroidHttp live streaming (HLS)