[发明专利]一种多媒体数据传输系统及其应用方法

说明书

技术领域

本发明属于多媒体数据传输领域，具体涉及一种多媒体数据传输系统及其应用方法。

背景技术

目前，RTSP/RTP  协议是当前应用比较广泛一种多媒体传输控制方法，其为应用提供端到端的实时网络传输。该方法的弊端是每个流媒体传输要使用3个连接信道:一个RTSP协议信道，一个RTCP信道，一个RTP信道，占用了较多的有限的系统端口（当前操作系统最大只支持65535个端口），信道建立的握手交互较多，不太适应以实时性要求高的连接频繁的场合。

另外，TCP/UDP协议属于网络传输层协议，其中TCP提供IP环境下的数据可靠传输，它提供的服务包括数据流传送、可靠性、有效流控、全双工操作和多路复用，通过面向连接、端到端和可靠的数据包发送。通俗说，它是事先为所发送的数据开辟出连接好的通道，然后再进行数据发送；而UDP则不为IP提供可靠性、流控或差错恢复功能。一般来说，TCP对应的是可靠性要求高的应用，而UDP对应的则是可靠性要求低、传输经济的应用，本发明是基于TCP/UDP协议实现的系统和方法。

发明内容

针对现有技术的缺点，本发明的目的是提供一种通过使用单通道进行多媒体数据传输和控制提高单个服务器能够管理的链接数据，提高传输握手的链接速度的多媒体数据传输系统及其应用方法。

为实现上述目的，本发明的一种多媒体数据传输系统包括：

流媒体协议，用于规定通信消息格式封装和通信流程；

安装有流媒体协议的服务器，用于接受客户端连接和连接的管理，接收、解析并响应客户端的请求，以及把多媒体数据按流媒体协议发送到客户端；

安装有流媒体协议的客户端，用于建立与服务器的连接和对连接进行维护，并将请求按流媒体协议发送给服务器以及对接收到的响应消息进行解析返回给应用者。

作为一种优选方案，流媒体协议的结构包括依次排列的包头数据、负载数据和CRC校验数据。

作为进一步的优选方案，包头数据的长度为80比特，负载数据的长度随实际传输的多媒体数据长度变化而变化。

作为进一步的优选方案，包头数据的结构包括依次排列的当前包长度、协议版本、包类型、校验方式、分包末尾包标识、包序号、包内分包序号、会话子通道号、附加值。

作为进一步的优选方案，当前包长度、协议版本、包类型、校验方式、分包末尾包标识、包序号、包内分包序号、会话子通道号、附加值长度分别为24比特、3比特、1比特、3比特、1比特、16比特、16比特、8比特、8比特。

为了实现第二个发明目的，采用如下技术方案：

本发明提供了一种多媒体数据传输的应用方法，采用权利要求1所述系统实现，包括如下步骤：

A.客户端建立会话通道：客户端向服务器发送连接请求；

B.服务器接收到连接请求后对连接请求进行解析，建立与客户端的会话通道；此时客户端等待服务器的连接请求响应，服务器建立会话通道后向客户端返回连接请求结果；

C. 会话通道建立后，服务器等待客户端的心跳或者命令；

D.客户端向服务器发送开始播放命令，请求进行多媒体数据的传输；

E.服务器接收到开始播放命令后向客户端传输多媒体数据；

F.客户端向服务器发送结束命令并等待服务器的响应；

G．服务器接收到结束命令后返回结束响应结果，停止传输多媒体数据并拆除与客户端的会话通道，会话结束；

H.客户端接收到结束响应结果后拆除与服务器的会话通道。

作为一种优选方案，客户端和服务器中安装有流媒体协议，所述流媒体协议的结构包括依次排列的包头数据、负载数据和CRC校验数据。

作为进一步的优选方案，包头数据的长度为80比特，负载数据的长度随实际传输的多媒体数据长度变化而变化。

作为进一步的优选方案，包头数据的结构包括依次排列的24比特的当前包长度、3比特的协议版本、1比特的包类型、3比特的校验方式、1比特的分包末尾包标识、16比特的包序号、16比特的包内分包序号、8比特的会话子通道号、8比特的附加值。

作为另一种优选方案，客户端中设置有存活定时器keepalive，在进行流媒体数据传输过程中，还进行如下步骤：

e1.客户端向服务器发送keepalive命令，探测流媒体数据传输是否发生拥塞；此时客户端还向服务器发送控制命令；

e2.客户端等待服务器的keepalive响应；

e3.服务器返回keepalive响应，如果keepalive响应为拥塞，则客户端向服务器发送重传命令。