基于多屏互動的OTT平臺的設計與實現

葉　楠

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

基于多屏互動的OTT平臺的設計與實現

葉楠

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

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

關鍵詞:多屏互動；OTT；移動終端；CDN

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

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

1總體設計

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

圖1OTT平臺總體框架

1.1BO管理子系統

OTT平臺BO子系統提供了媒資元數據的維護管理，認證鑒權服務，以及產品流程的生命周期管理。BO管理子系統包含了CMS內容管理系統、OSS運營支撐系統、AAA鑒權計費模塊、PortalMS門戶發布系統等子模塊[9-10]。

1.2統一Portal門戶

統一Portal系統是業務最終展現的出口，是各種業務面向多終端用戶的最后一道關口，是前端系統與終端間的橋梁，并能夠根據地區差異提供不同的門戶信息。

1.3轉碼系統

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

1.4ISS流服務系統

ISS系統是OTT平臺中對直播、點播、時移和回看數據進行不同格式封裝后以HLS分片傳輸的流服務系統[11]。通過對視頻元數據的熱點處理、緩存定位及HTTP傳輸，實現了平臺到終端設備的出流，對于設備的有效利用率、用戶的出流穩定性上也做了關鍵性的處理。

2關鍵技術與處理流程

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

2.1媒資內容播發流程

如圖2所示為媒資元數據的注入及上線流程。媒資系統通過ADI接口同步編目信息至OTT平臺，通過對ADI字段的解析處理，調用離線轉碼設備的相應模板，即完成了媒資的注入過程。媒資文件下載完成后，由內容播發模塊CPM對媒資來進行上線過程的處理。

2.2CDN內容分發子系統

圖3所示為CDN內容分發系統的架構圖。CDN支持集中式部署、多級部署方式。其中，中心存儲只做中心內容緩存，由邊緣加速層面向終端，提供流服務。CDN中，重要模塊功能如下：

1)CI：內容導入模塊，提供將媒資內容導入到CDN中的接口。

圖2　CPM內容播發流程

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

3)CL：內容中心存儲，主要負責節目存儲，同時為其他CL和CG提供下載服務。

4)CLS：內容調度模塊，負責對CG或CL的調度管理。

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

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

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

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

圖3CDN內容分發子系統

2.3基于云互動的跨屏協同平臺

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

2.4設計方案合理性及有效性

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

1)推流架構設計：與傳統的一級推流相比，本設計方案采用分布式CDN部署，能有效解決收視業務的并發推流能力分配問題及分節點的建設部署。

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

圖4　基于云互動的跨屏協同平臺

POST請求來進行交互信息傳遞，與傳統的機頂盒局域網內UDP交互相比，適應性更強，應用場景更廣泛。

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

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

圖5業務層及協議層工作流程

3系統冗余性設計

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

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

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

表1Keepalive浮動IP冗余備份

排序主服務器業務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

另外，通過定時任務監測推流進程的服務情況，當進程因不明故障終止運行時，通過crond即可使進程在5min內自動啟動，繼續對外提供服務。

4系統測試與對比

為了驗證設計方案的穩定性，方便對系統性能做出評估，對OTT平臺的各項指標做了如下測試。

4.1接口性能測試

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

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

接口說明及測試結果如表2所示。

表2Portal接口性能測試

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

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

4.2推流并發測試

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

表3收視業務用戶數分配

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

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

TitleTransactionResponseTimeUnderLoad

GraphTypeCorrelate

BaseGraphRunningVusers

AdditionalAverageTransactionResponseTime

Granularity1Second

表4測試數據統計表

顏色規格測試項最短時間/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　負載下事務響應時間測試(截圖)

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

從以上測試結果可以看到，對直播、點播、時移、回看業務按同比例用戶數進行綜合測試，分片下載正常，時延在合理的范圍內，表明本系統具備較高的穩定性。

5小結

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

參考文獻：

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

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

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

[4]劉洋.三網融合下電信運營商TV屏業務發展策略建議[J].電信科學，2011(S1)：187-190.

[5]鄭鵬思.關于三網融合視頻業務實現的研究[J].廣播與電視技術，2011，38(12)：82-84.

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

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

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

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

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

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

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

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

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

[15]馬曉，馬立銘，曹三省.面向業務的智能電視系統架構設計[J].電視技術，2012，36(12)：32-34.

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

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

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

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

[20]章鹿華，王思彤，易忠林，等.面向智能用電的家庭綜合能源管理系統的設計與實現[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

文獻標志碼:A

DOI：10.16280/j.videoe.2016.03.014

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

作者簡介：

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

責任編輯：許盈

收稿日期：2015-09-17

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

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