葉　楠

(福州理工學(xué)院 信息工程系，福建 福州 350506)

基于多屏互動的OTT平臺的設(shè)計與實現(xiàn)

葉楠

(福州理工學(xué)院 信息工程系，福建 福州 350506)

摘要:為了解決傳統(tǒng)電視業(yè)務(wù)單一、傳播區(qū)域受限的問題，使電視業(yè)務(wù)運營走向智能化和豐富化，實現(xiàn)手機、PC、電視的三屏聯(lián)動，提出了一種基于多屏互動的OTT平臺設(shè)計方案。該方案通過搭建BO管理系統(tǒng)、Portal門戶系統(tǒng)、CDN系統(tǒng)和推流系統(tǒng)，提供了面向全終端的直播、點播、時移和回看等收視服務(wù)；通過建立移動終端與機頂盒之間、移動終端之間的交互協(xié)議，實現(xiàn)了收視服務(wù)的云互動，并且支持手機遙控器控制電視。OTT平臺下個性化收視服務(wù)及多屏互動系統(tǒng)的設(shè)計與實現(xiàn)，不僅促進了電視的多樣化業(yè)務(wù)傳播，也豐富了人們的智能化生活。

關(guān)鍵詞:多屏互動；OTT；移動終端；CDN

移動互聯(lián)網(wǎng)的蓬勃發(fā)展，刺激著智能終端市場的不斷增長。中青年用戶利用碎片化的時間，觀看視頻、玩游戲、交友以及溝通等，大大降低了電視大屏的開機使用率，這也促使廣電運營商必須加速全面轉(zhuǎn)型[1]。以O(shè)TTTV和互聯(lián)網(wǎng)新型網(wǎng)絡(luò)服務(wù)為代表的新業(yè)務(wù)形態(tài)以互聯(lián)網(wǎng)上豐富的視頻、信息內(nèi)容，良好的用戶操作體驗和用戶自主、便捷的溝通交流手段迎合并滿足了消費者日益增長的精神文化需求[2]。

OTTTV和互聯(lián)網(wǎng)新型網(wǎng)絡(luò)服務(wù)近年來快速發(fā)展，逐步開始聚合視頻內(nèi)容和互聯(lián)網(wǎng)信息服務(wù)，用戶所關(guān)注的屏幕逐漸從電視快速向PC、手機、Pad等拓展，多屏互動與跨屏業(yè)務(wù)逐漸成為行業(yè)關(guān)注焦點[3-4]。對于有線電視運營商而言，順應(yīng)、滿足用戶對于多屏的需求，將自己的服務(wù)從電視屏延伸到智能終端(PC，Pad，Phone)上，已經(jīng)成為增強用戶粘性、降低用戶離網(wǎng)率、提升行業(yè)競爭力的重要舉措[5-6]。

1總體設(shè)計

本方案采用如圖1所示的OTT平臺架構(gòu)進行搭建，以直播組播源接入、點播媒資內(nèi)容注入為入口，流媒體ISS出流、統(tǒng)一面向用戶的Portal門戶為出口提供了多樣化的信息服務(wù)。OTT整體平臺按照功能可分為5個域：內(nèi)容業(yè)務(wù)域、運營管控域、運營支撐域、能力支撐域、終端設(shè)備域，平臺內(nèi)部架構(gòu)的具體子模塊可分為BO管理子系統(tǒng)、信息交互系統(tǒng)IS、UBA統(tǒng)計系統(tǒng)以及面向移動終端設(shè)備域的ISS流媒體系統(tǒng)。下面對OTT平臺的各個關(guān)鍵模塊進行詳細說明介紹[7-8]。

圖1OTT平臺總體框架

1.1BO管理子系統(tǒng)

OTT平臺BO子系統(tǒng)提供了媒資元數(shù)據(jù)的維護管理，認證鑒權(quán)服務(wù)，以及產(chǎn)品流程的生命周期管理。BO管理子系統(tǒng)包含了CMS內(nèi)容管理系統(tǒng)、OSS運營支撐系統(tǒng)、AAA鑒權(quán)計費模塊、PortalMS門戶發(fā)布系統(tǒng)等子模塊[9-10]。

1.2統(tǒng)一Portal門戶

統(tǒng)一Portal系統(tǒng)是業(yè)務(wù)最終展現(xiàn)的出口，是各種業(yè)務(wù)面向多終端用戶的最后一道關(guān)口，是前端系統(tǒng)與終端間的橋梁，并能夠根據(jù)地區(qū)差異提供不同的門戶信息。

1.3轉(zhuǎn)碼系統(tǒng)

轉(zhuǎn)碼系統(tǒng)分為實時轉(zhuǎn)碼系統(tǒng)和離線轉(zhuǎn)碼系統(tǒng)兩部分。直播組播源入流時，經(jīng)過實時轉(zhuǎn)碼系統(tǒng)，轉(zhuǎn)出需要的分辨率和碼率的直播源，以適應(yīng)不同類型終端的觀看。點播媒資注入后，經(jīng)過離線轉(zhuǎn)碼系統(tǒng)，轉(zhuǎn)出多種碼率，在終端上可根據(jù)網(wǎng)絡(luò)環(huán)境的狀況及帶寬來選擇適合的碼率，保證了用戶端的流暢播放。

1.4ISS流服務(wù)系統(tǒng)

ISS系統(tǒng)是OTT平臺中對直播、點播、時移和回看數(shù)據(jù)進行不同格式封裝后以HLS分片傳輸?shù)牧鞣?wù)系統(tǒng)[11]。通過對視頻元數(shù)據(jù)的熱點處理、緩存定位及HTTP傳輸，實現(xiàn)了平臺到終端設(shè)備的出流，對于設(shè)備的有效利用率、用戶的出流穩(wěn)定性上也做了關(guān)鍵性的處理。

2關(guān)鍵技術(shù)與處理流程

OTT平臺可根據(jù)運營商的資源情況進行靈活部署，目前初期采用集中式部署，通過對統(tǒng)一組播信源的轉(zhuǎn)碼收錄，由OTT服務(wù)器進行切片封裝處理后，以HLS分片的形式，對外提供服務(wù)[12]。

2.1媒資內(nèi)容播發(fā)流程

如圖2所示為媒資元數(shù)據(jù)的注入及上線流程。媒資系統(tǒng)通過ADI接口同步編目信息至OTT平臺，通過對ADI字段的解析處理，調(diào)用離線轉(zhuǎn)碼設(shè)備的相應(yīng)模板，即完成了媒資的注入過程。媒資文件下載完成后，由內(nèi)容播發(fā)模塊CPM對媒資來進行上線過程的處理。

2.2CDN內(nèi)容分發(fā)子系統(tǒng)

圖3所示為CDN內(nèi)容分發(fā)系統(tǒng)的架構(gòu)圖。CDN支持集中式部署、多級部署方式。其中，中心存儲只做中心內(nèi)容緩存，由邊緣加速層面向終端，提供流服務(wù)。CDN中，重要模塊功能如下：

1)CI：內(nèi)容導(dǎo)入模塊，提供將媒資內(nèi)容導(dǎo)入到CDN中的接口。

圖2　CPM內(nèi)容播發(fā)流程

2)CPM：策略管理模塊，負責(zé)對CL、CG的管理。

3)CL：內(nèi)容中心存儲，主要負責(zé)節(jié)目存儲，同時為其他CL和CG提供下載服務(wù)。

4)CLS：內(nèi)容調(diào)度模塊，負責(zé)對CG或CL的調(diào)度管理。

5)RTCL：直播錄制模塊，負責(zé)直播流的收錄和錄制。

6)CG/ISS：邊緣緩存，對CL和RTCL中內(nèi)容進行緩存和加速。

7)GLSB：全局負載均衡模塊，對CLS進行全局調(diào)度。

CDN可以很方便地進行橫向和縱向擴容。通過在邊緣加速層，新增一個CG節(jié)點，從而完成橫向擴容，不影響原有緩存節(jié)點的服務(wù)。通過縱向擴容，增加邊緣緩存加速的層數(shù)，從而實現(xiàn)樹狀體系結(jié)構(gòu)，即增加了一層CDN的分節(jié)點。

圖3CDN內(nèi)容分發(fā)子系統(tǒng)

2.3基于云互動的跨屏協(xié)同平臺

如圖4所示為OTT平臺中的多屏互動系統(tǒng)實現(xiàn)架構(gòu)[13]。為了體現(xiàn)手機與手機之間、手機與機頂盒之間的信息交互[14]，通過前端中介交互時，移動終端之間分別與前端XMPP服務(wù)器交互，手機與機頂盒之間通過網(wǎng)關(guān)交互服務(wù)器傳輸互動消息[15]。將原本發(fā)送的消息通過BASE64變換后得到字符串，作為報文消息來傳輸[16-17]。

2.4設(shè)計方案合理性及有效性

通過與國內(nèi)外主流的多屏互動實現(xiàn)方式進行了深入對比，本設(shè)計方案從多個角度考慮，采取了最優(yōu)的設(shè) 計方法，具體包含如下內(nèi)容：

1)推流架構(gòu)設(shè)計：與傳統(tǒng)的一級推流相比，本設(shè)計方案采用分布式CDN部署，能有效解決收視業(yè)務(wù)的并發(fā)推流能力分配問題及分節(jié)點的建設(shè)部署。

2)移動終端與機頂盒外交互設(shè)計：本方案采用TCP

圖4　基于云互動的跨屏協(xié)同平臺

POST請求來進行交互信息傳遞，與傳統(tǒng)的機頂盒局域網(wǎng)內(nèi)UDP交互相比，適應(yīng)性更強，應(yīng)用場景更廣泛。

3)移動終端之間的交互設(shè)計：通過前端XMPP實現(xiàn)移動終端交互，可以建立用戶家庭組，后期可添加家庭成員聊天等更多互動功能，業(yè)務(wù)及接口擴展性較強。

4)業(yè)務(wù)層、協(xié)議層模塊化處理：如圖5所示，業(yè)務(wù)層只處理業(yè)務(wù)相關(guān)的工作，切拉屏消息、按鍵消息等，而協(xié)議層則只處理傳輸相關(guān)工作，例如UDP字符串序列化，外交互方式配對、JSON封裝等。本方案采用分層設(shè)計方法，方便了后續(xù)增加新的協(xié)議支持，提高了擴展性。

圖5業(yè)務(wù)層及協(xié)議層工作流程

3系統(tǒng)冗余性設(shè)計

多屏互動系統(tǒng)目前設(shè)備按照1臺點播推流(IP為192.168.12.12)，3臺直播推流(IP分別為192.168.12.13、192.168.12.14和192.168.12.15)。

推流服務(wù)器采用N+1備份(N=4)，使用一臺服務(wù)器(192.168.12.7)作為3臺直播和1臺點播服務(wù)器的備用服務(wù)器，使用浮動IP實現(xiàn)主備部署，當(dāng)主服務(wù)器宕機后，浮動IP會跳轉(zhuǎn)至備用服務(wù)器，備用服務(wù)器將繼續(xù)提供推流服務(wù)。各個主服務(wù)器對應(yīng)的浮動IP見表1。

回看錄制文件及點播媒資存儲在HP2000磁陣存儲上，并通過FC接入到服務(wù)器上，通過NFS共享給主流媒體服務(wù)器和備流媒體服務(wù)器。各主機和備機之間通過keepalive保持心跳，當(dāng)主流媒體服務(wù)器宕機時，通過keepalive可以秒級切換至備機繼續(xù)提供推流服務(wù)，視頻數(shù)據(jù)也可保持一致性，保證了災(zāi)備的冗余。

表1Keepalive浮動IP冗余備份

排序主服務(wù)器業(yè)務(wù)IP浮動IP1192.168.12.12192.168.12.22192.168.12.13192.168.12.33192.168.12.14192.168.12.44192.168.12.15192.168.12.5

另外，通過定時任務(wù)監(jiān)測推流進程的服務(wù)情況，當(dāng)進程因不明故障終止運行時，通過crond即可使進程在5min內(nèi)自動啟動，繼續(xù)對外提供服務(wù)。

4系統(tǒng)測試與對比

為了驗證設(shè)計方案的穩(wěn)定性，方便對系統(tǒng)性能做出評估，對OTT平臺的各項指標(biāo)做了如下測試。

4.1接口性能測試

ApacheJMeter作為基于Java的壓力測試工具，可針對軟件接口進行模擬HTTP請求并發(fā)負載。本次測試主要結(jié)合終端界面，針對PORTAL服務(wù)器的幾個重要接口，測試要求達到如下幾項指標(biāo)：1)測試機CPU不超過80%；2)接口請求的最大響應(yīng)時間不超過1 000ms(平均值一般在3ms左右)；3)請求響應(yīng)的成功率保持100%；4)單接口同時并發(fā)請求達到3 000并發(fā)及以上。

終端啟動后，接口調(diào)用順序如下：getPortalServerIP，getUpdateInfo，getSessionId，其他配置信息順序任意。

接口說明及測試結(jié)果如表2所示。

表2Portal接口性能測試

接口類型并發(fā)用戶數(shù)測試機CPU/%最大響應(yīng)時長/msError/%Portal服務(wù)獲取門戶地址getPortalServerIP獲取客戶端版本信息getUpdateInfo獲取會話IDgetSessionId獲取首頁推薦列表getWelcomeList獲取直播節(jié)目列表getChannelInfoList獲取欄目列表getColumnInfoList獲取點播節(jié)目列表getProgramInfoList獲取點播節(jié)目信息getProgramInfo3000363505521004057067218040670662810754570521210

表2給出了Portal服務(wù)的不同接口在3 000并發(fā)用戶下的響應(yīng)時延及錯誤率的測試結(jié)果。由表2可見，通過Jmeter限定用戶數(shù)在一定時間內(nèi)增加至最高3 000時，各接口的請求響應(yīng)時延最大值均小于1 000ms，符合測試參數(shù)要求。另一方面，表2中的測試機CPU在測試過程中均未達到80%，保證了測試機的性能充裕，不會對測試響應(yīng)時延值的準(zhǔn)確性造成影響。由于不同接口所請求的信息量不同，所以同樣是3 000并發(fā)下的接口請求，請求信息量大的相對時延稍長，但從用戶體驗的角度來說，都能夠滿足指標(biāo)要求。

4.2推流并發(fā)測試

為了模擬真實用戶點播場景，必須采用端到端的方式來進行測試，即保證壓力測試機的性能充裕，不會成為瓶頸，且網(wǎng)絡(luò)帶寬足夠。本次測試選取了LoadRunner作為推流并發(fā)測試軟件，并編寫創(chuàng)建了Vuser腳本來模擬并發(fā)請求；另外，在Linux下使用了nmon來采集實時監(jiān)控的數(shù)據(jù)。將直播、點播、時移、回看按照1∶1∶1∶1的用戶數(shù)比例進行壓測，如表3所示。

表3收視業(yè)務(wù)用戶數(shù)分配

設(shè)備組用戶數(shù)占比/%事務(wù)數(shù)/時HLS-LIVE50025556315.2HLS-VOD50025121038.4HLS-TIMESHIFT50025281980.4HLS-BACK5002579898.4合計2000100—

用戶請求響應(yīng)的時延，實際上就取決于分片的大小，客戶端會根據(jù)m3u8索引文件不斷地下載并播放這些小文件，因此播放是否流暢，由分片是否在短時間內(nèi)成功下載來決定。本次測試分片下載基本概況為(詳見表4和圖6)：

TitleTransactionResponseTimeUnderLoad

GraphTypeCorrelate

BaseGraphRunningVusers

AdditionalAverageTransactionResponseTime

Granularity1Second

表4測試數(shù)據(jù)統(tǒng)計表

顏色規(guī)格測試項最短時間/s平均時間/s最長時間/s紫1Action_Transaction0.2661.0886.298綠1vuser_end_Transaction000紅1vuser_init_Transaction0.0010.0010.003黃1分片下載0.0060.2132.275藍1分片列表下載0.0340.1710.908

圖6　負載下事務(wù)響應(yīng)時間測試(截圖)

分析以上測試數(shù)據(jù)，可得出：1)分片下載成功率為100%；2)平均分片下載時長為0.2s。

從以上測試結(jié)果可以看到，對直播、點播、時移、回看業(yè)務(wù)按同比例用戶數(shù)進行綜合測試，分片下載正常，時延在合理的范圍內(nèi)，表明本系統(tǒng)具備較高的穩(wěn)定性。

5小結(jié)

本文結(jié)合廣電運營商在面向OTT移動終端用戶上的發(fā)展需求，提出了一種在OTT平臺上實現(xiàn)多屏互動的設(shè)計方案。采用XMPP協(xié)議在前端中介進行交互的形式，為直播、點播、時移、回看業(yè)務(wù)在移動終端和機頂盒之間進行信息互動共享提供了實現(xiàn)[18]。測試表明，本設(shè)計方案對不同類型終端設(shè)備的兼容性強，為業(yè)務(wù)的廣泛覆蓋提供了前提條件；對外圍接口的開放性高，具有良好的業(yè)務(wù)擴展性；可流暢播放，符合實際的使用需求。在OTT平臺上實現(xiàn)多屏互動系統(tǒng)對促進廣電運營商增強用戶群的黏度，實現(xiàn)用戶與用戶間的有效聯(lián)動，實現(xiàn)多網(wǎng)絡(luò)、多終端、多業(yè)務(wù)的智能融合具有重要的意義[19-20]。

參考文獻：

[1]呂品.智能終端與OTT業(yè)務(wù)[J].電視技術(shù)，2012，36(S1)：34-36.

[2]劉明亮.OTTTV的直播解決方案[J].電視技術(shù)，2014，38(20)：33-36.

[3]賈云濤，趙強.IPTV，OTTTV對有線電視運營影響分析及應(yīng)對策略的思考[J].中國數(shù)字電視，2013(7)：30-35.

[4]劉洋.三網(wǎng)融合下電信運營商TV屏業(yè)務(wù)發(fā)展策略建議[J].電信科學(xué)，2011(S1)：187-190.

[5]鄭鵬思.關(guān)于三網(wǎng)融合視頻業(yè)務(wù)實現(xiàn)的研究[J].廣播與電視技術(shù)，2011，38(12)：82-84.

[6]王澤，屈海偉.IPTV與OTT+TV融合業(yè)務(wù)客戶端解決方案研究[J].互聯(lián)網(wǎng)天地，2015(1)：36-38.

[7]黃升民.八問OTT—OTTTV對電視產(chǎn)業(yè)的影響和對策解析[J].現(xiàn)代傳播，2013(10)：1-6.

[8]魏國亮.多屏互動技術(shù)在高清互動平臺中的應(yīng)用[J].中國有線電視，2013(10)：1180-1182.

[9]吳軼群，朱亞東，王明敏.基于平臺的多屏互動系統(tǒng)設(shè)計[J].計算機應(yīng)用與軟件，2014，31(10)：234-238.

[10]鐘成軍，鄭鵬思，胡昕宇.基于多屏互動的OTT平臺建設(shè)的研究[J].廣播與電視技術(shù)，2014，41(4)：40-45.

[11]董道國，李青，魏國慶.一種適用于傳統(tǒng)互動機頂盒的多屏互動技術(shù)方案[J].中國有線電視，2014(1)：31-34.

[12]成霄，李玉軍.基于IGRS的數(shù)字電視多屏互動關(guān)鍵技術(shù)研究[J].高新技術(shù)，2013(1)：1-2.

[13]萬心茹.不同終端多屏互動平臺的交互設(shè)計研究[D].天津：天津大學(xué)，2012.

[14]倪喧.融合新媒體環(huán)境下廣電OTT發(fā)展現(xiàn)狀[J].中國傳媒科技，2012(4)：73-74.

[15]馬曉，馬立銘，曹三省.面向業(yè)務(wù)的智能電視系統(tǒng)架構(gòu)設(shè)計[J].電視技術(shù)，2012，36(12)：32-34.

[16]樊軍，曾培峰，唐莉萍.基于和的網(wǎng)絡(luò)視頻會議系統(tǒng)的研究[J].計算機應(yīng)用與軟件，2011，28(10)：227-230.

[17]楊 斌.XMPP協(xié)議分析與應(yīng)用探討[J].微型機與應(yīng)用，2005(8)：32-34.

[18]沈建輝，席彥彬.迎接云電視時代[J].中國有線電視，2013(1)：28-30.

[19]施唯佳，蔣力，賈立鼎.和的技術(shù)比較分析[J].電信科學(xué)，2014，30(5)：14-19.

[20]章鹿華，王思彤，易忠林，等.面向智能用電的家庭綜合能源管理系統(tǒng)的設(shè)計與實現(xiàn)[J].電測與儀表，2010，47(9)：35-38.

DesignandimplementationofmultiscreenonOTTplatform

YENan

(Department of Information Engineering, Fuzhou Institute of Technology, Fuzhou 350506, China)

Abstract:In order to solve the problems that traditional TV business is single and the communication area is limited, the designing project of a OTT platform based on multi screen interactive is proposed to achieve three screen linkage of mobile phones, computers and TV. The scheme through setting up by BO management system, Portal system, CDN system and plug-flow system that provides for the whole terminal live, on-demand and back to see TV service. Through the establishment of the interactive protocol between the mobile terminal and set-top boxes, as well as between mobile terminals, the service of the cloud is realized, and the remote control TV is supported. The design and implementation of personalized service and multi screen interactive system based on OTT platform not only promote the diversified business communication, but also enrich people's intelligent life.

Key words:multi screen interaction; OTT; mobile terminal; CDN

中圖分類號:TN949.2

文獻標(biāo)志碼:A

DOI：10.16280/j.videoe.2016.03.014

基金項目：福建省教育廳B類科技項目(JB14230)

作者簡介：

葉楠(1990— )，女，碩士，助教，主研電子信息、圖形學(xué)與通信。

責(zé)任編輯：許盈

收稿日期：2015-09-17

文獻引用格式：葉楠. 基于多屏互動的OTT平臺的設(shè)計與實現(xiàn)[J].電視技術(shù)，2016，40(3)：65-70.

YEN.DesignandimplementationofmultiscreenonOTTplatform[J].Videoengineering，2016，40(3)：65-70.