前言
截至2007年底，我国的数字电视用户已经达到2600万。这2600万数字电视用户绝大多数是单向的。这样的数字电视除了把模拟信号转变成数字信号外，还提供了数据广播，股票，NVOD等业务。这些业务都不能激发用户的消费热情，因为数字信号的电视仅仅是比模拟电视清晰了一点，数据广播提供的信息量有限，股票也仅仅是一个实时的行情，不能提供交易的功能，NVOD并非一个实时的点播。
单纯的模拟转数字对于运营商来说意义不大，运营商希望通过数字电视为用户提供更多的业务类型，进而获得更多的收益。单向很难提供吸引人的业务，双向成了必然的趋势。而VOD被认为是最基本的双向业务之一。
广电行业VOD现状
VOD业务的特点之一就是需要很高的带宽来传送媒体流，媒体流是下行的。CATV网络能提供非常高的下行带宽。这就提出了IPQAM的VOD，也就是利用IP网络实现流媒体的控制，通过CATV网络下发媒体流。下图是一个简单的IPQAM VOD的逻辑图。
IPQAM VOD的逻辑图
基于IPQAM的VOD的相关标准有ISA，NGOD等。其中ISA架构的流控协议采用DSM-CC基础上的SSP和LSCP协议，前端服务器实体之间采用Corba，实现复杂。NGOD是在RTSP协议的基础上提出来的，目前还很少有厂商提供商用的产品。
用于部署IPQAM VOD的商用系统都比较昂贵。能提供IPQAM VOD的厂商国内有华为，思华等，国外厂商有MOTO，CISCO，Tandberg（没有自己的视频服务器）等。其中国外厂商的产品都支持ISA规范，而ISA规范由于本身的复杂性，造成整个系统复杂性，也直接导致了这些系统非常昂贵。思华的产品不是ISA架构的，点播协议采用RTSP，尽管如此，也价格不菲。
事实上，IPQAM VOD实现的核心之一是视频服务器，只要视频服务器能够支持TS流格式，并以UDP的方式发送，就能连接到IPQAM设备，从而实现IPQAM的VOD。另外，考虑到IPQAM VOD是为了商业运营，因此视频服务器要支持用户认证，计费接口以及远程管理的功能。
免费、开源并支持TS流的视频服务器在互联网上能够下载到，比如live555，但是它不是一个可以用于商业运营的软件。免费、开源并可以用于商业运营的视频服务器也可以从互联网上下载到，比如Darwin Streaming Server就是一款很优秀的视频服务器，但是它不支持TS流。因此可以基于DSS，通过扩展使之支持MPEG2TS流来实现一个支持IPQAM VOD的视频服务器。
DSS简介
Darwin Streaming Server是苹果公司的开源视频服务器版本，符合ISMA规范，支持MP4文件格式的编码为MPEG4或者H.264的视频，支持RTSP流控协议，支持RTP流媒体传输协议。该服务器提供了一个很好的扩展方法，就是模块的方法。利用DSS提供的API可以编写静态或动态的模块。
通过编写模块的方法，可以扩展DSS使其支持新的文件格式，新的协议以及其他新的功能。我们就是利用模块的方法对DSS进行扩展，使其支持MPEG2TS封装格式的MPEG2视频文件。
如下图所示，是DSS的逻辑框图：
DSS模块的编写
每个QTSS模块必须实现两个函数，一个是Main函数，服务器在启动的时候将调用这个函数进行必要的初始化。 另一个是Dispatch函数，服务器为了调用模块完成特定处理时就是通过这个函数来实现的。
每个QTSS模块必须提供一个Main数。服务器在启动的时候会调用这个函数，并通过这个函数进行相应的初始化，以便之后调用该模块。对于编译到服务器里面的模块，其主函数的地址必须传递到服务器的模块初始化函数中。要了解细节，请参照QuickTime 流媒体服务器模块文档的相关章节。主函数必须命名为MyModule_Main，其中MyModule是模块的文件名。主函数的实现通常是下面的样子：
QTSS_Error MyModule_Main(void* inPrivateArgs)
{
}
每个QTSS模块都必须提供一个分发函数。服务器为了特定的目的需要某个模块时，是通过调用该模块的分发函数来实现的，调用时将任务的名称及相应的参数传递给该函数。DSS中，使用“角色”这个术语来描述特定的任务。分发函数的原型如下：
void MyModuleDispatch(QTSS_Role inRole, QTSS_RoleParamPtr inParams);
其中MyModuleDispatch是分发函数的名称；inRole是角色的名称，只有注册了该角色的模块才会被调用；inParams是一个结构，用于传递参数。
扩展DSS使之支持MPEG2TS
实现一个MPEG2TS流的发送，涉及到三个层面的问题，一个是RTSP协议需要支持MPEG2TS over DVBC，另一个是能够通过UDP协议把TS流直接发送出去，第三个是发送的速率要按照PCR进行适当的调节。
为了让RTSP协议能支持QAM传输，需要对标准的RTSP协议做一点扩展，在SETUP阶段终端告诉服务器需要QAM传输，服务器会为该终端分配传输资源，并告诉终端相应的参数，这些参数包括频点和节目号。在IPQAM上节目号与UDP端口号是一一对应的，视频服务器可以维护一个UDP端口、节目号、频点以及UDP端口使用状况的列表。对Transport字段做如下扩展：
transport-protocol
profile
lower-transport
经过扩展后的RTSP协议，实现一次MPEG2TS流的点播的时候，与通常的RTSP交互过程相比，在SETUP阶段有所不同。如下是实现一次UDP直接承载MPEG2TS流以便支持IPQAM VOD的RTSP协议的SETUP阶段的内容：
……
SETUP rtsp://192.168.0.251/crazestone.ts/track0 RTSP/1.0
CSeq: 3
Transport: MP2T/DVBC/QAM
User-Agent: ./testProgs/openRTSP (LIVE555 Streaming Media v2007.08.03)
RTSP/1.0 200 OK
Server: DSS/5.5.5 (Build/489.16; Platform/Linux; Release/Darwin; state/beta; )
Cseq: 3
Session: 5156424843980725402
Date: Sat, 29 Dec 2007 16:33:32 GMT
Expires: Sat, 29 Dec 2007 16:33:32 GMT
Transport: MP2T/DVBC/QAM;source=192.168.0.251;server_port=6970-6971;
frequency=30000;symbol-rate=6875;modulation=3;program-number=1
……
为了实现MPEG2 TS流通过Cable下发，关键点是视频服务器能够采用UDP协议将TS流依特定速率发送到IPQAM设备。
采用UDP协议把TS包发送到IPQAM设备，实现相对比较简单，假定TS包的大小是188字节的，只要遵照一个UDP包不应大于以太网最大传输单元的原则，将7个TS包打包成一个UDP包，发送给IPQAM设备即可实现。
而依特定的速率发送则要求服务器在发送MPEG2 TS流时，必须保证发送数据的速率与媒体正常播放的速率一致性。考虑到终端会有一个缓冲区来平滑发送数据时可能产生的波动，因此对于发送速率与正常播放速率的一致性的要求并不是绝对的。但发送数据带来的波动要在IPQAM设备许可的范围内，否则IPQAM无法正常处理。
本文中依特定速率发送是基于PCR来实现的。PCR即节目时钟参考，是TS包中的一个字段，用于同步解码器与前端编码器或者视频服务器的时钟。在编码器进行编码的过程中，会不断读取硬件时钟并放入TS中PCR字段。 解码器在解码的过程中会参照一个本地时钟，确定解码和显示的速度。本地时钟要根据PCR进行修正，以避免时钟“过快”造成停帧或者时钟“过慢”造成丢帧。
我们已经在linux下面按照本文所述方法实现了支持MPEG2 TS流的视频服务器，并进行了测试。测试环境基于千兆网环境，服务器采用Dell 2950，IPQAM设备分别采用了Scivo以及Tandberg的产品，用PC模拟若干终端，同时用天柏STB8作为点播终端。
测试结果是单个Ge口支持并发250个3.75M码流的MPEG2电影，每个流的硬件成本不足100元人民币。根据实验结果，我们认为这种VOD低成本实现方案便于中小型运营商开展VOD业务运营，同样也可以为公司或研究机构提供一个低成本的研发环境。本文提出方法仍有不少待完善之处，希望感兴趣的专家能共同探讨这种VOD解决方案的可行性。
四、结束语
进行双向网络改造，大力发展双向业务，是中国广电行业提高市场竞争力的必经之路。目前中国广电运营商仍是分而治之的状态，运营机构极度分散化，缺乏电信行业运营商的统一建制。这种情况下，一些小的广电运营商很难有财力购买现有的商用VOD业务系统，无法开展VOD这一双向基础业务，盈利模式更无从谈起。本文主要从VOD业务系统的运营角度出发，提出了一种低成本实现的VOD解决方案，便于VOD业务系统的快速部署，为小型运营商的发展增加一个符合实际的选择方案。
另外，因为是基于符合ISMA规范的开源产品来实现的，所以对于希望降低运营成本的IPTV运营商来说，也是一个不错的选择。
参考文献
[1]
[2]