支持VCR功能的多播流合并方法

摘要

支持VCR功能的多播流合并方法，由服务器端向客户端提供多播视频服务，客户端通过主动缓存预取和缓存数据，通过控制及请求机制为服务器端的流合并创造条件；在服务器端，使用流合并机制，当一个新客户加入系统时，播放器向缓存请求数据，缓存控制检查缓存内的数据，如果有相应数据，则直接将数据返回给播放器进行播放；如果没有，则向服务器发送请求，等待直到服务器返回多播流地址后，接收器开始接收相应地址的流数据；发明提供一种客户端和服务器端的协作机制：在客户端通过主动缓存机制，一方面预取和缓存数据，另一方面通过特殊的控制及请求机制为服务器端的流合并创造条件。

说明书

                            技术领域

本发明涉及视频服务系统，特别涉及一种以多播形式发送数据，并可支持用户VCR操作的个性化视频服务系统。

                            背景技术

使用多播技术的视频服务系统可以广泛应用于网络教学、视频会议、网络课堂、视频点播等服务。与单播方式的视频服务相比，使用多播技术的视频服务系统更节省服务器的带宽，使其具有更高的性能。与传统的视频直播服务相比，多播流合并方法可以使视频服务更具有个性化，能随时满足客户不同的需求。现有的支持VCR功能的多播流合并方法在功能上有不足之处。

VCR软件可以把ASF、RM、WMA、RA等流文件下载到本地再播放，再也不用因为网络速度慢而影响观看了，当然最大的好处是可以保存那些本来不能保存的“流”节目了。它同时支持现场下载和点播下载。提高了多种流媒体文件的下载能力。现在已经能够支持下载Real Helix的流文件。并且在下载的带宽上已经支持到了10Mbps LAN的新速率。对于采用T1速率之上的ADSL、Cable Modem、光缆、LAN等设备的用户的下载道路可是更加的宽阔了。可以把ASF、RM、WMA、RA等等流文件下载到本地再播放，再也不用因为网络速度慢而影响观看了。当然最大的好处是可以保存那些本来不能保存的“流”节目了。它同时支持现场下载和点播下载。多播流合并方法应该支持VCR功能。

                          发明内容

本发明的主要目的是针对现有技术在个性化服务与服务器可扩展性之间不能兼顾的情况，提出一种支持VCR功能的多播流合并方法，使在满足个性化视频服务的同时，不过多的损耗服务器性能。

为实现本发明所述目的，本发明提供一种客户端和服务器端的协作机制：(1)在客户端通过主动缓存机制，一方面预取和缓存数据，另一方面通过特殊的控制及请求机制为服务器端的流合并创造条件；(2)在服务器端，使用特殊的流合并机制，既满足用户观看以及VCR操作的需要，又尽可能地提高流的共享度，增强服务器的服务性能。

下面将结合附图进行详细说明。

                        附图说明

图1是支持VCR功能的多播视频服务系统的结构图

图2是此视频服务系统的工作流程图

图3是本发明的客户端缓存控制逻辑

图4是客户端缓存简单示意图

图5是本发明的服务器端调度逻辑

图6是服务器调度策略辅助说明图

                         具体实施方式

如图1所示，视频服务系统由客户端和服务器端两部分组成，这两部分通过网络进行视频数据和控制信息的转的。客户端缓存负责向播放器提供数据并观察其行为，适时地向服务器发送请求。客户端接收器负责从网络接收数据放入缓存。服务器端调度器接收到请求后进行流调度，并将数据以多播流形式发送给客户端。

本发明的总流程如图2所示。当一个新客户加入系统时，播放器向缓存请求数据(步骤11)，缓存控制检查缓存内的数据(步骤12)，如果有相应数据，则直接将数据返回给播放器进行播放(步骤13)；如果没有，则向服务器发送请求(步骤14)，等待直到服务器返回多播流地址后(步骤15)，接收器开始接收相应地址的流数据(步骤16)。在客户的播放过程中，播放器会不断向缓存请求数据，且当客户发生VCR操作时也会向缓存请求数据，直至影片播放结束。缓存控制是比较复杂的一个过程，其中涉及本发明特有的方法，将在后面详细描述。

相应地，服务器端从步骤20开始启动服务，等待直到客户请求到达(步骤21)，进行多播流的调度与合并(步骤22)，将结果返回给客户端(步骤23)，并向客户发送数据(步骤24)，调度的算法也将在后面详细描述。一个调度过程完成以后，将回到步骤21等待新的客户请求到达，如此往复，直到服务器停止服务。

在图3中详细描述了客户端的缓存控制流程。当播放器请求数据时，先判断缓存中有无被请求的数据(步骤121)，如果没有则向服务器发送立即请求(步骤124)，如果有则将数据返回给播放器(步骤122)，同时检查接收器接收数据的状况(步骤123)。如果接收器不在接收数据，或者正在接收的数据不是客户在一段时间以后需要但缓存中缺失的数据，则向服务器发送延迟请求(步骤125)，即此请求要求服务器在限定的延迟内发送被请求数据。如图4所示，从D_start到D_end表示观看整部影片所需要的数据，阴影部分表示缓存中已有数据，D_now表示播放器当前正在播放的数据，D_rup表示缓存中缺失数据的起始位置，播放器消耗数据的速率为v，则缓存发送的延迟请求的允许延迟时间可以通过公式(1)求得，即服务器必须在播放器到达D_rup之前向客户发送D_rup之后的数据。

$>>>T>delay>>=>>>>D>rup>>->>D>now>>>v>>->->->>(>1>)>>>s>$

接收器接收到数据后，先判断此数据是否是播放器正在请求的数据(步骤127)，若是，则回到步骤122将数据放入缓存并返回给播放器；如果不是，则继续判断缓存中是否还有可用空间(步骤128)。如果有剩余空间，则将数据放入缓存；如果没有，则停止接收该流的数据。

图5显示了服务器的调度流程。当服务器接收到客户请求后，先判断请求类型(步骤221)。如果是立即请求，则判断服务器有无多余带宽(步骤222)，如果没有则调度失败，向客户返回失败信息。如果服务器还有剩余带宽可供使用，则以请求地址为起始开辟一个新的多播流P，并且进行多播流的合并(步骤223)。在进行流合并时，假设D_now为流正在发送的数据位置，D_end表示流的结束位置，则在现存流中寻找一个满足以下条件的多播流A作为流P的目标流：

                  D_{A_now}-D_{P_now}＜D_{A_end}-D_{A_now}           (2)

调度成功，将补丁流P及其目标流A的地址发送给客户。具体如图6(a)所示，可用坐标轴对上述调度策略加以解释说明。横坐标表示时间，纵坐标表示发送的数据在影片中的位置。坐标轴中的每一条斜线就是服务器发送的一个数据流。假设在时间t₁，服务器接收到一个立即请求，要求发送数据D_req。服务器立即调度一个新流P，并在现有所有同一影片的多播流中查找一个符合条件(2)的流作为合并的目标流。流a不能满足条件，因为D_{a_now}-D_{P_now}＞D_{a_end}-D_{a_now}，会导致流P为追上流a而发送完D_{a_now}时，流a已经结束发送，不能再进行合并。流b符合条件(2)，因此可以作为流P的目标流进行合并，流P发送至D_{b_now}结束。

如果客户的请求是延迟请求，则判断系统中有无符合条件的现存流(步骤225)。假设客户请求数据D_req，允许的延迟为T_delay，假设存在符合以下条件的流A：

                D_req＞D_{A_now}＞D_req-T_delay*v且D_req＜D_{A_end}         (3)

则调度成功，将流A的地址返回给客户。如果没有符合此条件的流，则暂缓调度，等待客户再次发送请求。同样可用图6(b)来说明对延迟请求的调度策略。假设在时间t₂，服务器接收到一个请求数据D_req、允许延迟为T_delay的延迟请求。服务器在现有多播流中，查找一条满足条件(3)的流。因为对于流a，D_req＜D_{a_now}，显然不能满足从t₂～t₂+T_delay时间段内发送D_req；而对于流b，D_{b_now}＜D_req-T_delay*v，从而不能在T_delay时间段内发送D_req；流c满足条件D_req＞D_{c_now}＞D_req-T_delay*v，但D_req＞D_{c_end}，即流c在发送到数据D_req之前就已经结束；流d满足条件(3)，可以在t₂～t₂+T_delay时间段内发送客户请求的数据，及时满足客户的需求。

纵上所述，客户缓存控制逻辑以及服务器调度逻辑是本发明的核心。