CN1983907A

CN1983907A - 一种流媒体发送速率的控制方法

Info

Publication number: CN1983907A
Application number: CN200510130491.2A
Authority: CN
Inventors: 王金东
Original assignee: ZTE Corp
Current assignee: ZTE Corp
Priority date: 2005-12-13
Filing date: 2005-12-13
Publication date: 2007-06-20

Abstract

本发明公开了一种流媒体发送速率的控制方法，包括如下步骤：客户端和服务器依照标准实时流协议，开启点播服务；客户端统计数据丢包率、以及客户端缓冲区当前剩余大小，向服务器发送反馈信息；服务器收到客户端反馈信息之后，根据客户端丢包率、以及客户端缓冲区当前剩余大小，调整发送速率。所述客户端缓冲区当前剩余大小，可以是在流媒体传输开始后，客户端在内存开辟的作为存储音视频数据的缓冲区中当前空闲、可用于接收新的音视频数据的缓冲区的大小。本方法中利用客户端反馈的丢包率、客户端缓冲区当前剩余大小作为控制媒体发送速率的方法，从而能够更加有效的利用空闲的网络带宽。

Description

一种流媒体发送速率的控制方法

技术领域

本发明涉及一种发送速率的控制方法，特别涉及一种流媒体发送速率的控制方法。

背景技术

以往，网络上传送的大多数数据为文本数据。今天，随着多媒体和网络技术的提高，多媒体成为了互联网上不可或缺的特征。目前多媒体数据在网络上的下发，主要采取流媒体的形式。流媒体是指在Internet/Intranet中使用流式传输技术的连续时基媒体，如：音频、视频或多媒体文件。流式媒体在播放前并不下载整个文件，只将开始部分存入内存，流式媒体的数据流随时传送随时播放，只是在一开始时有一些延迟。

目前网络上多媒体实时应用的主要控制协议为RTSP(实时流协议)，它是一个客户—服务器多媒体节目协议，可以控制流式多媒体数据在IP网络上的发送。它提供用于音频和视频流的远程控制功能，例如：播放、停止、快进、快退和定位。数据源包括实况数据和存储片断。RTSP(实时流协议)是一个应用层协议，用来与诸如RTP(实时传输协议)、RSVP(资源预留协议)等更低层的协议一起，提供基于互联网的整套流化服务。

它可以选择发送通道，例如：UDP(用户数据报协议)、组播UDP和TCP(传输控制协议)和基于RTP(实时传输协议)的发送机制。它可以服务于多客户组播和单一观众点播。

RTSP(实时流协议)工作的基本流程如图1所示：

客户端向媒体服务器A(audio.example.com)和V(video.example.com)请求一部电影。媒体描述存储在网页服务器上。媒体描述包含节目描述和它的全部流，包括可用的编码信息、动态RTP负载类型、协议栈和内容信息，例如语言和版权限制。它同样会给出电影的时间。

具体步骤如下：

1.向网页服务器发出获取媒体信息请求；

2.网页服务器返回相应的媒体信息；

3.向音频服务器发出创建会话请求；

4.音频服务器返回创建会话的相应信息；

5.向视频服务器发出创建会话请求；

6.视频服务器返回创建会话的相应信息；

7.向视频服务器发出播放请求；

8.视频服务器创建会话成功；

9.向音频服务器发出播放请求；

10.音频服务器创建会话成功；

11.向音频服务器发出销毁会话请求；

12.音频服务器销毁会话成功；

13.向视频服务器发出销毁会话请求；

14.视频服务器销毁会话成功。

RTP(实时传输协议)是用于互联网上针对多媒体数据流的一种传输协议。RTP被定义为在一对一或一对多的传输情况下工作，其目的是提供时间信息和实现流同步。

RTP协议本身包括两部分：RTP和RTCP(实时传输控制协议)。为了可靠，高效的传送实时数据，RTP和RTCP必须配合使用，通常，RTCP包的数量占所有传输量的5％。

RTP实时传输协议主要用于负载多媒体数据，并通过包头时间参数的配置使其具有实时的特征。RTCP传输控制协议主要用于周期的传送RTCP包，监视RTP传输的服务质量。在RTCP包中，含有已发送的数据包的数量、丢失的数据包的数量等统计资料。

因此，服务器可以利用这些信息动态地改变传输速率，甚至改变有效载荷类型，实现流量控制和拥塞控制服务。RTP本身并不能为按顺序传送数据包提供可靠的传送机制，也不提供流量控制或拥塞控制，它依靠RTCP传输控制协议提供这些服务。

RTP的控制协议RTCP通过在会话用户之间周期性地递交控制报文来完成监听服务质量和交换会话用户信息等功能。根据用户间的数据传输反馈信息，可以制定流量控制的策略，而会话用户信息的交互，可以制定会话控制的策略。

RTCP协议将控制包周期发送给所有连接者，应用与数据报文相同的分发机制。底层协议提供数据与控制包的复用，如使用单独的UDP(用户数据报协议)端口号。

RTCP工作流程如图2所示：

1、在流媒体正常播放过程中，服务器下发数据包；

2、客户端开启一个计时器，大约每隔5秒，采用UDP协议，向服务器发送回传信息；

3、在RTCP回传信息中，包括了丢包率等一系列统计信息。

但由于流媒体对于实时性的要求较高，5秒一次的回传信息，在这一情况下，就显得过于漫长，无法满足当前流媒体视频点播的要求。另外，RTCP的回传信息，是通过UDP进行传输的，而UDP本身是不可靠传输协议，因此，当网络出现某种特殊情况的时候，RTCP信息就极有可能丢失掉。这样，在相当长一段时间内(相对于流媒体视频点播而言)，服务器就无法知道客户端的状态，只能盲目的下发数据包。

为了保证及时的递交媒体，适应网络带宽的随时变化，已经有人提出了一些控制流媒体服务器发送媒体速率的方法。但目前来看，主要依赖于客户端反馈的丢包率、CPU利用率、和延迟等条件，这些方法的缺点是即使当丢包率为0、CPU利用率很低、和/或延迟很小的情况下，流媒体服务器仍然会一丝不苟的按照原来的编码速率进行发送，而没有充分的利用空闲的网络资源。

发明内容

本发明所解决的技术问题在于提供了一种流媒体发送速率的控制方法，以达到利用客户端反馈的丢包率、客户端缓冲区当前剩余大小作为控制媒体发送速率的方法，从而能够更加有效的利用空闲的网络带宽。

为解决上述技术问题，本发明提供了一种流媒体发送速率的控制方法，本方法包括如下步骤：

客户端和服务器依照标准实时流协议，开启点播服务；

客户端统计数据丢包率、以及客户端缓冲区当前剩余大小，向服务器发送反馈信息；

服务器收到客户端反馈信息之后，根据客户端丢包率、以及客户端缓冲区当前剩余大小，调整发送速率。

所述客户端缓冲区当前剩余大小，可以是在流媒体传输开始后，客户端在内存开辟的作为存储音视频数据的缓冲区中当前空闲、可用于接收新的音视频数据的缓冲区的大小。

所述服务器收到客户端反馈信息之后，根据客户端丢包率、以及客户端缓冲区当前剩余大小，调整发送速率的步骤可以是：

(1)、当丢包率很少、剩余缓冲区很小：流媒体服务器不调整发送速率；

(2)、当丢包率很少、剩余缓冲区很大：流媒体服务器将发送速率调高；

(3)、当丢包率很多、剩余缓冲区很小：流媒体服务器将发送速率降低；

(4)、当丢包率很多、剩余缓冲区很大：流媒体服务器将发送速率降低。

所述发送速率可以是媒体的编码速率。

所述当丢包很少、剩余缓冲区很大：流媒体服务器将发送速率调高可以是调高为媒体的编码速率的1～2倍。

所述当丢包很多、剩余缓冲区很小：流媒体服务器将发送速率调低可以是调低为媒体的编码速率的0.3～0.5倍。

所述当丢包很多、剩余缓冲区很大：流媒体服务器将发送速率调低可以是调低为媒体的编码速率的0.8倍。

由于本方法中利用客户端反馈的丢包率、客户端缓冲区当前剩余大小作为控制媒体发送速率的方法，从而能够更加有效的利用空闲的网络带宽。克服了即使当丢包率为0、CPU利用率很低、和/或延迟很小的情况下，流媒体服务器仍然会按照原来的编码速率进行发送的弱点，从而充分的利用了空闲的网络资源。

同时本发明中由于能实时的回传信息，所以满足了流媒体应用实时性的需求。本发明中服务器能根据网络实际可用情况，调整发送速率，减小网络拥塞状况，在一定程度上满足客户端观看的需求。同时还实现了网络控制协议的智能化。

附图说明

图1为标准的RTSP协议(实时流协议)工作流程图；

图2为标准的RTCP协议(实时传输控制协议)工作流程图；

图3为本发明实施例的流程示意图。

具体实施方式

下面结合附图对本发明的具体实施方式做出说明。

实施例中客户端和流媒体服务器采用RTSP/TCP/RTP/RTCP/UDP协议进行流媒体的传输。在流媒体传输开始后，客户端会开辟一定的内存作为存储音视频数据的缓冲区，通常缓冲区的大小要求能够存储15秒钟左右的音视频数据。按照RTCP协议的规定，当流媒体服务器发送音视频数据时，客户端会进行丢包的统计，并每隔一定的时间(例如5秒钟)向流媒体服务器反馈统计情况。

实施例扩充了RTCP协议，要求客户端在上报丢包统计的时候，也向流媒体服务器上报客户端缓冲区当前剩余大小。流媒体服务器接收到客户端的反馈情况后根据丢包和缓冲区剩余大小进行调整当前的发送速率。

图3是实施例的流程示意图，如图所示，实施的具体步骤是：

步骤301：客户端利用RTSP向流媒体服务器点播流媒体；

步骤302：客户端利用RTP协议进行媒体内容的接收；

步骤303：丢包与缓冲区当前剩余大小统计；

步骤304：利用RTCP协议反馈丢包情况和客户端缓冲区当前剩余大小；

步骤305：流媒体服务器判断发送是否完毕，是则转向步骤308，否则转向步骤306；

步骤306：流媒体服务器调整发送速率；

步骤307：流媒体服务器向客户端继续发送媒体内容，转向步骤302；

步骤308：流媒体服务器利用RTSP协议结束点播流程。

步骤303、304中客户端缓冲区当前剩余大小，是在流媒体传输开始后，客户端在内存开辟的作为存储音视频数据的缓冲区中当前空闲、可用于接收新的音视频数据的缓冲区的大小。

其中，具体的发送速率调整量如下：

1、丢包很少、剩余缓冲区很小：说明网络情况很好，客户端的音视频数据很充足，流媒体服务器可以按照当前的发送速率继续发送媒体内容。点播开始时初始的发送速率可以等于媒体的编码速率。

2、丢包很少、剩余缓冲区很大：说明网络情况很好，但客户端的音视频数据备用的不多，因此流媒体服务器可以以超过媒体编码速率的发送速率进行媒体内容的发送，优选发送速率为编码速率的1～2倍。

3、丢包很多、剩余缓冲区很小：说明网络情况较差，客户端的音视频数据很充足，这时流媒体服务器可以以低于媒体编码速率的发送速率进行媒体内容的发送，优选发送速率为编码速率的0.3～0.5。

4、丢包很多、剩余缓冲区很大：说明网络情况很差，客户端的音视频数据不足，这是流媒体服务器可以以略低于媒体编码速率的发送速率进行发送，优选发送速率为编码速率的0.8。

Claims

1、一种流媒体发送速率的控制方法，其特征在于，包括以下步骤：

客户端和服务器依照标准实时流协议，开启点播服务；

2、如权利要求1所述的控制方法，其特征在于，所述客户端缓冲区当前剩余大小，是在流媒体传输开始后，客户端在内存开辟的作为存储音视频数据的缓冲区中当前空闲、可用于接收新的音视频数据的缓冲区的大小。

3、如权利要求1所述的控制方法，其特征在于，所述发送速率在首次发送的速率等于媒体的编码速率。

4、如权利要求1所述的控制方法，其特征在于，所述服务器收到客户端反馈信息之后，根据客户端丢包率、以及客户端缓冲区当前剩余大小，调整发送速率的步骤是：

5、如权利要求4所述的控制方法，其特征在于，所述调整发送速率是依据媒体的编码速率进行调整的。

6、如权利要求5所述的控制方法，其特征在于，所述当丢包很少、剩余缓冲区很大：流媒体服务器将发送速率调高是调高为媒体的编码速率的1～2倍。

7、如权利要求5所述的控制方法，其特征在于，所述当丢包很多、剩余缓冲区很小：流媒体服务器将发送速率调低是调低为媒体的编码速率的0.3～0.5倍。

8、如权利要求5所述的控制方法，其特征在于，所述当丢包很多、剩余缓冲区很大：流媒体服务器将发送速率调低是调低为媒体的编码速率的0.8倍。