CN101188601B

CN101188601B - 一种多媒体数据快速发送和接收的方法

Info

Publication number: CN101188601B
Application number: CN2006101451687A
Authority: CN
Inventors: 李加周; 陈重奋; 王志英; 孙健
Original assignee: ZTE Corp
Current assignee: ZTE Corp
Priority date: 2006-11-15
Filing date: 2006-11-15
Publication date: 2011-03-16
Anticipated expiration: 2026-11-15
Also published as: CN101188601A

Abstract

一种实现多媒体数据快速发送和接收的方法，包括：服务端侦听控制协议端口；客户端向服务端的控制协议端口发起通讯连接；客户端向服务端发送控制消息；服务端响应客户端的请求消息，如果服务端和客户端都支持快发而且采用带外传送，客户端连接服务端的媒体数据快发的传输控制协议端口，建立媒体数据快发的传输控制协议通道；服务端和客户端正常交互控制协议消息结束后，服务端通过媒体数据快发的传输控制协议通道，尽力将媒体数据发送给客户端；发送完毕后，服务端根据正常流程发送码流。本发明的方法采用了TCP快速发送媒体，利用TCP的滑动窗口特性，既可以充分利用带宽，又不会因为数据包发送速度没有控制而导致网络丢包。

Description

一种多媒体数据快速发送和接收的方法

技术领域

本发明涉及多媒体通信的流媒体点播、直播、时移和视频实时通信领域，尤其涉及一种用于实现流媒体在客户端快速呈现图像的多媒体数据快速发送和接收的方法。

背景技术

随着网际协议(Internet Protocol，以下简称IP)技术的飞速发展，基于IP的视频通信及相关技术也得到了大量应用，例如固定网络的网际协议电视(Internet Protocol Television，简称IPTV)、第三代移动通信(ThirdGeneration，简称3G)网络的流媒体技术、会议电视以及可视电话等都是视频通信在固定网络和移动网络应用的实例。

由于IP网络是基于分组交换的技术，通信双方不能独占网络资源，网络质量不能得到保证，因此必然存在着网络的抖动和延时，网络的抖动会造成数据包先发后到，造成接收端数据乱序，而延时会造成播放的不连续，当前通用的技术是通过播放端缓存一定的数据来消除抖动和延时。这种缓冲技术在消除网络抖动和延时同时，必然会造成播放时间的滞后。

数据接收缓冲区的大小和网络状况有关系，网络状况不好时，缓冲区可能会开得比较大，这样在通信会话建立到呈现图像或者在媒体点播做拖动操作时，用户需要等待较长的时间，影响用户体验。

当前还没有处理这种问题的公开方法。

发明内容

本发明的目的是克服基于IP技术的多媒体通信中由于增加了缓冲区造成的延时等待时间过长的缺点，既能充分利用现有网络带宽，尽量缩短接收端缓冲时间，又不会由于网络阻塞而造成大量丢包。

为实现上述目的，本发明提供一种多媒体数据快速发送和接收的方法，其包括下列步骤：

步骤1：服务端侦听控制协议端口，如果快发数据需要带外发送，需要侦听快发数据的控制协议端口；

步骤2：客户端向服务端的控制协议端口发起通信连接，连接成功后，客户端向服务端发送控制消息，消息中扩展两个字段，一个字段表示客户端支持接收快发数据，另一字段表示期望快发的媒体数据时长；

步骤3：服务端响应客户端的请求消息，如果服务端支持快发，则在响应消息中携带支持快发数据的字段，同时携带服务端侦听的快发数据控制协议端口字段；如果服务端不支持快发，不携带支持快发数据字段，客户端认为服务端不支持快发，进行步骤8；

步骤4：如果服务端和客户端都支持快发而且采用带外传送，客户端连接服务端的快发数据的控制协议端口；建立媒体数据快发的控制协议通道；

步骤5：服务端和客户端正常交互控制协议消息结束后，进入媒体数据发送阶段；

步骤6：服务端通过媒体数据快发的控制协议通道，尽力将媒体数据发送给客户端；

步骤7：媒体数据快发的控制协议通道的媒体数据发送完毕后，服务端发送一个字段标识，表示通过该通道的快发的媒体数据流结束；

步骤8：服务端根据正常流程发送码流。

上述步骤2中所述的控制协议可以是传输控制协议(TransmissionControl Protocol，以下简称TCP)，也可以是用户数据报协议(User DatagramProtocol，以下简称UDP)；如果控制协议采用UDP方式，则不需要连接，客户端直接向服务端发送控制消息。

在上述步骤4中，如果服务端和客户端双方都采用TCP传送媒体数据，则媒体快发通道使用媒体的TCP通道，不需要另外建立媒体快发通道。例如通过实时流协议(Real-time Streaming Protocol，以下简称RTSP)、超文本传输协议(Hyper Text Transfer Protocol，以下简称HTTP)协议传送流媒体数据的隧道方式就属于这种情况。

如果服务端和客户端双方都采用UDP传送媒体数据，而控制协议采用TCP交互，则媒体快发通道采用带外传送方式，建立媒体快发通道，或者借用控制协议交互的TCP通道。例如流媒体中通过TCP传送RTSP协议，通过UDP传送媒体的方式，另外H.323系统中通过TCP传送H.225.0和H.245，通过UDP传送媒体也属于这种情况。

如果客户端由于某些操作导致缓冲区清空，客户端可以向服务端发送请求快发字段，客户端向服务端发送快发请求的触发条件是下述触发条件a-e中的任意一项：a、通信双方会话建立初期；b、流媒体播放器执行拖动操作；c、流媒体播放器执行快进、快退操作；d、流媒体播放器快进、快退转正常播放操作；e、多点会议的画面切换。

另外，上述服务端和客户端分别指多媒体通信服务端和多媒体通信客户端，这是一个逻辑概念，一个物理设备可以是一个独立的服务端，例如流媒体服务器；也可以是一个独立的客户端，例如流媒体播放器；也可以是服务端和客户端的组合，例如可视电话。

本发明的技术方案采用了TCP快速发送媒体，采用TCP通道的好处是，利用TCP的滑动窗口特性，当网络拥塞时，TCP协议滑动窗口变小，发送速度降低，如果网络状况较好，可以实现尽力发送，这样既可以充分利用带宽，又不会因为数据包发送速度没有控制而导致网络丢包。TCP快发通道可以是媒体发送通道，可以是控制协议通道，也可以单独建立快发通道。

下面结合附图，对本发明的具体实施作进一步的详细说明。对于熟悉本技术领域的人员而言，从对本发明方法的详细说明中，本发明的上述和其他目的、特征和优点将显而易见。

附图说明

图1是表示本发明的媒体服务端和客户端的示意图；

图2是表示本发明媒体服务端和客户端实现快发码流的交互图；

图3是本发明一较佳实施例在流媒体系统中实现的示意图；

图4是本发明一较佳实施例在H.323系统中实现的示意图。

具体实施方式

为使本发明的目的、技术方案及技术效果更加清楚明白，以下通过具体实施例并参照附图，对本发明进行详细说明。

图1表示本发明涉及的通信双方，即多媒体通信服务端，例如流媒体服务器；以及多媒体通信客户端，例如流媒体播放器，其通过网络通信(服务端和客户端是一个逻辑概念，一个物理设备可以是一个独立的服务端，也可以是一个独立的客户端，也可以是服务端和客户端的组合)。

图2、图3、图4所示的实施例中，首先服务端侦听控制协议端口，如果快发数据需要带外发送，需要侦听快发数据的控制协议端口，再进行媒体服务端和客户端之间的信息交互。进行信息交互时，客户端首先向服务端的控制协议端口发起通讯连接，连接成功后，客户端向服务端发送控制消息。控制协议可以是传输控制协议，也可以是用户数据报协议；如果控制协议采用用户数据报协议，则不需要连接，客户端直接向服务端发送控制消息。

图2表示本发明提出的媒体服务端和客户端之间的信息交互。具体实施流程如下：

1.客户端向服务端发起信令协议交互，在控制协议消息中携带快发标识，本例采用x-SpeedupPlay:yes和x-HopeSpeedupSecond:1字段，表示客户端支持快发，期望快发数据为1秒，实际使用可以采用其他类似扩展字段。

2.服务端响应客户端的协议请求后，如果服务端支持快发，服务端响应消息同样携带x-SpeedupPlay:yes，同时携带字段x-SpeedupPort:5000，快发通道侦听端口为5000，实际使用可以采用其他类似扩展字段和端口号。

3.客户端向服务器5000端口发起TCP连接请求且采用带外传送，建立媒体快发通道。

4.服务端按照正常协议进行交互。

5.协议双方交互完毕，客户端请求发送码流，在协议中携带x-SpeedupPlay:yes，表示服务端可以快发码流。客户端做好在正常媒体通道和快发通道接收码流的准备。

6.服务端发送应答，携带x-SpeedupPlay:yes确定快发发送码流。

7.服务端通过控制协议通道发送媒体码流。

8.服务端发送1秒的快发数据后，停止快发，向客户端发送消息，携带x-SpeedupPlay:no字段，表示快发结束。

9.服务端按照正常流程向客户端发送码流。

图3是本发明一较佳实施例在流媒体系统中实现的示意图。在本较佳实施例中，由于流媒体控制协议采用RTSP，通过TCP传输，因此快发通道可以采用控制协议的通道，x-SpeedupPort字段可以省略，下面参照该图对本发明一较佳实施例的具体实施流程进行说明如下：

1.用户通过客户端向流媒体服务器发送DESCRIBE点播请求，如：rtsp://serverip/dir1/dir2/test.mp4，携带x-SpeedupPlay:yes 和x-HopeSpeedupSecond:1表示支持快发。

2.流媒体服务器响应节目的会话描述协议(Session DescriptionProtocol，以下简称SDP)信息(RTSP/1.0 200 OK SDP)，携带扩展字段x-SpeedupPlay:yes，表示服务器支持快发。

3.客户端根据SDP信息向流媒体服务器发送SETUP流建立请求，本例客户端要求建立RTP/AVP的基于UDP的请求。

4.流媒体服务器响应确认客户端的流建立请求(RTSP/1.0 200 OK)。

5.客户端建立第二个流的SETUP请求。

6.流媒体服务器响应确认客户端的流建立请求(RTSP/1.0 200 OK)。

7.客户端向流媒体服务器发送播放请求，携带扩展字段x-SpeedupPlay:yes，表示客户端要求接下来的码流发送服务器进行快发。此时客户端应该在交互的UDP端口和TCP通道做好接收码流的准备。

8.流媒体服务器响应客户端的PLAY请求(RTSP/1.0 200 OK)，并携带扩展字段x-SpeedupPlay:yes，表示流媒体服务器将进行媒体流快发。

9.流媒体服务器通过RTSP的控制通道尽力发送媒体流，快发的媒体流播放时间应该为1秒。媒体流在TCP通道的打包格式见rfc2326中10.12关于交织数据的格式描述。

10.快发结束后，流媒体服务器发送SET_PARAMETER消息，携带x-SpeedupPlay:no字段，表示快发结束。

11.客户端响应流媒体服务器的SET_PARAMETER消息(RTSP/1.0200 OK)。

12.流媒体服务器通过交互的正常UDP通道向客户端发送媒体流。

13.用户做暂停操作，客户端向流媒体服务器发送PAUSE消息。

14.流媒体服务器响应客户端的暂停请求(RTSP/1.0 200 OK)。

15.客户端向流媒体服务器发送PLAY播放请求。由于客户端的缓冲区还有数据，客户端不需要服务器快发媒体数据。

16.流媒体服务器响应客户端的播放请求(RTSP/1.0 200 OK)。

17.流媒体服务器通过UDP通道按照正常速度把码流发送给客户端。

18.用户做拖动操作，由于客户端缓冲的数据不能继续播放，将被清空，因此客户端的播放请求中携带了要拖动的位置信息，同时携带x-SpeedupPlay:yes字段，要求流媒体服务器快发数据。

19.流媒体服务器响应客户端的快发播放请求(RTSP/1.0 200 OK)，同时携带x-SpeedupPlay:yes字段。

20.流媒体服务器快发数据给客户端，流程进入步骤9，直到节目播放完毕或者用户发送TEARDOWN退出。

图4是本发明一较佳实施例在H.323系统中实现的示意图。在H.245的打开逻辑通道OLC中扩展字段，本实施例是两个端点之间呼叫的流程，具体实施流程如下：

1.端点1呼叫端点2，端点1和端点2和网闸之间有消息认证系统(Message Authentication System，RAS)消息通信。

2.端点1和端点2之间经过H.225.0过程。

3.端点1和端点2之间经过H.245的主从决定和能力集交互。

端点1向端点2发起OLC消息，要求打开逻辑通道。OLC中扩展如下ASN.1消息。扩展消息包含两个字段，一个字段表示是否需要快发，另一个字段表示快发的时长。

4.端点2在OLCACK响应中携带同步骤4相同的扩展消息，hopeSpeedupSecond是可选字段，可以不带。

5.端点2向端点1发送OLC消息，要求打开逻辑通道。扩展字段同步骤4。

6.端点1在OLCACK响应中携带同步骤4相同的扩展消息，hopeSpeedupSecond是可选字段，可以不带。

7.端点之间通过H.245通道快速发送码流。

快发码流结束，H.245通道发送非标准消息，扩展快发结束的命令类型。表示快发数据结束。

8.通信双方按照正常RTP通道发送媒体流。

当然，本发明还可有其他实施例，在不背离本发明精神及其实质的情况下，熟悉本领域的技术人员当可根据本发明作出各种相应的改变和变形，但这些相应的改变和变形都应属于本发明的权利要求的保护范围。

Claims

1.一种多媒体数据快速发送和接收的方法，其特征在于，包括以下步骤：

步骤2：客户端向服务端的控制协议端口发起通讯连接，连接成功后，客户端向服务端发送控制消息，消息中扩展两个字段，一个字段表示客户端支持接收快发数据，另一字段表示期望快发的媒体数据时长；

步骤8：服务端根据正常流程发送码流。

2.根据权利要求1所述的方法，其特征在于上述步骤2中所述的控制协议是传输控制协议或用户数据报协议；如果控制协议采用用户数据报协议，则不需要连接，客户端直接向服务端发送控制消息。

3.根据权利要求1所述的方法，其特征在于在上述步骤4中，如果服务端和客户端双方都采用传输控制协议传送媒体数据，则媒体快发通道使用媒体的传输控制协议通道，不需要另外建立媒体快发通道；如果服务端和客户端双方都采用用户数据报协议传送媒体数据，而控制协议采用传输控制协议交互，则媒体快发通道采用带外传送方式，建立媒体快发通道，或者借用控制协议交互的传输控制协议通道。

4.根据权利要求1所述的方法，其特征在于如果客户端由于某些操作导致缓冲区清空，客户端可以向服务端发送请求快发字段，客户端向服务端发送快发请求的触发条件是下述触发条件a-e中的任意一项：a、通讯双方会话建立初期；b、流媒体播放器执行拖动操作；c、流媒体播放器执行快进、快退操作；d、流媒体播放器快进、快退转正常播放操作；e、多点会议的画面切换。

5.根据权利要求1至4中的任何一项所述的方法，其特征在于上述服务端和客户端是一个逻辑概念，一个物理设备是一个独立的服务端、一个独立的客户端或服务端与客户端的组合。