基于多屏互动的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.