一种实现流业务的方法及通信系统以及相关设备的制作方法

专利名称：一种实现流业务的方法及通信系统以及相关设备的制作方法
技术领域：
本发明涉及通讯领域，尤其涉及一种实现流业务的方法及通信系统以及相关设备。
背景技术：
随着组播技术的发展，在点到多点的媒体流传输系统中，常常采用组播技术传输 媒体流，例如在互联网协议电视(IPTV，Internet Protocol Television)，网络电视、移动 电视、数字电视(DTV，Digital Television)等媒体业务中都广泛的使用了组播技术。用户体验(QoE,Quality of Experience)是从普通用户体验的角度出发来评价一 种服务的质量，在IPTV服务当中，组播间切换的速度是影响QoE的一个重要指标，切换的时 间是从用户发出组播切换指令到用户观看到新的组播节目之间的时间。为了减少接收端在 不同组播之间切换的时延，可以采用快速切换或者称为快速获取组播的方法，在该方法中， 接收端先接收单播流(一般为快发的单播流)，一段时间之后，如当单播流有效载荷与组播 流有效载荷即将相同时或者单播流追上组播流时，接收端加入组播组，接收组播数据。在整个过程中，服务器提供的单播流应当满足如下的条件(1)、单播流需从关键信息(Key Information)处如图片组(G0P，Groupof Picture)起始处开始发送，这样才能使得接收端可以处理组播源端发送的数据。(2)、单播流结束后，接收端缓存的数据应该大于等于第一缓存要求(如最小缓存 要求)。第一缓存要求可能与应用有关，比如单播流结束后，需要进行前向纠错或重传。具体请参阅图1，图1为单播流起始点选择示意图，tc和td为两个接收端不同的 请求时刻点，服务器收到频道切换请求后为了使接收端收到视频数据后能进行解码，单播 流需要从GOP的起始处开始发送。对于tc时刻的请求，如果服务器从最近的GOP b起始点 tb处开始发送第一数据流，则无法满足第一缓存要求，所以起始点需要提前至GOP a的起 始处开始发送；对于td时刻的请求，因为tb至td之间的数据可以满足第一缓存要求，所以 服务器可以从GOP b的起始处开始发送。这样对于tc时刻的请求，单播流与组播流之间的 时移为(tc-ta)，对于td时刻的请求，单播流与组播流之间的时移就为(td-tb)，而(tc-ta) > (td-tb)，因此这两个接收端看到的同一组播频道节目是不同步的，而服务器给这两个接 收端发送的数据量和提供服务的时间长度也是不同的。由上可知，服务器收到组播切换请求后，如果从最近的媒体数据的随机接入点处 发送单播流无法满足最小缓存要求，则需要提前一个或几个媒体数据的随机接入点开始发 送，限制了服务器向接收端发送数据的灵活性。在这个过程中，接收端加入组播组的时间是由服务器通知的，当该通知消息丢失 后接收端无法确定加入组播组的时间，一段时间后，接收端就会没有数据可以播放；如果服 务器下发的更新的加入组播时间消息丢失，接收端就会过早或者过晚加入组播组，导致双 流问题或者单播流无法追赶上组播流。
发明内容
本发明实施例提供了一种实现流业务的方法及通信系统以及相关设备，能够提高 数据发送的灵活性。本发明实施例提供的实现流业务的方法，包括服务器确定响应消息，所述响应消 息中包括第一数据流与第二数据流之间的间隔、或第二数据流最新数据信息、或第一数据 流速率转变点信息中的至少一个；所述服务器向所述接收端发送第一数据流以及所述响应 消息，以使所述接收端根据所述响应消息进行相应的操作。本发明实施例提供的实现流业务的方法，包括接收端接收来自服务器的响应消 息，所述响应消息中包括第一数据流与第二数据流之间的间隔，或第二数据流的最新数据 信息，或第一数据流速率转变点信息中的至少一种；所述接收端根据所述响应消息执行相 应的操作。本发明实施例提供的实现流业务的方法，包括服务器接收来自接收端的消息，所 述消息中包括所述接收端的数据处理能力信息；所述服务器根据所述数据处理能力信息确 定响应消息，所述响应消息包括第一数据流与第二数据流之间的间隔、或第二数据流最新 数据信息、或第一数据流追上第二数据流需要的时间、或第一数据流速率转变点信息中的 至少一种；所述服务器将第一数据流以及所述响应消息发送给所述接收端，以使所述接收 端根据所述响应消息进行数据处理。本发明实施例提供的实现流业务的方法，包括服务器确定第一消息，所述第一消 息包括第一数据流与第二数据流之间的间隔、或第二数据流最新数据信息、或第一数据流 追上第二数据流需要的时间、或第一数据流速率转变点信息中的至少一种；所述服务器将 第一数据流以及所述第一消息发送给所述接收端，以使所述接收端根据所述第一消息进行 数据处理。本发明实施例提供的通信系统，包括服务器，用于确定响应消息，所述响应消息 包括第一数据流与第二数据流之间的间隔，或第二数据流最新数据信息，或第一数据流速 率转变点信息中的至少一个；向所述接收端发送第一数据流以及所述响应消息；接收端， 用于接收来自服务器的第一数据流以及所述响应消息，根据所述响应消息进行相应的操 作。本发明实施例提供的通信系统，包括服务器，用于接收来自接收端的消息，所述 消息中包括所述接收端的数据处理能力信息；根据所述数据处理能力信息确定响应消息， 所述响应消息包括第一数据流与第二数据流之间的间隔、或第二数据流最新数据信息、或 第一数据流追上第二数据流需要的时间、或第一数据流速率转变点信息中的至少一种；将 第一数据流以及所述响应消息发送给所述接收端；接收端，用于接收服务器发送的第一数 据流以及所述响应消息，根据所述响应消息进行数据处理。本发明实施例提供的通信系统，包括服务器，用于确定第一消息，所述第一消息 包括第一数据流与第二数据流之间的间隔、或第二数据流最新数据信息、或第一数据流追 上第二数据流需要的时间、或第一数据流速率转变点信息中的至少一种；将第一数据流以 及所述第一消息发送给所述接收端；接收端，用于接收服务器发送的第一数据流以及第一 消息，根据所述第一消息进行数据处理。本发明实施例提供的服务器，包括响应生成模块，用于确定响应消息，所述响应消息包括第一数据流与第二数据流之间的间隔、或第二数据流最新数据信息、或第一数据 流速率转变点信息中的至少一种；发送模块，用于向接收端发送第一数据流以及所述响应 消息，以使所述接收端根据所述响应消息进行相应的操作。本发明实施例提供的服务器，包括接收单元，用于接收来自接收端的消息，所述 消息中包括所述接收端的数据处理能力信息；确定单元，用于根据所述数据处理能力信息 确定响应消息，所述响应消息包括第一数据流与第二数据流之间的间隔、或第二数据流最 新数据信息、或第一数据流追上第二数据流需要的时间、或第一数据流速率转变点信息中 的至少一种；发送单元，用于将第一数据流以及所述响应消息发送给所述接收端，以使所述 接收端根据所述响应消息进行数据处理。
本发明实施例提供的服务器，包括确定单元，用于确定第一消息，所述第一消息 包括第一数据流与第二数据流之间的间隔、或第二数据流最新数据信息、或第一数据流追 上第二数据流需要的时间、或第一数据流速率转变点信息中的至少一种；发送单元，用于将 第一数据流以及所述第一消息发送给所述接收端，以使所述接收端根据所述第一消息进行 数据处理。本发明实施例提供的网络设备，包括接收模块，用于接收服务器发送的响应消 息，所述响应消息包括第一数据流与第二数据流之间的间隔、或第二数据流的最新数据信 息、或第一数据流速率转变点信息中的至少一种；确定模块，用于根据所述响应消息确定间 隔信息，根据所述间隔信息确定获取第二数据流的时刻。本发明实施例提供的网络设备，包括数据接收单元，用于接收来自服务器的第一 数据流以及消息，所述来自服务器的消息包括第一数据流与第二数据流之间的间隔、或第 二数据流最新数据信息、或第一数据流追上第二数据流需要的时间、或第一数据流速率转 变点信息中的至少一种；数据处理控制单元，用于根据所述来自服务器的消息进行数据处理。从以上技术方案可以看出，本发明实施例具有以下优点通过本发明实施例，服务器可以向接收端发送第一数据流与第二数据流之间的间 隔等信息，使得接收端能够了解所发送的第一数据流和第二数据流的信息，根据该信息进 行后续操作，例如计算请求第二数据流的时间或者调整接收端的数据处理速度，可以避免 服务器计算并下发接收端请求第二数据流的时间，如果服务器要下发请求第二数据流的时 间，也可以避免服务器下发的信息丢失而引发的双流问题或第一数据流无法追赶上第二数 据流的风险，也提高了服务器向接收端发送数据的灵活性。


为了更清楚地说明本发明实施例或现有技术中的技术方案，下面将对实施例或现 有技术描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本 发明的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动性的前提下，还可 以根据这些附图获得其他的附图。图1为第一数据流起始点选择示意图；图2(a)为本发明实施例中实现流业务的方法一个实施例示意图；图2(b)为本发明实施例中响应消息一种报文格式示意图2(c)为本发明实施例中响应消息另一报文格式示意图；图3为本发明实施例中实现流业务的方法另一实施例示意图；图4为本发明实施例中实现流业务的方法另一实施例示意图；图5为本发明实施例中实现流业务的方法另一实施例示意图；图6为本发明实施例中的一种流业务实现过程坐标示意图；图7为本发明实施例中的另一种流业务实现过程坐标示意图；图8为本发明实施例中实现流业务的方法另一实施例示意图；图9为本发明实施例中实现流业务的方法另一实施例示意图；图10为本发明实施例中实现流业务的方法另一实施例示意图；图11为本发明实施例中通信系统一个实施例示意图；图12为本发明实施例中服务器一个实施例示意图；图13为本发明实施例中服务器另一实施例示意图；图14为本发明实施例中服务器另一实施例示意图；图15为本发明实施例中网络设备一个实施例示意图；图16为本发明实施例中网络设备另一实施例示意图。
具体实施例方式下面将结合本发明实施例中的附图，对本发明实施例中的技术方案进行清楚、完 整地描述，显然，所描述的实施例是本发明一部分实施例，而不是全部的实施例。基于本发 明中的实施例，本领域普通技术人员在没有作出创造性劳动前提下所获得的所有其他实施 例，都属于本发明保护的范围。本发明实施例提供了一种实现流业务的方法及通信系统以及相关设备，用于提高 数据发送的灵活性。在本发明实施例中，接收端可以是请求流业务的客户端设备，比如计算机、媒体播 放器、手机等，向接收端提供流业务的可以是网络侧设备，比如服务器等设备，本发明实施 例中以服务器为例作说明，但不限于服务器。本发明实施例中，第二数据流最新数据信息可以是第二数据流最新的序列号信 息，或第二数据流最新的时间信息(如时间戳timestamp)等。后续各实施例中的第二数据 流最新数据信息可以如上述说明，但不限于上述说明本发明实施例中，第一数据流速率转变点信息包括第一数据流速率转变时间，如 第一数据流速率转变时与开始发送第一数据流时刻的时间差，或第一数据流速率转变时与 第一数据流起始位置的第一个数据包的mediatimestamp差等，或第一数据流速率转变时 与第二数据流之间的间隔，或第一数据流速率转变时接收端缓存到的数据量或时间，或第 一数据流速率转变时第一数据流与第二数据流之间间隔减少的数据量或时间。后续各实施 例中的第一数据流速率转变点信息可以如上述说明，但不限于上述说明。本发明实施例中，间隔(或者偏移(offset)信息)可以是数据量信息如包数，序列号之差，字节数等，也可以是时间信息如media timestamp之差，本地时间差等。后续各 实施例中的间隔可以如上述说明，但不限于上述说明。本发明实施例中，第一数据流和第二数据流之间的间隔可以直接从服务器下发的响应消息中获取，也可以通过响应消息中第二数据流最新数据信息和第一数据流起始位置 的第一个数据包的信息计算得到，也可以通过响应消息中第二数据流最新数据信息和接收 端收到的第一数据流起始位置的第一个数据包的信息计算得到。后续各实施例中的第一数 据流和第二数据流之间的间隔可以如上述说明，但不限于上述说明。 本发明实施例中，缓存要求指的是接收端缓存的数据量或时间应该满足的要求。 缓存要求可以是实际的缓存要求，也可以是折算的缓存要求，第一缓存要求可以为接收端 进行流畅数据处理需要缓存的最小数据量或时间，第二缓存要求可以为接收端能够缓存的 最大数据量或时间。后续各实施例中的缓存要求、第一缓存要求、第二缓存要求可以如上述 说明，但不限于上述说明。请参阅图2(a)，本发明实施例中实现流业务的方法一个实施例包括步骤201、 202,203 和 204，其中201、服务器接收来自接收端的消息；本实施例中的消息在实际应用中可以为频道切换请求或组播切换请求，或快速获 取组播数据(RAMS，Rapid Acquisition of Multicast RTP Sessions)请求，或者是其他类 型的请求消息，具体类型此处不做限定。202、服务器确定响应消息；本实施例中，服务器在接收到接收端发送的消息之后即可确定响应消息，该响应 消息中可以包括第一数据流的起始位置信息、或第一数据流与第二数据流之间的间隔，或 第二数据流的最新数据信息中的至少一个。响应消息还可以包括第一数据流追上第二数据 流需要的时间、或第一数据流速率转变点信息、或数据处理控制信息等。第一数据流速率转变点信息，包括第一数据流速率转变时间，或第一数据流速率 转变时与第二数据流之间的间隔，或第一数据流速率转变时接收端缓存到的数据量或时 间，或第一数据流速率转变时第一数据流与第二数据流之间间隔减少的数据量或时间。后 续各实施例中的第一数据流速率转变点信息可以如上述说明，但不限于上述说明。需要说明的是，本实施例中的第一数据流在实际应用中可以为单播流或组播流， 第二数据流也可以为单播流或组播流，在本实施例以及后续的各个实施例中，可以以单播 流作为第一数据流，以组播流作为第二数据流，可以理解的是，在实际应用中，同样还可以 采取其他方式，具体此处不作限定。本发明实施例中的间隔(或者偏移(offset)信息)可以是数据量信息，可以是包 数，序列号之差，数据大小，也可以是时间信息等；第二数据流最新数据信息可以是第二数 据流最新的序列号信息，和/或第二数据流最新的时间信息(如时间戳timestamp)等。需要说明的是，在实际应用中，本实施例的方案中也可以不执行步骤201，即服务 器无需收到接收端的消息之后才确定响应消息，而可以直接根据服务器本地缓存的数据信 息确定响应消息，该响应消息同样可以包括第一数据流的起始位置信息、或第一数据流与 第二数据流之间的间隔，或第二数据流的最新数据信息，或第一数据流追上第二数据流需 要的时间、或第一数据流速率转变点信息、或数据处理控制信息中的至少一个。203、服务器将第一数据流以及响应消息发送给接收端；服务器生成了响应消息之后，即可将该响应消息以及第一数据流发送给接收端。需要说明的是，本实施例中，服务器向接收端发送响应消息可以采用多种方式，其中一种可以如图2(b)所示，其中，distance parameter是间隔的参数，字段的长度可以为 16bits, distance parameter字段的长度此处不做限定。该间隔可以是Packetl和Packet2的序列号(SN)的差值，也可以是Packetl和 Packet2对应时间(显示时间戳，解码时间戳，时间戳等)的差值，也可以是Packetl和 Packet2之间数据量的大小(字节数)。 该Packetl是指第一数据流起始数据包的标记，该Packet2是指第二数据流最新 数据包的标记。其中extensions字段和distance parameter字段没有必要的先后顺序另外一种方式可以如图2(c)所示，即在实时传输控制协议(RTCP，Real-time Control Protocol)中，distance parameter 字段的格式可以为；1)、包括第一数据流与第二数据流之间的间隔该间隔可以是Packetl和Packet2的序列号(SN)的差值，也可以是Packetl和 Packet2对应时间(显示时间戳，解码时间戳，时间戳等)的差值，也可以是Packetl和 Packet2之间数据量的大小(字节数)。该Packetl是指第一数据流起始数据包的标记，该Packet2是指第二数据流最新 数据包的标记。2)、包括 FirstSN 以及 NewSN 其中，FirstSN表示Packetl的序列号，NewSN表示Packet2的序列号。接收端可 以根据两者之差可以计算出第一数据流与第二数据流之间的间隔。需要说明的是，FirstSN也可以不发送，而只发送NewSN。接收端可以根据接收到 的数据判断FirstSN，进而算出第一数据流与第二数据流之间的间隔。需要说明的是FirstSN以及NewSN的顺序不限制。3)、包括 FirstPTS 以及 NewPTS 其中，FirstPTS表示Packetl的显示时间戳，NewPTS表示Packet2的显示时间戳。 接收端可以根据两者之差可以计算出第一数据流与第二数据流之间的间隔。需要说明的是，FirstPTS也可以不发送，而只发送NewPTS。接收端可以根据接收 到的数据判断FirstPTS，进而算出第一数据流与第二数据流之间的间隔。需要说明的是FirstPTS以及NewPTS的顺序不限制。4)、包括 FirstDTS 以及 NewDTS 其中，FirstDTS表示Packetl的解码时间戳，NewDTS表示Packet2的解码时间戳。 接收端可以根据两者之差可以计算出第一数据流与第二数据流之间的间隔。需要说明的是，FirstDTS也可以不发送，而只发送NewDTS。接收端可以根据接收 到的数据判断FirstDTS，进而算出第一数据流与第二数据流之间的间隔。需要说明的是FirstDTS以及NewDTS顺序不限制。5)、包括 FirstTS 以及 NewTS 其中，FirstTS表示Packetl的时间戳，NewTS表示Packet2的时间戳。接收端可 以根据两者之差可以计算出第一数据流与第二数据流之间的间隔。需要说明的是，FirstTS也可以不发送，而只发送NewTS。接收端可以根据接收到 的数据判断FirstTS，进而算出第一数据流与第二数据流之间的间隔。
可以理解的是，后续各个实施例中均可采用上述的方式发送第一数据流与第二数 据流之间的间隔。需 要说明的是FirstTS以及NewTS顺序不限制。本实施例中的distance parameter字段也可以采用RAMS-I消息来承载，上述提 到的第一数据流与第二数据流之间的间隔信息，FirstSN信息，NewSN信息，FirstPTS信息， NewPT信息，FirstDTS信息，NewDTS信息，FirstTS信息和NewTS信息也可以采用TLV格式；204、接收端根据响应消息进行相应的操作。本实施例中，服务器将响应消息发送至接收端之后，接收端即可根据该响应消息 进行相应的操作。需要说明的是，具体的操作可以为多种，例如进行数据处理，或者是确定获取第二 数据流的时刻等，下面分别进行说明一、接收端根据响应消息进行数据处理在该方式中，接收端向服务器发送的消息中可以携带有接收端的数据处理能力信 息，该数据处理能力信息包括接收端是否支持快速/慢速数据处理，以及支持的快速/慢速 数据处理的程度。需要说明的是，本实施例中的数据处理可以是解码，或者播放，或者数据读取，或 者数据消耗，或者数据裁剪，或者数据复制，或者数据插入，或者其它数据处理类型等。后续 各实施例中的数据处理可以如上述说明，但不限于上述说明。本实施例中，服务器根据支持的慢速或快速数据处理能力信息以及服务器缓存的 数据信息确定响应消息，响应消息包括第一数据流的起始位置信息、或第一数据流与第二 数据流之间的间隔(或者偏移(offset)信息)、或第二数据流最新数据信息、或第一数据流 持续时间、或第一数据流速度、或第一数据流追上第二数据流需要的时间、或第一数据流速 率转变点信息、或数据处理控制信息、或估计的接收端缓存的第一数据量或时间中的至少 一种或多种，而且不限于上述的信息。需要说明的是，本发明实施例中的第一数据流在实际应用中可以为单播流或组播 流，第二数据流也可以为单播流或组播流，在本实施例以及后续的各个实施例中，可以以单 播流作为第一数据流，以组播流作为第二数据流，可以理解的是，在实际应用中，同样还可 以采取其他方式，具体此处不作限定。本实施例中的间隔(或者偏移(offset)信息)可以是数据量信息，可以是包数， 序列号之差，数据大小，也可以是时间信息等；第二数据流最新数据信息可以是第二数据流 最新序列号信息，和/或第二数据流最新时间信息(如timestamp)等。需要说明的是，在本实施例以及后续各实施例中所描述的间隔均可以如上所述， 但不限于上述说明。本实施例中，服务器可以使用默认的第一缓存要求和/或第二缓存要求。缓存要 求可以指的是接收端缓存的数据量或时间应该满足的要求。本实施例中，缓存要求可以是实际的缓存要求，也可以是折算的缓存要求，第一缓 存要求可以为接收端进行流畅数据处理需要缓存的最小数据量或时间，第二缓存要求可以 为接收端能够缓存的最大数据量或时间。后续各实施例中的缓存要求、第一缓存要求、第二缓存要求可以如上述说明，但不限于上述说明。本实施例中，第一数据量或时间可以是第一数据流结束时或第一数据流结束后接 收端缓存的数据量或时间，或第一数据流追上第二数据流时或第一数据流追上第二数据流 后接收端缓存的数据量或时间，或在一定的数据处理启动条件下接收端缓存的数据量或时 间，或在一段时间后接收端缓存的数据量或时间。后续各实施例中的第一数据量或时间可以如上述说明，但不限于上述说明。本实施例中，确定第一数据流与第二数据流之间的间隔(或者偏移(offset)信 息)和第一数据流的发送起始位置的方法可以参阅图1，假设服务器在tb点至tc点之间的 数据量或时间较小，服务器估计在预置条件下接收端缓存的数据量或时间小于第一缓存要 求，但如果接收端具有慢速数据处理能力如可以以3/4倍正常速度数据处理，则服务器可 以从tb点开始发送第一数据流，间隔(或者偏移(offset)信息)就是tb点至tc点之间 的数据量或时间，第一数据流发送起始位置信息就是tb点的数据信息；如果接收端不具有 慢速数据处理能力，服务器可以从ta点开始发送第一数据流，间隔(或者偏移(offset)信 息)就是ta点至tc点之间的数据量或时间，第一数据流发送起始位置信息就是ta点的数 据信息。确定第一数据流与第二数据流之间的间隔(或者偏移(offset)信息)和第一数 据流的发送起始位置的方法可以如上所述，但也不限于上述方法。本实施例中，数据处理控制信息可以包括快速数据处理参数、或慢速数据处理参 数、或延时数据处理参数。数据处理参数可以是快速数据处理/慢速数据处理/延时数据 处理的指示，或快速数据处理/慢速数据处理的速度信息，或快速数据处理/慢速数据处理 的时间信息，或延时数据处理的时间信息等。速度信息可以是数据处理速度，也可以是正常 速度的倍数，也可以是处理m个帧插入或复制或延迟η个帧，也可以是改变帧或图像之间的 显示间隔，或者其它能够获得数据处理速度的信息。时间信息可以是时间长度，也可以是一 共插入或复制或延迟χ帧，或者其它能够获得时间信息的信息等。后续各实施例中的数据处理控制信息可以如上述说明，但不限于上述说明。服务器可以估计在预置条件下接收端缓存的数据量或时间，当该数据量或时间小 于预置的第一缓存要求时，则确定慢速数据处理参数或延时数据处理参数，当该数据量或 时间大于预置的第二缓存要求时，则确定快速数据处理参数或延时数据处理参数。服务器生成了响应消息之后，即可将该响应消息以及第一数据流发送给接收端。本实施例中，接收端接收到第一数据流以及响应消息之后，如果该响应消息包括 第一数据流与第二数据流之间的间隔(或者偏移(offset)信息)、或估计的接收端缓存 的第一数据量或时间，则接收端可以根据第一数据流与第二数据流之间的间隔(或者偏移 (offset)信息)、或估计的接收端缓存的第一数据量或时间确定真实间隔对应的数据量或 时间，并且判断该真实间隔对应的数据量或时间是否满足预置的第一缓存要求，若小于第 一缓存要求，则对第一数据流进行慢速处理，若该真实间隔对应的数据量或时间大于预置 的第二缓存要求，则对第一数据流进行快速处理，若该真实间隔对应的数据量或时间小于 或等于预置的第二缓存要求，且大于或等于预置的第一缓存要求，则进行正常数据处理。本实施例中，真实间隔可以是第一数据流与第二数据流之间的实际间隔(或者 偏移(offset)信息)，也可以是该实际间隔加上接收端启动条件算出的间隔(或者偏移 (offset)信息)，也可以是第一数据流结束和/或第一数据流追上第二数据流和/或在一定的数据处理启动条件和/或在一段时间后的条件下接收端所处理的数据流和第二数据 流之间的间隔(或者偏移(offset)信息)，也可以是第一数据流结束和/或第一数据流追 上第二数据流和/或在一定的数据处理启动条件和/或在一段时间后的条件下接收端所缓 存的数据量或时间等。在后续的各个实施例中所描述的真实间隔均可如上述说明，但不限于上述说明。 如果该响应消息包括第一数据流的起始点位置信息，和/或第二数据流最新数据 信息，和/或第一数据流持续时间与第一数据流速度信息，和/或第一数据流速率转变点信 息，和/或第一数据流追上第二数据流需要的时间，则接收端可以根据这些信息计算第一 数据流与第二数据流之间的间隔(或者偏移(offset)信息)，然后再确定真实间隔对应的 数据量或时间，之后进行与上述方式相同的处理。本实施例中，接收端根据响应消息可以获知tc时刻到tb时刻之间的服务数据流 是第一缓存要求的一半，则接收端可以采用3/4倍的正常速度进行慢速数据处理，也可以 采用一段时间之后再进行数据处理。如果该响应消息包括数据处理控制信息，接收端接收到该响应消息之后，即可根 据快速数据处理参数，或慢速数据处理参数，或延时数据处理的参数对第一数据流进行快 速数据处理或慢速数据处理或延时数据处理。需要说明的是，本实施例中，第一缓存要求小于等于第二缓存要求，预置条件可以 是第一数据流结束，和/或第一数据流追上第二数据流，和/或在一定的数据处理启动条 件，和/或在一段时间等。本实施例中，如果步骤201的消息中还携带有缓存要求，该缓存要求可以是第一 缓存要求或第二缓存要求，则202步骤中的第一缓存要求或第二缓存要求可以使用该消息 中携带的第一缓存要求或第二缓存要求。本实施例中，接收端在适当的时刻，接收第二数据流。适当的时刻可以是在第一数 据流接收过程中，或者是第一数据流结束后。本实施例可以用于互联网协议电视(IPTV，Internet Protocol Television)，网 络电视、移动电视、数字电视(DTV，Digital Television)等媒体业务中，也可以用于其它 涉及流切换的业务中，如接收端先接收第一数据流(一般为快发的第一数据流)，一段时间 之后，如当第一数据流与第二数据流有效载荷即将相同时或者第一数据流追上第二数据流 时，接收端接收第二数据流。本实施例中，服务器可以向接收端发送第一数据流与第二数据流之间的间隔(或 者偏移(offset)信息)等信息，使得接收端能够根据该信息进行数据处理，从而提高了服 务器向接收端发送数据的灵活性。同样请参阅图2(a)，本发明实施例中，实现流业务的方法另一实施例包括201、服务器接收来自接收端的消息；本实施例中，该消息中可以包括接收端的数据处理启动条件。202、服务器根据接收到的来自接收端的消息，确定响应消息；本实施例中，该响应消息中可以携带有服务器建议的数据处理启动条件，服务器 在确定响应消息时，可以使用默认的第一缓存要求和第二缓存要求，服务器估计在预置条 件下接收端缓存的数据量或时间，当该数据量或时间小于预置的第一缓存要求时，则可以建议使用较大的数据处理启动条件，当该数据量或时间大于预置的第二缓存要求时，则可 以建议使用较小的数据处理启动条件。比如接收端数据处理启动条件为300ms，默认的第一 缓存要求为500ms，服务器估计在IOOms启动时延下第一数据流结束时接收端缓存的时间 为400ms，则服务器可以建议接收端启动时延为200ms。
本实施例中的预置条件可以是第一数据流结束，和/或第一数据流追上第二数据 流，和/或在一定的数据处理启动条件，和/或在一段时间等。203、服务器将响应消息和第一数据流发送至接收端；204、接收端根据收到的响应消息对第一数据流进行数据处理。本实施例中，接收端接收到响应消息之后，可以确定服务器建议的数据处理启动 条件，进行数据处理。本实施例中，接收端在适当的时刻，接收第二数据流。适当的时刻可以是在第一数 据流接收过程中，或者是第一数据流结束后。本实施例可以用于IPTV，网络电视、移动电视、DTV等媒体业务中，也可以用于其 它涉及流切换的业务中，如接收端先接收第一数据流(一般为快发的第一数据流)，一段时 间之后，如当第一数据流与第二数据流有效载荷即将相同时或者第一数据流追上第二数据 流时，接收端接收第二数据流。本实施例中，服务器可以向接收端发送第一数据流与数据处理启动条件等信息， 使得接收端能够根据该数据处理启动条件进行数据处理，从而提高了服务器向接收端发送 数据的灵活性。请参阅图3，本发明实施例中实现流业务的方法另一实施例包括301、服务器确定第一消息；本实施例中，服务器可以根据服务器缓存的数据信息确定第一消息，第一消息 包括第一数据流的起始位置信息、或第一数据流与第二数据流之间的间隔(或者偏移 (offset)信息)、或第二数据流最新数据信息、或第一数据流持续时间、或第一数据流速 度、或第一数据流追上第二数据流需要的时间、或第一数据流速率转变点信息、或数据处理 控制信息、或估计的接收端缓存的第一数据量或时间中的至少一种或多种，而且不限于上 述的信息。需要说明的是，本实施例中，服务器确定上述信息的过程与图2(a)所示的实施例 中的步骤202类似，此处不再赘述。该第一数据流与第二数据流之间的间隔(或者偏移(offset)信息)可以是数据 量信息，可以是包数，序列号之差，数据大小，也可以是时间信息等；第二数据流最新数据信 息可以是第二数据流最新序列号信息，和/或第二数据流最新时间信息(如timestamp)寸。302、服务器将第一数据流以及第一消息发送给接收端；本实施例中的步骤302与图2(a)所示的实施例中的步骤203类似，仅是将步骤 203中的响应消息替换为步骤302中的第一消息即可，此处不再赘述。303、接收端根据第一消息进行数据处理。本实施例中的步骤303与图2(a)所示的实施例中的步骤204类似，仅是将步骤 204中的响应消息替换为步骤303中的第一消息即可，此处不再赘述。
本实施例中，接收端在适当的时刻，接收第二数据流。适当的时刻可以是在第一数 据流接收过程中，或者是第一数据流结束后。本实施 例可以用于IPTV，网络电视、移动电视、DTV等媒体业务中，也可以用于其 它涉及流切换的业务中，如接收端先接收第一数据流(一般为快发的第一数据流)，一段时 间之后，如当第一数据流与第二数据流有效载荷即将相同时或者第一数据流追上第二数据 流时，接收端接收第二数据流。需要说明的是，本实施例中，在步骤301之前还可以包括一个步骤，该步骤为可选 步骤服务器接收来自接收端的消息。该消息在实际应用中可以为频道切换请求或组播切换请求或快速获取组播数据 (RAMS)请求，或者是其他类型的请求消息，具体类型此处不做限定，该消息中还可以携带接 收端的缓存要求。若该消息中还可以携带接收端的缓存要求，则在步骤302中，服务器根据该消息 中包括的缓存要求确定第一数据流的发送起始位置，并且根据第一数据流的发送起始位置 以及服务器缓存的数据信息确定第一消息，具体的接收端根据自身的数据处理能力信息和/或数据处理启动条件要求，计算出接收 端的需求信息，具体的需求信息可以是第一数据流与第二数据流之间的最小间隔(或者偏 移(offset)信息)，或第一数据流的起始位置信息、或第二数据流最新数据信息、或第一数 据流持续时间、或第一数据流速度、或第一数据流追上第二数据流需要的时间、或第一数据 流速率转变点信息、或数据处理控制信息、或估计的接收端缓存的第一数据量或时间中的 至少一种或多种，而且不限于上述的信息，向服务器发送消息，该消息中携带该需求信息或 由该需求信息折算出的缓存要求，该需求信息可以是时间也可以是数据量。服务器接收到接收端的消息后，根据接收端的缓存要求，或接收端的需求信息确 定实际需求信息，并且将该实际需求信息发送给接收端，该实际需求信息可以携带在第一 消息中。该实际需求信息可以是第一数据流与第二数据流之间的间隔(或者偏移 (offset)信息)，或第一数据流的起始位置信息、或第二数据流最新数据信息、或第一数据 流持续时间、或第一数据流速度、或第一数据流追上第二数据流需要的时间、或第一数据流 速率转变点信息、或数据处理控制信息、或估计的接收端缓存的第一数据量或时间中的至 少一种或多种，而且不限于上述的信息。接收端收到服务器发送的实际需求信息后，可以先判断该实际需求信息是否在预 置的范围之内，若是，则既可以按照接收端发送的需求信息确定数据处理启动条件和/或 数据处理速度进行数据处理控制，也可以根据该实际需求信息调整数据处理速度和/或数 据处理时延进行数据处理控制，若该实际需求信息不在预置的范围内，则接收端根据该实 际需求信息调整数据处理速度和/或数据处理启动条件进行数据处理控制。需要说明的是，接收端发送消息之后，也可以无需等待服务器发送的实际需求信 息，而直接根据自身发送的需求信息或缓存要求确定数据处理启动条件和/或数据处理速 度进行数据处理控制。本实施例中，服务器可以向接收端发送第一数据流与第二数据流之间的间隔等信息，使得接收端能够根据该信息进行数据处理，从而提高了服务器向接收端发送数据的灵 活性。请参阅图4，本发 明实施例中实现流业务的方法另一实施例包括401、服务器接收来自接收端的消息；本实施例中的消息在实际应用中可以为频道切换请求或组播切换请求或快速获 取组播数据(RAMS)请求，或者是其他类型的请求消息，具体类型此处不做限定。402、服务器对第一数据流中的数据进行调整或修改；具体的，本实施例中，服务器可以从第一数据流中增加信息、或者删除数据、或者 修改数据信息、或者重新压缩数据。增加的数据可以是重复处理前面的帧η次的信息，或者重复处理前面的帧的时间
fn息等。删除数据可以是从数据流中删除部分媒体数据；修改数据信息可以是解码时间信息、或者显示的时间信息、或者发送时间信息、或 者数据流中媒体信息。重新压缩数据可以是删除一部分原始数据后，在对新的数据流进行转码。本实施例中，服务器可以使用默认的第一缓存要求和/或第二缓存要求，如果步 骤401中的消息中包含第一缓存要求和/或第二缓存要求，服务器可以使用步骤401中的 第一缓存要求和/或第二缓存要求。服务器估计在预置条件下接收端缓存的数据量或时间，当该数据量或时间小于预 置的第一缓存要求时，服务器可以在第一数据流中增添一些数据，或者修改一些数据信息， 以使接收端处理第一数据流的时间长度增加，当该数据量或时间大于预置的第二缓存要求 时，服务器可以在第一数据流中删除一些数据，或者重新压缩数据，或者修改一些数据信 息，以使接收端处理第一数据流的时间缩短。本实施例中的第一缓存要求以及第二缓存要求的定义与前述图2(a)所示的实施 例中的定义相同，此处不再赘述。本实施例中，缓存要求可以是实际的缓存要求，也可以是折算的缓存要求。本实施例中的预置条件可以是第一数据流结束，和/或第一数据流追上第二数据 流，和/或在一定的数据处理启动条件，和/或在一段时间等。403、服务器将调整或修改后的第一数据流发送给接收端；服务器对第一数据流完成调整或修改之后，即可将该第一数据流发送给接收端。404、接收端对调整或修改后的第一数据流进行数据处理。接收端接收到调整或修改后的第一数据流之后，即可直接对该第一数据流进行数 据处理。本实施例中，接收端在适当的时刻，接收第二数据流。适当的时刻可以是在第一数 据流接收过程中，或者是第一数据流结束后。本实施例可以用于IPTV，网络电视、移动电视、DTV等媒体业务中，也可以用于其 它涉及流切换的业务中，如接收端先接收第一数据流(一般为快发的第一数据流)，一段时 间之后，如当第一数据流与第二数据流有效载荷即将相同时或者第一数据流追上第二数据 流时，接收端接收第二数据流。
本实施例中，服务器可以向接收端发送增长的第一数据流与减短的第一数据流， 从而提高了服务器向接收端发送数据的灵活性。请参阅图5，本发明实施例中实现流业务的方法另一实施例包括501、服务器接收来自接收端的消息；该消息在实际应用中可以为频道切换请 求或组播切换请求或快速获取组播数据 (RAMS)请求，或者是其他类型的请求消息，具体类型此处不做限定。502、服务器将第一数据流以及响应消息发送给接收端；本实施例中，服务器在接收到来自接收端的消息之后，将第一数据流以及响应消 息发送给接收端。503、接收端对第一数据流进行数据处理。接收端在接收到服务器发送的第一数据流之后，即可确定本地缓存数据的数据量 或时间是否满足缓存要求。本实施例中，具体的确定方式可以为(1)、当接收端开始接收第二数据流，并且该第二数据流的数据与接收到的第一数 据流连接上之后，接收端可以读取本地缓存中的数据，进而可以获知该缓存中的数据量或 时间是否满足缓存要求，该缓存要求可以为第一缓存要求或第二缓存要求；(2)、当接收端开始接收第二数据流，接收端可以读取本地缓存中的数据，进而可 以获知该缓存中的数据量或时间是否满足缓存要求，该缓存要求可以为第一缓存要求或第 二缓存要求；(3)、接收端在接收第一数据流的过程中可以实时检测本地缓存中的数据量或时 间是否满足缓存要求，该缓存要求可以为第二缓存要求。当接收端确定本地缓存的数据量或时间小于第一缓存要求时，对第一数据流进行 慢速数据处理，当接收端确定本地缓存的数据量或时间大于第二缓存要求时，则对第一数 据流进行快速数据处理，当接收端确定本地缓存数据满足第一缓存要求，且满足第二缓存 要求时，则对第一数据流进行正常速度数据处理。需要说明的是，本实施例中的步骤501中，接收端向服务器发送的消息中还可以 进一步携带有接收端的数据处理能力信息。若接收端向服务器发送的消息中还可以进一步携带有接收端的数据处理能力信 息，则服务器在步骤502之前可以根据该数据处理能力信息确定第一数据流起始点等信 息，并且向接收端发送第一数据流以及响应消息，接收端所执行的操作与前述步骤503中 执行的操作相同，此处不再赘述。本实施例中，接收端还可以判断本地缓存的数据量或时间是否小于预置的第二缓 存要求，若不满足，则对第一数据流进行快速处理。本实施例中，第一缓存要求以及第二缓存要求的定义与前述图2(a)所示的实施 例中的定义相同，此处不再赘述。本实施例中的缓存要求可以是实际的缓存要求，也可以是折算的缓存要求，此处 不作限定。本实施例中，接收端在适当的时刻，接收第二数据流。适当的时刻可以是在第一数 据流接收过程中，或者是第一数据流结束后。
本实施例可以用于IPTV，网络电视、移动电视、DTV等媒体业务中，也可以用于其 它涉及流切换的业务中，如接收端先接收第一数据流(一般为快发的第一数据流)，一段时 间之后，如当第一数据流与第二数据流有效载荷即将相同时或者第一数据流追上第二数据 流时，接收端接收第二数据流。本实施例中，接收端慢速数据处理时，可以降低服务器发送的第一数据流的数据 量，从而降低服务器的负载； 接收端快速数据处理时，可以降低用户之间的时移，使不同用户看到的内容尽可 能同步，提升用户体验。二、接收端根据响应消息确定获取第二数据流的时刻在本发明实施例中，获取第二数据流的时刻可以是发送请求第二数据流的消息 (比如 SFGMP (Source Filtering Group Management Protocol)message),也可以接收第二 数据流的时刻等。在实际应用中，当服务器向接收端发送了一段时间的单播流之后，接收端即可加 入组播组接收原始组播流，接收端具体加入组播组的时刻一般由服务器来确定，本发明实 施例的一种实现流业务的方法大致可以包括如下步骤1)接收端向频道切换服务器发送频道切换请求；2)服务器向接收端发送响应消息；3)服务器向接收端快发单播流；4)在提供服务的过程中，服务器至少一次发送通知消息指示接收端在某时刻加入
组播组；5)在提供服务的过程中，服务器可以调整数据的发送速率；6)接收端根据通知消息中携带的时刻加入组播组；7)服务器降速发送单播流直到追上组播流。为便于理解，下面以一具体坐标系来表示流业务的情况，请参阅图6，其中，横坐标 表示时间，纵坐标表示媒体数据；斜线39表示组播流；斜线40，41组成的斜线29表示服务 器发送的单播流；斜线38表示接收端消耗的媒体数据。其中，斜线38以及39的斜率代表组播速率，同时也是接收端消耗数据的速率，斜 线38以及39的斜率在正常情况下应当相同。H表示接收端请求频道切换后，接收的单播流与当时组播流之间的距离，该H可以 等于单播流与组播流之间时移所对应的媒体数据量。T表示正常加入组播的时刻；C表示单播结束点；Z表示正常情况下服务器给接收 端下发的单播数据量。在上述步骤4)中，为了避免接收端过早或者过晚加入原始组播组，服务器要提前 计算接收端加入组播组的时刻Τ，然后发送到接收端。服务器在发送单播流的过程中会根据 网络或者接收端的情况改变发送速度，改变速度时服务器会通知接收端新的加入时刻。接 收端根据最新接收到的时刻，加入组播组。但是，这种通知机制是不可靠的，服务器发送的通知消息很可能在网络中丢失，从 而导致接收端无法在合适的时刻加入组播组。如果因为通知消息丢失导致接收端延迟加入组播组(即图6中T点向右移)，则对应的J'也向右移，则服务器单播的数据量会增加，服务器服务的时间也会变长(即C向右 移)，这样会加重服务器的负载。如果加入组播组太迟，例如J'移到C右边，则接收端在加 入组播组前缓存数据已经耗光，频道切换将会失败。本发明实施例中又提供了一种实现流业务的方法，在该方法中，接收端无需完全 依赖于服务器通知的加入时刻即可确定合适的加入时刻，从而能够避免通知消息丢失而导 致的问题。
为便于说明，下面首先对本发明实施例中流业务坐标图进行说明，请参阅图7，该 图中，各参数的具体含义均与图6中各参数的具体含义相同，此处不再赘述。在本实施例的频道切换过程中，服务器会在快追上组播流时降速发送，准备接收 组播流。也就是说加入组播组的时刻(即获取原始组播流的时刻)应该在降速时刻附近。请参阅图7，在快发单播流阶段，由于单播流速度大于数据的消耗速度，接收端的 缓存数据量会逐渐增大(即Bl- > B2逐渐增大)。服务器在T2时刻降速之后，如果接收端还没有加入组播组，则由于单播流速度小 于数据的消耗速度，接收端的缓存数据量会逐渐减小(即B2- > B3逐渐减小)。如果服务器降速之后的速度与数据消耗的速度相等，那么降速之后如果接收端还 没有加入组播组，接收端的缓存数据量会基本保持不变(即由B 1逐渐增大到B2之后，维 持B2不变)。由这种现象可以获知在接收端没有加入组播组的前提下，如果在T时刻检测到 缓存数据量增大到一定程度后开始减小或者维持不变，则表明服务器已经开始降速发送， 组播加入时机应该在T附近。一般情况下，当服务器快追上原始组播流而降速时，接收端缓存应该在H值附近。 例如图7中在T2时刻降速时，接收端缓存B2很接近H。由上可知，如果服务器能够将单播流与原始组播流之间的间隔H发送至接收端， 则接收端也可以根据自身缓存的变化趋势确定合适的组播组加入时刻。下面对本发明实施例中的实现流业务的方法进行详细描述，请参阅图8，本发明实 施例中实现流业务的方法另一实施例包括801、服务器接收来自接收端的消息；该消息在实际应用中可以为频道切换请求或组播切换请求或快速获取组播数据 (RAMS)请求，或者是其他类型的请求消息，具体类型此处不做限定。802、服务器根据接收到的来自接收端的消息，确定响应消息；本实施例中，该响应消息中可以携带第一数据流的起始位置信息、或第一数据流 与第二数据流之间的间隔，或第二数据流的最新数据信息，或第一数据流速率转变点信息 中的至少一种。本实施例中，该第一数据流可以为单播流，第二数据流可以为原始组播流。该第一数据流与第二数据流之间的间隔(或者偏移(offset)信息)可以是数据 量信息，可以是包数，序列号之差，数据大小，也可以是时间信息等；第二数据流最新数据信 息可以是第二数据流最新序列号信息，和/或第二数据流最新时间信息(如timestamp)寸。需要说明的是，在实际应用中，本实施例的方案中也可以不执行步骤801，即服务器无需收到接收端的消息之后才确定响应消息，而可以直接根据服务器本地缓存的数据信 息确定响应消息，该响应消息同样可以包括第一数据流的起始位置信息、或第一数据流与 第二数据流之间的间隔，或第二数据流的最新数据信息，或第一数据流速率转变点信息中 的至少一个。803、服务器将 第一数据流以及响应消息发送给接收端，以使得接收端根据响应消 息确定获取第二数据流的时刻。在实际应用中，服务器既可以通过单播流的形式向接收端发送数据流，也可以通 过组播流的形式向接收端发送数据流，服务器所发送的数据流的封装格式不做限定，可以 是直接拷贝原始组播数据，也可以是重新封装后的原始组播流，也可以是以重传数据包的 格式封装的数据包，也可以是原始数据流经过重新封装或者没有重新封装后的数据。需要说明的是，服务器向接收端发送响应消息和第一数据流并没有严格的顺序关 系，既可以先发送第一数据流，再发送响应消息，也可以先发送响应消息，再发送第一数据 流，或者可以同时发送。服务器在发送第一数据流一段时间之后，还可以停止第一数据流的发送，具体过 程此处不作限定。本实施例中，服务器将第一数据流以及响应消息发送至接收端之后，接收端即可 根据响应消息以及自身的缓存确定获取第二数据流的时刻。上面从服务器的角度对本发明实施例中的实现流业务的方法进行了描述，下面从 接收端的角度进行描述，请参阅图9，本发明实施例中实现流业务的方法另一实施例包括901、接收端向服务器发送消息；该消息在实际应用中可以为频道切换请求或组播切换请求或快速获取组播数据 (RAMS)请求，或者是其他类型的请求消息，具体类型此处不做限定。902、接收端接收服务器发送的响应消息；接收端在向服务器发送了消息之后，则会从服务器收到第一数据流以及响应消 肩、ο本实施例中，该响应消息由服务器根据接收端发送的消息与服务器本地缓存的数 据确定得到，响应消息包括第一数据流的起始位置信息、或第一数据流与第二数据流之间 的间隔，或第二数据流的最新数据信息，或第一数据流速率转变点信息中的至少一种。该第一数据流可以为单播流，第二数据流可以为原始组播流。需要说明的是，在实际应用中，也可以不执行步骤901，即接收端无需向服务器发 送消息，而可以直接从服务器接收到响应消息，该响应消息由服务器根据本地缓存的数据 确定得到，该响应消息同样包括第一数据流的起始位置信息、或第一数据流与第二数据流 之间的间隔，或第二数据流的最新数据信息，或第一数据流速率转变点信息中的至少一种。903、接收端根据响应消息确定获取第二数据流的时刻；当接收端接收到响应消息之后，检测自身的缓存信息，本发明实施例中的缓存信 息可以是接收端缓存中所缓冲的第一数据流的数据量，或接收端缓存中所缓冲的第一数 据流的时间信息，接收端缓存中所缓冲的第一数据流的速率等。接收端缓存中所缓冲的第 一数据流的数据量可以是缓存中第一数据流的包数，或者字节数等，接收端缓存中所缓冲 的第一数据流的时间信息可以是接收端消耗完数据的时间，也可以是缓存中所缓存的最新数据包的时间信息和最早数据包的时间信息的差值，数据包的时间信息可以是数据包的时 间戳，数据包负载中所携带的时间。在前面提到过，获取第二数据流的时刻应该在降速时刻 附近，所以接收端可以通过如下方式确定获取第二数据流的时刻(1)接收端检测自身的缓存信息；当缓存信息增大到间隔/偏移信息后又开始减小或开始维持不变，则确定当前时 刻为获取第二数据流的时刻。(2)接收端检测自身的缓存信息； 当缓存信息达到间隔/偏移信息预置门限时，则确定当前时刻为获取第二数据流 的时刻。例如，在本发明的实施例中，用H来表示该间隔/偏移信息(以时间为单位)，则该 预置门限可以设置为(H-At)，At可以取0.1秒。At值此处不作限定。(3)接收端检测自身的缓存信息；接收端根据第一数据流速率转变点信息得到第一数据流速率转变时接收端缓存 到的数据量或时间。当缓存信息达到第一数据流速率转变时接收端缓存到的数据量或时间 的预置门限时，则确定当前时刻为获取第二数据流的时刻。例如，在本发明的实施例中用H’来表示第一数据流速率转变时接收端缓存的时间 信息，则该预置门限可以设置为(H’ -At)，At比如可以取0.1秒。At值此处不作限定。接收端根据第一数据流速率变点信息得到第一数据流速率转变时接收端缓存到 的数据量或时间的方法包括直接从第一数据流速率转变点信息中获取，或根据第一数据 流速率转变时间计算出第一数据流速率转变时接收端缓存到的数据量或时间，或根据第一 数据流速率转变时与第一数据流起始位置的第一个数据包的media timestamp差计算出第 一数据流速率转变时接收端缓存到的数据量或时间，或根据第一数据流速率转变时与第二 数据流之间的间隔以及开始发送第一数据流时第一数据流与第二数据流之间的间隔计算 出第一数据流速率转变时接收端缓存到的数据量或时间，或根据第一数据流速率转变时第 一数据流与第二数据流之间间隔减少的数据量或时间计算出第一数据流速率转变时接收 端缓存到的数据量或时间等。本发明中根据第一数据流速率转变点信息得到第一数据流速 率转变时接收端缓存到的数据量或时间的方法如上所述，但又不限于上述说明。(4)接收端检测自身的接收数据的速度T =间隔/偏移信息除以接收数据的速度；当接收端时间经过了 T时间长度附近的预置门限时，则确定当前时刻为获取第二 数据流的时刻。可以理解的是，本实施例中仅以几个例子对获取第二数据流的时刻的确定过程进 行了描述，在实际应用中，还可以有更多的确定方式，此处不作限定。需要说明的是，本实施例中，若响应消息中包含有第一数据流与第二数据流之间 的间隔/偏移信息，则接收端可以直接从响应消息中获取到该信息，若响应消息中只包含 有第二数据流的最新数据信息，则接收端还可以根据该第二数据流的最新数据信息以及第 一数据流的起始位置计算第一数据流与第二数据流之间的间隔/偏移信息，具体方式此处 不作限定。
904、接收端获取第二数据流。接收端确定了获取第二数据流的时刻之后，即可发送请求第二数据流的消息；如 果第二数据流是组播数据流，那么接收端发送加入组播组的请求消息，获取第二数据流。当接收端加入组播组开始接收原始组播流之后，接收端可以向服务器发送单播流 中止消息以请求服务器停止发送单播流。下面从服务器与接收端交互的角度对本发明实施例中的实现流业务的方法进行 描述，请参阅图10，本发明实施例中实现流业务的方法另一实施例包括1001、接收端向服务器发送消息； 该消息在实际应用中可以为频道切换请求或组播切换请求或快速获取组播数据 (RAMS)请求，或者是其他类型的请求消息，具体类型此处不做限定。1002、服务器确定响应消息；当服务器接收到接收端发送的消息之后，即可向接收端反馈响应消息，该响应消 息中除了包含原有响应消息中的内容之外，还包含第一数据流的起始位置信息、或第一数 据流与第二数据流之间的间隔，或第二数据流的最新数据信息，或第一数据流速率转变点 信息中的至少一种。本实施例中，该第一数据流可以为单播流，第二数据流可以为原始组播流。该第一数据流与第二数据流之间的间隔(或者偏移(offset)信息)可以是数据 量信息，可以是包数，序列号之差，数据大小，也可以是时间信息等；第二数据流最新数据信 息可以是第二数据流最新序列号信息，和/或第二数据流最新时间信息(如timestamp)寸。需要说明的是，该间隔/偏移信息可以是未经过任何处理的信息，例如按照正常 的数据处理速度将图1所示的ta至tc之间的数据处理完所需要的时间，或图1所示的ta 和tc处对应的实时传输协议包的时间戳之差，或图1所示的ta和tc处对应的实时传输协 议包中的传输流内的显示时间戳或解码时间戳之差，或ta和tc处对应的服务器系统时间 之差，或ta和tc处对应的节目参考时钟之差，也可以是上述的信息经过缩小或放大之后的 数据，此处不作限定。需要说明的是，在实际应用中，本实施例的方案中也可以不执行步骤1001，S卩服务 器无需收到接收端的消息之后才确定响应消息，而可以直接根据服务器本地缓存的数据信 息确定响应消息，该响应消息同样可以包括第一数据流的起始位置信息、或第一数据流与 第二数据流之间的间隔，或第二数据流的最新数据信息，或第一数据流速率转变点信息中 的至少一个。1003、服务器向接收端发送第一数据流以及响应消息；在实际应用中，服务器既可以通过单播流的形式向接收端发送数据流，也可以通 过组播流的形式向接收端发送数据流，服务器所发送的数据流的封装格式不做限定，可以 是直接拷贝原始组播数据，也可以是重新封装后的原始组播流，也可以是以重传数据包的 格式封装的数据包，也可以是原始数据流经过重新封装或者没有重新封装后的数据。需要说明的是，服务器向接收端发送响应消息和第一数据流并没有严格的顺序关 系，既可以先发送第一数据流，再发送响应消息，也可以先发送响应消息，再发送第一数据 流，或者可以同时发送。
1004、接收端接收服务器发送的响应消息； 本实施例中，该响应消息由服务器根据接收端发送的消息与服务器本地缓存的数 据确定得到，响应消息包括第一数据流的起始位置信息、或第一数据流与第二数据流之间 的间隔，或第二数据流的最新数据信息，或第一数据流速率转变点信息中的至少一种。1005、接收端根据响应消息确定获取第二数据流的时刻。当接收端接收到响应消息之后，即可检测自身的所接收数据的信息，在前面提到 过，获取第二数据流的时刻应该在降速时刻附近，所以接收端可以通过如下方式确定获取 第二数据流的时刻(1)接收端检测自身的缓存信息；当缓存信息增大到间隔/偏移信息后又开始减小或开始维持不变，则确定当前时 刻为获取第二数据流的时刻。(2)接收端检测自身的缓存信息；当缓存信息达到间隔/偏移信息附近的预置门限时，则确定当前时刻为获取第二 数据流的时刻。(3)接收端检测自身的缓存信息；当缓存信息达到第一数据流速率转变点信息附近的预置门限时，则确定当前时刻 为获取第二数据流的时刻。(4)接收端检测自身的接收数据的速度T =间隔/偏移信息除以接收数据的速度；当接收端时间经过了 T时间长度附近的预置门限时，则确定当前时刻为获取第二 数据流的时刻。可以理解的是，本实施例中仅以几个例子对获取第二数据流的时刻的确定过程进 行了描述，在实际应用中，还可以有更多的确定方式，此处不作限定。需要说明的是，本实施例中，若响应消息中包含有第一数据流与第二数据流之间 的间隔/偏移信息，则接收端可以直接从响应消息中获取到该信息，若响应消息中只包含 有第二数据流的最新数据信息，则接收端还可以根据该第二数据流的最新数据信息以及第 一数据流的起始位置计算第一数据流与第二数据流之间的间隔/偏移信息，具体方式此处 不作限定。需要说明的是，当服务器改变第一数据流的发送速度时，服务器还可以通过通知 消息向接收端发送服务器自身计算得到的加入时刻。本实施例中，接收端若接收到了该通知消息，则接收端还可以根据该加入时刻以 及响应消息确定获取第二数据流的时刻，具体方式可以为若该通知消息中的加入时刻早于接收端自身计算的获取第二数据流的时刻，同时 接收端尚未加入组播组，则接收端在该加入时刻加入组播组。若通知消息中的加入时刻晚于接收端自身计算的获取第二数据流的时刻，同时接 收端尚未加入组播组，则接收端在该获取第二数据流的时刻加入组播组。当接收端加入组播组开始接收原始组播流之后，接收端可以向服务器发送单播流 中止消息以请求服务器停止发送单播流，或者服务器在发送单播流一段时间之后也可以自 动停止发送单播流，此处不作限定。
本实施例中，接收端在没有接收到服务器的加入时刻的通知或者接收到错误的通 知时，通过下发本实施例中的信息，可以使得接收端在适当时刻加入组播组，从而避免接收 端不能加入组播组或者在错误时间加入组播组，避免接收端发生双流问题或者单播流追赶 不上组播流的问题。下面介绍本 发明实施例中的通信系统实施例，请参阅图11，本发明实施例中的通 信系统一个实施例包括服务器1101，用于确定响应消息，所述响应消息包括第一数据流的起始位置信 息、或第一数据流与第二数据流之间的间隔，或第二数据流的最新数据信息，或第一数据流 速率转变点信息中的至少一个；向所述接收端1102发送第一数据流以及所述响应消息；接收端1102，用于接收来自服务器1101的第一数据流以及所述响应消息，根据所 述响应消息进行相应的操作。本实施例中的接收端1102具体用于根据响应消息进行数据处理或确定获取第二 数据流的时刻。本实施例中的通信系统具体可以根据接收端1102进行操作的方式分为以下一些 情况一、接收端1102根据响应消息进行数据处理同样请参阅图11，本实施例中的通信系统包括服务器1101，用于接收来自接收端1102的消息，消息中包括接收端1102的数据 处理能力信息，根据数据处理能力信息以及服务器缓存的数据信息确定响应消息，响应消 息包括第一数据流的起始位置信息、或第一数据流与第二数据流之间的间隔(或者偏移 (offset)信息)、或第二数据流最新数据信息、或第一数据流持续时间、或第一数据流速 度、或第一数据流追上第二数据流需要的时间、或第一数据流速率转变点信息、或数据处理 控制信息、或估计的接收端缓存的第一数据量或时间中的至少一种或多种，而且不限于上 述的信息，将第一数据流以及响应消息发送给接收端1102 ；本实施例中，服务器1101确定响应消息的过程与前述图2(a)所示实施例步骤202 中确定响应消息的过程一致，此处不再赘述。接收端1102，用于接收服务器1101发送的第一数据流以及响应消息，根据响应消 息进行数据处理。本实施例中，接收端1102可以是请求流业务的客户端设备，比如计算机、媒体播 放器、手机等，向接收端提供流业务的服务器1101还可以是其它网络设备，本发明实施例 中以服务器为例作说明，但不限于服务器。本实施例中，接收端1102根据响应消息获取第一数据流与第二数据流之间的间 隔(或者偏移(offset)信息)，并根据第一数据流与第二数据流之间的间隔(或者偏移 (offset)信息)和缓存要求，对第一数据流进行慢速处理或快速处理，具体的慢速处理或 快速处理的时机以及方式与前述图2(a)所示的实施例中的描述一致，此处不再赘述。本实施例中的响应消息中的数据处理控制信息包括快速数据处理参数、或慢速 数据处理参数、或延时数据处理参数；接收端1102根据快速数据处理参数进行快速数据处理，或根据慢速数据处理参 数进行慢速数据处理，或根据延时数据处理参数进行延时数据处理。
本实施例中，接收端1102在适当的时刻，接收第二数据流。适当的时刻可以是在 第一数据流接收过程中，或者是第一数据流结束后。本实施例可以用于IPTV，网络电视、移动电视、DTV等媒体业务中，也可以用于其 它涉及流切换的业务中，如接收端1102先接收第一数据流(一般为快发的第一数据流)，一 段时间之后，如当第一数据流与第二数据流有效载荷即将相同时或者第一数据流追上第二 数据流时，接收端1102接收第二数据流。同样请参阅图11，本发明实施例中的通信系统另一实施例包括服务器1101，用于接收来自接收端1102的消息，消息中包括接收端1102的数据处 理启动条件，根据数据处理启动条件以及服务器缓存的数据信息确定响应消息，该响应消 息中至少包括服务器建议的数据处理启动条件，将第一数据流以及响应消息发送给接收端 1102 ；
本实施例中，服务器1101在确定响应消息时，可以使用默认的第一缓存要求和第 二缓存要求，服务器1101估计在预置条件下接收端缓存的数据量或时间，当该数据量或时 间小于预置的第一缓存要求时，则可以建议使用较大的数据处理启动条件，当该数据量或 时间大于预置的第二缓存要求时，则可以建议使用较小的数据处理启动条件。比如接收端 数据处理启动条件为300ms，默认的第一缓存要求为500ms，服务器估计在IOOms启动时 延下第一数据流结束时接收端缓存的时间为400ms，则服务器可以建议接收端启动时延为 200ms ο本实施例中的预置条件可以是第一数据流结束，和/或第一数据流追上第二数据 流，和/或在一定的数据处理启动条件，和/或在一段时间等。接收端1102，用于接收服务器1101发送的第一数据流以及响应消息，根据响应消 息进行数据处理。本实施例中，接收端1102可以是请求流业务的客户端设备，比如计算机、媒体播 放器、手机等，向接收端提供流业务的服务器1101还可以是其它网络设备，本发明实施例 中以服务器1101为例作说明，但不限于服务器。本实施例中，接收端1102根据服务器建议的启动时延执行延时数据处理。本实施例中，接收端1102在适当的时刻，接收第二数据流。适当的时刻可以是在 第一数据流接收过程中，或者是第一数据流结束后。本实施例可以用于IPTV，网络电视、移动电视、DTV等媒体业务中，也可以用于其 它涉及流切换的业务中，如接收端1102先接收第一数据流(一般为快发的第一数据流)，一 段时间之后，如当第一数据流与第二数据流有效载荷即将相同时或者第一数据流追上第二 数据流时，接收端1102接收第二数据流。同样请参阅图11，本发明实施例中的通信系统另一实施例包括服务器1101，用于确定第一消息，第一消息包括第一数据流的起始位置信息、或第 一数据流与第二数据流之间的间隔(或者偏移(offset)信息)、或第二数据流最新数据 信息、或第一数据流持续时间、或第一数据流速度、或第一数据流追上第二数据流需要的时 间、或第一数据流速率转变点信息、或数据处理控制信息、或估计的接收端缓存的第一数据 量或时间中的至少一种或多种，而且不限于上述的信息，将第一数据流以及响应消息发送 给接收端1102;
本实施例中，服务器1101确定第一消息的过程与前述图3所示的实施例中步骤 302所描述的过程类似，此处不再赘述。接收端1102，用于接收服务器发送的第一数据流以及第一消息，根据第一消息进 行数据处理。本实施例中，接收端1102可以是请求流业务的客户端设备，比如计算机、媒体播 放器、手机等，向接收端提供流业务的服务器1101还可以是其它网络设备，本发明实施例 中以服务器1101为例作说明，但不限于服务器。本实施例中，接收端1102根据响应消息获取第一数据流与第二数据流之间的间 隔(或者偏移(offset)信息)，并根据第一数据流与第二数据流之间的间隔(或者偏移 (offset)信息)和缓存要求，对第一数据流进行慢速处理或快速处理，具体的慢速处理或 快速处理的时机以及方式与前述图3所示实施例中的描述一致，此处不再赘述。 本实施例中的响应消息中的数据处理控制信息包括快速数据处理参数、或慢速 数据处理参数、或延时数据处理参数；接收端1102根据快速数据处理参数进行快速数据处理，或根据慢速数据处理参 数进行慢速数据处理，或根据延时数据处理参数进行延时数据处理。本实施例中，服务器1101还用于接收来自接收端1102的消息。需要说明的是，来自接收端1102的消息中还可以进一步携带缓存要求，则服务器 1101根据缓存要求确定第一数据流的发送起始位置，根据第一数据流的发送起始位置确定 第一消息。本实施例中，接收端1102在适当的时刻，接收第二数据流。适当的时刻可以是在 第一数据流接收过程中，或者是第一数据流结束后。本实施例可以用于IPTV，网络电视、移动电视、DTV等媒体业务中，也可以用于其 它涉及流切换的业务中，如接收端1102先接收第一数据流(一般为快发的第一数据流)，一 段时间之后，如当第一数据流与第二数据流有效载荷即将相同时或者第一数据流追上第二 数据流时，接收端1102接收第二数据流。本实施例中，服务器1101可以向接收端1102发送第一数据流与第二数据流之间 的间隔(或者偏移(offset)信息)等信息，使得接收端1102能够根据该信息进行数据处 理，从而提高了服务器1101向接收端1102发送数据的灵活性；其次，接收端1102慢速数据处理时，可以降低服务器发送的第一数据流的数据 量，从而降低服务器的负载；接收端1102快速数据处理时，可以降低用户之间的时移，使不 同用户看到的内容尽可能同步，提升用户体验。同样请参阅图11，本发明实施例中的通信系统另一实施例包括服务器1101，用于接收来自接收端1102发送的消息，对第一数据流中的数据进行 调整或者修改，将调整或者修改后的第一数据流发送给接收端1102 ；本实施例中，服务器1101对第一数据流中的数据进行调整或者修改的过程与前 述图4所示的实施例中步骤402所描述的过程类似，此处不再赘述。接收端1102，用于接收服务器1101发送的调整或修改后的第一数据流，对调整后 的第一数据流进行数据处理。本实施例中，接收端1102可以是请求流业务的客户端设备，比如计算机、媒体播放器、手机等，向接收端提供流业务的服务器1101还可以是其它网络设备，本发明实施例 中以服务器1101为例作说明，但不限于服务器。本实施例中，接收端1102在适当的时刻，接收第二数据流。适当的时刻可以是在 第一数据流接收过程中，或者是第一数据流结束后。本实施例可以用于IPTV，网络电视、移动电视、DTV等媒体业务中，也可以用于其 它涉及流切换的业务中，如接收端1102先接收第一数据流(一般为快发的第一数据流)，一 段时间之后，如当第一数据流与第二数据流有效载荷即将相同时或者第一数据流追上第二 数据流时，接收端1102接收第二数据流。
本实施例中，服务器1101可以向接收端1102发送增长的第一数据流与减短的第 一数据流，从而提高了服务器1101向接收端1102发送数据的灵活性。二、接收端1102根据响应消息确定获取第二数据流的时刻同样请参阅图11，本实施例中的通信系统包括服务器1101，用于接收来自接收端1102的消息，根据该消息与服务器本地缓存的 数据确定响应消息，该响应消息包括第一数据流的起始位置信息、或第一数据流与第二数 据流之间的间隔，或第二数据流的最新数据信息，或第一数据流速率转变点信息中的至少 一种，向接收端1102发送第一数据流以及响应消息；接收端1102，用于向服务器1101发送消息，接收服务器1101发送的响应消息以及 第一数据流，根据响应消息确定获取第二数据流的时刻。本实施例中，服务器1101还可以用于在调整第一数据流的发送速度时向接收端 发送包含加入时刻的通知消息；接收端1102还用于根据加入时刻以及响应消息确定获取第二数据流的时刻。本实施例中的接收端1102还用于根据第二数据流的最新数据信息以及第一数据 流的起始位置计算第一数据流与第二数据流之间的间隔/偏移信息。为便于理解，下面以一具体应用场景对本发明实施例中的通信系统进行描述当接收端1102需要进行频道切换时，接收端1102会向服务器1101发送频道切换 请求。当服务器1101接收到接收端1102发送的频道切换请求之后，即可向接收端反馈 频道切换响应，该频道切换响应中除了包含原有频道切换响应中的内容之外，还包含有第 一数据流与第二数据流之间的间隔/偏移信息，或第二数据流的最新数据信息中的至少一 种。本实施例中，该第一数据流可以为单播流，第二数据流可以为原始组播流。本实施例中的间隔/偏移信息可以与前述方法实施例中描述的间隔/偏移信息相 同，此处不再赘述。服务器1101向接收端1102发送第一数据流以及频道切换响应；在实际应用中，服务器1101既可以通过单播流的形式向接收端1102发送数据流， 也可以通过组播流的形式向接收端1102发送数据流，服务器1101所发送的数据流的封装 格式不做限定，可以是直接拷贝原始组播数据，也可以是重新封装后的原始组播流，也可以 是以重传数据包的格式封装的数据包，也可以是原始数据流经过重新封装或者没有重新封 装后的数据。
需要说明的是，服务器1101向接收端1102发送频道切换响应和第一数据流并没有严格的顺序关系，既可以先发送第一数据流，再发送频道切换响应，也可以先发送频道切 换响应，再发送第一数据流，或者可以同时发送。接收端1102在向服务器1101发送了频道切换请求之后，则会从服务器1101收到 第一数据流以及频道切换响应。当接收端1102接收到频道切换响应之后，即可检测自身的缓存信息以确定获取 第二数据流的时刻，具体确定过程与前述方法实施例中描述的确定过程相同，此处不再赘 述。需要说明的是，本实施例中，若频道切换响应中包含有第一数据流与第二数据流 之间的间隔/偏移信息，则接收端1102可以直接从频道切换响应中获取到该信息，若频道 切换响应中只包含有第二数据流的最新数据信息，则接收端1102还可以根据该第二数据 流的最新数据信息以及第一数据流的起始位置计算第一数据流与第二数据流之间的间隔/ 偏移信息，具体方式此处不作限定。当服务器1101改变第一数据流的发送速度时，还可以通过通知消息向接收端 1102发送服务器1101自身计算得到的加入时刻。本实施例中，接收端1102若接收到了该通知消息，则根据该加入时刻以及响应消 息确定获取第二数据流的时刻，具体确定过程如前面方法实施例中的描述。当接收端1102加入组播组开始接收原始组播流之后，接收端1102可以向服务器 1101发送单播流中止消息以请求服务器1101停止发送单播流，或者服务器1101在发送单 播流一段时间之后也可以自动停止发送单播流，此处不作限定。本实施例中，接收端1102在没有接收到服务器的加入时刻的通知或者接收到错 误的通知时，通过下发本实施例中的信息，可以使得接收端1102在适当时刻加入组播组， 从而避免接收端1102不能加入组播组或者在错误时间加入组播组，避免接收端1102发生 双流问题或者单播流追赶不上组播流的问题。下面介绍本发明实施例中的服务器实施例，请参阅图12，本发明实施例中的服务 器一个实施例包括接收单元1201，用于接收来自接收端的消息，该消息中包括接收端的数据处理能 力信息；确定单元1202，用于根据数据处理能力信息以及服务器缓存的数据信息确定响应 消息，响应消息包括第一数据流的起始位置信息、或第一数据流与第二数据流之间的间隔 (或者偏移(offset)信息)、或第二数据流最新数据信息、或第一数据流持续时间、或第一 数据流速度、或第一数据流追上第二数据流需要的时间、或第一数据流速率转变点信息、或 数据处理控制信息、或估计的接收端缓存的第一数据量或时间中的至少一种或多种，而且 不限于上述的信息；本实施例中，确定单元1202确定响应消息的过程与前述图2(a)所示实施例步骤 202中确定响应消息的过程一致，此处不再赘述。发送单元1203，用于将第一数据流以及响应消息发送给接收端，以使接收端根据 响应消息进行数据处理。本实施例中，数据处理能力信息包括接收端是否支持快速/慢速数据处理，或支持的快速/慢速数据处理的程度；当接收端 支持慢速数据处理时，确定单元1202根据支持的慢速数据处理能力信 息确定响应消息；当接收端支持快速数据处理时，确定单元1202根据支持的快速数据处理能力信 息确定响应消息。同样请参阅图12，本发明实施例中的服务器另一实施例包括接收单元1201，用于接收来自接收端的消息，该消息中包括接收端的数据处理启 动条件；确定单元1202，用于根据数据处理启动条件以及服务器缓存的数据信息确定响应 消息，响应消息包括服务器建议的数据处理启动条件；本实施例中，确定单元1202在确定响应消息时，可以使用默认的第一缓存要求和 第二缓存要求，确定单元1202估计在预置条件下接收端缓存的数据量或时间，当该数据量 或时间小于预置的第一缓存要求时，则可以建议使用较大的数据处理启动条件，当该数据 量或时间大于预置的第二缓存要求时，则可以建议使用较小的数据处理启动条件。比如接 收端数据处理启动条件为300ms，默认的第一缓存要求为500ms，服务器估计在IOOms启动 时延下第一数据流结束时接收端缓存的时间为400ms，则服务器可以建议接收端启动时延 为 200ms。本实施例中的预置条件可以是第一数据流结束，和/或第一数据流追上第二数据 流，和/或在一定的数据处理启动条件，和/或在一段时间等。发送单元1203，用于将第一数据流以及响应消息发送给接收端，以使接收端根据 响应消息进行数据处理。同样请参阅图12，本发明实施例中的服务器另一实施例包括确定单元1202，用于确定第一消息，第一消息包括第一数据流的起始位置信息、或 第一数据流与第二数据流之间的间隔(或者偏移(offset)信息)、或第二数据流最新数据 信息、或第一数据流持续时间、或第一数据流速度、或第一数据流追上第二数据流需要的时 间、或第一数据流速率转变点信息、或数据处理控制信息、或估计的接收端缓存的第一数据 量或时间中的至少一种或多种，而且不限于上述的信息；本实施例中，确定单元1202确定第一消息的过程与前述图3所示的实施例中步骤 302所描述的过程类似，此处不再赘述。发送单元1203，用于将第一数据流以及第一消息发送给接收端，以使接收端根据 第一消息进行数据处理。本实施例中的服务器还可以进一步包括接收单元1201，用于接收来自接收端的消息，则确定单元1202根据该消息确定第
一消息。本实施例中，接收单元1201接收到的消息中包括缓存要求；则确定单元1202还用于根据消息中包括的缓存要求确定第一数据流的发送起始 位置，根据第一数据流的发送起始位置确定第一消息。本实施例中，发送单元1203可以向接收端发送第一数据流与第二数据流之间的 间隔(或者偏移(offset)信息)等信息，使得接收端能够根据该信息进行数据处理，从而提高了服务器向接收端发送数据的灵活性。请参阅图13，本发明实施例中的服务器另一实施例包括
接收单元1301，用于接收来自接收端的消息；调整单元1302，用于对第一数据流中的数据进行调整或者修改；本实施例中，调整单元1302对第一数据流中的数据进行调整或者修改的过程与 前述图4所示的实施例中步骤402所描述的过程类似，此处不再赘述。发送单元1303，用于将调整或修改后的第一数据流发送给接收端，以使接收端对 调整后的第一数据流进行数据处理。本实施例中，调整单元1302可以根据接收端提供的数据处理能力信息以及服务 器缓存的数据信息对第一数据流进行增长或减短，从而提高了服务器向接收端发送数据的 灵活性。下面介绍本发明实施例中的服务器实施例，请参阅图14，本发明实施例中的服务 器一个实施例包括数据存储模块1401，用于存储至少一个数据流的数据；生成模块1402，用于对数据存储模块1401存储的第二数据流的数据进行分析，生 成第一数据流；响应生成模块1403，用于确定响应消息，该响应消息包括第一数据流的起始位 置信息、或第一数据流与第二数据流之间的间隔，或第二数据流的最新数据信息，或第一数 据流速率转变点信息中的至少一种；发送模块1404，用于向接收端发送响应消息，向接收端发送第一数据流。本实施例中，响应生成模块1403可以根据来自接收端的消息与数据存储模块 1601保存的数据确定响应消息，响应消息包括第一数据流的起始位置信息、或第一数据 流与第二数据流之间的间隔，或第二数据流的最新数据信息，或第一数据流速率转变点信 息中的至少一种。本实施例中的服务器还可以进一步包括消息接收模块1400，用于接收来自接收 端的消息，接收到的消息中包括有接收端的数据处理能力信息；响应生成模块1403根据数据处理能力信息确定响应消息。为便于理解，下面以一具体应用场景对本发明实施例中的服务器进行描述当接收端需要进行频道切换时，服务器会接收到接收端发送的频道切换请求。当服务器接收到接收端发送的频道切换请求之后，响应生成模块1403即可确定 频道切换响应，该频道切换响应中除了包含原有频道切换响应中的内容之外，还包含第一 数据流的起始位置信息、或第一数据流与第二数据流之间的间隔，或第二数据流的最新数 据信息，或第一数据流速率转变点信息中的至少一种。发送模块1404向接收端发送第一数据流，以及频道切换响应，以使得接收端根据 频道切换响应获得加入组播组时刻。在实际应用中，发送模块1404既可以通过单播流的形式向接收端发送数据流，也 可以通过组播流的形式向接收端发送数据流，发送模块1404所发送的数据流的封装格式 不做限定，可以是直接拷贝原始组播数据，也可以是重新封装后的原始组播流，也可以是以 重传数据包的格式封装的数据包，也可以是原始数据流经过重新封装或者没有重新封装后的数据。本实施例中，服务器将第一数据流以及频道切换响应发送至接收端之后，接收端 即可根据频道切换响应以及自身的缓存确定获取第二数据流的时刻，所以接收端在没有接 收到服务器的加入时刻的通知或者接收到错误的通知时，通过下发本实施例中的信息，可 以使得接收端在适当时刻加入组播组，从而避免接收端不能加入组播组或者在错误时间加 入组播组，避免接收端发生双流问题或者单播流追赶不上组播流的问题。下面介绍本发明实施例中的网络设备实施例，请参阅图15，本发明实施例中的网 络设备一个实施例包括数据接收单元1502，用于接收服务器发送的第一数据流以及消息，消息包括第一 数据流的起始位置信息、或第一数据流与第二数据流之间的间隔(或者偏移(offset)信 息)、或第二数据流最新数据信息、或第一数据流持续时间、或第一数据流速度、或第一数据 流追上第二数据流需要的时间、或第一数据流速率转变点信息、或数据处理控制信息、或估 计的接收端缓存的第一数据量或时间中的至少一种或多种，而且不限于上述的信息；数据处理控制单元1505，用于根据数据接收单元1502接收到的消息进行数据处 理。需要说明的是，本实施例中数据接收单元1502接收到的消息可以是前述图2(a) 所示的实施例中描述的响应消息，也可以是图3所示的实施例中描述的第一消息，具体此 处不作限定。本实施例中的网络设备还可以进一步包括请求发送单元1501，用于向服务器发送消息，消息中包括自身的数据处理能力信 息，或缓存要求。本实施例中的响应消息中的数据处理控制信息包括快速数据处理参数、或慢速 数据处理参数、或延时数据处理参数；数据处理控制单元1505根据快速数据处理参数进行快速数据处理，或根据慢速 数据处理参数进行慢速数据处理，或根据延时数据处理参数进行延时数据处理。本实施例中的网络设备还可以进一步包括获取单元1503，用于根据响应消息获取第一数据流与第二数据流之间的间隔(或 者偏移(offset)信息)，并根据第一数据流与第二数据流之间的间隔(或者偏移(offset) 信息)、或估计的接收端缓存的第一数据量或时间确定真实间隔对应的数据量或时间；判断单元1504，用于判断真实间隔对应的数据量或时间是否满足预置的缓存要 求；本实施例中的真实间隔的含义与前述图2(a)所示的实施例中步骤204中描述的 真实间隔的含义相同，此处不再赘述。数据处理控制单元1505还用于根据所述第一数据流与第二数据流之间的间隔和 缓存要求，对所述第一数据流进行慢速处理或快速处理。本实施例中的数据处理控制单元1505具体可以当真实间隔对应的数据量或时间 小于预置的第一缓存要求时，则对第一数据流进行慢速处理，当真实间隔对应的数据量或 时间大于预置的第二缓存要求时，则对第一数据流进行快速处理。本实施例中的第一缓存要求以及第二缓存要求的含义与前述图2(a)所示的实施例中描述的第一缓存要求以及第二缓存要求的含义相同，此处不再赘述。本实施例中，接收端在适当的时刻，接收第二数据流。适当的时刻可以是在第一数 据流接收过程中，或者是第一数据流结束后。本实施例可以用于IPTV，网络电视、移动电视、DTV等媒体业务中，也可以用于其 它涉及流切换的业务中，如接收端先接收第一数据流(一般为快发的第一数据流)，一段时 间之后，如当第一数据流与第二数据流有效载荷即将相同时或者第一数据流追上第二数据 流时，接收端接收第二数据流。本实施例中的网络设备可以是请求流业务的客户端设备，比如计算机、媒体播放 器、手机等。下面介绍本发明实施例中的网络设备实施例，请参阅图16，本发明实施例中的网 络设备一个实施例包括请求发送模块1601，用于向服务器发送消息；接收模块1602，用于接收服务器发送的响应消息，响应消息包括第一数据流的 起始位置信息、或第一数据流与第二数据流之间的间隔，或第二数据流的最新数据信息，或 第一数据流速率转变点信息中的至少一种；本实施例中，第一数据流速率转变点信息可以包括第一数据流速率转变时间，或 第一数据流速率转变时与第二数据流之间的间隔，或第一数据流速率转变时接收端缓存到 的数据量或时间，或第一数据流速率转变时第一数据流与第二数据流之间间隔减少的数据 量或时间。确定模块1603，用于根据响应消息获取间隔信息，根据间隔信息确定获取第二数 据流的时刻；数据接收模块1604，用于接收服务器发送的第一数据流；解码与播放模块1605，用于对接收到的第一数据流进行解码播放。本实施例中的确定模块1603还可以进一步包括响应处理模块16031，用于获取所述响应消息中的第一数据流与第二数据流之间 的间隔；或者，根据所述第二数据流的最新数据信息以及第一数据流的起始位置确定第一 数据流与第二数据流之间的间隔；或者，根据所述响应消息中的第一数据流速率转变点信 息，以及第一数据流的起始位置计算第一数据流与第二数据流之间的间隔；确定子模块16032，用于根据所述响应处理模块16031确定的间隔信息，以及缓存 信息确定获取第二数据流的时刻。本实施例中，接收模块1602还可以用于接收服务器发送的通知消息，通知消息中 携带有加入时刻；确定模块1603还用于根据响应消息以及加入时刻确定获取第二数据流的时刻。需要说明的是，本实施例中，请求发送模块1601以及解码与播放模块1605为可选 模块。为便于理解，下面以一具体应用场景对本发明实施例中的网络设备进行描述当接收端需要进行频道切换时，请求发送模块1601会向服务器发送频道切换请 求。请求发送模块1601在向服务器发送了频道切换请求之后，接收模块1602则会从服务器收到第一数据流以及频道切换响应。本实施例中，该频道切换响应由服务器根据频道切换请求与服务器本地缓存的数 据确定得到，频道切换响应包括第一数据流的起始位置信息、或第一数据流与第二数据流 之间的间隔，或第二数据流的最新数据信息，或第一数据流速率转变点信息中的至少一种。当接收模块1602接收端接收到频道切换响应之后，确定模块1603即可检测自身 所接收到的数据的信息，可以通过如下方式确定获取第二数据流的时刻(1)接收端检测自身的缓存信息；当缓存信息增大到间隔/偏移信息后又开始减小或开始维持不变，则确定当前时 刻为获取第二数据流的时刻。(2)接收端检测自身的缓存信息；当缓存信息达到间隔/偏移信息附近的预置门限时，则确定当前时刻为获取第二 数据流的时刻。(3)接收端检测自身的缓存信息；当缓存信息达到第一数据流速率转变点信息附近的预置门限时，则确定当前时刻 为获取第二数据流的时刻。(4)接收端检测自身的接收数据的速度T =间隔/偏移信息除以接收数据的速度；当接收端时间经过了 T时间长度附近的预置门限时，则确定当前时刻为获取第二 数据流的时刻。可以理解的是，本实施例中仅以几个例子对获取第二数据流的时刻的确定过程进 行了描述，在实际应用中，还可以有更多的确定方式，此处不作限定。需要说明的是，本实施例中，若频道切换响应中包含有第一数据流与第二数据流 之间的间隔/偏移信息，则响应处理模块1606可以直接从频道切换响应中获取到该信息， 若频道切换响应中只包含有第二数据流的最新数据信息，则响应处理模块1606还可以根 据该第二数据流的最新数据信息以及第一数据流的起始位置计算第一数据流与第二数据 流之间的间隔/偏移信息，具体方式此处不作限定。当服务器改变第一数据流的发送速度时，还可以通过通知消息向接收端发送服务 器自身计算得到的加入时刻。本实施例中，接收模块1602若接收到了该通知消息，则确定模块1603可以根据该 加入时刻与响应消息获取间隔信息，根据间隔信息确定获取第二数据流的时刻。接收端在加入组播组之后，即可开始接收原始组播流。本实施例中，接收端在没有接收到服务器的加入时刻的通知或者接收到错误的通 知时，通过下发本实施例中的信息，可以使得接收端在适当时刻加入组播组，从而避免接收 端不能加入组播组或者在错误时间加入组播组，避免接收端发生双流问题或者单播流追赶 不上组播流的问题。本领域普通技术人员可以理解实现上述实施例方法中的全部或部分步骤是可以 通过程序来指令相关的硬件完成，所述的程序可以存储于一种计算机可读存储介质中，上 述提到的存储介质可以是只读存储器，磁盘或光盘等。以上对本发明所提供的一种实现流业务的方法及通信系统以及相关设备进行了
38详细介绍，对于本领域的一般技术人员，依据本发明实施例的思想，在具体实施方式
及应用 范围上均会有改变之处，综上所述，本说明书内容不应理解为对本发明的限制。
权利要求
一种实现流业务的方法，其特征在于，包括服务器确定响应消息，所述响应消息中包括第一数据流与第二数据流之间的间隔、或第二数据流最新数据信息、或第一数据流速率转变点信息中的至少一个；所述服务器向所述接收端发送第一数据流以及所述响应消息，以使所述接收端根据所述响应消息进行相应的操作。
2.根据权利要求1所述的方法，其特征在于，所述第一数据流速率转变点信息包括 第一数据流速率转变时间，或第一数据流速率转变时与第二数据流之间的间隔，或第一数据流速率转变时接收端缓存到的数据量或时间，或第一数据流速率转变时第一数据流 与第二数据流之间间隔减少的数据量或时间。
3.根据权利要求1所述的方法，其特征在于，所述服务器确定响应消息之前还包括 服务器接收来自接收端的消息，所述来自接收端的消息中包括所述接收端的数据处理能力信息；所述服务器确定响应消息包括 服务器根据所述数据处理能力信息确定响应消息。
4.根据权利要求1至3中任一项所述的方法，其特征在于，所述以使接收端根据所述响 应消息进行相应的操作包括以使所述接收端根据所述响应消息获取间隔信息，根据所述 间隔信息进行数据处理。
5.根据权利要求1所述的方法，其特征在于，所述服务器确定响应消息之前还包括 服务器接收来自接收端的消息；所述服务器确定响应消息包括服务器根据所述来自接收端的消息与本地存储的数据 确定响应消息。
6.根据权利要求1或5所述的方法，其特征在于，所述以使接收端根据所述响应消息进 行相应的操作包括以使所述接收端根据所述响应消息获取间隔信息，根据所述间隔信息 确定获取第二数据流的时刻。
7.一种实现流业务的方法，其特征在于，包括接收端接收来自服务器的响应消息，所述响应消息中包括第一数据流与第二数据 流之间的间隔，或第二数据流的最新数据信息，或第一数据流速率转变点信息中的至少一 种；所述接收端根据所述响应消息执行相应的操作。
8.根据权利要求7所述的方法，其特征在于，所述第一数据流速率转变点信息包括 第一数据流速率转变时间，或第一数据流速率转变时与第二数据流之间的间隔，或第一数据流速率转变时接收端缓存到的数据量或时间，或第一数据流速率转变时第一数据流 与第二数据流之间间隔减少的数据量或时间。
9.根据权利要求7所述的方法，其特征在于，所述接收端接收来自服务器的响应消息 之前还包括接收端向服务器发送消息；所述响应消息由所述服务器根据所述接收端发送的消息与服务器本地缓存的数据确 定得到。
10.根据权利要求7所述的方法，其特征在于，所述接收端根据响应消息执行相应的操作包括接收端根据所述响应消息确定间隔信息，根据所述间隔信息和缓存信息确定获取第二 数据流的时刻。
11.根据权利要求10所述的方法，其特征在于，所述接收端根据间隔信息和缓存信息 确定获取第二数据流的时刻之前包括接收端检测接收端缓存信息；所述接收端根据间隔信息和缓存信息确定获取第二数据流的时刻包括 当所述缓存信息增大到所述间隔后又开始减小或开始维持不变时，确定开始获取第二 数据流；或者，当所述缓存信息达到所述间隔附近的预置门限时，确定开始获取第二数据流；或者， 当所述缓存信息达到所述第一数据流速率转变点信息附近的预置门限时，确定开始获 取第二数据流。
12.根据权利要求10所述的方法，其特征在于，所述接收端根据所述响应消息确定间 隔信息包括接收端获取所述响应消息中的第一数据流与第二数据流之间的间隔；或者， 接收端根据所述响应消息中的第二数据流的最新数据信息，以及第一数据流的起始位 置计算第一数据流与第二数据流之间的间隔；或者，接收端根据所述响应消息中的第一数据流速率转变点信息，以及第一数据流的起始位 置计算第一数据流与第二数据流之间的间隔。
13.一种实现流业务的方法，其特征在于，包括服务器接收来自接收端的消息，所述消息中包括所述接收端的数据处理能力信息； 所述服务器根据所述数据处理能力信息确定响应消息，所述响应消息包括第一数据流 与第二数据流之间的间隔、或第二数据流最新数据信息、或第一数据流追上第二数据流需 要的时间、或第一数据流速率转变点信息中的至少一种；所述服务器将第一数据流以及所述响应消息发送给所述接收端，以使所述接收端根据 所述响应消息进行数据处理。
14.根据权利要求13所述的方法，其特征在于，所述数据处理能力信息包括所述接收 端是否支持快速数据处理或慢速数据处理，或者支持的快速数据处理的程度或慢速数据处 理的程度；所述服务器根据所述数据处理能力信息确定响应消息包括当所述接收端支持慢速数据处理时，服务器根据所述支持的慢速数据处理能力信息确 定响应消息； 或，当所述接收端支持快速数据处理时，服务器根据所述支持的快速数据处理能力信息确 定响应消息。
15.根据权利要求13或14所述的方法，其特征在于，所述响应消息中的数据处理控制 信息包括快速数据处理参数、或慢速数据处理参数、或延时数据处理参数； 所述第一数据量或时间包括第一数据流结束时或第一数据流结束后接收端缓存的数据量或时间，或第一数据流追 上第二数据流时或第一数据流追上第二数据流后接收端缓存的数据量或时间，或在一定的 数据处理启动条件下接收端缓存的数据量或时间，或在一段时间后接收端缓存的数据量或 时间。
16.根据权利要求15所述的方法，其特征在于，所述接收端根据所述响应消息进行数 据处理包括接收端根据所述快速数据处理参数进行快速数据处理，或根据所述慢速数据处理参数 进行慢速数据处理，或根据所述延时数据处理参数进行延时数据处理。
17.根据权利要求13或14所述的方法，其特征在于，所述服务器将第一数据流以及所 述响应消息发送给所述接收端之后，还包括接收端根据所述响应消息获取所述第一数据流与第二数据流之间的间隔；接收端根据所述第一数据流与第二数据流之间的间隔和缓存要求，对所述第一数据流 进行慢速处理或快速处理。
18.根据权利要求17所述的方法，其特征在于，所述接收端根据所述第一数据流与第 二数据流之间的间隔和缓存要求，对所述第一数据流进行慢速处理或快速处理包括接收端根据所述第一数据流与第二数据流之间的间隔或所述估计的接收端缓存的第 一数据量或时间确定真实间隔对应的数据量或时间；当所述真实间隔对应的数据量或时间小于预置的第一缓存要求时，则对所述第一数据 流进行慢速处理；当所述真实间隔对应的数据量或时间大于预置的第二缓存要求时，则对所述第一数据 流进行快速处理。
19.根据权利要求17所述的方法，其特征在于，所述接收端根据所述响应消息获取所 述第一数据流与第二数据流之间的间隔包括接收端从所述响应消息获取所述第一数据流与第二数据流之间的间隔；或，接收端根据所述第二数据流最新数据信息、第一数据流追上第二数据流需要的时间、 或第一数据流速率转变点信息中的至少一种计算第一数据流与第二数据流之间的间隔。
20.一种实现流业务的方法，其特征在于，包括服务器确定第一消息，所述第一消息包括第一数据流与第二数据流之间的间隔、或第 二数据流最新数据信息、或第一数据流追上第二数据流需要的时间、或第一数据流速率转 变点信息中的至少一种；所述服务器将第一数据流以及所述第一消息发送给所述接收端，以使所述接收端根据 所述第一消息进行数据处理。
21.根据权利要求20所述的方法，其特征在于，所述第一数据流速率转变点信息包括第一数据流速率转变时间，或第一数据流速率转变时与第二数据流之间的间隔，或第一数据流速率转变时接收端缓存到的数据量或时间，或第一数据流速率转变时第一数据流 与第二数据流之间间隔减少的数据量或时间。
22.根据权利要求20或21所述的方法，其特征在于，所述服务器将第一数据流以及所 述第一消息发送给所述接收端之后包括接收端根据所述第一消息获取所述第一数据流与第二数据流之间的间隔； 接收端根据所述第一数据流与第二数据流之间的间隔和缓存要求，对所述第一数据流 进行慢速处理或快速处理。
23.根据权利要求22所述的方法，其特征在于，所述接收端根据所述第一数据流与第 二数据流之间的间隔和缓存要求，对所述第一数据流进行慢速处理或快速处理包括接收端根据所述第一数据流与第二数据流之间的间隔或所述估计的接收端缓存的第 一数据量或时间确定真实间隔对应的数据量或时间；当所述真实间隔对应的数据量或时间小于预置的第一缓存要求时，则对所述第一数据 流进行慢速处理；当所述真实间隔对应的数据量或时间大于预置的第二缓存要求时，则对所述第一数据 流进行快速处理。
24.根据权利要求22所述的方法，其特征在于，所述接收端根据所述第一消息获取所 述第一数据流与第二数据流之间的间隔包括接收端从所述第一消息获取所述第一数据流与第二数据流之间的间隔； 或，接收端根据所述第二数据流最新数据信息、或第一数据流追上第二数据流需要的时 间、或第一数据流速率转变点信息中的至少一种计算第一数据流与第二数据流之间的间 隔。
25.根据权利要求20或21所述的方法，其特征在于，在所述确定第一消息之前，还包括所述服务器接收来自接收端的消息； 所述确定第一消息包括所述服务器根据所述来自接收端的消息确定第一消息。
26.根据权利要求25所述的方法，其特征在于，所述来自接收端的消息中包括缓存要求；所述服务器确定第一消息包括服务器根据所述接收端的消息中包括的缓存要求确定第一数据流的发送起始位置； 根据所述第一数据流的发送起始位置确定所述第一消息。
27.一种通信系统，其特征在于，包括服务器，用于确定响应消息，所述响应消息包括第一数据流与第二数据流之间的间 隔，或第二数据流最新数据信息，或第一数据流速率转变点信息中的至少一个；向所述接收 端发送第一数据流以及所述响应消息；接收端，用于接收来自服务器的第一数据流以及所述响应消息，根据所述响应消息进 行相应的操作。
28.根据权利要求27所述的通信系统，其特征在于，所述接收端用于根据所述响应消 息进行数据处理或确定获取第二数据流的时刻。
29.根据权利要求27或28所述的通信系统，其特征在于，所述接收端还用于根据所述 第二数据流的最新数据信息以及第一数据流的起始位置计算第一数据流与第二数据流之 间的间隔。
30.一种通信系统，其特征在于，包括服务器，用于接收来自接收端的消息，所述消息中包括所述接收端的数据处理能力信 息；根据所述数据处理能力信息确定响应消息，所述响应消息包括第一数据流与第二数据 流之间的间隔、或第二数据流最新数据信息、或第一数据流追上第二数据流需要的时间、或 第一数据流速率转变点信息中的至少一种；将第一数据流以及所述响应消息发送给所述接 收端；接收端，用于接收服务器发送的第一数据流以及所述响应消息，根据所述响应消息进 行数据处理。
31.根据权利要求30所述的通信系统，其特征在于，所述接收端根据所述响应消息获取所述第一数据流与第二数据流之间的间隔，根据所 述第一数据流与第二数据流之间的间隔和缓存要求，对所述第一数据流进行慢速处理或快 速处理。
32.根据权利要求30或31所述的通信系统，其特征在于，所述响应消息中的数据处理 控制信息包括快速数据处理参数、或慢速数据处理参数、或延时数据处理参数；所述接收端根据所述快速数据处理参数进行快速数据处理，或根据所述慢速数据处理 参数进行慢速数据处理，或根据所述延时数据处理参数进行延时数据处理。
33.一种通信系统，其特征在于，包括服务器，用于确定第一消息，所述第一消息包括第一数据流与第二数据流之间的间隔、 或第二数据流最新数据信息、或第一数据流追上第二数据流需要的时间、或第一数据流速 率转变点信息中的至少一种；将第一数据流以及所述第一消息发送给所述接收端；接收端，用于接收服务器发送的第一数据流以及第一消息，根据所述第一消息进行数 据处理。
34.根据权利要求33所述的通信系统，其特征在于，所述第一数据流速率转变点信息 包括第一数据流速率转变时间，或第一数据流速率转变时与第二数据流之间的间隔，或第 一数据流速率转变时接收端缓存到的数据量或时间，或第一数据流速率转变时第一数据流 与第二数据流之间间隔减少的数据量或时间。
35.根据权利要求33所述的通信系统，其特征在于，所述接收端根据所述第一消息获取所述第一数据流与第二数据流之间的间隔，根据所 述第一数据流与第二数据流之间的间隔和缓存要求，对所述第一数据流进行慢速处理或快 速处理。
36.根据权利要求33至35中任一项所述的通信系统，其特征在于，所述服务器还用于 接收来自接收端的消息。
37.根据权利要求36所述的通信系统，其特征在于，所述来自接收端的消息中包括缓 存要求；所述服务器根据所述缓存要求确定第一数据流的发送起始位置，根据所述第一数据流 的发送起始位置确定所述第一消息。
38.一种服务器，其特征在于，包括响应生成模块，用于确定响应消息，所述响应消息包括第一数据流与第二数据流之间的间隔、或第二数据流最新数据信息、或第一数据流速率转变点信息中的至少一种；发送模块，用于向接收端发送第一数据流以及所述响应消息，以使所述接收端根据所 述响应消息进行相应的操作。
39.根据权利要求38所述的服务器，其特征在于，所述第一数据流速率转变点信息包括第一数据流速率转变时间，或第一数据流速率转变时与第二数据流之间的间隔，或第 一数据流速率转变时接收端缓存到的数据量或时间，或第一数据流速率转变时第一数据流 与第二数据流之间间隔减少的数据量或时间。
40.根据权利要求38或39所述的服务器，其特征在于，所述服务器还包括消息接收模块，用于接收来自所述接收端的消息，所述接收到的消息中包括有接收端 的数据处理能力信息；所述响应生成模块根据所述数据处理能力信息确定响应消息。
41.根据权利要求38或39所述的服务器，其特征在于，所述响应生成模块根据所述来 自接收端的消息与数据存储模块保存的数据确定响应消息。
42.一种服务器，其特征在于，包括接收单元，用于接收来自接收端的消息，所述消息中包括所述接收端的数据处理能力 fn息；确定单元，用于根据所述数据处理能力信息确定响应消息，所述响应消息包括第一数 据流与第二数据流之间的间隔、或第二数据流最新数据信息、或第一数据流追上第二数据 流需要的时间、或第一数据流速率转变点信息中的至少一种；发送单元，用于将第一数据流以及所述响应消息发送给所述接收端，以使所述接收端 根据所述响应消息进行数据处理。
43.根据权利要求42所述的服务器，其特征在于，所述数据处理能力信息包括所述接 收端是否支持快速/慢速数据处理，或支持的快速/慢速数据处理的程度；当所述接收端支持慢速数据处理时，所述确定单元根据所述支持的慢速数据处理能力 信息确定响应消息；当所述接收端支持快速数据处理时，所述确定单元根据所述支持的快速数据处理能力 信息确定响应消息。
44.一种服务器，其特征在于，包括确定单元，用于确定第一消息，所述第一消息包括第一数据流与第二数据流之间的间 隔、或第二数据流最新数据信息、或第一数据流追上第二数据流需要的时间、或第一数据流 速率转变点信息中的至少一种；发送单元，用于将第一数据流以及所述第一消息发送给所述接收端，以使所述接收端 根据所述第一消息进行数据处理。
45.根据权利要求44所述的服务器，其特征在于，所述第一数据流速率转变点信息包括第一数据流速率转变时间，或第一数据流速率转变时与第二数据流之间的间隔，或第 一数据流速率转变时接收端缓存到的数据量或时间，或第一数据流速率转变时第一数据流 与第二数据流之间间隔减少的数据量或时间。
46.根据权利要求45所述的服务器，其特征在于，所述服务器还包括接收单元，用于接收来自接收端的消息。
47.根据权利要求46所述的服务器，其特征在于，所述接收单元接收到的消息中包括缓存要求；所述确定单元还用于根据所述消息中包括的缓存要求确定第一数据流的发送起始位 置，根据所述第一数据流的发送起始位置确定第一消息。
48.一种网络设备，其特征在于，包括接收模块，用于接收服务器发送的响应消息，所述响应消息包括第一数据流与第二数 据流之间的间隔、或第二数据流的最新数据信息、或第一数据流速率转变点信息中的至少 一种；确定模块，用于根据所述响应消息确定间隔信息，根据所述间隔信息确定获取第二数 据流的时刻。
49.根据权利要求48所述的网络设备，其特征在于，所述第一数据流速率转变点信息 包括第一数据流速率转变时间，或第一数据流速率转变时与第二数据流之间的间隔，或第 一数据流速率转变时接收端缓存到的数据量或时间，或第一数据流速率转变时第一数据流 与第二数据流之间间隔减少的数据量或时间。
50.根据权利要求48或49所述的网络设备，其特征在于，所述确定模块包括响应处理模块，用于获取所述响应消息中的第一数据流与第二数据流之间的间隔；或 者，根据所述第二数据流的最新数据信息以及第一数据流的起始位置确定第一数据流与第 二数据流之间的间隔；或者，根据所述响应消息中的第一数据流速率转变点信息，以及第一 数据流的起始位置计算第一数据流与第二数据流之间的间隔；确定子模块，用于根据所述响应处理模块确定的间隔信息，以及缓存信息确定获取第 二数据流的时刻。
51.一种网络设备，其特征在于，包括数据接收单元，用于接收来自服务器的第一数据流以及消息，所述来自服务器的消息 包括第一数据流与第二数据流之间的间隔、或第二数据流最新数据信息、或第一数据流追 上第二数据流需要的时间、或第一数据流速率转变点信息中的至少一种；数据处理控制单元，用于根据所述来自服务器的消息进行数据处理。
52.根据权利要求51所述的网络设备，其特征在于，所述第一数据流速率转变点信息 包括第一数据流速率转变时间，或第一数据流速率转变时与第二数据流之间的间隔，或第 一数据流速率转变时接收端缓存到的数据量或时间，或第一数据流速率转变时第一数据流 与第二数据流之间间隔减少的数据量或时间。
53.根据权利要求51或52所述的网络设备，其特征在于，所述网络设备还包括请求发送单元，用于向服务器发送消息，所述消息中包括自身的数据处理能力信息，或 缓存要求。
54.根据权利要求53所述的网络设备，其特征在于，所述网络设备还包括获取单元，用于根据所述来自服务器的消息获取所述第一数据流与第二数据流之间的8间隔，根据所述第一数据流与第二数据流之间的间隔、或估计的接收端缓存的第一数据量 或时间确定真实间隔对应的数据量或时间；判断单元，用于判断所述真实间隔对应的数据量或时间是否满足预置的缓存要求； 所述数据处理控制单元用于根据所述第一数据流与第二数据流之间的间隔和缓存要 求，对所述第一数据流进行慢速处理或快速处理。
全文摘要
本发明实施例公开了一种实现流业务的方法及通信系统以及相关设备。方法包括服务器确定响应消息，所述响应消息中包括服务器确定响应消息，所述响应消息中包括第一数据流与第二数据流之间的间隔、或第二数据流最新数据信息、或第一数据流速率转变点信息中的至少一个；所述服务器向所述接收端发送第一数据流以及所述响应消息，以使所述接收端根据所述响应消息进行相应的操作。本发明实施例还提供一种通信系统以及相关设备。本发明实施例可以有效提高数据发送的灵活性。
文档编号H04L12/56GK101964716SQ20091020758
公开日2011年2月2日 申请日期2009年10月23日 优先权日2009年7月21日
发明者刘欣, 张卫娥, 王业奎, 胡昌启, 艾常权, 许阳坡, 邸佩云, 邹子轩 申请人:华为技术有限公司