VOD点播系统设计

VOD点播系统设计（精选八篇）

VOD点播系统设计 篇1

但同时随着互联网节目源的增多,用户的需求增大,视频Server I/O带宽及网络带宽的瓶颈缺点也日益明显。如何合理调度视频Server和网络资源,如何优化Server资源配置成为VOD发展的关键问题。为了解决视频Server的并发问题,典型的静态节目调度算法有周期广播算法、金字塔算法等;动态调度算法有Batching算法、客户端缓冲算法和补丁算法[2]。在具体调度策略研究中,文献[3]提出了在系统不同运行阶段采用不同的点播方案,考虑了点播周期和点播频率信息,但没有考虑用户行为;文献[4]研究了节目流行度,但没有分析点播周期。

本文基于VOD系统的实际应用需求,通过对几种常用节目调度方案分析,综合考虑用户行为和节目流行度,改进了一种有效的符合用户需求的的节目调度方案,在一定程度上克服网络带宽及存储服务器的I/O瓶颈,实现系统的优化设计。

1 VOD系统体系结构和数据结构

VOD系统的体系结构如图1所示,大规模分布式VOD系统一般都采用层次化存储架构[5]。一个典型的系统结构包括:服务器模块、网络传输模块和用户终端。

其中服务器模块包括中心Server和边缘Server,中心Server分为存储系统和管理系统,功能是进行状态记录管理和流媒体信息的检索与传输;边缘Server提供视频点播和流传输。网络传输模块负责视频节目信息流的实时点播传输和调度传输。用户终端采用pc端RTSP流播放器。

该系统设计的数据结构,数据包规定存放数据的一般形式,不规定具体存放什么数据。每个数据包由报头Header和有效负载Payload组成。Header携带通用数据,用于标识此数据包属VOD系统,指明数据包类型并分析负载参数,Header长度和格式固定;Payload携带私有数据,用于存放需要交换的数据,包括数个结构Struct,每个Struct又由一个数据Data段和数个描述子Descriptor段构成,Payload具有一定的格式规范,其长度和内容不定。连接通信两端的程序通过判断Header以及Struct中的类型标识来使用对应的格式解析数据包中的数据。

2 VOD点播流程

VOD点播过程中,主要数据包有点播请求包REQ_VOD,点播响应包ACK_VOD,用户状态变动请求包REG_USRSTATUS等。

REQ_VOD包用于终端申请点播服务,它分别向当前连接的边缘Server和中心Server各发送一次。对于当前连接的边缘Server来讲,此请求是一次点播记录,由于其不一定存有用户请求的视频流,此记录也可以用于登记某视频流在某边缘Server上点播没有命中的次数。此数据被边缘Serve统计并定期状态反应给中心Server,以决策如何在边缘Server间调度视频流。此外,此数据还可以用于建立用户点播习惯的数据库,以用于节目流行度预测。对于中心Server来讲,此请求是一次点播行为的开始,中心Server根据此请求来开始一次点播流程。

ACK_VOD包用于中心Server回应终端的点播REQ_VOD包,中心Server根据REQ_VOD包的Program ID查询边缘Server列表,再根据Service ID从该Server列表中选出与请求终端较近的服务器的子集列表,将此表封装在ACK_VOD包回发给终端,以供终端路径选择。

REG_USRSTATUS包用于已接受终端RTSP连接的边缘Server向中心管理Server报告终端的连接动作。中心Server记录终端的行为以供统计分析。

用户具体点播流程如图2所示。

3 节目调度方案

VOD系统中,不同节目本身的流行度不同,而且用户对节目的访问时间对节目的冷热度有很大的影响(如周一到周五20:00-22:00以及周六周日点播强度较高[6])。若采用单一调度方案,或调度方案比较固定,将会影响整个VOD系统的服务水平。我们从用户点播行为和节目流行度入手分析。

3.1 用户行为分析

统计分析研究表明,在一定时间段内,用户点播行为满足Zipf-like分布。假设中心Server有n个片源,点播率由大到小排列,则第k部片源的点播率满足,其中修正参数θ=0.271[7]。即用户对系统节目源的选择大体上表现为用户80%的点播集中于20%的流行节目上。

另一方面,当用户成功点播一部节目,通过一段时间的观看,逐渐对节目产生个人认识和评价,之后决定是继续观看还是退出点播其它节目。所以在单个节目的点播中,节目前期的点播比例较大。统计表明,当一次点播超过节目总长的50%后,用户基本不会再退出[8]。

3.2 节目流行度分析

节目流行度的分布反应用户访问的局部性现象,它对流媒体系统冗余缓存算法的设计有着显著影响。现有对流行度的建模工作中,流行度被定义为用户对媒体对象的访问次数[9]。我们在数据库存储上采用流行节目靠前的文件段在每个边缘Server冗余存储的方法。但是由于节目流行度会随时间变化,所以需要实时调度。

3.3 中心Server节目调度

由于单个节目点播率会随时间而变化,每隔一定时间,中心Server要对片源存储进行调整。文献[10]对节目点播率随时间变化的特性做了统计分析,指出每个节目都有高峰期,中间期和低谷期。中心Server定期查询和操作数据库,增加流行热播节目的备份数量,删除冷门节目的冗余备份。

节目调度策略如下:

1)每个片源文件分段存储,文件段初始分配时均匀发布在边缘Server上;

2)当中心Server收到边缘Server(目的Server)的节目调度请求。查询数据库记录,若当前有空闲边缘Server(源Server),向其发送节目调度命令数据包。使目的Server获得源Server地址,用户名和密码;若当前无空闲边缘Server,则从下一服务时间最近的边缘Server列表中选择,返回给目的Server;

3)每隔一定时间,中心Server根据各节目的流行信息进行重发布。对于流行度在前20%的节日,将其时间靠前的文件段,冗余存储在每个边缘Server上,文件的中间段,存储在部分负载较低的边缘server上,时间靠后的的文件段,不进行重发布;

4)中心Server记录并统计边缘Server的负载情况,对于一定时间周期内用户负载量大且持续时间长的边缘Server,该周期内片源文件整块冗余发布。

另外,中心Server通过统计边缘Server的反馈信息,可以从某小区点播预测出热门节目,提前在临小区边缘Server上做好冗余,为用户可能的高频率点播做好准备,以提高系统的全局负载均衡能力。

4 管理软件和系统点播安全

数据库LSDB按需求建立表和表之间的关联,用对象属性来表示对象对数据库的相关内容。包括用户userinfo,边缘Server_List,节目源Program_List和节目分配Program_Distribute_Table。

用户管理软件有增加、查找(按照所有数据域查找)、删除、修改(在查找出的列表中修改)用户;打印用户点播记录、用户缴费记录等功能。服务器管理软件有增加边缘Server、查找Server(按各种数据域查找和修改)、删除Server、修改Server等功能。

用户账户合法性检查。当用户向中心Server发送REQ_RETSPEED包点播连接成功时,中心Server为此次RTSP连接生成一次性随机密钥。判断用户主机物理地址属实后,将流媒体信息格式化为类似rtsp://ServiceID:Password@192.168.1.16/VodStreamName.ts”的RTSP连接地址,通过ACK_RETSPEED包(包含播放该视频流所必须的参数)发送给用户终端。随机密钥以加密形式发送,从而保证用户账户被盗后其权益不受侵害,实现系统的安全点播。

5 结束语

本文所设计系统从用户行为入手,通过对用户动作特征分析,将视频文件分段存储在中心Server数据库中;根据流行节目的点播率不同在边缘Server数据库进行一定量的冗余存储;同时中心Server定时检测边缘Server负载量以在边缘Server间实时节目调度,从而实现视频节目的分段分时综合调度。通过实验表明,该调度方案具有良好的应用价值,能有效缓解点播服务中的带宽瓶颈问题,提高整个系统的负载均衡能力。另外,在数据库模块和软件模块设计上从用户实际操作需求出发,最终达到系统的可行性设计。

摘要：视频点播(VOD)是目前广受网络用户欢迎的应用服务,而节目调度问题始终是VOD系统方案设计和实现中的一个重要问题。该文针对互联网的用户点播特点,从用户行为和节目流行度入手,详尽分析了系统体系和用户点播流程。通过改进基于流行度的节目调度策略,采用每个节目不同片段分块备份存储和不同时间实时调度相结合的方案。实验表明,该方案的边缘Server资源利用率较高,系统能达到较好的服务性能。

关键词：节目调度,分布式系统,用户行为,视频点播

参考文献

[1]何涛.如何使VOD家喻户晓[J].有线电视技术,2004,61(11):60-65.

[2]宛斌.基于NAT_PT的流媒体调度公平性研究[D].南京:东南大学.2006.

[3]魏维,罗时爱,刘凤玉.视频点播中视频服务器节目替换算法研究[J].计算机工程与应用,2008,44(2):245-248.

[4]胡玉琦,臧怀泉,高远.基于代理缓存的VOD系统的节目综合调度[J].东北大学学报:自然科学版,2004(9):833-835.

[5]李永丹.一种集群分布式VOD系统的实现[J].软件导刊,2009(8):118-119.

[6]鄢仁祥,高远.视频点播系统中的节目调度[J].小型微型计算机系统,2002(10):1214-1217.

[7]王永亮,刘峰,张春.VOD系统的负载均衡存储策略及调度算法研究[J].电视技术,2004(11):40-42.

[8]胡涛,许胤龙.分布存储VOD系统的负载均衡设计及其仿真[J].计算机仿真,2009(4):186-189.

[9]周铀.视频点播系统访问行为分析[D].合肥:中国科技大学,2009.

VOD点播系统设计 篇2

摘要：文中简单介绍了VOD点播系统的构成、功能、特点，以及各种不同方案不同的应用场所等。

关键词：VOD点播系统方案有线电视网机顶盒

1VOD介绍

VOD(Viedo On Demand)即视频点播技术的简称，也称为交互式电视点播系统。它是一种受用户控制的音视频分配业务，使得每一个用户可以交互式地访问远端服务器所存储的丰富的节目。VOD系统使用非常简单直观，用户可以按照自己的意愿自由地选择节目内容和节目的播放时间，实现人与电视机的直接对话(人机交互式操作)，用户选择节目的过程可以像在饭店吃饭点菜一样简单。VOD点播技术曾广泛应用于卡拉OK娱乐业；另外，它还有在电影点播、点播新闻、信息服务、远程教学、远程购物和家庭银行等方面的具体应用。

2VOD系统有三种实现方案

2.1基于有线电视的模拟方案

2.1.1配置①网络有线电视网+电话网；②主机房：视频服务器+视频解压设备+模拟电视调制设备；⑧客房：模拟机顶盒。

2.1.2实现方式客人在房间内用遥控器向模拟机顶盒发出命令，模拟机顶盒通过电话线将客户请求发送至视频服务器端。视频服务器将客户请求观看的节目通过视频解压设备转换为模拟电视信号，通过模拟电视调制设备与普通的有线电视节目一起传输。客户端机顶盒自动选取客户点播节目所在频道，使客人观看到点播的节目。

2.2基于有线电视的数字方案

2.2 1配置①网络：经过改造的有线电视网：②主机房：视频服务器+数字电视调制设备：③客房：数字机顶盒。

2.2.2实现方式这种方案其实是有线电视台的数字化方案。首先需要对有线电视网进行双向改造，数字机顶盒接收的客户请求可以通过有线电视网上行到达视频服务器，视频服务器端将压缩的数字视频信号经过数字电视调制设备发送到有线电视网上，每个模拟频道可由多个数字视频流复用，数字机顶盒接收数字视频信号后进行实时解压并输出到电视机上。经过数字化改造的有线电视网还可以传输数据，实现上网、综合服务等功能。

2.3基于计算机网络的方案

2.3.1配置①网络：计算机局域网；②主机房：视频服务器+网络交换机：③客房：PC机或网络机顶盒。

2.3.2实现方式基于计算机网络的方案相当于一套计算机应用系统。从早期的10兆网，发展到现在的百兆、千兆交换网，计算机网络为用户提供了越来越多的带宽资源，这就使人们对在网络中传输多路视频节目的需求能够实现，计算机应用也从以文本为主向着包含文本、音频、视频的多媒体应用发展。基于计算机网络的视频点播工作过程如下：用户在客户端PC机或机顶盒启动播放请求，这个请求通过网络发出，到达并由服务器的网卡接收，传送给服务器，经过请求验证后，服务器把节目库中可访问的节目名准备好，使用户可以浏览到所喜爱的节目单。用户选择节目后，服务器从节目库中取出节目内容，并传送到客户端播放。

由于计算机网络本身具有的功能，只需加上一台代理服务器，就可以将所有客房连入Internet网，并且可以实现强大的点菜、计费、游戏等功能。

3VOD系统在宾馆、酒店中的应用

3.1VOD的应用中国宾馆酒店产业规模正在逐年扩大，并且明显地朝着娱乐化、高档化、规范化、计算机网络化、国际化等方向转化。宾馆酒店只有为客人提供更加丰富完善的服务，才能在激烈的竞争中获胜。影视点播、上Internet网、综合信息服务，将渐渐成为宾馆酒店的客房里必不可少的功能。

目前VOD视频点播在宾馆酒店行业发展迅速，以香港地区为例，现有酒店80％左右都配备了影视点播及收费系统，而我国仅在10％左右。由于宾馆的客人来自不同的国家和地区，教育、文化背景均不相同，因而对电视节目的要求也千差万别。视频点播业务以其丰富的节目内容给客人提供享受，能够满足不同客人的不同需求，无疑是酒店客人喜爱的一种服务形式。

酒店视频点播系统在国内外的酒店能够得到广泛的认可，有其以下一些原因，如：①可增加酒店娱乐服务的内容：增加传统广播电视节目以外的一些精彩节目，增加节目的娱乐性，可使顾客得到极大享受。②可以提供特殊的信息服务功能，如股票证券、交通等信息。③降低管理成本：由于该系统自动化程度高，完全可以做到无人值守，从而提高服务质量的同时又降低了人员与经济的消耗。④提高了酒店的服务档次：在酒店星级评审中，根据国家旅游局计划VOD视频点播也将作为星级评审的标准之一。⑤增收创益。

3.2宾馆酒店VOD系统前面已讲述VOD系统的三种实现方案，对于宾馆、酒店而言，各种方案有其不同适合场所。

3.2.1第一种方案的优点在于其利用了现有的有线电视网和电话网，无需铺设新的线路，并且客户端模拟机顶盒造价低廉，整个系统的成本较低；但是模拟电视信号传输容易衰减和受干扰，每一路点播节目需要占用一个有线电视频道，所以并发点播数极其受限制，最多只能支持16路或24路，并且无法提供上网和消费等综合服务，功能单一。

因此这种方案属于过渡性方案，特别适合于旧楼改造工程，对新工程而言不失为一个低成本方案，在低档酒店还有一定生命期，同时该方案为目前一个主流产品，但是长期来看将逐渐被淘汰。

3.2.2第二种方案的优点在于利用了现有的有线电视网，无需铺设新的线路数字调制采用的频道复用技术可以在一个模拟频道上传输多达25路VCD品质的视频节目，可以满足很大的并发点播要求，数字化传输保证了视频品质，同时采用CABLE MODEM技术后可以实现上网等功能；当然该方案也存在着包括有线电视网需要经过改造、数字机顶盒价格较高以及服务器和数字调制设备代价昂贵的缺点。

目前这种方案的相关技术尚未完全成熟，投资较大，在实际应用中较少。

3.2.3第三种方案也就是基于计算机网络方案，与前前两种方案相比，节省服务器的有线电视调制设备费用，完全数字化传输保证了视音频品质，上网、消费等综合服务功能很容易实现而且功能强大，高达千兆的网络带宽可以支持几百个客户的并发点播，同时由于综合布线的日益普及，计算机网络的建设已不再是该方案的关键问题。

技术已经十分成熟，能够提供的综合功能是其它方案无法比拟的。但是该系统也有初期投资大，计算机更新换代快、容易造成投资风险等缺点。

该方案适合于新建高标准的宾馆、酒店。

4VOD系统功能特点

4.1影视歌曲点播一台视频服务器可以存储多达100部电影，支持超过40个用户同时点播一个节目或不同节目，配备多台视频服务器实现分布式点播，可以支持多达几百个用户同时点播节目，可以包括电影、卡拉OK歌曲，也可以是自制的介绍节目或者广告，播放的视频品质支持MPEG-1、MPEG-2，可以达到相当于VCD和DVD品质，客户在观看时可以对节目进行完全控制，包括播放、暂停、快进、快退等；丰富美观的交互界面，支持多种点播方式：采用红外线遥控设备，操作方便快捷。

4.2计费管理点播计费：对客人点播的节目按点播节目次数进行收费；上网计费：根据时间收费(选项)；帐单查询客人可自己查询消费的内容和应付金额；营业报表：自动统计每日和周期营业报表：经理查询：经理可随时查看当前营业状况和历史记录。

4.3其它服务Internet上网：VOD-4000机顶盒可以通过网络上的代理服务器直接连Internet；客人若带有便携式电脑，亦可直接通过计算机网络上网收发邮件和浏览，无需拨号。游戏：可提供多种趣味电脑游戏供客人休闲娱乐。内部网站可以建立单位内部网站，为用户提供个性化信息服务甚至可以有BBS和聊天室。

5结束语

VOD点播系统设计 篇3

1NGOD架构

新一代视频点播服务的基本架构NGOD是由有线电视服务商美国康卡斯特电信公司(Comcast Corp.)提出的一种网络框架结构,已经逐渐取代ISA架构。为满足不断更新的视频业务的部署需求,NGOD采用模块化、灵活性、可扩展性的视频架构以支持多种业务。 NGOD架构中,采用ERM来实现边缘资源的管理和分配。ERM的逻辑功能分为设备发现功能和资源管理功能,D6接口[6]用于动态发现边缘设备,R6接口[7]用于边缘资源的分配和回收,两者相互独立,同时,R6接口和边缘设备通信前,需要从D6接口来收集自己管理的资源信息。如图1所示为NGOD架构中的边缘组件架构图。

本文的工作重心为NGOD架构下EdgeQAM端D6、 R6接口的设计与实现。

2D6接口的设计与实现

D6接口是基于VREP(Video Registration Protocol) 协议(在TRIP协议的基础上进行扩展)实现的。VREP协议基于底层TCP/IP提供可靠传输,包括OPEN消息、 UPDATE消息、NOTIFICATION消息和KEEPALIVE消息4种。交互时序图文献[8]已有明确说明,当连接处于已建立状态时,D6客户端通过UPDATE消息向管理自己的唯一ERM注册,主要包括每个QAM通道的属性以及边缘设备相关参数。

2.1客户端D6接口的功能模块图

D6接口的客户端程序主要包括主流程模块、组包模块、解包模块、定时器模块、状态转换模块、事件模块、与EdgeQAM主板软件NGOD进程的通信模块。D6客户端功能模块如图2所示。

主程序模块主要负责与ERM建立连接,与其交互,并对相关异常进行处理。组包模块负责OPEN消息、UPDATE消息、NOTIFICATION消息、KEEPALIVE消息的组包。解包模块则为除UPDATE之外的其他消息提供解析函数。定时器模块包括重连定时器、保持定时器和心跳连接定时器,定时器的功能各不相同,但一般保持定时器hold time的时间是心跳连接定时器的3倍,也就是连续3次发送KEEPALIVE消息仍收不到回复,那么hold time超时,需要断开连接。状态模块包括空闲、连接、激活、OPEN已发送、OPEN确认和已建立6种状态。事件模块包括起始、终止、TCP异常、定时器超时、收包等12种事件。其中,收到消息、定时器超时等会触发相应事件,事件的发生会导致状态的转换。自定义的通信模块主要是与EdgeQAM的主板软件NGOD进程之间通信。

2.2客户端D6接口的状态转换图

程序实现采用有限状态机方式编程,如图3所示, VREP会话共有6种状态。在IDLE状态下,当一个开始事件(IE1来自系统或者操作员)出现时,初始化所有的VREP资源,打开重连定时器,初始化到ERM的连接, 转换到CONNECT状态,其他事件发生则保持IDLE状态不变。在CONNECT状态下,如果TCP连接成功 (IE3),则发送OPEN消息给ERM,设置定时器的值,并转移状态为OPENSENT;若TCP连接建立失败(IE5), 则转移到ACTIVE状态,其他事件做相应处理。在ACTIVE状态下,VREP试图与ERM建立TCP连接,如果连接成功则仍可建立连接,否则重连超时(IE7)会退回到CONNECT状态,其他事件做相应处理。在OPENSENT状态下,如果从ERM收到OPEN消息(IE10),检测无误则向ERM发送KEEPALIVE消息状态转移到OPENCONFIRM状态,否则发送NOTIFICATION报错,转到IDLE状态,其他事件做相应处理。在OPENCONFIRM状态下,收到KEEPALIVE消息的回复(IE11),那么最终会转移到ESTABLISHED状态,在已建立状态下D6客户端即可向ERM发送UPDATE消息来实现QAM等详细信息的注册。

3R6接口的设计与实现

R6接口的消 息交互是 基于RTSP(Real Time Streaming Protocol)[9]实时流传输协议,RTSP文本消息的传输既可以建立于TCP/IP,也可以建立在UDP之上, 鉴于文本消息的数据有限,采用TCP传输更为可靠。主要包括Setup,Teardown,Announce,Get_Parameter, Session Keepalive信令。当SM发送一个资源请求,要求ERM建立一个点播会话时,ERM作为客户端将向EdgeQAM服务端发 送一个会 话建立请 求消息 , EdgeQAM根据分配请求的参数,建立UDP+节目号+ QAM的映射关系,也可以要求EdgeQAM向TS流中注入带内标记,或停止注入、检查等功能。当用户撤销点播时,SM发送撤销请求给ERM,ERM通过R6接口的Teardown信令通知EdgeQAM,回收资源。

3.1R6接口的流程图

程序首先创建RTSP服务器,监听554端口,ERM客户端根据D6接口注册的IP地址访问该端口。由于RTSP协议不同于HTTP协议,其交互是双向的,信令可以由客户端发起,服务端应答,也可反过来。如果已分配的QAM在会话过程中发生异常时,可主动发送Announce消息通知ERM。所以收到的消息可能是Announce请求的应答消息,也可能是其他信令请求消息中的一种。若是请求应答,则调用应答处理函数。若是请求消息,则根据请求首部的命令字段判断消息类型,如Setup消息,且含有ProvisionPort字段,此消息就是预分配请求,R6接口服务端收到该请求,调用rtsp_r6_setup_parse函数进行解析,需要服务器随机产生一个不重复的Session ID,并将该Session添加到一个会话链表,然后把Transport字段的参数传递给EdgeQAM的主板软件做相应底层配置,最后给出回复消息。 Teardown消息请求则需要将会话从链表中撤销,完成资源的回收工作。若为其他请求消息,则共同维护一个Session ID。R6服务端流程图如图4所示。

3.2R6接口端口状态转换机

在该状态机中,端口状态可以从Not Configured或Provisioned任一个状态开始。如果EdgeQAM支持动态端口映射,那么端口起始状态是Not Configured,如果EdgeQAM支持其他方式(如固件映射或配置文件)的静态配置端口,则端口可选择从Provisioned状态开始。 当EdgeQAM收到ERM的预分配请求后,端口从Not Configured状态转换为Provisioned状态。端口在Not Configured状态,没有数据被传输到QAM输出,然而在Provisioned状态,所有数据被映射到QAM输出,如果可能,ERM请求EdgeQAM在输入流带内标记发生变化时通知它,这会导致流在无带内标记到有带内标记之间互相转换。当EdgeQAM收到ERM的StartChecking消息后,端口从Provisioned状态进入到In Session状态,其又分为两个子状态,Markers Match和Markers Mismatch。在Markers Match状态,带内标记必须检查,如果带内标记不匹配,数据流不会被输出到QAM,也不会注入任何数据;若匹配,则可以注入一些带内标记。当收到StopChecking消息后,会退回到Provisioned状态。 当收到Teardown消息后,端口进入Not Configured状态。如图5所示为R6接口的端口状态机。

4D6,R6与主板软件的通信机制

EdgeQAM的主板是整个设备的控制中心,主板软件中的NGOD进程负责与D6,R6接口通信,该通信协议标准中并未定义。进程间通信可采用管道、信号量、 共享内存、套接字、消息队列等。此处采用消息队列比较合适,Linux下的消息队列中的消息体字符数组最大支持8 192 byte,如果消息的长度大于8 192 byte,应该按8 192为单元划分成若干条消息。为了实现双方交互,可以在两个进程中都开启一个发送和接收队列。 NGOD进程与D6,R6进程通信协议如图6所示。

命令头中的第1个字节Type为D6或R6,表示通信对象。第2个字节Ret为返回值取0、1或2,分别表示消息返回状态是默认、失败和成功。Total Length表示消息的总长度包括命令头的长度。All Frame num表示消息的总帧数,Current Frame表示当前帧数,接收端根据这两个值判断消息是否接收完成,后面保留4 byte长度。参数头则包括4 byte的参数类型和2 byte的参数长度。由于EdgeQAM输入端口参数和QAM子板各通道的参数比较多,所以为了区分不同类型的参数采用基地址加偏移量的方式表示。

5实验与测试结果

本接口是基于Linux(内核版本3.5)进行验证的,采用的芯片是Xilinx公司的基于ARM cortex-A9处理器平台的Zynq-7030。EdgeQAM的Flash最小为32 Mbyte,DDR容量为256 Mbyte。由于测试内容比较多,主要分别对D6,R6接口建立过程和部分消息进行测试。测试结果在下文介绍。

5.1D6接口与ERM的通信验证

D6接口的实现包括与ERM连接的建立,以及各种消息的交互,ERM的IP地址通过Web端由用户设置为192.168.0.160,端口号为8888。图7为D6接口与ERM的连接建立过程以及OPEN消息的详细信息。 程序启动之后会采用EdgeQAM主板软件传递过来ERM的IP地址和端口号等参数尝试连接ERM,地址正确则可以连接上,主动发送OPEN消息,收到的OPEN消息如图7所示,最终处于已建立状态,保持心跳连接等待UPDATE消息和其他消息的交互。由图中运行结果与预期一致,可以证明D6接口与ERM交互正确。

5.2R6接口与ERM的通信验证

R6接口的实现包括与ERM连接的建立,以及各种请求消息和应答消息的交互,R6接口启动之后在本地的554端口监听,ERM通过D6接口注册的IP地址及固定端口与R6建立连接。如图8所示为R6接口收到ERM的端口预分配请求,CSeq为314,Transport头包括请求分配的QAM信息和UDP信息,InbandMaker头包括请求注入带内标记信息等。R6通过解析该请求, 发现请求正确并且底层成功处理完成,回复该请求如图9所示,Session为随机产生的不重复的ID,该结果与预期的结果一致。除此之外,还通过大量的测试, 如带宽请求过大等,R6接口皆能识别并能正确回复请求应答或是发送异常请求,由此证明R6与ERM的交互是正确的。

6小结

VoD点播系统资源管理实践 篇4

1 节目

节目上载过程如图1所示, 可通过多种渠道获取节目, 部分由供应商现成提供, 部分需自己制作。

1) 节目质量。节目供应商、媒资平台的节目质量一般不存在问题, 基本无I帧丢失, 节目时钟参考 (PCR) 抖动也在接受范围内;录像带、影碟编码的节目无I帧丢失, 无PCR抖动;而通过数字电视前端采集及在媒资平台的节目可能存在I帧丢失和PCR抖动问题。针对该问题, 可在节目上载前进行节目自动修正, 而且在上载过程中, 要求能够再次进行节目质量检测。同时, 应禁止I帧丢失严重、PCR抖动严重的节目上传到视频点播系统, 并且要求节目以CBR恒定码率上传到视频点播系统, 以利于依据频点带宽状况进行动态调整。

2) 节目信息。建议采用美国Cable Labs制定的Vo D Metadata标准定义的资产传送接口Asset Distribution Interface (ADI) 2.0, 对所有的节目进行规范管理。Metadata信息是对与之相关的节目内容进行描述的数据或信息。Metadata信息被资产管理系统用来管理节目资产, 同时也被传送给用户的机顶盒 (STB) 供其电子节目指南 (EPG) 使用。在用户点播前或点播过程中应允许用户进行节目信息的调阅, 甚至允许实现简单信息、详细信息的不同调阅。由于大部分的节目可能需要人工自行添加ADI信息, 人力、物力都会是一笔不小的开销。

3) 节目操作权限。由于需求不同, 会采取节目集中存储或分布存储, 这都应该由资源管理系统统一进行上载和发布, 以免造成节目丢失、选单与节目库不一致或产生垃圾文件。

4) 节目审核。在节目选单真正发布之前, 建议先通过节目人工预览系统进行检视 (可以采取多画面快进方式浏览以加快检视速度) , 将不合要求和违规的节目下线, 保证发出去的节目都是合乎要求的。

2 选单

已发布的选单和节目库必须紧密联系, 由资源管理系统进行一致性管理。建议采用动态生成选单的方式, 即在节目通过审核后, 选单中立即呈现该新的节目名称;当节目下线后, 选单中也立即取消该节目名称。要求保证在选单中所见的节目必须能够被点播。

3 频谱资源动态更新

随着运营周期增加, 网络中会同时存在多个不同厂家的IPQAM设备。不同设备有不同容量, 且由于下行网络的差异, 可能会同时存在64QAM和256QAM两种调制方式。

主流的Vo D厂商一般均和一些IPQAM进行过集成, 资源管理系统可以通过和IPQAM的实时交互获知该IPQAM的容量、调制方式等信息。但在运营过程中, 可能会采用一些新的、价格更合理的IPQAM, 但这些IPQAM有可能没有和当前的资源管理系统进行过集成, 因为前期系统规模不够大等原因, 如果要进行集成, 难度会比较大。

建议通过STB将该STB所处区域的IPQAM信息发送给资源管理系统, 由资源管理系统进行统一调度 (见图2) 。具体方式为全网的IPQAM下行通道进行唯一的标识设置, 称为TSID。在资源管理系统中建立IPQAM IP地址和TSID的动态清单。STB在开机或者进入Vo D系统的时候扫描频段, 获取网络中IPQAM的TSID和64QAM或256QAM信息, 之后将全部的信息发送给资源管理系统。

这种方式的一个好处是如果IPQAM的某个下行模块损坏, 或者由于频道受干扰, STB将接收不到相关的TSID信息, 而能够收到的TSID全部是可用的QAM通道。另一个好处是资源管理系统不必和IPQAM集成, 也不必关心IPQAM的工作状态, 从STB就可获得真实的网络参数。同时, 网络维护人员可以随时根据下行状况进行64QAM和256QAM转换调整, 而不必通知高一级的管理系统。STB会实时地将调制信息发送给资源管理系统, 资源管理系统再自动进行并发流数/频点的调整。

4 频点设置

为提高并发数, 对IPQAM通常通过空间复用的方式进行分配。即将IPQAM部署到前端或小区, 分配固定的频点范围给所有的IPQAM使用。

为提高业务安全性, 建议总前端再配置可覆盖所有区域的IPQAM, 该IPQAM使用和分前端、小区IPQAM不同的频点。当分前端、小区IPQAM因故不能使用, 资源管理系统可调用全局IPQAM对故障区域进行覆盖。

另外, 当某区域IPQAM满负载, 而又有新的点播请求, 可通过资源管理系统调用全局IPQAM进行支持。

5 机顶盒设置

如果对Vo D点播流进行加扰, 付出的代价可能比较大。可设置一个专用频段划归Vo D点播流使用。将机顶盒在工厂就设置为对该频段不能够进行自动和手动扫描, 只允许机顶盒内点播软件调用高频头调频到该频段, 这样就可以防止非点播用户手动搜索频点盗看其他点播用户点播的节目。

三种VOD视频点播技术比较 篇5

VOD (Video On Demand) 视频点播技术, 是近几年来在网络上开展的新业务热点之一 (最早产生于日本, 由中心电脑系统根据用户的点播需求将电影或录影节目直接传送到家庭的家庭娱乐系统。未来视频点播有望进入其他交互电视服务, 包括游戏、银行业务和个人理财、购物和教育服务) 。分为T V O D (T r u e V O D简称V O D) 和NVOD (N e a r V O D) 两个方式。T V O D对于每一个点播请求, 服务器都要输出一个对应的视频流, 对网络的带宽要求非常大。N V O D可支持任意多用户的点播请求, 虽然解决了带宽问题, 但是每个用户可能需要等待很长的时间, 才能得到相应的服务。

TVOD的三个特点:

1. 基于双向网络

2. 即点即放

3. 并发流数量有限、支持用户数有限、单位用户成本高

二、NVOD

NVOD (Near Video On Demand) 准视频点播是单向数字电视系统增值业务之一, 是利用视频服务器将一个数字电视节目在几个数字通道中延时播放, 使用户在点播该节目时可以等待一段时间后完整地观看该节目。

N V O D的五个特点:

1. NVOD播控系统软件功能特点:

图形化界面

节目编排采用直观的图形界面, 以不同颜色区分不同的播放状态

简单明了的操作方式

支持鼠标拖拽选择, 支持批量添加节目, 添加删除简单

信道资源的自动分配

系统可根据节目长度和节目间隔自动计算并分配通道数量

信道带宽的自动检测

节目编排、播出分离

针对数据库操作。可实现节目编排、播出分离

节目上传功能支持

可将本地硬盘的节目码流上传至视频服务器

打印功能的支持

可打印出节目编排计划, 支持打印预览

节目编排过程中自动计算同一频点的所有数字通道的节目带宽之和, 若超过最大值 (QAM64时为38Mbps) 时给出提示信息

2. NVOD节目表单生成软件功能特点:

自动从节目编排数据库中提取数据, 生成N V O D节目表单

采用M P E G-2私有分段 (Privatesection) 进行封装传输

采用单一PID结构, 可送进复用器进行复用输出

节目表单随节目编排的变化而动态刷新

TS流的生成及输出均在内存中进行, 不生成任何文件, 减小对硬盘的损耗并提高TS流的生成速度

节目表单数据中包含前端服务器的系统实时钟信息, 用于机顶盒时钟与前端时钟的同步

3. NVOD (Near VOD) 的传输网络:基于广播网络

4. NVOD优点:无用户数量限制、单位成本低

5. NVOD缺点:等待时间长 (10~15分钟)

三、PUSH-VOD

P U S H-V O D即视频推送业务, 该系统可实现让电视节目或者科普电子书通过卫星直接传输到各家的机顶盒, 并保存在其中;让老百姓可以通过点播的方式看到这些节目和翻阅电子书。

P U S H-V O D系统的核心思想

P U S H-V O D是使用少部分的资源进行广播预推服务。在非高峰时段把用户关心的热点资源进行推送, 用户端机顶盒之间可以存大量的东西, 也能带来一定的互动的效益。

P U S H-V O D的概念不是凭空想出来的, 而是仿造了很相似的概念提出的, 在互联网业务上普遍存在的现象, 欧美国家存在着预推的业务。互联网业务和有线电视点播业务也存在着短时间内大量访问的情况, 这造成了极大的缓冲和连不上。欧盟国家进行了预推, 大家对这个业务感兴趣的可以提前进行点播, 进行预下载和进行观看。过去的V O D不一样, 使用一部分资源以固定的时间大容量的方式进行强推。

P U S H-V O D系统在几种环境下的应用

1. PUSH_VOD系统在单向有线电视网中的应用

单向网络中能够很好的发挥其优势, 因为P U S H-V O D提出的思想和推出的目的是为了使运营商不需要进行大规模投资和不需要进行双向网络改造就能获得互动的功能获得增值业务的收益。P U S H-VOD使它在单向网络中很好地发挥它的优点, 用户也是一样, 随时可以点播自己喜欢的视频、音频、图片等内容;也可以进行快进、快退、检索、重复播放等功能, 而对运营商来讲前期的投入是非常少的。

2. PUSH-VOD系统在双向有线电视网中的应用

如果能将热点的节目推到机顶盒的内部硬盘内, 将极大地减少用户点播时实际占用的专用频道和播出流资源, 可以有效地提高系统运营的效果。

3. PUSH-VOD系统在专用环境中的应用。

目前有一些专用系统像党员教育系统、农村信息化平台, 都有一些共同的特点, 网络环境不一定具备双向互动的条件, 特别是偏远地区, 不可能进行大规模的双向改造。而传递的内容具有信息量很大的特点, 很可能是视频、大量的文字, 大量的图片。而何时观看、观看什么内容、如何观看等方面用户必须有完全的主动权。

4. PUSH-VOD系统在IPTV中的应用

真正的双向系统或者是真正的I P T V系统P U S H-V O D是真正有用的, 这跟双向网络很相似, 也是为了解决终端用户带宽不足的极端情况。但是IPTV环境中的P U S H-V O D与有线网络当中的P U S H-VOD略有不同, 利用业务网络的空暇带宽把数据量一点点推到用户的终端上。而在有线系统中使用了专用的通道进行大规模数据量的强推, 一部分电影可能需要8个小时才能下载完, 但是P U S H-V O D系统只用1 0分钟全部推下去。

四、VOD运营商遇到的问题

现在已经实现的V O D业务运营商都遇到了那些问题呢?第一高峰时段资源不足, 在高峰时段很多的用户会集中点播一两部热点的电影, 造成在短时间之内资源大量集中, 而在单向网之内我们根本无法提供VOD业务, 需要进行双向化改造。目前的运营商如何解决这些问题?高峰时段资源不足的问题现在无限制地增加发流数量, 增加IPQAM的数量, 这是不可能的。在这基础之上, 运营商进行了媒体服务器的前移, 采用多镜像服务器方式。

在此基础上我们进行了深入的思考, 我们是否能够进一步将服务器平移, 进一步将资源分散。这个时候我们想到广大的终端用户的资源, 我们是否可以用终端用户的资源来实现我们的V O D业务。我们发现, 当我们把V O D业务真正推到用户的机顶盒上时, I P Q A M也增加了。这就是P U S H-V O D的思想, 核心思想是在一个集中时段以广播的模式将大量的内容同时下载到所有的用户的本地终端内, 从而使得在用户实际使用时系统只需要进行终端本地操作不占有网络资源, 提供了个性化的服务。

五、三种VOD系统比较

将目前常见的几种有线数字电视网络服务类型进行比较, 一种是最基础的广播型电视服务, 一种是N V O D, 还有是真正的VOD业务。这几种业务的不同:广播型的业务还是像以前的电视一样, 虽然是台多了, 但是普遍的受众没有选择的余地, 没有选择的内容, 放什么看什么。N V O D相对来说有了一定程度的可选择性, 我们可以选择在不同的时段来看内容, 可选择的内容是固定的, 还是由运营商来确定的。互动电视VOD业务有非常好的互动能力, 强调了互动的能力, 可选的业务非常多。很显然互动电视业务是非常受欢迎的业务。但是没有大批量地推广开来, 只是在大城市做得好些, 很多地区在平移, 涉及到了互动电视的问题, 前端需要投入大量的人力、财力、物力。N V O D加少量的服务器和少量的资源就可以完成, 但是要实现互动必须要进行双向的改造。从实现服务所需要增加的投入来看, 广播电视已经做到, NVOD非常少, 互动电视业务非常多。可以看到互动电视业务与P U S H-V O D系统是矛盾, 虽然资源消耗极大, 但是有非常好的优势和有很良好的互动性。

VOD点播系统设计 篇6

1 技术及系统概述

1.1 P2P技术及VOD

点对点技术即被称之为P2P技术，是peer to peer的简称，也被称之为对等互联网技术形态，属于一种网络新技术方式。该技术的实现，主要是依赖于网络良好的宽带以及计算能力，并非集中在少数几台计算机上[1]。

VOD，即Video On Demand，是视频点播技术的简称，同时也被称之为一种交互式的电视点播系统。在人的主观能动性以及自身需求环境下，满足点播功能以及点播要求，进而获取视频资源。

1.2 某图书馆多媒体数字化系统概述

在当前视频点播系统的整体环境中，其中以娱乐为主导的视频点播系统的发展时间以及发展条件较为成熟，传播娱乐资讯以及视频资源等，在当前主流的包括基于P2P的电视直播——PPLive，基于P2P技术的视频点播——爱奇艺等。虽然在娱乐传播、视频资源传播等多方面具备较好的发展高度，但并未针对文化传播以及学术资源的传播方面做出探究。针对这一问题，某图书馆提出这一要求，引领技术服务，实现了将学术资源与在线播放软件的良好融合，在图书馆多媒体数字化系统当中的应用状况良好。基于P2P技术的VOD点播系统在该图书馆得以运行，为文化传播以及资源利用提供新的形态。

2 基于P2P技术的VOD视频点播系统应用与实践

P2P技术的VOD视频点播系统虽然在当前的研究中并非技术难题，在娱乐文化传播方面取得了突出的成就，各个类别的文化传播软件层出不穷。图书馆承载着信息传播的使命，在该环节应用视频点播系统，能够增强信息资源的获取渠道，社会效用显著。下面对具体应用进行实践分析：

2.1 系统运行环境

视频点播系统当中所传达出的视频文件对视频的相关性较强，对网络延迟相当敏感，带宽以及实时性要求尤为突出。基于此，在确保可靠性的前提下，使其能够具备稳定的带宽。确保带宽环境能够全面适应多媒体高速率以及突出性传输基本要求。只有这样，才能够在图书馆视频点播系统中，为用户提供全方位的服务体系，进而增强用户对视频数据信息的获取能力。本次探究的图书馆视频点播的服务器型号为NF8560M2,12核心CPU,32G内存，存储容量为30TB，搭载Windows7操作系统，千兆光纤以及千兆交换机，为整个多媒体系统的高校运行以及快速发展提供保障。具体视频点播系统的示意图如下图1所示：

基于上述涉及的点播系统各个系统的性能分析可以发现，该图书馆具备良好的视频点播系统的运行条件，带宽以及各项硬件符合标准，为应用于实践提供了前提条件。

2.2 系统具体操作

该图书馆的基于P2P的VOD视频点播系统具备良好的服务形态，整个系统包括前台页以及后台管理两个部分，后台管理主要是对资源进行集中的管理，具体的操作环节以及操作内容如下所示：

1）系统前台首页

在视频点播系统的首页中，界面简洁明了，能够准确的找出其中的资源。同时各个标题栏当中分为不同的类别，并在界面显示资源推荐内容[2]。当然，用户还可以依据自身的需求特性，在检索栏当中检索相应的视频资源，可搜索题目名或者主讲人等信息，在搜索完成后观看资源。

2）后台管理

后台管理通常由系统管理人才进行有效的控制，非系统管理人员通常会受到权限因素的限制。该视频点播系统的后台管理环节当中，通常包括两个方面的内容，分别为首页管理以及资源管理。

首页管理：对于点播系统的首页显示状态进行布置，操作中涉及的内容较多。(1)推荐资源，对近期收看以及搜索率较高的资源口进行统计，作为推荐资源滚动；(2)点击排行，通常图书馆的点击排行系统能够进行记忆，分为固定的时间段，管理人员对于搜索排行进行更新即可，以便于用户能够获取热门资源；(3)热门搜索词，人们搜索词在该系统中的表现，主要是在点击搜索栏出现，按照搜索频率进行降序排列。这种方式与网页搜索引擎十分相似，在视频点播系统中得以运行；(4)专题维护，对首页的专题版进行维护，实现资源的合理配置。

资源管理：主要是对资源进行上传工作，丰富图书馆视频点播系统的内部资源，并实现全面的优化。

2.3 系统使用效果

本次选取的图书馆视频点播系统运行的时间已经长达6个月，在6个月的运行时间中，视频点播功能表现的效果良好，在强大的硬件以及带宽的支撑下，视频播放无压力，资源的录入以及分享渠道更加快捷[3]。总体分析，基于P2P的VOD视频点播系统在图书馆当中的运用效果良好，能否发挥出良好的作用。但在这一良好的发展状态下，应该注意对系统的后期维护与资源的丰富，管理员充分发挥出自身职责，丰富内在资源，承载着信息传播的重要使命，为信息获取提供便捷服务。

3 结论

总而言之，在计算机技术高速发展的今天，信息以及文化传播逐渐得到应有的重视程度。探索P2P技术下的VOD视频点播在图书馆当中的运用，承载着信息传播任务的同时，社会效用显著。在未来的发展中，依旧需要对该系统进行不断完善，增强视频点播的自主服务环节，强化用户的体验。

摘要：关于VOD视频点播,是一种能够以用户为主导的音频信息系统。而相对于传统的视频点播系统而言,其C/S的框架结构得以改变,出现较大的管理以及维护开销,拓展性无法体现。该次研究提出了基于P2P技术的VOD视频点播系统,探索其具体的应用与实践,结合某图书馆多媒体数字化系统分析,分析应用实效。

关键词：P2P技术,VOD视频点播,应用实践

参考文献

[1]高平.基于P2P技术的VOD视频点播系统应用与实践——以黑龙江省图书馆多媒体数字化系统为例[J].农业图书情报学刊,2015,10(4):149-151.

[2]张敏,李玲娟,王汝传.基于Bit Torrent的P2PVOD系统研究[J].计算机技术与发展,2010,12(10):111-114.

VOD点播系统设计 篇7

关键词：VOD系统,视频点播,数据传输

随着即时网络多媒体服务需求的增加, 使流媒体系统的应用逐步多样化和规模化。目前的流媒体系统一般是建立在两种结构上:C/S结构与P2P结构。C/S结构流媒体系统在管理上具优势, 但存在以下问题[1]:

1.多客户单服务器构架难以应付大规模并发客户;

2.资源集中于服务器易形成瓶颈, 客户端资源利用率低;

3.难以实现信息被传播越广、获取越方便。

互联网上用户访问具非均衡性, 单纯增加服务器和带宽将造成极大浪费。1998年美国学者在IEEE Multimedia杂志上发表了一篇关于P2P技术实现大规模流媒体点播和直播系统的论文, 其充分利用各节点的空闲资源分担服务器负载, 无需太多改造网络, 成本低, 尤其适合现有Internet架构, 为解决流媒体系统瓶颈问题提供了新途径。

所谓P2P (peer-to-peer) 可以简单的理解为对等联网的意思。P2P之所以在Internet和C/S模式已经非常成熟的背景下走向前台, 是因为目前网络的发展水平仍然无法满足迅速膨胀的用户需求。一方面, 用户的数量呈爆炸性增长;另一方面, 原来以文本页面为主的Internet服务转向了以多媒体为主[2]。如:V0D (video On Demand) 、音乐、图片、3D、互动游戏、远程教学、远程医疗以及互动购物等。由于这些突变, 使得原来强大的集中式服务器不堪重负, 服务质量Qo S (Quality of Service) 也得不到保障。例如, 访问过宽带电影网站的人都会有这样的感受:一到高峰时段, 几乎所有的宽带网站都很难连上, 即使连接上了, 电影的播送也是时断时续。另外.网络电影的显示画面都较小。画面质量很粗糙。之所以如此, 是因为无论是集中式服务器本身, 还是它的网络带宽, 都构成系统的瓶颈。要想消除这个瓶颈, 最好的办法是将它的服务分散化, 使系统中的任意主机既享受服务, 也提供服务—这就是P2P的策略。

一、基于P2P模式的视频点播系统

本文所提出的基于P2P模式的视频点播系统基于一种分布式的思想, 它的主要优点是:

1. 充分利用了用户的资源而不是像有些基于应用层多播的同类研究, 只有正在播放的用户才参与系统服务。

2. 充分考虑到P2P系统中用户的自由性和差异性。用户可以随时断开连接或改变共享带宽, 而且共享带宽的设定也各不相同, 所以我们采用一个接收者对多个发送者的数据传输方式, 并根据发送者的带宽大小采用各尽所能的原则来分配数据传输量。

3. 我们的发送者选择策略, 能够使数据传输尽可能本地化, 从而有效地减轻主干网络的负担。

二、系统的组成

我们的VOD系统是建构在一种混合型的P2P逻辑网络模型之上的 (如图1) , 系统中的成员有:

1. 流媒体服务器:

将媒体文件分段存贮, 建立索引。并提供给用户。

2. 索引服务器:

通常是流媒体服务提供商发布媒体文件信息的Web服务器, 在用户请求媒体文件时向用户返回媒体文件的各片段的索引值。

3. 超级用户:

一个用户组内负责维护组内成员信息及各成员所拥有资源信息的用户, 同时还负责响应和转发用户的查询请求。一个组内只有一个超级用户。

4. 候选用户:

候选用户在超级用户失效时取代超级用户。一般一个组内有若干个候选用户。

5. 一般用户:

既向其它用户索取媒体文件片段, 也向其它用户提供自己拥有的媒体文件片段。

三、用户分组和管理

用户在播放之前要先查询哪些用户拥有所需媒体文件片段, 所以我们对用户进行分组并为每个组指定一个超级用户, 以提高查询的效率, 减小查询带来的播放启动延迟。分组的另一个好处是, 避免用户洪泛查找带来的网络负荷。索引服务器用一个数据表维护着系统中所有的超级用户和对应的候选用户的信息, 以及一个结点距离 (跳数) 阈值T。超级用户以数据表的形式维护着本组中所有用户的信息, 候选用户维护着超级用户上用户表的一个备份, 一般用户则只保有本组中的超级用户和候选用户的信息。用户在加入系统时先从索引服务器获得系统超级用户集合S及距离阈值T, 如果用户是系统中的第一个用户 (S为空) 或者与S中的任何一个超级用户距离都大于T, 则用户组成一个新组并成为组中超级用户。否则用户加入到S中与用户距离最小的超级用户所在的组中。系统靠定时器来维护分组结构, 索引服务器为每个超级用户设一个定时器, 在规定的时间内没有收到该超级用户的消息。就从同一组内的候选用户中选择一个作为超级用户。超级用户为组内每个一般用户和候选用户设一个定时器, 在规定的时间内没有收到用户的消息。就从表中删除该用户项。超级用户需要响应用户的查询及维护本组成员信息, 最好由性能好, 带宽高的机器来担任, 同时要求有较长的在线时间, 以避免超级用户的频繁更换给系统带来的影响。

四、片段的查询与种子用户的选择

片段的查询如果逐个进行, 系统中就会充斥着查询数据流。而一次性查询完所有的片段, 然后开始数据传输, 一方面增加了播放的启动延迟, 另一方面由于系统的动态性。到后来可能因有些种子已经离线或拥有的片段已经改变而使查询结果准确性下降。我们采取的方案是分组进行片段查询。在传输前一组片段的同时进行后一组片段的查询。如果用集合S{S1, S2, S3, ……Sn}表示查询所返回的拥有片段se的种子用户, ni表示种子用户Si与用户的距离 (跳数) 、bi表示Si的共享带宽, m表示Si连接的用户数用, 那么我们可以用T=bi/ni*mi为标准来对查询所返回的种子用户由高到低排序。按顺序选择一些作为活动种子用于数据传输, 其余的作为后备种子。这个标准的好处是:在另外两个条件相同的情况下, (1) 带宽高的种子用户优先被选中, 可有效均衡系统负载; (2) 距离近的种子用户优先被选中, 可使传输尽可能本地化, 减轻主干网络的负荷; (3) 连接数少的种用户优先被选中。可避免所有用户都去请求带宽大的种子用户而出现热区问题。为保证用户的播放质量, 用户下载数据的速度要大于视频文件的播放速度R。所以选出的活动种子的带宽之和要大于R, 如果种子数太少, 无法满足带宽之和大于R, 则启用流媒体服务器来补足。

五、数据传输

为减小正在传输数据的种子失效造成的冲击, 我们采用一个接收者对多个发送者的数据传输方式。而不是像有些研究简单地采用一个接收者对一个发送者的方式。

在本文中我们引入MDC (Multiple Description Coding) 的概念, 来进一步减小每一个p2p网络中的节点在发送数据时的负担。

多描述编码MDC假设在信源和信道之间有多个信道, 各个信道同时出错的概率非常低。通过生成多个同等重要、可独立解码的关于编码的描述, 保证在其中一些描述丢失时, 仍可以得到可接受的信号。因此, 多描述编码在基于包的网络、无有效保护机制的Internet、分集通信系统 (多天线的无线信道) 、语音编码、图像编码、视频编码、多分布的存储系统中有很好的应用前景。

针对视频的多描述编码构造方法很多, 最简单直观的方法是针对空间分辨率、时间分辨率进行亚抽样, 编码成多路描述码流。此外, 还有多描述量化、多描述变换编码及基于FEC的多描述编码。

通过对MDC和P2P技术的分析可知, 这两项技术在网络多媒体数据传输中有显著的优势和特点。将这两项技术结合起来进行视频直播能发挥其各自技术优势。基本的思路是:对原始视频采用多描述编码, 形成多路码流;对编码后的多路描述流采用P2P方式, 使多点 (即多个Peer) 相互协作, 实现多径传输。

如图2所示, 对原始图像帧进行空间亚抽样, 形成低分辨率的视频子流。按2n (n可以取1, 2, 3, ……) 进行水平和垂直方向的亚抽样。这样一路原始视频流经空间亚抽样后可形成4路、16路等2路视频子流。具体的抽样间隔根据实际应用情况进行选择。对每路视频子流进行单独编码, 可得到2路编码描述子流。编码后的描述子流通过不同的信道发往接收者。接收者对每路描述子流进行单独的接收和解码, 并将解码后的视频流合成为原始视频流。如果只接收到部分视频子流, 也可以通过相应的插值算法恢复出原始视频图像。

传输时活动种子按共享带宽的大小分配传输的数据量。假定S1, S2, S3是选中的片段segi的活动种子, 带宽分别是bl, b2, b3, 我们用s表示带宽之和b1+b2+b3, 则分配给S1的传输数据是大小为b1/S*2n的部分, 同理, 分配给S2和S3的大小为b2/S*2n和b3/S*2n的部分。

正在传输数据的种子用户的突然离线或停止共享, 以及网络的波动都会造成用户的下载速度下降, 为确保用户的下载速度大于视频的播放速度R。我们引入动态监控机制:当发现一个种子失效时。及时从后备种子中选出若干新的种子取代失效的种子, 新种子的带宽之和要大于被取代种子的带宽, 负责传输该种子未完成的部分;当发现一个种子的连接速度下降并使总的下载速度小于R时, 及时从后备种子中选出若干新的种子, 与该种子共同传输余下的部分。新种子的带宽之和要大于该种子连接速度的下降值。

六、Q o S的讨论

当用户在播放影片的过程中, 各种不稳定的状况都有可能出现, 比如网络拥塞、影片提供者断网或关机等情形。我们一方面考虑采用与RTP协议相配套的RTCP协议来对网络中的数据传输质量进行监控, 以及针对不同的网络带宽状况和相应Peer的QoS请求考虑可以引入RSVP协议预留一部分网络资源, 来获得特殊的Qo S;另一方面为了动态地保障Qo S, 可以制定相关的包含数据正确性、传输延时、数据丢包率、播放的稳定性等在内的参数标准, 在用户播放的过程中进行当前Qo S的评估, 如果存在Qo S不断下降的情况, 则可以从搜索结果中找到其他备用的影片提供者, 发送数据包进行连接探测, 当确认QoS下降到某个阈值时, 就切换到备用的影片提供者上, 只有当所有的影片提供者都不可行时, 用户的播放才显示失败, 从而最大程度地保障系统的QoS[3]。

比如在本系统中, 如果用户在第一个片段下载完成时开始播放, 并同时开始第二个片段的下载, 以后都按每开始播放一个片段同时开始下载后一个片段的方式进行。我们用t表示播放一个片段所用的时间, 那么除第一个片段外, 每个片段都必须严格在时间t内完成下载, 否则就会出现前一个片段已经播放完而后一个片段却还未下载完成的情况, 引起播放停顿。动态监控机制虽然能够在总体上保证用户的下载速度大于视频的播放速度R, 但对于单个片段来说, 有可能因为种子的调整而使下载速度小于R, 从而没法在时间t内完成下载。而如果我们在用户端设置一个大小为N+1个片段的播放缓冲区.用户在前N个片段下载完成时才开始播放, 同时开始第N+1个片段的下载, 以后按每开始播放一个片段同时开始下载后面第N+1个片段的方式进行, 则从第N+1个片段起每个片段只要在N*t的时间内完成下载, 就不会引起播放停顿。这样做无疑增加了用户的播放启动延迟。不过我们可通过以用户的最大下载速度而不是视频播放速度R来传输前N个片段的方法来减小这种延迟。在后面的仿真实验中我们可以看到, 保证用户能够平滑播放的N的最小取值与片段的大小有关系.并且即使不采用加速下载前N个片段的方法, 这种启动延迟也还是可以容忍的。

七、实验

仿真环境的参数设定为:媒体文件的长度为3O分钟.被分成一系列1O秒的片段。影片的录制速度是256Kb/s。播号用户的速度为1Mb/s, 局域网用户的带宽为10Mb/s。主干网络的带宽为155Mb/s。流媒体服务器的带宽为10Mb/s。系统中用户的加入服从Poisson分布。

我们针对不同的用户端资源缓存设定, 进行了系统服务能力对比实验, 图3是实验结果。用户缓存O%意味着所有的用户都从媒体服务器上得到资源, 与传统的VoD系统类似。图中用户缓存为50%时和用户缓存为70%时系统的服务能力相当, 是因为主干网络的速度限制了系统的服务能力。

八、结论

本文提出了一种通过用户的相互合作来提高系统服务能力的P2P视频点播系统。并通过仿真实验证明这个系统可以大大提高系统的服务能力。我们从用户组织、查询、数据传输等多方面保证用户取得较小的播放延迟和平滑的播放效果。提出一种较好的种子选择策略, 既保证了用户的下载速度, 又可使传输尽可能本地化, 减轻了主干网络的负担。基于P2P技术的视频点播系统的服务能力的提高得益于用户的参与, 进一步工作将是研究用户对系统贡献大小的度量机制, 流媒体服务提供商可据此来采用某种措施, 鼓励用户参与系统服务。

参考文献

[1]蒋雪玲.基于P2P流媒体系统的实现研究[J].宁波职业技术学院学报, 2006, 10

[2]张伟文, 金鑫, 吴国新.一种基于P2P的视频点播系统的研究与设计[J].计算机技术与发展, 2007, 2

[3]张谢华, 夏士雄, 张欢.基于P2P的分布式VOD系统的研究[J].计算机应用与软件, 2005, 11

VOD点播系统设计 篇8

关键词：VOD,视频服务器,负载均衡,负载均衡算法

基于集群的VOD系统视频服务器设计负载均衡时，要求做到由多个视频服务器分担众多的客户请求，当有客户请求到来时，负载均衡调度系统将该请求分配到一个最合适的视频服务节点[1]。对于由异构处理机节点构成的集群系统而言，由于各节点的处理能力不同，相同的负载在其上运行的时间和资源占有率都不同。因此，负载的准确定义应该是绝对的负载量与节点处理能力的比值。当整个系统任务较多时，分配给各节点的负载可能并不均衡，整个系统的利用率就会降低。因此，如何有效地将各个任务比较均衡地分布到不同的处理节点上并行执行，使各个节点的利用率达到最大，是研究的关键问题。下面将研究适用于视频服务器任务均衡的负载均衡算法。

目前许多负载均衡的算法是针对WWW服务器提出的。虽然这类研究多适用于通用的网络服务器，但是视频服务器主要为用户提供视频点播服务，因此具有其自身的特点：

(1)视频点播服务按播放的方式可分为点播和广播，它们对于磁盘和网络的要求不同。

(2)视频点播系统中，各个节目的受欢迎程度是非常不同的。

(3)影片的码率和需要播放的剩余时间可为负载均衡提供参考信息。

因此，现有的一般负载均衡算法并不能很好的满足视频服务器的性能要求。本文针对视频服务中不同的点播方式、视频文件存储调度的特点和视频文件的播放信息等问题，对一般负载均衡的算法进行改进，提出了适用于视频服务器的负载均衡算法，并且能够向广域网扩展。

1 改进加权最少连接法算法

在负载均衡的算法中，加权最少连接法是性能最优的均衡算法[2]。系统根据服务器的处理能力大小，给它一个相应的权值，在调度新连接时尽可能使服务器的已建立连接数和其权值成比例，因此在集群系统中的服务器性能差异较大的情况下也可以优化负载均衡性能。系统还可以自动询问服务器的负载情况，并动态地调整服务器的权值，以达到更好的负载均衡效果。

这里，利用加权最少连接的思想，同时加入了节点状态因素，以保证节点处于可服务状态。对本系统负载均衡的算法建立数学模型，此模型中主要考虑的因素有节点状态Si、节点性能Pi和节点处理中的用户请求数Ci(i是节点的编号)。

(1)节点状态Si表征节点是否处于服务状态的标志。在使用时调度器会定时地监视节点状态，节点死机失效时，调度器将不再分配用户请求给它。当节点处于服务状态时Si=1;节点失效时Si=0(Si∈{0,1})。

(2)节点性能Pi节点的性能直接关系到节点处理用户请求的能力。节点的性能由CPU频率、内存大小、缓存大小、网络接口带宽及磁盘读写速度决定，只有在上述几个因素匹配的情况下单节点性能才能成为最好的。节点的性能值Pi(Pi∈N)的值取在保证服务质量情况下处理的最多的用户请求数。

(3)节点处理中用户请求数Ci如果节点正在处理中的用户请求数已经比较多的情况下，再分配用户请求给该节点，将会影响该节点的服务质量，所以调度器进行负载调度的时候也必须考虑Ci(Ci∈N)。在使用中调度器上要有每个节点处理中的用户请求数信息，各个节点必须定期更新此信息来保证调度依据的准确性。

综上所述，节点i在t时刻的负载能力Lit就由以上三个因素决定，用式(1)表示：

式中，Cit表示t时刻节点i处理中的用户请求数;Sit为t时刻节点i的状态，它们是动态数据(随时间变化)。

该调度算法可以表现为：

式中：n为节点编号，n=1,2,…;t为时间;i’为应当分配用户请求的视频服务节点号。

在t时刻可能存在多个处理能力相当的节点，这时调度器将从其中随机地抽取一个节点i’，并将用户请求分配给它。

2 视频服务节点负载排名算法

一般来说，影响视频服务负载的因素包括服务器CPU的利用率、磁盘活动状况和网络负载状况[3]。设CPU_RATE为CPU占用率，DISK_RATE为磁盘带宽占用率，是磁盘使用带宽和磁盘最大带宽的比值，NETWORK_RATE为网络带宽占用率，是网络占用带宽和网络最大带宽的比值。对于视频服务器来说，CPU_RATE、DISK_RATE和NETWORK_RATE都有个阈值，分别为CPU_RATE_MAX、DISK_RATE_MAX、NETWORK_RATE_MAX。当超过这个阈值时，服务器的服务质量将得不到保证。定义负载率为LOAD_RATE:

根据实际经验中，把CPU_RATE_MAX设为85%，DISK_RATE_MAX设为90%，NETWORK_RATE_MAX设为60%。一般的网络服务器只需要根据收集到的每个服务节点的CPU_RATE,DISK_RATE,NET-WORK_RATE计算出LOAD_RATE，然后选择出一个LOAD_RATE最小的服务节点，就能达到较好的负载均衡效果。

文献[4]提出服务器排名法，它能够对服务器的性能进行分析，利用可用内存、I/O中断和CPU利用率等特定的系统信息计算服务器的负载，还可以得到服务器过载信息，作出相应的反馈。该方法的服务器排名由服务器CPU的利用率、磁盘活动状况和网络负载状况三方面构成：

(1)监视磁盘活动;

(2)监视CPU活动;

(3)监视网络活动。

进一步考虑，为了达到均衡数据流量，充分利用系统资源的目的，将节目的存储错误!未找到引用源。调度环节纳入负载均衡考虑的范畴。由于客户点播请求的内容中包含热播影片和冷播影片，这两类影片的存储方式不同：热播影片存储在每个区域的影片库中，而冷播影片则分散存储在个别区域的影片库上。这使得这两种点播请求对系统资源的占用情况是很不相同的，因此将这两类影片分别称之为本地点播服务和远程点播服务，对它们采用不同的处理策略。针对这一问题，给出“服务器排名法”的改进算法“视频服务节点负载排名法”，它计算负载的公式是：

其中，id为服务器编号，Sid为服务节点的状态，time为刷新时间，l_num为本地点播服务数，r_num为远程点播服务数，h_movie为本机存储热播影片数量，c_movie为本机存储冷播影片数量，cpu为过载，memory为内存不足，net为网络拥塞，disk为磁盘过载。上述各种参数根据它们对负载影响的大小而被赋予不同的权值，例如远程点播服务数的权值明显大于本地点播服务数的权值，本机存储热播影片数量(h-movie)的权值明显大于本机存储冷播影片数量(c-movie)的权值。

负载均衡器根据所获取的负载数据按以上公式计算每台视频服务节点的负载值，得出排名;同时执行视频服务节点的异步反馈功能，在自身过载时及时向集群管理节点反馈过载信息，此后点播请求将不再被指派到此台服务节点上，直至负载恢复正常。

该算法的流程是：负载均衡器收到用户的点播请求后，立即查询出所有存储有这部影片的视频服务节点的当前负载数据，并计算排名。以一定概率指派当前排名最佳的视频服务节点提供服务，这样可部分避免突发点播过度集中于某一台。当集群管理节点收到点播同一部影片的多个请求并且它们之间相距时间足够短时，可以指派同一台视频服务节点提供服务，因为这样有利于充分利用缓存数据，提高命中率，同时提高视频服务节点对点播请求的响应速度，减少用户的等待时间，提高服务质量，但因为受到缓存大小的限制，如果两个请求相距时间较远，这种好处就非常有限了。

3 针对视频文件播放信息的算法改进

前面的负载均衡算法能够根据服务器的实际负载状况和视频节目的存储调度情况，动态的调整负载分配策略[6]。但是，对于播放介质视频流，还需要一些针对性的改善，视频文件的码率和播放时间是两个需要考虑的重要因素。设想这样一种情况，有两台视频服务节点A和B，他们性能相同，并且都提供相同码率的影片。某一时刻，A提供了两个长度为90分钟的视频流服务，而B提供了三个长度为10分钟的视频流服务。此时，新的长度为40分钟的视频请求到来，按照上面所讨论的分配方案，大都会把这个请求分配给A。这样，在10分钟后，A会提供3条视频流服务，而B则没有，负载严重的不均衡。

这种情况的产生是因为这些均衡算法没有很好的利用影片的信息进行负载预测。通常，服务器的负载和其真正提供的所有影片的码率和是成正比关系的。由于很容易得到每个视频服务节点里正在服务的影片列表，以及这些影片的码率和还剩下的服务时间，因此可以估算出在未来的某一段时刻内，服务器的负载状况。

假设Server_Load是视频服务节点的当前负载，服务节点正在提供N部影片的点播服务，第i部影片的码率和还需服务的时间是Ri和Ti。那么，在未来的时间段t内，服务器的平均负载为：

假设新请求到来时，请求的电影时间长度为t，那么只需对每个服务节点计算出Server_load_t，选出值最小的服务节点进行服务。

结束，本文运用集群技术，结合Linux操作系统的强大能力，提出了基于集群的VOD系统视频服务器的负载均衡算法改进。本方案具有广泛的应用领域，因为集中控制模式而产生的瓶颈问题，都可以参考本文的方案解决。同时结合视频点播系统媒体服务器的特点，提出了有针对性的高可用，高可扩展及负载均衡的结构模型。而且，由于本文提出的方案基于Linux系统，继承了Linux系统本身所具有的各种优越性。随着视频点播业务的迅猛发展，运用集群机制的视频点播系统将更适合于电信级大规模的范围使用，具有广泛而良好的应用前景。

参考文献

[1]郑灵翔,刘君尧,陈辉煌.Linux下的负载均衡集群LVS实现分析与测试[J].厦门大学学报,2005,41(6):726-730.

[2]刘志明,陶阳,谭玉波,彭宇行.一种集群式并行VOD系统的研究与实现[J].计算机工程与设计,2006,7:76-78.

[3]王云岚,李增智,薛军,班世敏.基于DNS的负载均衡算法研究[J].计算机工程与应用,2002,38(4):11-13.

[4]鄢仁祥,高远.一种分布式视频点播系统模型[J].小型微型计算机系统,2002,23(8):10-13.

[5]韦伟,罗翔.计算机系统集群的负载均衡原理及实现方法[J].计算机时代,2002,7:25-26.