IPQAM的VOD低成本解决方案
1 前言
近年来,随着国家信息化建设的大力开展和三网融合的积极推进,广电行业加快了数字化整体转换工作的步伐。截至2007年底,我国的用户已经达到2600万。然而,数字电视用户数目的快速增长并没有为广电行业的发展带来实质的推动作用。目前2600万数字电视用户可消费的业务绝大多数仍基于单向,并且业务仅限于数据广播、信息浏览、NVOD等缺乏互动性的业务。这些业务中,数据广播提供的信息量有限,信息浏览和NVOD等业务不支持用户的参与,单纯的模拟转数字带来的清晰度提高(有限)和同质的频道增加已很难满足用户日益增长的消费需求。因此,单纯的数字化转换意义不大,运营商必须以用户为本,充分调动用户参与的积极性,不断满足用户快速增长的精神文化和信息服务需求,并努力提高相关收益。这些就需要运营商加快双向网络的改造,大力提供丰富多彩的互动业务。 业务是最基础的双向业务之一。一方面VOD业务是用户迫切需要的业务,另一方面当前VOD业务系统的系统成本和运营成本都很高,运营商很难盈利。如何解决这一矛盾,是运营商普遍关注的热点。本文试图从降低系统成本的角度进行分析探索,为解决这一问题提供可行的途径。由于文中提出的VOD低成本解决方案基于开源项目Darwin Streaming Server实现,而Darwin Streaming Server完全符合ISMA规范,所以该方案完全适用于其它基于的网络环境中。但本文的描述主要以基于IPQAM的广电网络环境为例,来说明该方案的实现过程。
2 广电行业的VOD业务现状
VOD业务即视频点播业务,是一种可以按用户需要点播节目的互动式视频业务。它的一个重要特点就是需要很高的带宽来传送下行的媒体流。广电的网络可以提供非常高的下行带宽,适于媒体流的传送。因此,广电行业的VOD业务提供多采用基于IPQAM的VOD解决方案,即利用IP网络实现流媒体的控制,通过CATV网络下发媒体流的方式。图1就是一个简单的IPQAM VOD业务系统的逻辑图。
目前,基于IPQAM的解决方案的相关规范主要有时代华纳提出的ISA(Interactive Services Architecture)和Comcast提出的NGOD (Next Generation On Demand)等。其中ISA架构的流控协议采用基于/IEC DSM-CC标准的SSP和LSCP协议,而前端服务器实体之间采用CORBA实现,实现的复杂性相对较高。NGOD则是在RTSP协议的基础上提出,实体交互基于Web Service实现,目前还很少有相关的商用产品。
在现在的国内外市场中,能提供基于IPQAM的VOD解决方案的国内厂商主要有,思华等。国外厂商主要有MOTO、CISCO、Tandberg(没有自己的视频服务器)等。国外厂商的产品都支持ISA规范,而ISA规范由于本身定义的复杂性,造成整个系统的复杂度提高,也直接导致了系统实现的成本非常昂贵。国内产品中,虽然思华的产品不是基于ISA架构,其点播协议采用RTSP协议,但其商用产品也价格不菲。
视频服务器是VOD解决方案中的核心实体。在基于IPOAM的VOD解决方案中,视频服务器需要支持TS流格式,并以UDP的方式传送TS流,以连接IPQAM设备。此外,考虑到VOD业务的可运营性。视频服务器还需要支持用户认证、计
费接口以及远程管理等功能。我们认为,降低视频服务器的开发成本,可以有效地降低整个VOD业务系统的成本。因此,本文基于开源项目实现了一个运行于通用服务器上的纯软件视频服务器,虽然此类视频服务器目前还难以被较大的运营商接受并采用,但已可成功地应用于小区、酒店等区域的VOD系统设计。
3 基于开源项目的VOD低成本解决方案
目前,与视频服务器相关的开源项目有很多,如MPEG4IP,VLS等等。其中live555是免费,开源的,并支持TS流,但live555的设计并不适用于商业运营;DarwinStreaming Server2具备商业运营必须的认证、计费、远程管理等特性,可以很好地支持商业运营,但是对于广电系统的应用来说,缺乏对TS流的支持。本文基于可运营性的考虑,选取Darwin Streaming Server作为基础,通过扩展使之支持MPEG-2TS流,实现低成本的视频服务器,以支持基于IPQAM的VOD解决方案。
DarWin Streaming Server简介
Darwin Streaming Server(简称DSS)是苹果公司的开源视频服务器版本,与DSS相对应,APPLE有一个商业版本的视频服务器QTSS(QuickTime Streaming Server),两者采用相同的核心设计。DSS符合ISMA规范,支持多种标准协议和格式,DSS的主要特性如下:完全符合标准,支持各种标准的播放器或者。
支持MP4、等文件格式; 支持-4、等视频编解码格式;
支持RTSP流控协议,支持HTTP协议;
支持RTP传输协议; 支持单播和组播; 支持基于Web的管理; 具有完备的日志功能。
此外,该版本提供了一个基于模块的扩展方法。利用DSS提供的API就可以很方便地编写静态或动态的模块,对DSS进行扩展,使其支持其它文件格式、协议或者功能。本文就是利用这种方法对DSS进行扩展,使其支持采用MPEG-2 TS封装格式的MPEG-2视频文件。
见图2即DSS系统的逻辑框图。 DSS模块的编写
每个DSS模块必须实现两个函数:一个是Main函数,在启动时将调用这个函数进行必要的初始化。另一个是Dispatch函数,通过实现此函数,服务器可调用DSS模块并完成特定处理。对于编译到服务器里面的模块,其主函数的地址必须传递到服务器的模块Main函数中。具体实现细节可参照QuickTime服务器模块文档[2]的相关章节。
具体实现时,Main函数必须命名为MyModule_Main,其中MyModule是模块的文件名。此函数的实现通常如下所示:
每个DSS模块都必须提供一个Dispatch函数。服务器为了特定的目的需要使用某个模块时,是通过调用该模块的Dispatch函数来实现的,调用时必须将
任务的名称及相应的参数传递给该函数。在DSS中,使用角色(Role)这个术语来描述特定的任务。Dispatch函数的格式如下所示:
void MyModuleDispatch(QTSS_Role inRole,QTSS_RoleParamPtr inParams); 其中MyModuleDispatch是Dispatch函数的名称;MyModule是模块的文件名;inRole是角色的名称,只有注册了该角色的模块才会被调用;inParams则是一个结构体,可用于传递相应的参数。
DSS对-2 TS流的支持
对DSS进行扩展,以实现对MPEG-2 TS流的支持,主要涉及三个方面的问题:首先,RTSP协议需要支持MPEG-2 TS over DVB-C;其次,能够通过UDP协议直接发送TS流;最后,发送的速率需要依据PCR[1](Program ClockReference,即节目时钟参考)实现适当的调节。下面针对这三个方面问题的解决进行简要的说明:
为了让RTSP协议能支持QAM传输,需要对标准的RTSP协议做扩展,即在SETUP阶段,终端告诉服务器需要QAM传输,服务器会为该终端分配传输资源,并告诉终端相应的参数(包括频点和节目号等)。对于IPQAM资源,节目号与UDP端口号是一一对应的,视频服务器可以维护一个包括UDP端口、节目号、频点以及UDP端口使用状况的列表。
当使用扩展后的RTSP协议实现一次MPEG-2 TS流点播时,与通常的RTSP交互过程相比,在SETUP阶段有所不同。