专利名称：支持多播视频点播系统交互性的尽力修补方法
技术领域：
本发明涉及一种视频点播系统，确切地说，涉及一种支持多播视频点播系统交互性的尽力修补方法，属于多媒体通信系统技术领域。
视频点播(VoD)技术广泛应用于家庭娱乐、数字图书馆、影片点播、远程购物、远程教学等领域。视频点播系统是由传输网络1、视频服务器2和多台位于客户端的点播设备3等构成(参见
图1)。从概念上讲，真视频点播服务允许远程用户在任何时间以任意的交互方式点播任何一个视频节目。传统的视频点播系统是为每个用户请求分配一个指定的信道，以提供真视频点播服务。但它的服务伸缩性差，使得服务器吞吐和网络带宽随用户数呈线形增长，服务性能有局限性。多播(multicast)技术提供了一种有效的一点对多点的传输方式，参见图2，使用多播技术的视频点播系统(简称多播VoD系统，)是利用视频服务器2中的客户管理模块22通过传输网络1以及交互控制信道4对多台位于客户端的点播设备3同时进行交互管理，而视频服务模块20则可以将存储在视频存储器21中的一个视频节目通过传输网络1构成一个多播信道5而同时向多个客户端的点播设备3传输播放，在多播信道5上传输的视频数据构成一个多播流，所以，该系统具有很好的客户伸缩性和服务性能，这种性能在热点节目的点播服务中尤为突出。
现在，基本的多播VoD系统是采用等时间隔(如5分钟)和批处理方式来为一组点播同一视频节目的客户调度一个多播流进行服务，是一种准视频点播服务。多播VoD系统要提供真视频点播服务必须解决两个问题一是为客户提供零延时的服务；二是支持客户使用类似家用录像机的实时交互功能，如播放/恢复、停止/暂停/终止、快进/倒带、向前搜索/反向搜索、慢动作等。
为了消除多播VoD服务中的服务延时，《PatchingA multicast technique for truevideo-on-demand services》(《修补一种面向真视频点播服务的多播技术》刊于Proc.ACMMultimedia’98，pp.191--200，Bristol，U.K.，Sept.1998.)提出了一种修补技术，该修补技术是支持动态的多播VoD服务。使用该技术时，客户端设备可同时从两个信道下载数据流，当新的请求到达时，通过在客户设备缓冲区中缓冲与该请求时间最接近的一个多播流，同时开始播放经修补信道下载的延误的节目开头部分，客户的请求就可得到立即服务。其修补信道的使用时间长度仅为新客户的请求时间(如9时2分)与最近的一个多播流的启动时间(如9时整)之间的时间差(即2分钟)。在修补信道的视频数据播放完后，接着开始播放被缓存的多播流视频数据。两个多播流之间使用修补技术的时间段称为修补窗口。在已知一个多播视频流的启动时间的情况下，何时调度相同视频节目的下一个多播流(即选择修补窗口的长度w)是一个影响系统性能的关键问题。然而，在上述修补过程中，服务器2和网络1之间的信道只是用来修补客户延误的视频节目部分，也就是说，现有的修补技术仅支持点播请求准入控制过程，而对交互性则没有采取任何相应的保证及修补措施。
关于多播VoD系统支持客户交互方面，目前只是在文献《The use of multicast deliveryto provide a scalable and interactive video-on-demand service》(《使用多播传输来提供一种可伸缩的交互视频点播服务》刊于IEEE Journal of Selected Areas onCommunications,Vol.14，No.6，pp.1110--1122,Aug.1996.)中提出在客户设备增加一个缓冲区，用于缓冲已接收的视频流，以支持有限长度的交互。《The split and merge protocolfor interactive video-on-demand》(《用于交互视频点播的分离合并协议》刊于IEEEMultimedia,Oct.-Dec.1997，Pages 51-62.)则提出了一种将交互操作和正常播放分离合并的方法，分别使用多播信道和交互信道服务于客户的正常播放和交互过程。这两种方法虽然可以解决多播视频点播系统中客户的连续交互操作的问题，但是，前者提供交互操作的时间长度局限于缓冲区的能力，后者的服务效率较低，所需带宽随交互数呈线性增长，无法很好地解决客户点播率高的热点节目的点播服务，这也是多播视频点播系统中急需解决的课题。
本发明的目的是提供一种支持多播视频点播系统交互性的尽力修补(Best EffortPatching，BEP)方法，该方法主要用于解决客户点播率高的热点节目的点播服务，以支持客户实现真VoD服务。
本发明的目的是这样实现的一种支持多播视频点播系统交互性的尽力修补方法，该方法主要解决客户点播率高的热点节目的点播服务，其特征在于其工作过程分为如下三个阶段(1)客户请求准入阶段首先，采用传统的修补技术，按间隔时间调度一个视频节目多播流，对两个相继的多播流间的客户请求，通过修补延误的节目起始段来共享最近的多播流；(2)交互阶段当客户进行交互时，首先判断客户交互是否有图象传输的交互，如否，用户交互不需要分配信道；如客户交互属于有图象传输的交互，则当交互时间长度少于客户设备缓冲区支持的时间长度时，不需要给客户分配修补信道；一旦客户交互时间长度超过客户设备缓冲区支持的时间长度，则服务器给客户分配一个修补信道支持客户交互；(3)合并阶段在客户交互时间长度超过客户设备缓冲区支持的时间长度情况下，客户完成交互后其视频流须合并到规则的多播流中；如果客户已使用一个修补信道进行了交互，则客户设备一边下载并缓冲最接近的多播流，同时继续使用上述用于交互的修补信道从期望播放点开始下载并播放视频流来弥补当前客户交互流与多播流两个流之间的差距，以完成交互流到多播流的合并；否则，服务器给客户另行分配一个修补信道来完成客户交互流和多播流的合并，使客户得到实时的连续交互服务，在该合并过程中，采用一种动态合并方法，以显著提高合并效率。
其中所述的动态合并方法的操作步骤描述如下首先设定一个合并队列具有下述的数据结构Struct Mqueue{element*head；/*首记录指针*/int offset；/*队列偏移时间*/int lifetime；/*队列修补流生存时间*/int latime；/*最新客户的加入时间*/}在下述算法中Q为合并队列集合；C为交互客户；n为多播流序号；t为交互客户C的到达时间；则动态合并方法的操作步骤为第1步获得交互客户C期望播放点与多播流n播放点的偏移时间量x；第2步在合并队列中选择到某一个队列q0，该队列是交互客户C的修补流合并到其中后，其所要的修补信道的时间需求达到最短的合并队列。该队列q0的表示公式为q0=Maxq∈Q{Min{q.offset+q.lifetime-x-(t-q.latime)，q.offset}q.offset≤x＜q.offset+q.lifetime-(t-q.latime)}第3步若找到上述队列q0，将交互客户C的修补流C合并到q0中，即在队列q0尾部加入修补流C的记录，并修改q0的信息如下delta=t-q0.latime；q0.latime=t；修补流C的生存时间置为x-q0.offset；如果x＞q0.lifetime-delta，则q0.lifetime=x；客户C先从修补流C下载播放视频数据，同时下载并缓存队列q0修补流中的视频数据，经x-q0.offset时间后，播放缓存区中队列q0修补流中下载的数据，并开始同时下载和缓存多播流n中的数据；转第5步。
第4步如找不到上述队列q0，则新生成一个合并队列，该队列的首记录为交互客户C的修补流C的信息，并设置队列q0的信息如下q0.offset=x；q0.lifetime=x；q0.latime=t；队列修补流即为修补流C；
客户C从修补流C下载播放视频数据，并同时下载和缓存多播流n中的数据；第5步结束。
本发明的支持多播视频点播系统交互性的尽力修补(BEP)方法的主要特点是将原来主要用于消除多播VoD系统中的服务延时的修补技术扩展到用于支持多播视频点播系统中客户的连续交互操作，从而为多播视频点播系统实现真视频点播服务提供一种有效的支持方法；并且，在用于支持交互的修补流和多播流的合并过程中提出了一种新的动态合并算法，该算法可以显著地提高信息流的合并效率。
下面结合附图进一步说明本发明的工作过程、方法步骤、特征和功效图1为目前使用的视频点播系统的结构组成示意图。
图2为目前使用的多播视频点播系统的数据流状态示意图。
图3为本发明的尽力修补方法的主流程图。
图4为本发明的“交互”阶段的子流程图。
图5为本发明的“合并”阶段的子流程图。
图6为本发明中的客户设备缓冲区与交互操作示意图。
图7为本发明用于前向交互时的信道与修补窗口关系的示意图。
图8为本发明用于后向交互时的信道与修补窗口关系的示意图。
图9为本发明动态合并算法示意图。
参见图3-图5，本发明是一种支持多播视频点播系统交互性的尽力修补方法，该方法主要用于解决客户点播率高的热点节目的点播服务，其工作过程分为如下三个阶段(1)客户请求准入阶段首先，采用传统的修补技术，按间隔时间调度一个视频节目多播流，对两个相继的多播流间的客户请求，通过修补延误的节目起始段来共享最近的多播流。
(2)交互阶段当客户被准入服务后，就可在任何时刻进行交互操作。在客户进行交互时，首先判断客户交互是否有图象传输的交互，如否，用户交互不需要分配信道；如客户交互属于有图象传输的交互，则当交互时间长度少于客户设备缓冲区支持的时间长度时，不需要给客户分配修补信道；一旦客户交互时间长度超过客户设备缓冲区支持的时间长度，则服务器给客户分配一个修补信道支持客户交互。
下面详细介绍本发明的尽力修补方法中支持客户交互和合并阶段的工作步骤。
参见图4所示的客户交互过程子流程图，其中交互操作可分为无图象传输的操作(如暂停，停止，快进，倒带)和有图象传输的操作(如向前搜索，反向搜索，慢动作)。另外，根据交互中播放速率是否大于视频流的正常传输速率，可将交互操作分为前向操作(快进，向前搜索)和后向操作(反向搜索，倒带、慢动作，暂停，停止)。
当客户进行交互时，若交互时间长度少于客户设备缓冲区支持的时间长度(参见图6所示的交互后的恢复点或称交互期望播放点A位于其中斜线阴影部分所表示的客户设备缓冲区之内)，则服务器不需要给客户分配修补信道，即客户利用其设备缓冲区就可以完全保证连续交互。一旦客户交互的时间长度超过客户设备缓冲区支持的长度(参见图6所示的交互后的恢复点或称交互期望播放点C1或C2位于其中斜线阴影部分所表示的客户设备缓冲区之外)，则服务器需给客户分配一个修补信道，用于支持客户交互和交互后的交互流与多播流的合并。此时又分为两种情况分别讨论之A、无图象传输的交互操作当交互期望播放点位于客户设备缓冲区之外(即客户设备缓冲区不能完全保证连续交互)时，在交互过程中不分配修补信道。完成交互后，由服务器给该客户分配一个修补信道，使用这个修补信道客户的交互流将被合并到与其最近的多播流中。
参见图7，多播流n中一个客户的原播放点位于P0，使用一次前向交互操作(如快进)后，多播流n的正常播放点变为P(n)，但客户的交互期望播放点是位于多播流n-i和n-i-1的播放点P(n-i)和P(n-i-1)之间的A(i≥0)。注意多播流n和n-i之间的时间差为i×w，并且后调度的多播流的序号大于先调度的多播流的序号。在交互中，不需要给该客户分配修补信道。而交互完成后，该客户视频流要合并到离其最近的多播流n-i-1中，则服务器给该客户分配一个修补信道，客户使用该修补信道下载并播放用户交互期望点A与多播流n-i-1相差的部分，另一方面下载并缓存多播流n-i-1中的视频数据，在修补流播放完后，接着播放被缓存的多播流视频数据。这样的合并一般需要使用的修补信道的长度为｜P(n-i-1)-A｜，该修补信道的长度对应着图7中多播流n-i-1中的网格部分。
对于后向交互操作，参见图8所示，其除了交互期望点是位于后于多播流n调度的多播流n+i和n+i-1的播放点P(n+i)和P(n+i-1)之间的A(i≥0)，交互完成后客户视频流要合并到离其最近的多播流n+i-1中，服务器给该客户分配的修补信道的使用时间长度为｜P(n+i-1)-A｜之外，其余步骤与前向交互操作一致。
B、有图象传输的交互操作一旦交互需要的客户设备缓冲区存储需求超出客户设备缓冲区的能力，服务器将给该客户分配一个修补信道，用于交互和合并阶段。交互阶段客户使用独占的修补信道进行交互操作；而在合并阶段时，该修补信道用于交互流和多播流的合并。
参见图7，多播流n中一个客户使用一次时间为t的前向交互(如向前搜索)，该客户交互期望的播放点是A，多播流n的正常播放点则变为P(n)。交互阶段使用的修补信道的长度为t-t0(t＞t0)，这里t0是不需要修补通道客户缓冲区就可支持的前向搜索的时间长度，t0=dr/(SP-1)，dr是交互开始时该客户设备缓冲区缓存的将要播放的视频流的长度，SP是加速因子。
对于后向交互操作(如反向搜索)，参见图8所示，若客户后向交互的时间为t，客户交互期望播放点是A，多播流n的正常播放点变为P(n)。交互阶段使用的修补信道的长度为t-t0(t＞t0)，这里t0是不需要修补通道客户缓冲区就可支持的后向搜索的时间长度，t0=dr/(SP+1)，dr是交互开始时客户设备缓冲区缓存的已经播放的视频流的长度，SP是加速因子。
(3)合并阶段在客户交互时间长度超过客户设备缓冲区支持的时间长度情况下，客户完成交互后其视频流须合并到规则的多播流中；如果客户已使用一个修补信道进行了交互，则客户设备一边下载并缓冲最接近的多播流，同时继续使用上述用于交互的修补信道从期望播放点开始下载并播放视频流来弥补当前客户交互流与多播流两个流之间的差距，以完成交互流到多播流的合并；否则，服务器给客户另行分配一个修补信道来完成客户交互流和多播流的合并，使客户得到实时的连续交互服务，在该合并过程中，采用一种动态合并方法，以显著提高合并效率。
在本发明的尽力修补方法中有图象传输的交互操作合并过程与无图象传输的交互操作的合并过程是相同的。使用本发明的动态合并方法，可以提高合并效率。
参见图9所示，P(n)为多播流n的播放点，若一交互客户A期望播放点与多播流n播放点偏移时间为a(0＜a＜w，w为修补窗口的时间长度)，该客户需要使用修补信道来并入多播流n。其修补流记为流A，在图9中以首行中的网格部分表示之。该流A的生存时间为a，当合并进行时，比如t1分钟后，其他交互客户的交互流也需要合并到多播流n中。假定某一个新的交互客户B期望播放点与多播流播放点P(n)的偏移时间为b，若t1小于修补流A的生存时间a，并且t1＜2a-b，则使后一个交互的修补流(记为流B，在图9中以第二行下侧的斜线部分表示之)共享流A的网格部分，也就是两个流A、B的时间共存部分，以减少其修补信道的使用。在这种情况下，流A将被扩展，以使它的生存时间为b，而流B的生存时间设置为b-a。该新的客户可同时从流A和流B下载视频流数据，在播放完流B数据后，该客户B设备播放缓存的流A的视频数据，并且开始从多播流n中下载并缓存视频流，流A中为修补客户B的合并部分播放完后，接着播放从多播流n中下载并缓存的视频流。需要注意的是，客户设备只具备同时下载两个流和播放一个流的能力。如此的修补流的合并可以继续进行下去，所合并的客户记录在一个合并队列中。
现在考虑一个新的交互客户的合并过程。假定q为多播流n的合并队列，q的元素(element)记录加入其中的修补流信息，q的队列偏移时间(offset)为其第一个客户期望播放点与多播流n播放点的偏移时间，q的首(head)记录为初始建立该队列的第一个客户修补流信息，q的生存时间(lifetime)初始置为第一个客户修补流的生存时间并可能在新的客户修补流加入时改变。如果t是最新一个客户加入时间(latime)，则如无另外的客户修补流加入该队列，将在t加入队列的生存时间后释放。
如图9所示，当一个新的交互客户C希望加入多播流n的合并队列q时，已知x是客户C的期望播放点与多播流n播放点的偏移时间，并且客户C的到达时间为t+t2。若q.offset≤x＜q.offset+q.lifetime-t2，客户C的修补流(记为流C)加入合并队列；否则，客户C的修补流不能加入到队列q。
在客户C的修补流加入合并队列时，可按两种情况管理该队列情形1当x＞q.lifetime-t2时，意味队列q修补流(流A)的生存时间不足以合并流C，所以流A的生存时间必须被扩展。即流C合并后，流C的生存时间置为x-q.offset，且置q.lifetime=x，q.latime=t+t2。客户同时从流A和C下载视频数据，首先播放流C的视频数据，经过x-q.offset时间后，客户开始播放流A的视频数据，并从多播流n下载视频数据。在这种情形，本发明的动态合并方法可节省的修补信道的使用时间为q.offset+q.lifetime-t2-x。
情形2当x≤q.lifetime-t2时，意味队列q修补流(流A)的生存时间足以合并流C，所以流A的生存时间不扩展。即流C合并后，流C的生存时间置为x-q.offset，且置q.latime=t+t2，q.lifetime不变。客户从流A和流C及多播流n下载和播放视频数据的顺序与情形1一致。在这种情形，本发明的动态合并方法可节省的修补信道的使用时间为q.offset。
如果流C不能加入在现有的合并队列中，一个由流C作为首记录发起的新的队列被建立，初始的队列的修补流就是流C。同时由于可能存在很多合并队列，流C将被合并到具有最大修补信道节省的队列中。
本发明的动态合并方法的操作步骤描述如下首先设定一个合并队列具有下面的数据结构Struct Mqueue{element*head；/*首记录指针*/int offset；/*队列偏移时间*/int lifetime；/*队列修补流生存时间*/int latime；/*最新客户的加入时间*/
}在下述算法中Q为合并队列集合；C为交互客户；n为多播流序号；t为交互客户C的到达时间；则动态合并方法的操作步骤为第1步获得交互客户C期望播放点与多播流n播放点的偏移时间量x；第2步在合并队列中选择到某一个队列q0，该队列是交互客户C的修补流合并到其中后，其所要的修补信道的时间需求达到最短的合并队列。该队列q0的表示公式为q0=Maxq∈Q{Min{q.offset+q.lifetime-x-(t-q.latime)，q.offset}｜q.offset≤x＜q.offset+q.lifetime-(t-q.latime)}第3步若找到上述队列q0，将交互客户C的修补流C合并到q0中，即在队列q0尾部加入修补流C的记录，并修改q0的信息如下delta=t-q0.latime；q0.latime=t；修补流C的生存时间置为x-q0.offset；如果x＞q0.lifetime-delta，则q0.lifetime=x；客户C先从修补流C下载播放视频数据，同时下载并缓存队列q0修补流中的视频数据，经x-q0.offset时间后，播放缓存区中队列q0修补流中下载的数据，并开始同时下载和缓存多播流n中的数据；转第5步。
第4步如找不到上述队列q0，则新生成一个合并队列，该队列的首记录为交互客户C的修补流C的信息，并设置队列q0的信息如下q0.offset=x；q0.lifetime=x；q0.latime=t；队列修补流即为修补流C；客户C从修补流C下载播放视频数据，并同时下载和缓存多播流n中的数据；第5步结束。
本发明已经利用计算机进行仿真模拟试验，试验的结果表明，本发明的尽力修补方法在性能上显著优于《The split and merge protocol for interactive video-on-demand》(刊于IEEE Multimedia,Oct.-Dec.1997，Pages 51-62.)中介绍的交互操作和正常播放分离合并的方法，也优于《Providing unrestricted VCR capability in multicast video-on-demand systems》(刊于Proc.IEEE International Conference on MultimediaComputing and System’98，June-July 1998.)中提出的基于用户设备缓冲区改进的分离合并方法。
权利要求
1.一种支持多播视频点播系统交互性的尽力修补方法，该方法主要解决客户点播率高的热点节目的点播服务，其特征在于其工作过程分为如下三个阶段(1)客户请求准入阶段首先，采用传统的修补技术，按间隔时间调度一个视频节目多播流，对两个相继的多播流间的客户请求，通过修补延误的节目起始段来共享最近的多播流；(2)交互阶段当客户进行交互时，首先判断客户交互是否有图象传输的交互，如否，用户交互不需要分配信道；如客户交互属于有图象传输的交互，则当交互时间长度少于客户设备缓冲区支持的时间长度时，不需要给客户分配修补信道；一旦客户交互时间长度超过客户设备缓冲区支持的时间长度，则服务器给客户分配一个修补信道支持客户交互；(3)合并阶段在客户交互时间长度超过客户设备缓冲区支持的时间长度情况下，客户完成交互后其视频流须合并到规则的多播流中；如果客户已使用一个修补信道进行了交互，则客户设备一边下载并缓冲最接近的多播流，同时继续使用上述用于交互的修补信道从期望播放点开始下载并播放视频流来弥补当前客户交互流与多播流两个流之间的差距，以完成交互流到多播流的合并；否则，服务器给客户另行分配一个修补信道来完成客户交互流和多播流的合并，使客户得到实时的连续交互服务，在该合并过程中，采用一种动态合并方法，以显著提高合并效率。
2.如权利要求1所述的支持多播视频点播系统交互性的尽力修补方法，其特征在于其中所述的动态合并方法的操作步骤描述如下首先设定一个合并队列具有下述的数据结构Struct Mqueue{element*head；/*首记录指针*/int offset；/*队列偏移时间*/int lifetime；/*队列修补流生存时间*/int latime；/*最新客户的加入时间*/}在下述算法中Q为合并队列集合；C为交互客户；n为多播流序号；t为交互客户C的到达时间；则动态合并方法的操作步骤为第1步获得交互客户C期望播放点与多播流n播放点的偏移时间量x；第2步在合并队列中选择到某一个队列q0，该队列是交互客户C的修补流合并到其中后，其所要的修补信道的时间需求达到最短的合并队列。该队列q0的表示公式为q0=Maxq∈Q{Min{q.offset+q.lifetime-x-(t-q.latime)，q.offset}｜q.offset≤x＜q.offset+q.lifetime-(t-q.latime)}第3步若找到上述队列q0，将交互客户C的修补流C合并到q0中，即在队列q0尾部加入修补流C的记录，并修改q0的信息如下delta=t-q0.latime；q0.latime=t；修补流C的生存时间置为x-q0.offset；如果x＞q0.lifetime-delta，则q0.lifetime=x；客户C先从修补流C下载播放视频数据，同时下载并缓存队列q0修补流中的视频数据，经x-q0.offset时间后，播放缓存区中队列q0修补流中下载的数据，并开始同时下载和缓存多播流n中的数据；转第5步。第4步如找不到上述队列q0，则新生成一个合并队列，该队列的首记录为交互客户C的修补流C的信息，并设置队列q0的信息如下q0.offset=x；q0.lifetime=x；q0.latime=t；队列修补流即为修补流C；客户C从修补流C下载播放视频数据，并同时下载和缓存多播流n中的数据；第5步结束。
全文摘要
一种支持多播视频点播系统交互性的尽力修补方法,该方法工作过程分为如下三个阶段:(1)客户请求准入阶段,(2)交互阶段,(3)合并阶段。该方法特点是将原来主要用于消除多播VoD系统中的服务延时的修补技术扩展到用于支持多播视频点播系统中客户的连续交互操作,从而为多播视频点播系统实现真视频点播服务提供一种有效的支持方法;并且,在用于支持交互的修补流和多播流的合并过程中提出了一种新的动态合并算法,该算法可以显著地提高信息流的合并效率。
文档编号H04N7/173GK1296358SQ00134538
公开日2001年5月23日 申请日期2000年12月11日 优先权日2000年12月11日
发明者马华东, G.Shin) 康·G·申(Kang 申请人:北京邮电大学