潘涵洋　于　翔　葉德建

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

?

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

潘涵洋于翔葉德建*

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

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

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

0引言

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

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

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

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

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

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

(1) 云推送

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

(2) 云轉(zhuǎn)碼

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

(3) 視頻服務用戶體驗質(zhì)量保障

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

(4) 個性化推薦

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

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

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

2模塊設計

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

圖1　OTT流媒體視頻終端軟件模塊化架構示意圖

下面對幾個主要的功能模塊的設計進行說明。

2.1界面繪制模塊

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

2.2流媒體視頻播控模塊

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

2.3配置管理模塊

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

2.4推送客戶端模塊

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

2.5第三方軟件管理模塊

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

2.6日志收集模塊

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

表1　日志信息分類

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

3開機更新和啟動流程設計

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

圖2　終端軟件開機啟動流程

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

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

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

4.1監(jiān)測方法

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

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

4.2調(diào)控方法

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

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

4.3關鍵實現(xiàn)

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

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

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

(1) 準備線程

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

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

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

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

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

(4) 下載控制線程

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

(5) 下載線程

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

(6) 清理線程

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

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

5應用與測試

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

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

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

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

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

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

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

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

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

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

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

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

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

6結語

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

參考文獻

[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)平臺設計[J]．計算機應用與軟件，2015，32(1)：167-170．

[3] 趙少卡，李立耀，凌曉，等．基于OpenStack的清華云平臺構建與調(diào)度方案設計[J]．計算機應用，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] 金達，葉慶偉，狄紅衛(wèi)．基于HLS 的流媒體播放系統(tǒng)的設計與實現(xiàn)[J]．信息技術，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ā)展基金攻關項目(12511503002)。潘涵洋，碩士生，主研領域：網(wǎng)絡多媒體。于翔，碩士生。葉德建,副教授。

中圖分類號TP3

文獻標識碼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)