CN1124742C - 支持多播视频点播系统交互性的尽力修补方法 - Google Patents
支持多播视频点播系统交互性的尽力修补方法 Download PDFInfo
- Publication number
- CN1124742C CN1124742C CN 00134538 CN00134538A CN1124742C CN 1124742 C CN1124742 C CN 1124742C CN 00134538 CN00134538 CN 00134538 CN 00134538 A CN00134538 A CN 00134538A CN 1124742 C CN1124742 C CN 1124742C
- Authority
- CN
- China
- Prior art keywords
- stream
- client
- repairing
- merging
- mutual
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Expired - Fee Related
Links
Images
Abstract
一种支持多播视频点播系统交互性的尽力修补方法,该方法工作过程分为如下三个阶段:(1)客户请求准入阶段,(2)交互阶段,(3)合并阶段。该方法特点是将原来主要用于消除多播VoD系统中的服务延时的修补技术扩展到用于支持多播视频点播系统中客户的连续交互操作,从而为多播视频点播系统实现真视频点播服务提供一种有效的支持方法;并且,在用于支持交互的修补流和多播流的合并过程中提出了一种新的动态合并算法,该算法可以显著地提高信息流的合并效率。
Description
技术领域
本发明涉及一种视频点播系统,确切地说,涉及一种支持多播视频点播系统交互性的尽力修补方法,属于多媒体通信系统技术领域。
背景技术
视频点播(VoD)技术广泛应用于家庭娱乐、数字图书馆、影片点播、远程购物、远程教学等领域。视频点播系统是由传输网络1、视频服务器2和多台位于客户端的点播设备3等构成(参见图1)。从概念上讲,真视频点播服务允许远程用户在任何时间以任意的交互方式点播任何一个视频节目。传统的视频点播系统是为每个用户请求分配一个指定的信道,以提供真视频点播服务。但它的服务伸缩性差,使得服务器吞吐和网络带宽随用户数呈线形增长,服务性能有局限性。多播(multicast)技术提供了一种有效的一点对多点的传输方式,参见图2,使用多播技术的视频点播系统(简称多播VoD系统,)是利用视频服务器2中的客户管理模块22通过传输网络1以及交互控制信道4对多台位于客户端的点播设备3同时进行交互管理,而视频服务模块20则可以将存储在视频存储器21中的一个视频节目通过传输网络1构成一个多播信道5而同时向多个客户端的点播设备3传输播放,在多播信道5上传输的视频数据构成一个多播流,所以,该系统具有很好的客户伸缩性和服务性能,这种性能在热点节目的点播服务中尤为突出。
现在,基本的多播VoD系统是采用等时间隔(如5分钟)和批处理方式来为一组点播同一视频节目的客户调度一个多播流进行服务,是一种准视频点播服务。多播VoD系统要提供真视频点播服务必须解决两个问题:一是为客户提供零延时的服务;二是支持客户使用类似家用录像机的实时交互功能,如播放/恢复、停止/暂停/终止、快进/倒带、向前搜索/反向搜索、慢动作等。
为了消除多播VoD服务中的服务延时,《Patching:A 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 protocol forinteractive 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步:在合并队列集合Q中选择一个合并队列q0,该合并队列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的修补流Sc合并到合并队列q0中,即在合并队列q0尾部加入修补流Sc的记录,并设delta为交互客户C到达时间与合并队列q0中交互客户C到达之前最近一次加入的客户的加入时间的差,即delta=t-q0.latime;
再修改合并队列q0的信息如下:q0.latime=t;
修补流Sc的生存时间置为x-q0.offset;
如果x>q0.lifetime-delta,则q0.lifetime=x;
交互客户C先从修补流Sc下载播放视频数据,同时下载并缓存合并队列q0修补流中的视频数据,经x-q0.offset时间后,播放缓存区中合并队列q0修补流中下载的数据,并开始同时下载和缓存多播流n中的数据;转第5步;
第4步:如找不到上述合并队列q0,则新生成一个合并队列,该合并队列的首记录为交互客户C的修补流Sc的信息,并设置合并队列q0的信息如下:
q0.offset=x;q0.lifetime=x;q0.latime=t;合并队列修补流即为修补流Sc;
交互客户C从修补流Sc下载播放视频数据,并同时下载和缓存多播流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。其修补流记为流SA,在图9中以首行中的网格部分表示之。该流SA的生存时间为a,当合并进行时,比如t1分钟后,其他交互客户的交互流也需要合并到多播流n中。假定某一个新的交互客户B期望播放点与多播流播放点P(n)的偏移时间为b,若t1小于修补流SA的生存时间a,并且t1<2a-b,则使后一个交互的修补流(记为流SB,在图9中以第二行下侧的斜线部分表示之)共享流SA的网格部分,也就是两个流SA、SB的时间共存部分,以减少其修补信道的使用。在这种情况下,流SA将被扩展,以使它的生存时间为b,而流SB的生存时间设置为b-a。该新的客户可同时从流SA和流SB下载视频流数据,在播放完流SB数据后,该客户B设备播放缓存的流SA的视频数据,并且开始从多播流n中下载并缓存视频流,流SA中为修补客户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的修补流(记为流Sc)加入合并队列;否则,客户C的修补流Sc不能加入到合并队列q。
在客户C的修补流Sc加入合并队列时,可按两种情况管理该队列:
情形1:当x>q.lifetime-t2时,意味合并队列q修补流(流SA)的生存时间不足以合并流Sc,所以流SA的生存时间必须被扩展。即流Sc合并后,流Sc的生存时间置为x-q.offset,且置q.lifetime=x,q.latime=t+t2。客户同时从流SA和Sc下载视频数据,首先播放流Sc的视频数据,经过x-q.offset时间后,客户开始播放流SA的视频数据,并从多播流n下载视频数据。在这种情形,本发明的动态合并方法可节省的修补信道的使用时间为q.offset+q.lifetime-t2-x。
情形2:当x≤q.lifetime-t2时,意味队列q修补流(流SA)的生存时间足以合并流Sc,所以流SA的生存时间不扩展。即流Sc合并后,流Sc的生存时间置为x-q.offset,且置q.latime=t+t2,q.lifetime不变。客户从流SA和流Sc及多播流n下载和播放视频数据的顺序与情形1一致。在这种情形,本发明的动态合并方法可节省的修补信道的使用时间为q.offset。
如果流Sc不能加入在现有的合并队列中,一个由流Sc作为首记录发起的新的队列被建立,初始的队列的修补流就是流Sc。同时由于可能存在很多合并队列,流Sc将被合并到具有最大修补信道节省的队列中。
本发明的动态合并方法的操作步骤描述如下:
首先设定一个合并队列具有下面的数据结构:
Struct Mqueue{
element *head;/*首记录指针*/
int offset;/*队列偏移时间*/
int lifetime;/*队列修补流生存时间*/
int latime;/*最新客户的加入时间*/
}
在下述算法中:Q为合并队列集合;C为交互客户;n为多播流序号;t为交互客户C的到达时间;则动态合并方法的操作步骤为:
第1步:获得交互客户C期望播放点与多播流n.播放点的偏移时间量x;
第2步:在合并队列集合Q中选择一个合并队列q0,该合并队列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的修补流Sc合并到q0中,即在合并队列q0尾部加入修补流Sc的记录,并设delta为交互客户C到达时间与合并队列q0中交互客户C到达之前最近一次加入的客户的加入时间的差,即delta=t-q0.latime;再修改合并队列q0的信息如下:q0.latime=t;修补流Sc的生存时间置为x-q0.offset;
如果x>q0.lifetime-delta,则q0.lifetime=x;
交互客户C先从修补流Sc下载播放视频数据,同时下载并缓存合并队列q0修补流中的视频数据,经x-q0.offset时间后,播放缓存区中合并队列q0修补流中下载的数据,并开始同时下载和缓存多播流n中的数据;转第5步;
第4步:如找不到上述合并队列q0,则新生成一个合并队列,该队列的首记录为交互客户C的修补流Sc的信息,并设置合并队列q0的信息如下:
q0.offset=x;q0.lifetime=x;q0.latime=t;队列修补流即为修补流Sc;
交互客户C从修补流Sc下载播放视频数据,并同时下载和缓存多播流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-demandsystems》(刊于Proc.IEEE International Conference on Multimedia Computing andSystem’98,June-July 1998.)中提出的基于用户设备缓冲区改进的分离合并方法。
Claims (2)
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步:在合并队列集合Q中选择一个合并队列q0,该合并队列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的修补流Sc合并到q0中,即在合并队列q0尾部加入修补流Sc的记录,并设delta为交互客户C到达时间与合并队列q0中交互客户C到达之前最近一次加入的客户的加入时间的差,即delta=t-q0.latime;
再修改合并队列q0的信息如下:q0.latime=t;
修补流Sc的生存时间置为x-q0.offset;
如果x>q0.lifetime-delta,则q0.lifetime=x;
交互客户C先从修补流Sc下载播放视频数据,同时下载并缓存合并队列q0修补流中的视频数据,经x-q0.offset时间后,播放缓存区中合并队列q0修补流中下载的数据,并开始同时下载和缓存多播流n中的数据;转第5步;
第4步:如找不到上述合并队列q0,则新生成一个合并队列,该队列的首记录为交互客户C的修补流Sc的信息,并设置合并队列q0的信息如下:
q0.offset=x;q0.lifetime=x;q0.latime=t;队列修补流即为修补流Sc;
交互客户C从修补流Sc下载播放视频数据,并同时下载和缓存多播流n中的数据;
第5步:结束。
Priority Applications (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN 00134538 CN1124742C (zh) | 2000-12-11 | 2000-12-11 | 支持多播视频点播系统交互性的尽力修补方法 |
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN 00134538 CN1124742C (zh) | 2000-12-11 | 2000-12-11 | 支持多播视频点播系统交互性的尽力修补方法 |
Publications (2)
Publication Number | Publication Date |
---|---|
CN1296358A CN1296358A (zh) | 2001-05-23 |
CN1124742C true CN1124742C (zh) | 2003-10-15 |
Family
ID=4596261
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
CN 00134538 Expired - Fee Related CN1124742C (zh) | 2000-12-11 | 2000-12-11 | 支持多播视频点播系统交互性的尽力修补方法 |
Country Status (1)
Country | Link |
---|---|
CN (1) | CN1124742C (zh) |
Families Citing this family (4)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN100432965C (zh) * | 2005-03-11 | 2008-11-12 | 北京凯诚高清电子技术有限公司 | 网络播放机 |
KR101214167B1 (ko) * | 2007-08-06 | 2012-12-21 | 삼성전자주식회사 | Vod 서비스 방법, vod 수신기 및 vod 서버 |
CN109348430B (zh) * | 2018-10-29 | 2020-05-12 | 电子科技大学 | 面向多信道多内容基站小区的组播调度方法 |
US11546185B2 (en) * | 2020-04-27 | 2023-01-03 | Hewlett Packard Enterprise Development Lp | Multicast route summarization |
-
2000
- 2000-12-11 CN CN 00134538 patent/CN1124742C/zh not_active Expired - Fee Related
Also Published As
Publication number | Publication date |
---|---|
CN1296358A (zh) | 2001-05-23 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
US7383346B2 (en) | Progressive streaming media rendering | |
US7523482B2 (en) | Seamless digital channel changing | |
CN1244080C (zh) | 带宽动态分配方法 | |
Gao et al. | Threshold-based multicast for continuous media delivery | |
CN1926867A (zh) | 提供vod媒体流的增强特征的系统和方法 | |
CN1655609A (zh) | 记录视频会议数据的方法和系统 | |
JP5596669B2 (ja) | ライブ作品におけるコンテンツ置換方法及び装置 | |
CN1842160A (zh) | 快速媒体频道转换机制及包括该机制的接入网节点 | |
CN1949846A (zh) | 在同一画面中显示多个频道信息的方法、系统、装置及机顶盒 | |
CN1271834C (zh) | 一种支持大容量用户的多路实时视频网关及其应用方法 | |
CN1124742C (zh) | 支持多播视频点播系统交互性的尽力修补方法 | |
Ma et al. | Best-effort patching for multicast true VoD service | |
Wang et al. | Wrap harmonic broadcasting and receiving scheme for popular video service | |
Guan et al. | A two-level patching scheme for video-on-demand delivery | |
CN115086472B (zh) | 基于关键帧信息的手机app管理系统 | |
JP3560556B2 (ja) | マルチキャスト・ビデオ・オンデマンドによる動画コンテンツの配送方法 | |
Krunz et al. | Efficient support for interactive scanning operations in MPEG-based video-on-demand systems | |
Chen et al. | Multiple videos broadcasting scheme for near video-on-demand services | |
Ma et al. | A new scheduling scheme for multicast true VoD service | |
Lee | Channel folding-an algorithm to improve efficiency of multicast video-on-demand systems | |
Psannis et al. | Transmitting additional data of MPEG-2 compressed video to support interactive operations | |
Wu et al. | A reverse-order scheduling scheme for broadcasting continuous multimedia data over a single channel | |
Xiang et al. | Piecewise patching for time-shifted TV over HFC networks | |
CN1622471A (zh) | 确定运动矢量和宏块类型的方法 | |
CN1309255C (zh) | 控制点播数据客户机访问 |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
C10 | Entry into substantive examination | ||
SE01 | Entry into force of request for substantive examination | ||
C06 | Publication | ||
PB01 | Publication | ||
C14 | Grant of patent or utility model | ||
GR01 | Patent grant | ||
C19 | Lapse of patent right due to non-payment of the annual fee | ||
CF01 | Termination of patent right due to non-payment of annual fee |