CN101212328A - 组播频道快速启动系统及其方法 - Google Patents

Abstract

本发明公开了一种组播频道快速启动系统，包括流服务器、头端和至少一个播放器，其中，头端产生或者中转频道的媒体数据并发送；播放器设置有缓冲区，用于播放所述媒体数据；流服务器，设置有历史缓冲区，所述历史缓存区保存有历史码流；接收所述头端发出的码流，保存在所述历史缓冲区，当所述流服务器收到所述播放器的组播请求后，所述流服务器将历史缓冲区的历史码流，以单播方式填充到所述播放器的缓冲区，当所述播放器加入组播组后，所述流服务器停止发送单播码流；所述播放器加入组播组后接收组播码流，并将所述组播码流和单播码流拼接。本发明还公开了一种组播频道快速启动方法。

Description

组播频道快速启动系统及其方法

技术领域

本发明涉及一种流媒体技术，具体说，涉及一种组播频道快速启动的系统和方法。

背景技术

在一个现有流媒体频道系统中，头端、流服务器和播放器是最基本的组成部分，通常采用TCP/IP协议转输码流和信令，播放器和流服务器之间采用RTSP协议交换信令，在UDP或TCP协议之上承载RTP或TS等格式的载荷，传输媒体数据。一般来说，UDP较TCP更为常用。

组播是UDP的一种，由于历史和现有不少网络都不能很好地支持组播，当网络不能支持组播协议时，只能由流服务器接收头端发出的码流，然后通过TCP协议或点对点的UDP协议，分发给各个播放器，我们把码流分发给其中一个播放器的过程称为单播。在一个IPTV频道系统中，单播是流服务器最为基本的功能之一。

组播是TCP/IP协议中，从一个单点向多点发送相同的数据协议，发送者只需要向组播IP地址发送一份组播UDP包，然后由网络上的路由器把数据分发复制到感兴趣的接收者，不管接收者的数量，发送者的工作负荷是常数，同时，组播协议的设计，可以把网络上传输的数据量减到最小。这一特性，使得组播非常适合于频道数据的传输。

如果网络支持组播协议，播放器则可以通过加入组播组，直接接收头端发出的组播码流，从而大大减轻流服务器的工作负荷和降低网络流量。由于通过组播传输码流，中间无须流服务器参与，这样减少了一个故障点，也提高了系统的可靠性。

如图1所示，组播频道子系统是流媒体频道系统的一个子系统，一般来说，逻辑上没有流服务器的参与，仅仅由一个头端和数量不等的播放器组成，由于头端没有信令交互能力，头端只能按照媒体编码方法的要求，按照固有的方式发送码流。例如按照一定的时间间隔，定期发送视频媒体的I帧数据等。头端发送媒体码流时，数据发送的方向是单向的，由头端发送到播放器。

客户端是由用户操纵的，可能在任意一个时刻点，加入组播接收码流，因此接收到的码流的起始点是随机的。

而相当多的编码方法，尤其是视频编码方法，必须接收到一帧完整的关键帧(例如，视频编码的I帧)，其解码结果才是完整正确的。收到关键帧之前接收的码流不能完全正确解码，要么是只能丢弃，要么强行解码，但解码后的数据是有误的，对于视频来说，会有马赛克或停顿等异常现象出现，同样影响用户体验。

从开始接收数据，到接收到关键帧的码流，需要一段时间，这段时刻称为关键帧等待时间。关键帧等待时间取决时关键帧的发送频率，平均值为关键帧的发送间隔的1/2。

同时，为了防止传输的抖动，客户端一般都设置了缓冲区，需要首先把接收到的码流保存到缓冲区中，当缓冲区填充到一定大小时，才把媒体数据从缓冲区取出解码播放。这段缓冲区的填充，也需要一段时间，这段时间称为缓冲填充时间。

同时，从播放器加入组播组，到收到组播包，也需要一段时间，这段时间称为加入组播时间，加入组播时间取决网络结构。在某些网络结构或环境下，这个时间可能非常长。

在一个码率大于1Mbps的IPTV频道系统中，关键帧的发送间隔往往设为2秒左右，同时缓冲填充时间也为2秒左右。也就是说，从用户开始点播一个频，到正常观看节目，不计加入组播时间，平均需要3秒左右的等待时间。而人在观看电视时，切换频道时能容忍的等待时间往往在1秒以内，因此有必要采用某些技术方案，提高播放启动速度，提高用户体验。

绝大部分播放器，都设置了最大等待时间，如果在规定的时间内，收到不到组播包，则认为播放失败，中止播放。如果出现某些特殊情况，加入组播时间大于最大等待时间，还可能造成播放失败。

在申请号为CN200410069507的专利申请中，提及了一些提高组播频道切换速度的技术方案。该方法的核心是当用户终端离开当前所在的组播频道时，根据所述用户终端接入的位置信息判断该组播频道下的该位置信息是否还存在其他接入的用户终端，并根据判断结果对相应组播频道的组播复制表进行维护。其目的是解决播放器从一个组播频道，切换到另一个频道时，切换时间长的问题，它工作的层次在网络设备，并没有解决前面所述的问题。

发明内容

本发明所解决的技术问题是提供一种组播频道快速启动系统，提高了播放器的启动速度，并且缩短了切换时间。

技术方案如下：

组播频道快速启动系统，包括：头端和至少一个播放器，其中，

头端，产生或者中转频道的媒体数据并发送；

播放器，设置有缓冲区，用于播放所述媒体数据；

流服务器，设置有历史缓冲区，所述历史缓存区保存有历史码流；接收所述头端发出的码流，保存在所述历史缓冲区，当所述流服务器收到所述播放器的组播请求后，所述流服务器将历史缓冲区的历史码流，以单播方式填充到所述播放器的缓冲区，当所述播放器加入组播组后，所述流服务器停止发送单播码流；

所述播放器加入组播组后接收组播码流，并将所述组播码流和单播码流拼接。

优选的，所述流服务器以TCP方式发送单播码流。

优选的，当所述历史缓冲区耗尽时，所述流服务器向播放器发送快发结束通知。

本发明所解决的另一个技术问题是提供一种组播频道快速启动方法，提高了播放器的启动速度，并且缩短了切换时间。

技术方案如下：

组播频道快速启动方法，步骤如下：

(1)播放器向流服务器发送播放组播频道的请求；

(2)流服务器进行历史码流的快发；

(3)流服务器向播放器发送快发结束通知；

(4)播放器加入组播组，接收组播码流；

(5)播放器收到组播码流之后，通知所述流服务器停止发送单播码流；

(6)播放器把收到的组播码流和单播码流进行拼接后继续播放。

进一步，步骤(1)中，当用户操作播放器选择播放组播频道时，播放器向流服务器发送播放组播频道的请求。

进一步，步骤(2)中，流服务器从历史缓冲区的关键帧开始，以单播快发方式将历史码流填充到所述播放器的缓冲区。

进一步，步骤(3)中，当历史缓冲区耗尽之前或者之后，流服务器向播放器发送快发结束通知；或者，流服务器在信令交互中，通知播放器快发的数量，由播放器根据快发的数量得出快发结束的点。

进一步，步骤(5)中，播放器发送的通知中附带从组播接收到的媒体包的标记信息，所述标记信息包括RTP包号或者时间戳，流服务器在处理同一RTP包前停止发送单播码流。

步骤(6)进一步包括，播放器把从单播通道和组播通道接收到的RTP包填充到缓冲区。

步骤(6)进一步包括：填充前过滤已经收到的重复的RTP包。

技术效果如下：

本发明解决了关键帧等待时间、缓冲区时间和加入组播时间三者的累积导致的播放启动速度慢的问题，有效地提高了播放器的启动速度，实现快速启动组播频道的播放，提高用户体验。同时，本发明也可以有效地防止意外出现的，加入组播时间过长，造成的播放失败的错误。

在快发单播阶段，采用的是TCP协议，可以防止网络流量过大，通信链路拥塞造成的丢包；快发结束后，边收边发，继续以正常速度发送单播码流，直到播放器收到组播包，防止两段码流出现空档拼接不上；快发结束后，才让播放器加入组播，防止在快发阶段，组播码流的加入，进一步加激通信链路拥塞。

收到流服务器发出的快发结束标记播放器就加入组播分组，尽量缩短流服务器单播的时间，即尽量减轻流服务器的工作负荷；收到组播包后，尽快通知流服务器停止继续单播，把单播和组播两份码流在通信链路上重叠传输的时间减到最小。流服务器可以从历史码流中，选择从关键帧开始发送，播放器接收到码流，就可以解码播放，所以关键帧等待时间被缩减到零。

播放器在通知流服务器停止单播时，附带媒体包的标记性信息，流服务器可以判断到该媒体包之间，是否所有的媒体包已经发送，如果没有，则继续发送，直至通知中指定的媒体包为止，保证单播和组播码流可以无缝地拼接在一起。不管播放器加入组播时间的长短，都不影响播放器正常播放组播频道，加入组播时间对播放启动速度的影响被缩减为0。

本发明还可以解决偶然出现的，播放器加入组播时间很长，超过播放器的最大等待时间而导致的播放失败异常。

附图说明

图1是现有技术中组播频道系统结构图；

图2是本发明所采用的组播频道系统结构图；

图3是本发明方法的基本流程图。

具体实施方式

下面结合附图，对本发明的优选实施例作详细描述。

如图2所示，一个组播频道系统由头端、流服务器和数量不等的播放器组成。头端和流服务器在逻辑是两个实体，既可以是两个不同的物理上实体，也可以同一个物理的实现。流服务器实时不停地从头端接收码流，并保存到自己的历史缓冲区中。

头端负责产生或中转频道的媒体数据，发送到不同客户的设备，与播放器之间没有信令交互。

播放器设置有缓冲区，由最终用户操纵的，接收并播放媒体数据的设备。对于IPTV，则更多称为机顶盒(STB)。

流服务器是通过信令交互，为不同用户或播放器提供个性化的流媒体服务的实体。本发明中，流服务器设置有历史缓冲区，通过信令交互，为不同用户或播放器提供个性化的流媒体服务。历史缓存区保存有历史码流，当流服务器收到播放器的组播请求后，流服务器从历史缓冲区的历史码流的关键帧开始，以单播方式将历史码流填充到播放器的缓冲区。当播放器加入组播组后，流服务器停止发送单播码流。

处理过程如下：

第一步：用户操作操纵播放器选择播放某个组播频道。

第二步：播放器向流服务器发送播放组播频道的请求。

播放器点播一个组播频道时，首先向流服务器点播该频道。

第三步：流服务器进行历史码流的快发。

流媒体系统中，每一小段时间内，头端或流服务器发送的码流，都应该满足这段时间内播放器播放媒体的需求。如果一段较长时间内，发送速率连续超出播放的需要，则称之为快发。

流服务器从缓冲区中的历史码流中，选取一部分或全部码流，以快发的方式，向点播该频道的播放器发送单播码流，快发的单播码流是从历史某一时刻点开始，到最近接收到的连续码流。

在这一步中，流服务器可以选择性采用其它方法进一步优化效果，包括：

采用TCP方式发送单播码流，而不是流媒体应用中常用的UDP传输协议。采用尽力而为的方式，以期采用所能达到的最快的速率发送历史码流，以通信链路允许的最大速率，在最短的时间内，完成播放器缓冲区的填充工作，把缓冲区填充时间压缩到最短。检索历史码流，流服务器从历史缓冲区某个关键帧开始，以单播方式，通过快发快速填充播放器的缓冲区，让播放器在较短的时间内启动播放。

第四步：流服务器向播放器发送快发结束通知。

因为快发的发送速率大于头端的正常发送速率，历史缓冲区最终会被耗尽。

当历史缓冲区耗尽时，流服务器向播放器发送快发结束通知。

在这一步，可能有多种不同的简单变换方法，包括：

在历史缓冲区耗尽前一小段时间或后一段较长时间内发送快发结束通知；或者，流服务器在此之前的信令交互中，通知播放器自己将要快发的数量，由播放器根据接收的数据量，自行计算出快发结束的点；或者，播放器根据接收的速率计算快发结束的点。

第五步：播放器在快发结束点之前或者之后加入组播组。

第六步：流服务器以正常速率发送单播码流。

本优选实施例中，快发耗尽历史缓冲区之后，流服务器一边从头端接收码流，一边发送给播放器，继续以正常速率向播放器发送单播码流。

如果以下的步骤执行很快，这一步有可能被跳过。

第七步：当播放器收到组播码流之后，通知流服务器停止发送单播码流。

在这一步中，播放器可以更进一步，在通知中，附带从组播接收媒体包的标记信息，例如，该标记信息可以是RTP包号或时间戳等。

第八步：流服务器收到停止通知后，停止发送单播码流。

如果通知中附带了媒体包的标记性信息，流服务器还可以更进一步，采用判断比较RTP包序号或时间戳大小等办法，判断到该媒体包之间，是否所有的媒体包已经发送，如果没有，则继续发送，直至通知中指定的媒体包为止。

从用户发出播放指令到播放器正常播放媒体节目时间的长短来衡量播放器的启动速度。流服务器需要收到播放器已经接收到组播码流，才能停止单播的发送，因此，不管播放器加入组播时间的长短，都不影响播放器正常播放组播频道，加入组播时间对播放启动速度的影响被缩减为0。

第九步：播放器把从流服务器和组播接收到码流进行拼接，拼接成一份单一的码流进行播放。

如图3所示，在一个IPTV系统，通过本发明方法，能够提高播放器点播频道时的启动速度。

这个IPTV系统包括三个基本实体：头端、流服务器和播放器(又称机顶盒)。头端和流服务器通过千兆以太网连接入网络，机顶盒通过4MbpsADSL接入网络，整个网络采用的是TCP/IP协议。

媒体是音视频数据，其中音频采用AAC方式编码，AAC编码无须关键帧，解码器收到媒体包即可解码；视频采用MPEG4编码，采用MPEG4的解码器要收到一个完整的I帧，才能完整完成后续的媒体数据解码工作，关键帧为I帧。码流的传输协议是RTP，机顶盒与流服务器之间信息交互协议是是RTSP。

头端输出的正常速率码率是1.5Mbps，平均每隔2秒发送一个I帧。机顶盒在缓冲区填充2秒媒体数据后，开始解码播放。机顶盒从加入组播，到收到第1个组播包，平均时间是0.5秒。

在现在方法下，机顶盒点播一个组播频道，理论上平均必须3.5秒时间才能启动播放，最小必须2.5秒才能启动播放。而采用本发明方法，理论上只需要1.5×2÷4＝0.75秒的缓冲区填充时间，即可完成缓冲区填充工作，启动播放。在本实施例中，实测结果绝大部分点播的启动时间都小于1.0秒。

机顶盒在一次点播组播频道的流程如下：

1、机顶盒向流服务器发送RTSP DESCRIBE请求；

2、流服务器响应RTSP 200成功响应；

3、机顶盒发送视频轨道的RTSP SETUP请求；

4、流服务器响应RTSP 200成功响应；

5、机顶盒发送音频轨道的RTSP SETUP请求；

6、流服务器响应RTSP 200成功响应；

7、机顶盒发送音频轨道的RTSP PLAY请求；

8、流服务器响应RTSP 200成功响应；

9、流服务器通过TCP通道，发送快发单播流码；

10、历史码流耗尽后，流服务器通过RTSP SET_PARAMETER SpeedUp：End信令，通知机顶盒快发结束；

11、机顶盒收到RTSP SET_PARAMETER Speed Up：End信令后，响应RTSP 200成功响应，并加入组播组；

12、流服务器边收边发，继续通过TCP通道，以正常速率，向机顶盒发送单播码流；

13、机顶盒收到组播包后，发送RTSP PAUSE请求，并在请求中，附带了收到第1个组播包对应的Track ID和RTP包的RTP序号；

14、流服务器根据Track ID和RTP包序号，判断和该包之间，是否有其它RTP包尚未收到和发送，是则立刻中止发送，否则继续发送到该包为止；

15、流服务器中止发包后，响应RTSP 200成功响应；

16、机顶盒继续接收组播包；

17、机顶盒把从单播通道和组播通道接收到的RTP填充到缓冲区，填充前过滤已经收到的重复的RTP包；

18、当缓冲区填充到足够大小后，从缓冲区取出RTP包送往解码器解码播放。

Claims (10)

1.一种组播频道快速启动系统，包括：头端和至少一个播放器，其中，

头端，产生或者中转频道的媒体数据并发送；

播放器，设置有缓冲区，用于播放所述媒体数据；

其特征在于，还包括：

流服务器，设置有历史缓冲区，所述历史缓存区保存有历史码流；接收所述头端发出的码流，保存在所述历史缓冲区，当所述流服务器收到所述播放器的组播请求后，所述流服务器将历史缓冲区的历史码流，以单播方式填充到所述播放器的缓冲区，当所述播放器加入组播组后，所述流服务器停止发送单播码流；

所述播放器加入组播组后接收组播码流，并将所述组播码流和单播码流拼接。

2.根据权利要求1所述的组播频道快速启动系统，其特征在于，所述流服务器以TCP方式发送单播码流。

3.根据权利要求1所述的组播频道快速启动系统，其特征在于，当所述历史缓冲区耗尽时，所述流服务器向播放器发送快发结束通知。

4.一种组播频道快速启动方法，步骤如下：

(1)播放器向流服务器发送播放组播频道的请求；

(2)流服务器进行历史码流的快发；

(3)流服务器向播放器发送快发结束通知；

(4)播放器加入组播组，接收组播码流；

(5)播放器收到组播码流之后，通知所述流服务器停止发送单播码流；

(6)播放器把收到的组播码流和单播码流进行拼接后继续播放。

5.根据权利要求4所述的组播频道快速启动方法，其特征在于，步骤(1)中，当用户操作播放器选择播放组播频道时，播放器向流服务器发送播放组播频道的请求。

6.根据权利要求4所述的组播频道快速启动方法，其特征在于，步骤(2)中，流服务器从历史缓冲区的关键帧开始，以单播快发方式将历史码流填充到所述播放器的缓冲区。

7.根据权利要求4所述的组播频道快速启动方法，其特征在于，步骤(3)中，当历史缓冲区耗尽之前或者之后，流服务器向播放器发送快发结束通知；或者，流服务器在信令交互中，通知播放器快发的数量，由播放器根据快发的数量得出快发结束的点。

8.根据权利要求4所述的组播频道快速启动方法，其特征在于，步骤(5)中，播放器发送的通知中附带从组播接收到的媒体包的标记信息，所述标记信息包括RTP包号或者时间戳，流服务器在处理同一RTP包前停止发送单播码流。

9.根据权利要求4所述的组播频道快速启动方法，其特征在于，步骤(6)进一步包括，播放器把从单播通道和组播通道接收到的RTP包填充到缓冲区。

10.根据权利要求9所述的组播频道快速启动方法，其特征在于，步骤(6)进一步包括：填充前过滤已经收到的重复的RTP包。

Images