CN101998142A

CN101998142A - 一种实现盒式录像机操作的方法、设备和系统

Info

Publication number: CN101998142A
Application number: CN2009101627067A
Authority: CN
Inventors: 彭展; 汤博
Original assignee: Huawei Technologies Co Ltd
Current assignee: Huawei Technologies Co Ltd
Priority date: 2009-08-10
Filing date: 2009-08-10
Publication date: 2011-03-30

Abstract

本发明公开了一种实现盒式录像机VCR操作的方法、设备和系统，涉及移动富媒体技术领域，能够实现对富媒体流的VCR操作，满足了用户的需要，增强了用户体验，具有较高的实用性和较广的应用前景。本发明实施例提供的方法包括：服务器端接收客户端发送的对富媒体流的VCR操作请求信息；服务器端根据客户端当前所处的状态和所述VCR操作请求信息向客户端发送相应的富媒体流数据。客户端在该状态下，接收服务器端发送的相应的富媒体流数据，解析并呈现所述富媒体流数据。本发明适用于对富媒体流进行VCR操作的场合。

Description

一种实现盒式录像机操作的方法、设备和系统

技术领域

本发明涉及移动富媒体技术领域，尤其涉及一种富媒体流点播业务中实现盒式录像机VCR操作的方法、设备和系统。

背景技术

随着技术的发展以及为了满足用户日益增长的需求，开放移动联盟(OpenMobile Alliance，OMA)与第三代合作伙伴计划组织(3GPP)提出了移动富媒体场景标准。移动富媒体场景流可在现有视频业务的基础上，为用户提供内容更丰富、交互程度更高、用户参与度更高的交互式富媒体节目，例如交互式电视投票，交互式电视广告等。

富媒体流业务通常会包括场景流、音频流和视频流等多种流数据，动态交互多媒体场景(Dynamic and Interactive Multimedia Scenes，DIMS)流，是一种典型的移动富媒体场景流数据。DIMS场景流是由场景描述和一系列场景更新构成的。DIMS场景流的场景描述基于SVG T1.2，场景描述包括正常随机接入点、初始场景和冗余信息，如矢量图形、动画、图像、文本、音频、视频以及脚本等媒体类型的其中一种或多种的组合；DIMS场景流的场景更新则通过DIMS场景命令来实现，例如，添加命令(Add)、替换(Replace)命令、插入(Insert)命令和删除(Delete)命令等。

对于广播模式下的DIMS数据，服务器端可以发起场景流跳转，例如，服务器端向客户端发送跳转(seek)场景命令，指示客户端进行相应场景流的跳转。在进行场景切换、场景接入和错误恢复时，根据需要服务器端发送不同的接入数据包，例如，正常随机接入点(Normal RAP)、冗余随机接入点(Redundant RAP)和分布式随机接入点(Distributed Random Access Point，DRAP)。

而在不同的处理状态下，DIMS客户端也处于不同的状态，例如，接入状态(tune-in state)、正常状态(normal state)和冗余处理状态(redundant-processingstate)。并且，位于一种状态下的客户端只能处理与该状态下所允许的数据包，例如，客户端在正常状态下只能处理正常DIMS数据包。

在实现本发明的过程中，发明人发现现有技术中至少存在如下问题：在许多场景下，客户端会对富媒体流数据进行盒式录像机(Video Cassette Recorder，VCR)操作，如在进行点播业务时，客户端需要进行如暂停/播放、跳转、快(慢)进、快(慢)退等VCR操作。而现有技术只能在服务器端发起及执行对DIMS场景流的跳转切换等简单操作，还未提出一套针对DIMS场景流的VCR操作控制技术，从而无法满足用户的需要，用户体验较差。

发明内容

为解决现有技术中存在的问题，本发明的实施例提供一种富媒体流点播业务中实现盒式录像机VCR操作的方法、设备和系统，能够实现对富媒体流数据的VCR操作，满足了用户的需要，增强了用户体验，具有较高的实用性和较广的应用前景。

为达到上述目的，本发明的实施例采用如下技术方案：

一种富媒体流点播业务中实现盒式录像机VCR操作的方法，包括：

服务器端接收客户端发送的对富媒体流的VCR操作请求信息；

服务器端根据客户端当前所处的状态和所述VCR操作请求信息向客户端发送相应的富媒体流数据。

一种富媒体流点播业务中实现盒式录像机VCR操作的方法，该方法包括：

客户端向服务器端发送对富媒体流的VCR操作请求信息并确定当前所处的状态；客户端在所述状态下，接收服务器端根据所述VCR操作请求信息发送的相应的富媒体流数据；客户端解析并呈现所述富媒体流数据。

一种网络服务器，包括：

接收单元，用于接收客户端发送的对富媒体流的VCR操作请求信息；

发送单元，用于根据客户端当前所处的状态和所述接收单元接收到的VCR操作请求信息向客户端发送相应的富媒体流数据。

一种客户端设备，包括：

发送单元，用于向服务器端发送对富媒体流的VCR操作请求信息并确定当前所处的状态；

接收单元，用于在所述状态下，接收服务器端根据所述VCR操作请求信息发送的相应的富媒体流数据；

解析呈现单元，用于解析并呈现所述富媒体流数据。

本发明实施例还提供了一种富媒体流的点播系统，所述系统包括服务器端和客户端，其中，

所述服务器端，用于接收客户端发送的对富媒体流的VCR操作请求信息；根据客户端当前所处的状态和所述VCR操作请求信息向客户端发送相应的富媒体流数据；所述客户端，用于向服务器端发送对富媒体流的VCR操作请求信息并确定当前所处的状态；在所述状态下，接收服务器端根据所述VCR操作请求信息发送的相应的富媒体流数据；解析并呈现所述富媒体流数据。

由上所述，本发明实施例提供的技术方案，当客户端需要针对富媒体流进行VCR操作时，向服务器端发送VCR操作请求信息并确定当前自身所述的状态，服务器端根据该VCR操作请求信息向客户端发送相应的富媒体流数据，客户端解析接收到的富媒体流数据并呈现所述富媒体流数据。本发明实施例提供的技术方案独创了一整套针对富媒体流数据的VCR操作控制技术，能够实现对富媒体流数据的VCR操作，满足了用户的需要，增强了用户体验，具有较高的实用性和较广的应用前景。

附图说明

为了更清楚地说明本发明实施例或现有技术中的技术方案，下面将对实施例或现有技术描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本发明的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他的附图。

图1为本发明实施例一提供的富媒体流点播业务中实现盒式录像机VCR操作的方法；

图2为本发明实施例二提供的富媒体流点播业务中实现盒式录像机VCR操作的方法；

图3为本发明实施例三提供的富媒体流点播业务中客户端在VCR处理状态和正常状态之间跳转的原理示意图；

图4为本发明实施例三提供的富媒体流点播业务中进行暂停/播放操作时计算场景呈现时间的示意图；

图5为本发明实施例三提供的富媒体流点播业务中进行跳转操作时的方法流程示意图；

图6(a)和图6(b)为本发明实施例三提供的富媒体流点播业务中进行跳转操作的原理示意图；

图7为本发明实施例三提供的富媒体流点播业务中一种快进/慢进操作的原理示意图；

图8为本发明实施例三提供的富媒体流点播业务中快进/慢进时获取场景呈现时间的原理图；

图9为本发明实施例三提供的富媒体流点播业务中另一种快进/慢进操作的原理示意图；

图10为本发明实施例三提供的富媒体流点播业务中一种快退/慢退操作的原理示意图；

图11为本发明实施例四提供的网络服务器结构示意图；

图12为本发明实施例五提供的客户端设备结构示意图；

图13为本发明实施例提供的一种富媒体流的点播系统的结构示意图。

具体实施方式

下面将结合本发明实施例中的附图，对本发明实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅仅是本发明一部分实施例，而不是全部的实施例。基于本发明中的实施例，本领域普通技术人员在没有作出创造性劳动前提下所获得的所有其他实施例，都属于本发明保护的范围。

本发明的技术构思主要在于首次提出了一套完整的富媒体流VCR操作的处理机制。主要涉及的处理包括，例如，用户发起一个VCR操作请求，客户端接收用户的VCR操作请求并自动切换到恰当的处理状态中，客户端把VCR操作请求转发给服务器端。服务器端收到该VCR操作请求后进行相应操作，如根据VCR的请求方式(如跳转、快进/快退等)和场景流的特点进行相应的处理。在服务器端处理完毕后，下发相应的场景流数据给客户端。客户端在接收到数据后，根据VCR操作的类型以及相应的时间信息(如时间戳)获取或计算场景呈现时间，并解析和呈现相应场景。客户端在完成上述VCR操作后，返回到正常状态。

下面对本发明实施例提供的技术方案进行详细描述。

本发明实施例一提供了一种富媒体流点播业务中实现盒式录像机VCR操作的方法，如图1所示，包括：

步骤11：服务器端接收客户端发送的对富媒体流的VCR操作请求信息；

步骤12：服务器端根据客户端当前所处的状态和所述VCR操作请求信息向客户端发送相应的富媒体流数据。

上述步骤11和步骤12可由服务器端的相关设备来实现，例如由支持富媒体流业务的服务器来实现。服务器端还可以根据需要，如客户端当前所处的状态，对相应的富媒体流数据进行处理。例如，当客户端处于只能接收正常富媒体场景流数据时，服务器端将冗余富媒体场景流数据转换为正常富媒体场景流数据。

其中，对服务器端获知客户端所处状态的具体方式不进行限定，例如，可以预先确定客户端进行VCR操作时所处的状态或状态的跳转方式，并通知服务器端；或者，客户端在VCR操作请求信息中携带自身所处的状态，服务器端通过该VCR操作请求信息获知客户端当前所处的状态；或者，客户端通过一条新设置的状态指示信息，将客户端所处的状态告知服务器端。

本发明实施例提供的技术方案，服务器端能够根据客户端发送的VCR操作请求信息，向客户端发送相应的富媒体流数据，从而保证了相应的VCR操作能够在客户端成功实现。

本发明实施例二提供的富媒体流点播业务中实现盒式录像机VCR操作的方法，如图2所示，包括：

步骤21：客户端向服务器端发送对富媒体流的VCR操作请求信息并确定当前所处的状态；

步骤22：客户端在所述状态下，接收服务器端根据所述VCR操作请求信息发送的相应的富媒体流数据；

步骤23：客户端解析并呈现所述富媒体流数据。

上述步骤21至步骤23可由客户端的相关设备来实现，如手机来实现。当客户端需要针对富媒体流进行VCR操作时，如用户发送指令执行点播业务时，客户端向服务器端发送VCR操作请求信息。进一步的，当该富媒体流为富媒体场景流时，客户端发送上述VCR操作请求信息时，会切换到相应的状态或保持当前所处的状态。这种状态可以包括第一状态、第二状态和第三状态，在所述第一状态下，客户端能够接收服务器端发送的冗余富媒体场景流数据和特定的正常富媒体场景流数据，在所述第二状态下，客户端只能接收服务器端发送的所有正常富媒体场景流数据，在所述第三状态下客户端能够接收服务器端发送的所有的冗余富媒体场景流数据和正常富媒体场景流数据。

在本发明实施例中采用“第一”、“第二”、第三”对具有相应关系的类似项进行标记，“第一”、“第二”、第三”不对操作的顺序或数量进行限定。相同描述同样适用于下文相关内容。

进一步的，对富媒体场景流进行不同类型的VCR操作时，客户端也会采用不同的处理方法。

当进行暂停/播放操作时，客户端可以进行如下处理：

向服务器端发送对富媒体场景流的暂停请求信息；接收服务器端发送的暂停请求响应并暂停接收服务器端发送的富媒体场景流数据；向服务器端发送对富媒体场景流的播放请求信息，以继续播放所述被暂停的富媒体场景流数据；

接收服务器端发送的播放请求响应和相应的富媒体场景流数据；计算得到所述富媒体场景流数据对应的场景呈现时间；解析所述富媒体场景流数据并根据所述场景呈现时间呈现所述富媒体场景流数据。

当进行跳转操作时，客户端可以进行如下处理：

向服务器端发送对富媒体场景流的跳转请求信息，所述跳转请求信息携带用于指示跳转时间点的信息；

接收服务器端发送的对应于所述跳转时间点的实现场景跳转所需的富媒体场景流数据；

获知所述富媒体场景流数据对应的场景呈现时间；

解析所述富媒体场景流数据并根据获知的场景呈现时间呈现所述富媒体场景流数据；

当进行快进/慢进操作时，客户端可以进行如下处理：

向服务器端发送对富媒体场景流的快进/慢进请求信息，所述快进/慢进请求信息指示对富媒体场景流的第一播放速度；接收服务器端以第二播放速度发送的相应的富媒体场景流数据；获知所述富媒体场景流数据对应的场景呈现时间；解析所述富媒体场景流数据并根据获知的场景呈现时间呈现所述富媒体场景流数据；向服务器端发送正常播放请求信息；结束快进/慢进操作，接收服务器端以正常速度发送的富媒体场景流数据并进行解析和呈现。

当进行快退/慢退操作时，客户端可以进行如下处理：

向服务器端发送对富媒体场景流的快退/慢退请求信息，所述快退/慢退请求信息指示对富媒体场景流的第三播放速度；接收服务器端以第四播放速度发送的相应的富媒体场景流数据；获知所述富媒体场景流数据对应的场景呈现时间；解析所述富媒体场景流数据并根据获知的场景呈现时间呈现所述富媒体场景流数据；向服务器端发送正常播放请求信息；结束快退/慢退操作，接收服务器端以正常速度发送的富媒体场景流数据并进行解析和呈现。

其中，所述暂停请求信息、播放请求信息、跳转请求信息、快进/慢进请求信息和快退/慢退请求信息属于所述VCR操作请求信息。

本发明实施例提供的技术方案，客户端能够向服务器端发送VCR操作请求信息，并进行相应的处理将接收到的服务器端根据该VCR操作请求信息发送的富媒体场景流数据，在客户端进行呈现，实现了针对富媒体场景流的VCR操作。

下面根据客户端所处的不同状态以及VCR操作的具体类型，对本发明实施例三提供的富媒体流点播业务中实现盒式录像机VCR操作的方法分别进行说明。

本发明实施例提供的技术方案适用于IPTV、Mobile TV的富媒体交互业务(Rich and Interactive Application)中的DIMS/OMA-RME场景流的VCR播放控制场景。开放移动联盟富媒体环境(Open Mobile Alliance Rich Media Environment，OMA-RME)，或称之为DIMS，是由OMA与3GPP联合制定的移动富媒体场景标准。在本发明实施例中以DIMS数据包为例来说明本发明实施例针对富媒体场景流数据的VCR操作的处理机制。但不局限于此，本发明实施例提供的技术方案适用于各种富媒体场景流数据。对富媒体流中的视频流和音频流的具体形式不进行限定。

为便于理解本发明实施例的技术方案，首先对DIMS场景流随机接入机制进行说明。主要涉及的技术特征包括正常随机接入点(Normal RAP)、冗余随机接入点(Redundant RAP)和分布式随机接入点(Distributed Random AccessPoint，DRAP)，对其具体的功能和内容分别描述如下：

正常RAP：包含了完整的场景描述信息，在切换场景及接入、错误恢复时使用。根据DIMS协议，Normal RAP中隐含了场景时间为零的属性，即场景切换、接入后，场景时间将被置零。Normal RAP在终端正常和冗余处理状态下均被处理。

冗余RAP：包含了完整的场景描述信息，在错误恢复或接入时使用。冗余RAP通过其currentSceneTime属性指定了该冗余RAP的场景时间。冗余RAP只在终端冗余状态下被处理。冗余RAP与正常RAP的区别在于冗余RAP比正常RAP多了一个上述currentSceneTime属性。

DRAP：DIMS定义了DRAP机制，DRAP是冗余的随机接入点。DRAP提供随机接入所需的内容并不是完全包含在它本身的DIMS包中，其所使用的一些元素将包含在后续的一系列资源包(冗余DIMS包)中，DRAP包只给出提供接入所需元素及对后续冗余包中某些元素的引用关系。DRAP的特点是可以平滑带宽，避免传输大的RAP包所带来的带宽峰值效应。

在本发明实施例中，客户端可以至少位于下述三种状态：

第一状态：VCR处理(VCR-processing)状态

为需要进行VCR操作的客户端新设置一个VCR处理状态，当执行VCR操作时，客户端便进入该VCR处理状态。

为便于理解，本发明实施例中客户端的VCR处理状态可以对应于DIMS协议中的客户端冗余处理状态，在VCR处理状态下客户端只处理冗余DIMS包和特定的正常DIMS数据包，如正常随机接入点(RAP)的数据。

第二状态：正常(Normal)状态

为了便于操作，上述正常状态与DIMS协议中定义的客户端的正常状态保持一致，在正常状态下，客户端只处理正常DIMS包。

第三状态：正常状态

将第三状态也称之为正常状态，但该正常状态与第二状态中被称之为的正常状态不同，本发明实施例不对具体的名称进行限定。当客户端位于第三状态中的正常状态时，可以处理所有的正常富媒体场景流数据和所有的冗余富媒体场景流数据，例如，所有的正常DIMS数据包和所有的冗余DIMS数据包。

可根据DIMS包的包头获知DIMS包的类型，DIMS包的包头格式参见表1。

表1

对表1所示包头中各标识位的具体含义进行简单说明。

标识位S：当此标识位为1时，包中的信息为场景描述；当此标识位为0时，则表示包中包含的信息是场景命令。

标识位M：当此标识位为1：表示是随机访问点；当此标识位为0：表示不是随机访问点。

标识位I：当此标识位为0：表示正常DIMS数据包；当此标识位为1：表示冗余DIMS数据包。

标识位D：当标识位I为0(该数据包为正常DIMS包)时，标识位D为0；当标识位I为1(该数据包为冗余DIMS包)时，如果标识位D为1，表示该数据包是DIMS协议中冗余处理状态的结束点，终端接下来接入DIMS协议中的正常状态；如果标识位D为0，表示冗余处理状态还需继续。

标识位P：表示数据包的优先级，当标识位P为0时：低优先级；当标识位P为1时：高优先级。如果一个数据包满足以下条件，则标识位P应该被设置为低优先级：丢失该数据包不会造成对后续数据包的解码产生错误，或者，场景的视觉效果和语义在制作者的接受范围之内。

标识位C：表示数据包的内容是否被压缩过：标识位C为0时：未压缩；标识位C为1时：压缩。

标识位X：保留，固定为0。

基于客户端在执行VCR操作时的上述三种状态，客户端和服务器端可采用如下两种处理方式：

第一种方式：客户端在VCR处理状态和正常状态之间跳转

在第一种方式中的正常状态仅仅指上述第二状态中的正常状态，具体包括如下处理：

1)在正常播放时，客户端处于正常状态。在此状态下，客户端只处理正常DIMS数据包，并且解析呈现。

2)当客户端发送VCR操作请求信息给服务器端后，参见图3，客户端进入VCR处理状态。在此状态下，客户端只处理冗余DIMS数据包和正常RAP，并且在接收到标识位D为1的冗余DIMS数据包后跳转回正常状态。

3)在VCR处理状态下，服务器端下发的各类型DIMS数据包(正常/冗余场景更新，冗余RAP，DRAP)都应该封装成冗余包，例如，将正常DIMS数据包的包头中的标识位I设置为1。其中，服务器端可不对正常RAP进行处理，将正常RAP直接发送给处于VCR处理状态的客户端。

4)待客户端收到DIMS数据包后，根据发起VCR操作时的该DIMS数据包的场景时间、该DIMS数据包的媒体时间及客户端所进行的VCR操作的类型，计算出场呈现景时间，并呈现相应的DIMS数据包。

5)当VCR操作处理结束后，客户端发送正常播放请求给服务器端，服务器端在执行该VCR操作所需发送的最后一个冗余DIMS数据包中携带指示信息，指示客户端返回到正常状态，例如，将该冗余DIMS数据包包头的标识位D设置为1，来指示客户端返回到正常状态。

6)客户端收到服务器发送的包头D位为1的冗余DIMS数据包时，客户端解析该DIMS数据包以进行呈现，并随后返回正常状态。

7)客户端处于正常状态，只处理正常DIMS数据包。

第二种方式：客户端保持在正常状态

客户端在进行正常播放和VCR播放时，保持在正常状态下，在第二种方式中，正常状态可以指第二状态中的正常状态或者第三状态中的正常状态，其处理流程分别如下：

1、在正常播放时，客户端只处理正常DIMS数据包，并解析呈现。

2、当客户端向服务器发起VCR操作请求后，进行的处理可以有两种方式：

21)客户端处于第二状态中的正常状态，服务器修改下发的DIMS数据包的类型：

由于客户端保持在第二状态中的正常状态，该正常状态下只处理正常DIMS数据包，因此服务器端需要把VCR播放中所需的全部冗余DIMS数据包转换成正常DIMS数据包，这种转换可以包括如下操作：

211)、将冗余DIMS数据包的包头的标识位I和标识位D设置为0；

212)、针对冗余RAP的具体转换操作：通过步骤211)的操作可将冗余RAP转换成正常RAP，但这种转换后的正常RAP中携带了currentSceneTime属性，这主要考虑到对该转换后的正常RAP，需要利用该currentSceneTime属性来获知场景呈现时间。这时，要求客户端支持上述转换后的正常RAP具有的currentSceneTime属性。

213)、针对DRAP的具体转换操作：

DRAP是一个冗余DIMS数据包，内容包括一部分场景描述和对后续DIMS数据包中其所需元素的引用关系。后续其引用的DIMS数据包为资源包。由于处理DRAP的客户端必须处于冗余处理状态，而处于冗余处理状态的客户端只处理冗余DIMS数据包，这些资源包是被封装成冗余DIMS数据包。针对DRAP的情况，需要将DRAP所引用的所有资源包都下发，并且在封装时对包头中的标识位作如下修改：标识位I＝0，标识位D＝0。

214)、针对标识位D为0的冗余DIMS数据包的转换：D位为0，说明客户端需要保持在冗余处理状态，继续处理后续的冗余DIMS数据包。因此，在这种情况下，服务器端需要将后续所有标识位D为0的冗余DIMS数据包都转换为正常DIMS数据包，直至标识位D为1的冗余DIMS数据包，例如，通过修改标识位I＝0，标识位D＝0进行上述转换，并将转换后的正常DIMS数据包下发给客户端。

22)客户端处于第三状态中的正常状态，

客户端在该正常状态下可以处理任何类型的DIMS数据包。在这种情况下，服务器端不对其所需要下发的DIMS数据包进行修改，客户端的处理流程如下：

221)、客户端在正常播放场景流时，只处理正常DIMS数据包；

222)、客户端在进行VCR播放过程中，处理正常DIMS数据包和冗余DIMS数据包。

3、当客户端接收到DIMS数据包后，根据发起VCR操作时的场景时间、媒体时间及所进行的VCR操作类型计算场景呈现时间，并根据该场景呈现时间呈现接收到DIMS数据包。

结合上述的分析，下面分别说明各种不同的VCR操作下，例如，暂停/播放、跳转、快进/慢进、快退/慢退，客户端和服务器端的具体处理方法。

暂停/播放

在本发明实施例中，对富媒体流的暂停/播放的请求与响应可以通过实时流传输协议(RTSP)信令来实现。可包括如下处理：

1、用户通过客户端利用RTSP向服务器端发起对富媒体流的暂停请求信息；

2、服务器端接收到上述暂停请求信息后，利用RTSP反馈响应，如暂停请求响应，并暂停向客户端发送富媒体流数据；

3、客户端接收服务器端发送的暂停请求响应并暂停接收服务器端发送的富媒体流数据；

4、经过一段暂停后，用户通过客户端利用RTSP向服务器端发起播放请求信息，以继续播放所述被暂停的富媒体流数据；

5、服务器端接收到播放请求信息后，向客户端发送播放请求响应和相应的富媒体流数据；

6、客户端接收到富媒体流数据后，解析并呈现该富媒体流数据。

上述的暂停请求信息、播放请求信息都属于VCR操作请求信息。

上述的处理流程可适用于各种类型的富媒体流数据，如场景流、视频流和音频流中的一种或其任意组合。但对于场景流，其具有一些与视频流和音频流不同的技术特征。

例如，对DIMS场景流中各个元素的呈现都依赖于场景时间模型，而场景时间模型具有音视频时间所不具备的特点。音视频的正常播放时间(NPT)时间是指音视频流的当前播放时间与流起始时间的绝对差值，音视频的播放时间与其NPT时间是相等的。但场景呈现时间与其场景流的NPT时间可能是不相等的，因为在一个DIMS流中可以包含多个的以正常RAP包下发的场景(存在场景切换或场景刷新时)，而正常RAP包将场景时间置0。并且，处于不同状态的客户端只能接收与该状态相对应的场景流。

对于富媒体场景流，除上述操作之外还包括下文中描述的相关操作。

对于场景流，需要在客户端进行状态的转换，例如，当执行场景流的VCR操作时，客户端发送对场景流的暂停请求信息后进入VCR处理状态或保持在正常状态，相应的，服务器端向客户端下发场景流时，需要对该场景流进行相应的转换，参见上述的步骤(5)和步骤211)至步骤214)等的相关内容。用户通过客户端利用RTSP向服务器端发起播放请求信息，以继续播放所述被暂停的富媒体流数据后，客户端返回到正常状态。

对于场景流，暂停该场景流并重新播放时，需要获取当前的场景呈现时间。在本发明实施例中，可通过下式计算出场景呈现时间SceneTime(z)：

SceneTime(z)＝T_so+scale×[mediaTime(z)-mediaTime(y)]

其中，客户端在y点发送相应的VCR操作请求信息，客户端在z点接收到自发起该VCR操作请求信息起的首个DIMS数据包，T_so表示y点对应的场景时间，scale表示播放速度，mediaTime(z)表示z点对应的媒体时间，mediaTime(y)表示y点对应的媒体时间；

参见图4，客户端在x点暂停播放场景流，在y点发送播放请求信息以重新播放被暂停的场景流，在z点接收到自发起播放请求信息起的首个DIMS数据包，则用SceneTime(x)表示客户端最初发起暂停请求信息时的场景时间，用SceneTime(y)表示客户端发起播放请求信息时的场景时间，由于暂停后场景时间也会暂停，则SceneTime(x)和SceneTime(y)表示的场景时间相同，例如，都可表示为T_so。

在此，scale取值为1，表示场景流按正常速度播放。

mediaTime(z)指的是客户端收到自执行重新播放后的首个DIMS包的媒体时间，该媒体时间可以为RTP时间戳信息。mediaTime(y)是客户端发起重新播放时的媒体时间，该媒体时间可在服务器端反馈的响应中携带，如在上述播放请求响应中携带。

跳转

参见图5，具体包括如下处理：

1、客户端发送对富媒体流的跳转请求信息，并确定当前所处的状态，所述跳转请求信息携带用于指示跳转时间点的信息，所述跳转请求信息属于所述VCR操作请求信息；

富媒体流业务通常会包含场景、音频、视频三个流，若这三个流都需要进行跳转且三个流是同步的，客户端会利用RTSP同时发送三个跳转请求信息，如图5所示。但不局限于此，例如，客户端也可以通过一个跳转请求信息，实现三种流的跳转。

在三个跳转请求信息中的播放范围(PLAY Range)属性中，指示了发起跳转请求信息的正常播放时间(NPT)为S1。

2、服务器端解析所述跳转请求信息，当能够在所述跳转时间点实现相应跳转时，向客户端发送在该跳转时间点实现相应跳转所需的富媒体流数据；当不能在所述跳转时间点实现相应跳转时，获取新的跳转时间点，向客户端发送在新的跳转时间点实现相应跳转所需的富媒体流数据。

因为在客户端指示跳转时间点上，相应的富媒体流数据可能不存在用以实现相应跳转的关键帧，例如视频流中的I帧、场景流中的DIMS RAP，这时在客户端指示的跳转时间点将无法实现跳转。服务器端必需根据客户端的跳转请求信息，重新定位各个媒体流的新的跳转时间点，该新的跳转时间点是距离客户端指示的跳转时间点最近的且具有关键帧的时间点。

以场景流为例进行说明，服务器端根据客户端在跳转请求信息中指定的跳转时间点，判断这个跳转时间点上对应的DIMS数据包是否是包含完整场景描述的RAP。如果是RAP(包括正常RAP或者冗余RAP)，参见图6(a)，在跳转时间点1和2上都存在RAP，则服务器端直接把该跳转时间点及后续的DIMS数据包通过RTP的方式发送给客户端；如果该跳转时间点没有完整的场景描述，参见图6(b)，在跳转时间点1和2上都不存在RAP，服务器端就需要找到与该跳转时间点最邻近的RAP，如与跳转时间点1最邻近的是RAP1，与跳转时间点2最邻近的是RAP2，将分别将该RAP对应的时间点作为新的跳转时间点(因为客户端在只接收到场景更新信息的情况下是无法呈现完整场景的)，把新的跳转时间点及其后续DIMS数据包通过RTP的方式下发给客户端。

由于在客户端发起的跳转时间点上，相应的媒体流可能不存在关键帧(I帧或DIMS RAP)，而且不同媒体流关键帧的设置可能是没有时间相关性的。参见图5，服务器端修改携带在发送数据中的Range属性，在原有的请求时间点S1上增加一个时间的偏移量Δt1，Δt2，Δt3(三个时间可以相等，也可以不等)，分别对应于场景流、视频流、音频流在S1基础上的偏移。

服务器端还需根据客户端所处的状态对DIMS数据包进行转换，具体方法参见上述相关内容，在此不再赘述。

3、客户端接收服务器端发送的对应于客户端指示的跳转时间点的实现场景跳转所需的富媒体流数据。客户端解析所述富媒体流数据并呈现所述富媒体流数据，然后返回正常状态。

其中，对于场景流，客户端需要获取当前的场景呈现时间。由于场景流的跳转是通过正常/冗余RAP实现的，因此跳转后的场景呈现时间是0(对正常RAP)，或者是冗余RAP中currentSceneTime属性的值，即场景呈现时间可以表示如下：

SceneTime(RAP_normal)＝0

SceneTime(RAP_redundant)＝currentSceneTime

下面以场景流、视频流和音频流三种媒体流为例，说明客户端对媒体流的呈现方法，但不限于此，可以为任一种媒体流，或这三种媒体流的任意组合，或其他需要处理的媒体流。

客户端根据场景流、视频流和音频流的呈现关系，对三种媒体流进行呈现。

当三种媒体流是同步的且同步关系是锁死(Locked)时，客户端将接收到的三种媒体流解析完毕后，同时开始呈现；

当三种媒体流是同步的且同步关系是可以滑动(CanSlip)时，对三种媒体流的呈现不是同时开始的，以第一个解析并进行呈现的媒体流为基准，将后续解析并进行呈现的每个媒体流与第一个媒体流进行同步，最终达到三种媒体流同步的效果。例如，当在第一个媒体流播放至时间点T时，开始呈现第二个媒体流，则即将呈现的第二个媒体流需要与时间点T的第一个媒体流保持同步。

当三种媒体流是独立(Independent)时，各个媒体流相对独立，不需保持同步，则分别解析并呈现三种媒体流。

快进/慢进

下面分别在客户端发送VCR操作请求信息后处于VCR处理状态和客户端发送VCR操作请求信息后保持在正常状态的两种情况下，说明本发明实施例提供的快进/慢进操作。

情况一：客户端处于VCR处理状态

参见图7，具体包括如下处理：

1、客户端发送对富媒体流的快进/慢进请求信息，所述快进/慢进请求信息指示对富媒体流的第一播放速度(PlAY Scale)为V1，在本示例中，以场景流和视频流为例进行说明，即此时客户端可通过发送两个快进/慢进请求信息，实现对场景流和视频流的快进或慢进。客户端进入VCR处理状态，在该状态下客户端只能处理冗余DIMS数据包和正常RAP。

2、服务器端根据客户端请求的播放速率、场景特点，以服务器端可接受的第二播放速度V2发送视频流和场景流。所述第一播放速度和第二播放速度可以相同，或者不同。

对场景流，在发送过程中将所有的DIMS数据包设置成冗余DIMS数据包，其中，对正常RAP可无需进行转换。并且，服务器可以采用相应的操作以在后续过程中通过客户端进行状态的切换，例如，服务器端通过包头中的标识位D来通知客户端进行状态的切换，在此，服务器将DIMS数据包的包头中的标识位D设置为0。

图7中的流程显示了场景流与音视频流有同步关系的情况(同步属性可为locked或canSlip)，客户端发起快/慢进请求的第一播放速度(V1)在服务器端可能不支持，所以服务器端要根据自身的实际能力反馈一个合适的第二播放速度(V2)，这时，第一播放速度和第二播放速度不同。

可选的，可提前在客户端对快/慢进请求的播放速率进行设置，使客户端发起的第一播放速度在服务器可承受的范围之内，服务器无需再对播放速度进行调整，这时，第一播放速度和第二播放速度相同。

对于场景流，服务器可根据场景流的如下两个特点，采用不同的场景流下发策略，以提高用户的业务体验。

(1)场景大小：在场景流快进播放操作中，服务器连续加速下发RAP情况时，由于每一个RAP都是一个完整的场景描述，RAP的大小与场景大小密切相关。如果场景本身比较大，连续加速下发的RAP会使DIMS场景流出现一系列峰值。为了解决这个问题，可以采用DRAP的机制，通过多个DIMS数据包传送整个场景来提供随机接入点，减少带宽的峰值，平滑带宽。而在场景本身比较小的情况下，不会对服务器负荷产生很大影响，可以直接加速发送RAP。

(2)更新频率：在场景变化比较慢，即更新频率比较低的情况下，服务器可以加速下发更新来实现场景的快进。但在场景变化非常快，即更新比较频繁时，如果加速下发更新，势必增加服务器负荷。并且更新序列中有可能更新存在一些逆操作(例如：同一个元素的insert和delete之间时间间隔非常短)，在这种情况下，服务器加速下发连续的RAP更能节省带宽，提高用户体验。

在场景流慢进过程中，由于相比正常播放状态，服务器单位时间内需要下发的数据量减少，对服务器的带宽需求和负荷相应减小，因此可以采用减速下发更新的方式来实现。并且，当场景比较小时，可直接减速发送RAP，当场景比较大时，也可采用DRAP机制。

由上所述，在本发明实施例中，实现场景流的快进、慢进操作时，可采用如下表所示的下发策略：

表2

表中的“/”表示在该情况下不需考虑更新频率或场景大小的因素。

对于快进操作：

当更新频率较密、场景较大时，根据快进/慢进请求信息，以第二播放速度向客户端加速发送分布式随机接入点；或者，

当更新频率较密、场景较小时，根据快进/慢进请求信息，以第二播放速度向客户端加速发送随机接入点(包括正常RAP和冗余RAP)；或者，

当更新频率较疏时，根据快进/慢进请求信息，以第二播放速度向客户端发送加速发送场景更新；

示例性的，在快进操作中，第一富媒体场景流数据对应于第一更新频率和第一场景；第二富媒体场景流数据对应于第二更新频率和第二场景，则可以进行如下处理：

当第一富媒体场景流数据对应的第一更新频率较密、场景较大，而第二富媒体场景流数据对应的第二更新频率较密、场景较小时，即当第一更新频率大于第二更新频率时(该比较步骤不是必须的)，根据快进/慢进请求信息，以第二播放速度向客户端发送第一富媒体场景流数据或者第二富媒体场景流数据，所述第一富媒体场景流数据为DRAP，所述第二富媒体场景流数据为RAP。

当第一富媒体场景流数据对应的第一更新频率较密，而第二富媒体场景流数据对应的第二更新频率较疏时，根据快进/慢进请求信息，以第二播放速度向客户端发送第二富媒体场景流数据，该第二富媒体场景流数据场景更新；

对于慢进操作：

可根据快进/慢进请求信息，以第二播放速度向客户端发送减速发送场景更新；或者，

当场景较大时，根据快进/慢进请求信息，以第二播放速度向客户端减速发送分布式随机接入点；或者，

当场景较小时，根据快进/慢进请求信息，以第二播放速度向客户端减速发送随机接入点。

示例性的，在慢进操作中，第一富媒体场景流数据对应于第一场景；第二富媒体场景流数据对应于第二场景，则可以进行如下处理：

根据快进/慢进请求信息，以第二播放速度向客户端发送场景更新；或者，

当第一场景大于第二场景时(该比较步骤不是必须的)，根据快进/慢进请求信息，以第二播放速度向客户端发送第一富媒体场景流数据或者第二富媒体场景流数据，所述第一富媒体场景流数据为分布式随机接入点，所述第二富媒体场景流数据为随机接入点景。

3、客户端接收服务器端以第二播放速度V2发送的富媒体流数据并以第二播放速度V2进行呈现。

对于场景流，客户端需要计算场景呈现时间，如图8所示，客户端可通过下式计算场景呈现时间SceneTime(z)：

SceneTime(x)＝T_so

SceneTime(z)＝T_so+scale×[mediaTime(z)-mediaTime(x)]

其中，客户端在x点发送快进/慢进请求信息，客户端在z点接收到自发起该快进/慢进请求信息起的首个DIMS数据包，T_so表示x点对应的场景时间，scale表示播放速度，mediaTime(z)表示z点对应的媒体时间，mediaTime(x)表示x点对应的媒体时间；

其中，scale是客户端的播放速度，在快进/慢进操作下，它的值是正数。当scale在(0，1)区间时表示慢进，当scale＞1时表示快进，当scale＝1时表示正常速度播放。

4、客户端发起正常播放请求，以正常速度播放场景流和视频流。

5、服务器端根据所述正常播放请求，结束快进/慢进操作，并以正常速度向客户端发送相应的数据。

对于场景流，服务器端在结束快进/慢进操作时，会通知客户端进行状态的切换。

51)服务器端接收到所述正常播放请求后，立即发送最后一个冗余DIMS场景更新包(如果该时刻没有场景更新，则发送一个空DIMS数据包)，将包头中标识位D设置为1。

52)客户端收到D位为1的冗余DIMS数据包，解析呈现，并跳转至正常状态，开始处理正常DIMS数据包。

6、服务器端以正常速度发送正常DIMS数据和视频流数据。

7、客户端以正常速度播放场景流数据和视频流数据。

情况二：客户端保持在第二状态中的正常状态

这种情况下，服务器端可通过只下发关键帧的方法，进行快进/慢进，如对场景流只下发RAP，对视频流，只下发I帧。参见图9，具体包括如下处理：

1、客户端发送对富媒体流的快进/慢进请求信息，所述快进/慢进请求信息指示对富媒体流的第一播放速度(PlAY Scale)为V1，在本示例中，以场景流和视频流为例进行说明，即此时客户端可通过发送两个快进/慢进请求信息，实现对场景流和视频流的快进或慢进。客户端保持正常状态，在该正常状态下客户端只能处理正常DIMS数据包。

2、服务器端根据客户端请求的播放速率、场景特点，以服务器端可接受的第二播放速度V2发送视频流的I帧和场景流的DIMS RAP。所述第一播放速度和第二播放速度可以相同，或者不同。

对场景流，在发送过程中将所有的DIMS RAP设置成正常RAP，其中，对于冗余RAP向正常RAP的转换参见上述的步骤212)，这时客户端需要支持上述转换后的正常RAP具有的currentSceneTime属性。

对于场景流，客户端需要获取场景呈现时间，在该情况下，场景呈现时间是通过RAP信息来获取的：

客户端根据服务器端下发的正常RAP获取场景呈现时间，当该正常RAP是未经过服务器端转换的原始正常RAP时，

场景呈现时间SceneTime(z)＝0；

当该正常RAP是经过服务器端转换而得到的正常RAP时：

场景呈现时间SceneTime(z)＝currentSceneTime。

6、客户端以正常速度播放场景流数据和视频流数据。

情况三：客户端保持在第三状态中的正常状态

此情况下的处理方法和情况二中的大体一致，对于场景流同样是通过只发送RAP信息来实现用户请求的快进/慢进VCR操作。与情况二相比的主要不同点在于，客户端在正常状态下具备同时处理正常DIMS包和冗余DIMS包的能力，因此服务器端在下发RAP信息时，只需要根据用户的请求调整下发速率即可，不需要把冗余RAP转换成正常RAP。

快退/慢退

当客户端处于VCR处理状态下的快退/慢退操作参见图10。其中，对于场景流的快退/慢退，通过倒序播放关键帧RAP的方法来实现。

1、客户端发起快退/慢退请求信息，指示以第三播放速度V3进行快退/慢退并进入VCR处理状态。在本示例中，以场景流和视频流为例进行说明，即此时客户端可通过发送两个快退/慢退请求信息，实现对场景流和视频流的快进或慢进。客户端进入VCR处理状态，在该状态下客户端只能处理冗余DIMS数据包和正常RAP。

2、服务器端根据客户端请求的播放速率、场景特点，以服务器端可接受的第四播放速度V4发送视频流以及倒序播放场景流(RAP)。所述第三播放速度和第四播放速度可以相同，或者不同。

对场景流，在发送过程中将所有的RAP设置成冗余RAP(包括DRAP)，其中，对正常RAP可无需进行转换。并且，服务器端可以采用相应的操作以在后续过程中通过客户端进行状态的切换，例如，服务器端通过包头中的标识位D来通知客户端进行状态的切换，在此，服务器端将RAP的包头中的标识位D设置为0。

对快退/慢退中，根据场景的大小，服务器端可以分别采用DRAP或者RAP的形式下加速/减速下发场景数据。下发策略的选择如下表所示：

表3

3、客户端收到以速度V4发送的冗余RAP/DRAP，计算场景时间，并呈现场景(静止)，并倒序播放视频。

5、服务器端根据所述正常播放请求，结束快退/慢退操作。

51)服务器端接收到所述正常播放请求后，如果当前所发送的冗余RAP/DRAP所引用的资源包尚未发送完，则需要加速将其发送完毕，并将最后一个DIMS包的包头中的标识位D位设置为1。

52)客户端收到D位为1的冗余DIMS数据包，解析呈现，并跳转至正常状态。

6、服务器端以正常速度向客户端发送富媒体流数据。

7、客户端以正常速度播放场景流数据和视频流数据。

当客户端处于第二状态中的正常状态下时，操作的方法与上述基本相同，主要区别在于服务器端在下发RAP时，需要把冗余RAP/DRAP转换成正常RAP。

当客户端处于第三状态中的正常状态下时，操作的方法与上述基本相同，主要区别在于服务器端在下发RAP时，不需要进行冗余包与正常包之间的转换。

由上所述，本发明方法实施例提供的技术方案，当客户端需要针对富媒体流进行VCR操作时，向服务器端发送VCR操作请求信息并确定当前自身所述的状态，服务器端根据该VCR操作请求信息向客户端发送相应的富媒体流数据，客户端解析接收到的富媒体流数据并呈现所述富媒体流数据。本发明实施例提供的技术方案独创了一整套针对富媒体流数据的VCR操作控制技术，能够实现对富媒体流数据的VCR操作，满足了用户的需要，增强了用户体验，具有较高的实用性和较广的应用前景。

本发明实施例四还提供了一种网络服务器11，如图11所示，包括：

接收单元111，用于接收客户端发送的对富媒体流的VCR操作请求信息；

发送单元112，用于根据客户端当前所处的状态和所述接收单元接收到的VCR操作请求信息向客户端发送相应的富媒体流数据。

进一步的，上述网络服务器11还包括：

转换单元，用于根据客户端所处的状态，转换相应的富媒体场景流数据的格式，所述富媒体流包括下述的至少一种或其组合：场景流、视频流和音频流；

所述发送单元112，还用于将所述转换单元转换后的富媒体场景流数据，向所述客户端发送。

其中，所述接收单元111包括第一接收模块和第二接收模块，所述发送单元112包括第一发送模块和第二发送模块，

所述第一接收模块，用于接收客户端发送的对富媒体流的暂停请求信息；所述第一发送模块，用于向客户端发送暂停请求响应并暂停向客户端发送富媒体流数据；所述第二接收模块，用于接收客户端发送的对富媒体流的播放请求信息，以继续播放所述被暂停的富媒体流数据；所述第二发送模块，用于向客户端发送播放请求响应并向客户端发送相应的富媒体流数据；

其中，所述暂停请求信息和播放请求信息属于所述VCR操作请求信息。

或者，

所述接收单元111包括第三接收模块，所述发送单元112包括解析模块，

所述第三接收模块，用于接收客户端发送的对富媒体流的跳转请求信息，所述跳转请求信息携带用于指示跳转时间点的信息，所述跳转请求信息属于所述VCR操作请求信息；所述解析模块，用于解析所述跳转请求信息，当能够在所述跳转时间点实现相应跳转时，向客户端发送在该跳转时间点实现相应跳转所需的富媒体流数据；当不能在所述跳转时间点实现相应跳转时，获取新的跳转时间点，向客户端发送在新的跳转时间点实现相应跳转所需的富媒体流数据。

或者，

所述接收单元111包括第四接收模块和第五接收模块，所述发送单元112包括第四发送模块和第五发送模块，

所述第四接收模块，用于接收客户端发送的对富媒体流的快进/慢进请求信息，所述快进/慢进请求信息指示对富媒体流的第一播放速度；或者，用于接收客户端发送的对富媒体流的快退/慢退请求信息，所述快退/慢退请求信息指示对富媒体流的第三播放速度；

所述第四发送模块，用于根据所述快进/慢进请求信息，以第二播放速度向客户端发送相应的富媒体流数据；或者，用于根据所述快退/慢退请求信息，以第四播放速度向客户端倒序发送相应的富媒体流数据；

所述第五接收模块，用于接收客户端发送的正常播放请求信息；

所述第五发送模块，用于根据所述正常播放请求，结束快进/慢进操作，并以正常速度向客户端发送相应的数据；或者，根据所述正常播放请求，结束快退/慢退操作，并以正常速度向客户端发送相应的数据；

其中，所述快进/慢进请求信息、快退/慢退请求信息和正常播放请求信息属于VCR操作请求信息。

进一步的，所述发送单元还用于根据更新频率和场景大小确定场景流下发策略；按照所述场景流下发策略，根据客户端当前所处的状态和所述VCR操作请求信息向客户端发送相应的富媒体流数据。

由上所述，本发明实施例提供的网络服务器，当客户端需要针对富媒体流进行VCR操作时，向网络服务器发送VCR操作请求信息并确定当前自身所述的状态，网络服务器根据该VCR操作请求信息向客户端发送相应的富媒体流数据，客户端解析接收到的富媒体流数据并呈现所述富媒体流数据。本发明实施例提供的技术方案独创了一整套针对富媒体流数据的VCR操作控制技术，能够实现对富媒体流数据的VCR操作，满足了用户的需要，增强了用户体验，具有较高的实用性和较广的应用前景。

本发明实施例五还提供了一种客户端设备12，其特征在于，包括：

发送单元121，用于向服务器端发送对富媒体流的VCR操作请求信息并确定当前所处的状态；

接收单元122，用于在所述状态下，接收服务器端根据所述VCR操作请求信息发送的相应的富媒体流数据；

解析呈现单元123，用于解析并呈现所述富媒体流数据。

进一步的，上述客户端设备12还包括获知单元，用于获知富媒体场景流数据对应的场景呈现时间，所述富媒体流包括下述的至少一种或其组合：场景流、视频流和音频流；

所述发送单元，还用于向服务器端发送对富媒体场景流的VCR操作请求信息并确定当前所处的状态；

所述接收单元，还用于在所述状态下，接收服务器端根据所述VCR操作请求信息发送的相应的富媒体场景流数据；

所述解析呈现单元，还用于解析所述接收单元接收到的富媒体场景流数据并根据所述获知单元获知到的场景呈现时间呈现所述富媒体场景流数据。

其中，所述获知单元根据如下方式获知所述富媒体场景流数据对应的场景呈现时间：

通过如下公式计算得到所述场景呈现时间SceneTime(z)：

SceneTime(z)＝T_so+scale×[mediaTime(z)-mediaTime(y)]

其中，客户端在y点发送相应的VCR操作请求信息，客户端在z点接收到自发起该VCR操作请求信息起的首个DIMS数据包，T_so表示y点对应的场景时间，scale表示播放速度，mediaTime(z)表示z点对应的媒体时间，mediaTime(y)表示y点对应的媒体时间；或者，

将接收到的冗余富媒体场景流数据中携带的场景时间作为所述场景呈现时间；或者，

确定所述场景呈现时间为零。

本发明装置实施例中各功能模块的具体工作方法参见本发明的方法实施例。

由上所述，本发明实施例提供的客户端设备，当需要针对富媒体流进行VCR操作时，向服务器端发送VCR操作请求信息并确定当前自身所述的状态，服务器端根据该VCR操作请求信息向客户端发送相应的富媒体流数据，客户端设备解析接收到的富媒体流数据并呈现所述富媒体流数据。本发明实施例提供的技术方案独创了一整套针对富媒体流数据的VCR操作控制技术，能够实现对富媒体流数据的VCR操作，满足了用户的需要，增强了用户体验，具有较高的实用性和较广的应用前景。

本发明实施例还提供了一种富媒体流的点播系统，如图13所示，包括服务器端131和客户端端132。

所述服务器端131，用于接收客户端发送的对富媒体流的VCR操作请求信息；根据客户端当前所处的状态和所述VCR操作请求信息向客户端发送相应的富媒体流数据；

所述客户端132，用于向服务器端发送对富媒体流的VCR操作请求信息并确定当前所处的状态；在所述状态下，接收服务器端根据所述VCR操作请求信息发送的相应的富媒体流数据；解析并呈现所述富媒体流数据。

其中，所述服务器端131还用于根据客户端所处的状态，转换相应的富媒体场景流数据的格式，并向所述客户端发送格式转换后的所述相应的富媒体场景流数据。并且，所述服务器端还可用于根据更新频率和场景大小确定场景流下发策略。

其中，上述客户端可以处于三种状态下，当客户端在所述第一状态下，能够接收服务器端发送的冗余富媒体场景流数据和特定的正常富媒体场景流数据；当客户端在所述第二状态下，只能接收服务器端发送的所有正常富媒体场景流数据；当客户端在所述第三状态下，能够接收服务器端发送的所有富媒体场景流数据。

客户端根据如下方式获知所述富媒体场景流数据对应的场景呈现时间：

客户端通过如下公式计算得到所述场景呈现时间SceneTime(z)：

SceneTime(z)＝T_so+scale×[mediaTime(z)-mediaTime(y)]

其中，客户端在y点发送相应的VCR操作请求信息，客户端在z点接收到自发起该VCR操作请求信息起的首个富媒体场景流数据包，T_so表示y点对应的场景时间，scale表示播放速度，mediaTime(z)表示z点对应的媒体时间，mediaTime(y)表示y点对应的媒体时间；或者，客户端将接收到的富媒体场景流数据中携带的场景时间作为所述场景呈现时间；或者，客户端确定所述场景呈现时间为零。

本发明系统实施例中各个设备的具体工作方法参见本发明的方法实施例。

由上所述，本发明实施例提供的技术方案，当客户端需要针对富媒体流进行VCR操作时，向服务器端发送VCR操作请求信息，服务器端根据该VCR操作请求信息向客户端发送相应的富媒体流数据，客户端解析接收到的富媒体流数据并呈现所述富媒体流数据。本发明实施例提供的技术方案独创了一整套针对富媒体流数据的VCR操作控制技术，能够实现对富媒体流数据的VCR操作，满足了用户的需要，增强了用户体验，具有较高的实用性和较广的应用前景。

本领域的技术人员可以清楚地了解到本发明可借助软件加必需的通用硬件平台的方式来实现。基于这样的理解，本发明的技术方案本质上或者说对现有技术做出贡献的部分可以软件产品的形式体现出来，该计算机软件产品可以存储在存储介质中，如ROM/RAM、磁碟、光盘等，包括若干指令用以使得一台计算机设备(可以是个人计算机，服务器，或者网络设备等)执行本发明各个实施例或者实施例的某些部分所述的方法。

以上所述，仅为本发明的具体实施方式，但本发明的保护范围并不局限于此，任何熟悉本技术领域的技术人员在本发明揭露的技术范围内，可轻易想到变化或替换，都应涵盖在本发明的保护范围之内。因此，本发明的保护范围应以权利要求的保护范围为准。

Claims

1.一种富媒体流点播业务中实现盒式录像机VCR操作的方法，其特征在于，所述方法包括：

服务器端接收客户端发送的对富媒体流的VCR操作请求信息；

2.根据权利要求1所述的富媒体流点播业务中实现盒式录像机VCR操作的方法，其特征在于，所述服务器端根据客户端当前所处的状态和所述VCR操作请求信息向客户端发送相应的富媒体流数据还包括：

服务器端根据客户端所处的状态，转换相应的富媒体场景流数据的格式，所述富媒体流包括下述的至少一种或其组合：场景流、视频流和音频流；

服务器端向所述客户端发送格式转换后的所述相应的富媒体场景流数据。

3.根据权利要求2所述的富媒体流点播业务中实现盒式录像机VCR操作的方法，其特征在于，所述服务器端根据客户端所处的状态，转换相应的富媒体场景流数据的格式具体包括：

当客户端处于第一状态时，服务器端将正常富媒体场景流数据转换为冗余富媒体场景流数据；或者，

当客户端处于第二状态时，服务器端将冗余富媒体场景流数据转换为正常富媒体场景流数据；

其中，所述冗余富媒体场景流数据包括分布式随机接入点，在所述第一状态下，客户端能够接收冗余富媒体场景流数据和特定的正常富媒体场景流数据；在所述第二状态下，客户端只能接收所有正常富媒体场景流数据。

4.根据权利要求1或2所述的富媒体流点播业务中实现盒式录像机VCR操作的方法，其特征在于，所述方法具体包括：

服务器端接收客户端发送的对富媒体流的暂停请求信息；服务器端向客户端发送暂停请求响应并暂停向客户端发送富媒体流数据；服务器端接收客户端发送的对富媒体流的播放请求信息；服务器端向客户端发送播放请求响应并向客户端发送相应的富媒体流数据；

或者，

服务器端接收客户端发送的对富媒体流的跳转请求信息，所述跳转请求信息携带用于指示跳转时间点的信息；服务器端解析所述跳转请求信息，当能够在所述跳转时间点实现相应跳转时，服务器端向客户端发送在该跳转时间点实现相应跳转所需的富媒体流数据；当不能在所述跳转时间点实现相应跳转时，获取新的跳转时间点，服务器端向客户端发送在新的跳转时间点实现相应跳转所需的富媒体流数据，其中，对于富媒体场景流，服务器端将距离所述客户端指示的跳转时间点最近的随机接入点对应的时间点作为所述新的跳转时间点；

其中，所述暂停请求信息、播放请求信息和跳转请求信息属于所述VCR操作请求信息。

5.根据权利要求1或2所述的富媒体流点播业务中实现盒式录像机VCR操作的方法，其特征在于，所述方法具体包括：

服务器端接收客户端发送的对富媒体流的快进/慢进请求信息，所述快进/慢进请求信息指示对富媒体流的第一播放速度；服务器端根据所述第一播放速度和自身能力确定第二播放速度，以所述第二播放速度向客户端发送相应的富媒体流数据；

服务器端接收客户端发送的正常播放请求信息；

服务器端根据所述正常播放请求，结束快进/慢进操作，并以正常速度向客户端发送相应的数据；

其中，所述快进/慢进请求信息和正常播放请求信息属于VCR操作请求信息。

6.根据权利要求5所述的富媒体流点播业务中实现盒式录像机VCR操作的方法，其特征在于，所述方法还包括：

服务器端根据更新频率和场景大小确定场景流下发策略。

7.根据权利要求5所述的富媒体流点播业务中实现盒式录像机VCR操作的方法，其特征在于，根据所述正常播放请求，结束快进/慢进操作包括：

服务器端接收到所述正常播放请求后，将最后一个向客户端发送的富媒体场景流数据包的包头中的标识位D置为1，以通知客户端进行状态的切换；

其中，所述富媒体场景流数据包为动态交互多媒体场景DIMS数据包。

8.根据权利要求1或2所述的富媒体流点播业务中实现盒式录像机VCR操作的方法，其特征在于，所述方法具体包括：

服务器端接收客户端发送的对富媒体流的快退/慢退请求信息，所述快退/慢退请求信息指示对富媒体流的第三播放速度，所述快退/慢退请求信息属于VCR操作请求信息；

服务器端根据所述第三播放速度和自身能力确定第四播放速度，以第四播放速度向客户端倒序发送相应的富媒体流数据；

服务器端接收客户端发送的正常播放请求信息；

服务器端根据所述正常播放请求，结束快退/慢退操作，并以正常速度向客户端发送相应的数据。

9.根据权利要求8所述的富媒体流点播业务中实现盒式录像机VCR操作的方法，其特征在于，所述以第四播放速度向客户端倒序发送相应的富媒体流数据具体包括：

服务器端根据场景大小以第四播放速度向客户端发送富媒体场景流数据，所述富媒体场景流数据为分布式随机接入点或随机接入点。

10.一种富媒体流点播业务中实现盒式录像机VCR操作的方法，其特征在于，所述方法包括：

客户端向服务器端发送对富媒体流的VCR操作请求信息并确定当前所处的状态；

客户端在所述状态下，接收服务器端根据所述VCR操作请求信息发送的相应的富媒体流数据；

客户端解析并呈现所述富媒体流数据。

11.根据权利要求10所述的富媒体流点播业务中实现盒式录像机VCR操作的方法，其特征在于，所述方法具体包括：

客户端向服务器端发送对富媒体场景流的VCR操作请求信息并确定当前所处的状态，所述富媒体流包括下述的至少一种或其组合：场景流、视频流和音频流；

客户端在所述状态下，接收服务器端根据所述VCR操作请求信息发送的相应的富媒体场景流数据；

客户端获知所述富媒体场景流数据对应的场景呈现时间；

客户端解析所述富媒体场景流数据并根据所述场景呈现时间呈现所述富媒体场景流数据。

12.根据权利要求10或11所述的富媒体流点播业务中实现盒式录像机VCR操作的方法，其特征在于，所述状态包括第一状态、第二状态和第三状态，

客户端在所述第一状态下，能够接收服务器端发送的冗余富媒体场景流数据和特定的正常富媒体场景流数据；

客户端在所述第二状态下，只能接收服务器端发送的所有正常富媒体场景流数据；

客户端在所述第三状态下，能够接收服务器端发送的所有富媒体场景流数据。

13.根据权利要求10或11所述的富媒体流点播业务中实现盒式录像机VCR操作的方法，其特征在于，客户端根据如下方式获知所述富媒体场景流数据对应的场景呈现时间：

客户端通过如下公式计算得到所述场景呈现时间SceneTime(z)：

SceneTime(z)＝T_so+scale×[mediaTime(z)-mediaTime(y)]

其中，客户端在y点发送相应的VCR操作请求信息，客户端在z点接收到自发起该VCR操作请求信息起的首个富媒体场景流数据包，T_so表示y点对应的场景时间，scale表示播放速度，mediaTime(z)表示z点对应的媒体时间，mediaTime(y)表示y点对应的媒体时间；或者，

客户端将接收到的富媒体场景流数据中携带的场景时间作为所述场景呈现时间；或者，

客户端确定所述场景呈现时间为零。

14.一种网络服务器，其特征在于，包括：

15.根据权利要求14所述的网络服务器，其特征在于，还包括：

所述发送单元，还用于将所述转换单元转换后的富媒体场景流数据，向所述客户端发送。

16.根据权利要求14所述的网络服务器，其特征在于，

所述接收单元包括第一接收模块和第二接收模块，所述发送单元包括第一发送模块和第二发送模块，

或者，

所述接收单元包括第三接收模块，所述发送单元包括解析模块，

所述第三接收模块，用于接收客户端发送的对富媒体流的跳转请求信息，所述跳转请求信息携带用于指示跳转时间点的信息，所述跳转请求信息属于所述VCR操作请求信息；所述解析模块，用于解析所述跳转请求信息，当能够在所述跳转时间点实现相应跳转时，向客户端发送在该跳转时间点实现相应跳转所需的富媒体流数据；当不能在所述跳转时间点实现相应跳转时，获取新的跳转时间点，向客户端发送在新的跳转时间点实现相应跳转所需的富媒体流数据，其中，对于富媒体场景流，将距离所述客户端指示的跳转时间点最近的随机接入点对应的时间点作为所述新的跳转时间点；

17.根据权利要求14所述的网络服务器，其特征在于，所述接收单元包括第四接收模块和第五接收模块，所述发送单元包括第四发送模块和第五发送模块，

18.根据权利要求17所述的网络服务器，其特征在于，所述发送单元还用于根据更新频率和场景大小确定场景流下发策略；按照所述场景流下发策略，根据客户端当前所处的状态和所述VCR操作请求信息向客户端发送相应的富媒体流数据。

19.一种客户端设备，其特征在于，包括：

解析呈现单元，用于解析并呈现所述富媒体流数据。

20.根据权利要求19所述的客户端设备，其特征在于，还包括获知单元，用于获知富媒体场景流数据对应的场景呈现时间，所述富媒体流包括下述的至少一种或其组合：场景流、视频流和音频流；

21.根据权利要求20所述的客户端设备，其特征在于，所述获知单元根据如下方式获知所述富媒体场景流数据对应的场景呈现时间：

通过如下公式计算得到所述场景呈现时间SceneTime(z)：

SceneTime(z)＝T_so+scale×[mediaTime(z)-mediaTime(y)]

将接收到的富媒体场景流数据中携带的场景时间作为所述场景呈现时间；或者，

确定所述场景呈现时间为零。

22.一种富媒体流的点播系统，其特征在于，所述系统包括服务器端和客户端，其中，

所述服务器端，用于接收客户端发送的对富媒体流的VCR操作请求信息；根据客户端当前所处的状态和所述VCR操作请求信息向客户端发送相应的富媒体流数据；

所述客户端，用于向服务器端发送对富媒体流的VCR操作请求信息并确定当前所处的状态；在所述状态下，接收服务器端根据所述VCR操作请求信息发送的相应的富媒体流数据；解析并呈现所述富媒体流数据。