CN103532923B - 一种实时媒体流传输方法及系统 - Google Patents

Abstract

本发明公开一种实时媒体流传输方法及系统，其中，所述方法包括步骤：服务器端判断需传输的媒体流的数据帧是否是关键帧，当判断数据帧为关键帧时，将所述数据帧拆分为数据包的同时在该数据帧中添加关键帧标识成为关键帧包；将所述关键帧包发送至客户端，并监听客户端是否返回了接收到所述关键帧包的确认信息；当服务器端在预定时间内没有监听到客户端返回的确认信息时，重新将所述关键帧包发送至客户端。本发明有效的减少了传输过程中的丢包率，确保了关键帧的完整性，提高了媒体流在客户端的解码效果，同时不会造成过多的网络负载负担。

Description

一种实时媒体流传输方法及系统

技术领域

本发明涉及信息传输领域，尤其涉及一种实时媒体流传输方法及系统。

背景技术

在目前的多媒体应用中，媒体流的实时传输得到越来越广泛的应用，比如视频会议，同屏显示等等。由于实时媒体流传输具有带宽占有率高，丢包率低，实时性高的特点，因而对于网络环境的要求也相对较高，在网络环境不稳定的情况下，用户体验往往就会比较差。

现有的媒体流实时传输流程一般是：1、服务器端：原始数据采集，编码，数据发送；2、客户端：数据接收，解码，及显示。在传输过程中，为了确保传输的实时性，通常使用RTP（Real-timeTransportProtocol，实时传输协议）+UDP（UserDatagramProtocol，用户数据报协议）的方法来实现，RTP协议用于实时数据的端到端传输，RTP一般运行在UDP之上，RTP从应用层接受媒体流，组装成RTP包，然后再使用UDP协议发送。

但在使用RTP+UDP协议进行实时媒体流传输时，由于UDP协议提供的是面向事务的简单不可靠信息传送服务，在传输数据的时候，会有数据包丢失的现象，例如传输视频流时，客户端在接收到数据后进行解码，丢包就会造成视频帧的不完整性，解码后图像就会花屏。

因此，现有技术还有待于改进和发展。

发明内容

鉴于上述现有技术的不足，本发明的目的在于提供一种实时媒体流传输方法及系统，旨在解决现有实时媒体流传输过程中丢包率高、影响媒体流传输质量的问题。

本发明的技术方案如下：

一种实时媒体流传输方法，其中，包括步骤：

A、服务器端判断需传输的媒体流的数据帧是否是关键帧，当判断数据帧为关键帧时，将所述数据帧拆分为数据包的同时在该数据帧中添加关键帧标识成为关键帧包；

B、将所述关键帧包发送至客户端，并监听客户端是否返回了接收到所述关键帧包的确认信息；

C、当服务器端在预定时间内没有监听到客户端返回的确认信息时，重新将所述关键帧包发送至客户端。

所述实时媒体流传输方法，其中，所述步骤B具体包括：

B1、服务器端与客户端建立监听；

B2、获取所述关键帧包，并将所述关键帧包发送至客户端；

B3、监听所述客户端是否返回了接收到所述关键帧包的确认信息。

所述实时媒体流传输方法，其中，所述步骤B中还包括：

C1、客户端判断接收到的数据包是否为关键帧包；

C2、当所述数据包是关键帧包时，提取所述关键帧包的数据包ID；

C3、将所述数据包ID与客户端的关键帧包ID列表匹配，查找所述关键帧包ID列表是否含有该数据包ID；

C4、当所述关键帧包ID列表没有该数据包ID时，将该数据包ID添加至所述关键帧包ID列表，并将含有该数据包ID的确认信息发送至服务器端。

所述实时媒体流传输方法，其中，所述步骤步骤C4还包括：

当所述关键帧包ID列表中含有该数据包ID时，则将客户端接收到的关键帧包丢弃。

所述实时媒体流传输方法，其特征在于，所述方法还包括步骤：

D、当服务器端在预定时间内监听到客户端返回的确认信息时，判断该确认信息中的数据包ID与最近发送的关键帧包的数据包ID是否相同，当是时，返回步骤A，否则重新发送该关键帧包。

所述实时媒体流传输方法，其中，当所述媒体流的编码方式为264编码时，所述步骤A中判断数据帧是否为关键帧的步骤具体包括：

A1、获取一帧264数据，查找所述264数据的帧开始标记；

A2、查找到帧开始标记后，开始读取该帧开始标记之后的第5个字节，若该字节是6，则转入步骤A3，若该字节是5，则判断该数据帧为关键帧，若该字节是5和6以外的值，则判断该数据帧不是关键帧；

A3、获取所述数据帧中的恢复帧计数的值，若该值大于0，则判断是关键帧，否则判断不是关键帧。

一种实时媒体流传输系统，包括服务器端和客户端，其中，所述服务器端包括关键帧包生成模块、关键帧包发送模块以及关键帧包重传模块；

所述关键帧包生成模块，用于判断需传输的媒体流的数据帧是否是关键帧，当判断数据帧为关键帧时，将所述数据帧拆分为数据包的同时在该数据帧中添加关键帧标识成为关键帧包；

所述关键帧包发送模块，用于将所述关键帧包发送至客户端，并监听客户端是否返回了接收到所述关键帧包的确认信息；

所述关键帧包重传模块，用于在预定时间内没有监听到客户端返回的确认信息时，重新将所述关键帧包发送至客户端。

所述实时媒体流传输系统，其中，所述关键帧包发送模块包括：

监听建立单元，用于与客户端建立监听；

关键帧包发送单元，用于获取所述关键帧包，并将所述关键帧包发送至客户端；

确认信息监听单元，用于监听所述客户端是否返回了接收到所述关键帧包的确认信息。

所述实时媒体流传输系统，其中，所述客户端包括：

关键帧包判断模块，用于判断接收到的数据包是否为关键帧包；

数据包ID提取模块，用于当所述数据包是关键帧包时，提取所述关键帧包的数据包ID；

数据包ID匹配模块，用于将所述数据包ID与客户端的关键帧包ID列表匹配，查找所述关键帧包ID列表是否含有该数据包ID；

确认信息发送模块，用于当所述关键帧包ID列表没有该数据包ID时，将该数据包ID添加至所述关键帧包ID列表，并将含有该数据包ID的确认信息发送至服务器端。

所述实时媒体流传输系统，其中，所述客户端还包括：

关键帧包丢弃模块，用于当所述关键帧包ID列表中含有该数据包ID时，则将客户端接收到的关键帧包丢弃。

有益效果：本发明通过在需传输的媒体流的关键帧拆分为RTP包的时候，添加关键帧标识，并针对具有关键帧标识的RTP包进行重传确认机制，有效的减少了传输过程中的丢包率，确保了关键帧的完整性，提高了媒体流在客户端的解码效果，并且由于本发明只对关键帧进行重传确认，而非对整个传输过程加入重传确认机制，因而减少了对网络负载开销的影响，对媒体流实时传输的影响也很小，不会造成过多的网络负载负担。

附图说明

图1为本发明实时媒体流传输方法较佳实施例的流程图。

图2为本发明关键帧包的结构示意图。

图3为本发明的方法中服务器端发送关键帧包以及监听确认信息的流程示意图。

图4为本发明的方法中客户端接收到数据包后的处理流程图。

图5为本发明的方法中判断关键帧的方法流程图。

图6为本发明实时媒体流传输系统较佳实施例的结构框图。

图7为图6所示系统中关键帧包发送模块具体的结构框图。

图8为图6所示系统中客户端具体的结构框图。

具体实施方式

本发明提供实时媒体流传输方法及系统，为使本发明的目的、技术方案及效果更加清楚、明确，以下对本发明进一步详细说明。应当理解，此处所描述的具体实施例仅仅用以解释本发明，并不用于限定本发明。

请参阅图1，图1为本发明实时媒体流传输方法较佳实施例的流程图，如图所示，其包括步骤：

S101、服务器端判断需传输的媒体流的数据帧是否是关键帧，当判断数据帧为关键帧时，将所述数据帧拆分为数据包的同时在该数据帧中添加关键帧标识成为关键帧包；

S102、将所述关键帧包发送至客户端，并监听客户端是否返回了接收到所述关键帧包的确认信息；

S103、当服务器端在预定时间内没有监听到客户端返回的确认信息时，重新将所述关键帧包发送至客户端。

S104、当服务器端在预定时间内监听到客户端返回的确认信息时，判断该确认信息中的数据包ID与最近发送的关键帧包的数据包ID是否相同，当是时，返回步骤S101，否则重新发送该关键帧包。

在步骤S101中，服务器端首先需要传输的媒体流的数据帧是否是关键帧，针对不同的情况进行不同的处理，对于如何判断数据帧是否是关键帧在后文中会有详述。如果判断数据帧是关键帧，则在将数据帧拆分为数据包的时候，在该数据帧中添加关键帧标识，例如在拆分后的RTP包（本发明中的数据包即指RTP包，即通过RTP协议进行封装的数据包）的DATA前添加6个字节的“IFRAME”标识，如图2所示。需注意的是，从关键帧拆分出来的每一个RTP包的DATA前都需要添加关键帧标识，例如前述的6个字节的“IFRAME”标识，以保证关键帧都能进行丢包重传。添加了关键帧标识后，在每一数据包上加上UDP包头，以通过UDP协议发送数据帧。

而在判断数据帧不是关键帧时，则可直接将该数据帧拆分为数据包，并加上UDP包头，通过UDP协议发送该数据帧，不同的是，没有在数据帧中添加关键帧标识，所以也不会在丢包的时候进行重传。

在步骤S102中，在将含有关键帧标识的关键帧包发送至客户端的时候，监听客户端是否收到该关键帧包，如图3所示，步骤S102具体可细化为以下步骤：

S201、服务器端与客户端建立监听；例如建立sockettcp（套接字传输）监听。

S202、获取所述关键帧包，并将所述关键帧包发送至客户端；此过程中还需要获取该关键帧包的数据包ID，每一关键帧包都具有一个数据包ID，获取该数据包ID有利于服务器端判断接下来收到的确认信息中的数据包ID与最近发送过去的关键帧包的数据包ID是否相同，以保证每一关键帧包都发送成功。

S203、监听所述客户端是否返回了接收到所述关键帧包的确认信息。

对于服务器端而言，只需监听客户端是否将确认信息发送回来即可，对于客户端而言，则需要接受该关键帧包，然后判断是否是含有关键帧标识的关键帧包以及去除关键帧标识等等一系列的处理，这在后文中会有详细描述。

在步骤S103中，当服务器端在预定时间（例如5ms）内没有监听到客户端返回的确认信息时，则需要重新将所述关键帧包发送至客户端，此步骤即为关键帧重传的步骤，以保证关键帧都能发送到客户端，避免关键帧丢包影响媒体流输出的质量。

在步骤S104中，即使服务器端在预定时间内监听到了客户端返回的确认信息，并不能保证客户端已接收到服务器最近发送的关键帧包，因为该关键帧包可能是由于网络延时由服务器端上一次或者上上一次发送给客户端的，不是针对服务器端最近一次发送的关键帧包的确认信息，所以还需要判断接收到的确认信息中的数据包ID与最近发送的关键帧包中的数据包ID是否相同，如果相同，则可以确定客户端已经接收到最近发送的关键帧包，并准备发送下一关键帧包，否则需要重新将该关键帧包发送给客户端，确保客户端能接到每一个含有关键帧标识的关键帧包。而如果不判断确认信息中的数据包ID与服务器端最近发送的数据包ID是否相同，有可能会造成服务器端误以为未发送成功的数据包发送成功，影响媒体流的输出效果。

在客户端与服务器端建立连接之后，就可以接收来自服务器端发送的数据包，此时客户端还会初始化关键帧包ID列表，客户端接收到一个新的关键帧包时，都会将该关键帧包的数据包ID添加至关键帧包ID列表中，以便判断接下来接收到的关键帧包是否已经接收到过，避免由于网络延时而进行重复的发送，保证数据传输的唯一性。

上述过程是对于服务器端而言，对于客户端接收到数据包的处理过程，即在前述的步骤S102中服务器端将数据包发送至客户端后，如图4所示，具体包括步骤：

S301、客户端首先判断从服务器端接收到的数据包是否是关键帧包，具体是通过判断该数据包是否含有关键帧标识来进行判断的，如果判断该数据包不是关键帧包，则可直接对该数据包进行解析即进入到步骤S305，重组为数据帧，并进行解码输出至显示设备，此为现有技术，故不再赘述。

S302、如果判断到该数据包是关键帧包，则需要解析该关键帧包的数据包ID，具体可通过解析该关键帧包的RTP包头获取得到（在发送前已经添加）；

S303、提取到数据包ID后，判断将该关键帧包的数据包ID与关键帧包ID列表进行匹配，查找在关键帧包ID列表中是否已经含有该数据包ID；

S304、如果该关键帧包ID列表中没有该数据包ID，则需要将该数据包ID添加至关键帧包ID列表中，并且向服务器端发送确认信息，在该确认信息中也含有相应的数据包ID，从而使服务器端在接收到确认信息后，还可以进一步判断该确认信息中的数据包ID与最近发送的数据包的数据包ID是否对应，在该确认信息中，还含有六个字节的确认标识信息，例如RECVOK。

当然，如果该关键帧包ID列表中已有含有该数据包ID，则说明客户端已经接收到了该关键帧包，无需进行重复发送，可直接将该关键帧包丢弃即进入到步骤S306。

在发送完确认信息后，客户端即可将接收到的关键帧包中的关键帧标识去掉，并将去掉标识后的关键帧包中的数据进行解析，重组为媒体流数据，然后进行解码，并将解码后的数据输出。

通过上述过程即可实现在关键帧包丢失的情况下丢包重传的目的，由于加入了关键帧包的传输确认机制，本发明确保了媒体流传输过程中关键帧的传输完整性，即降低了丢包率，又提高了客户端的输出效果，并且只是对关键帧进行丢包重传，对网络负载也不会增加过多的负担。

本发明中一个重要的步骤是判断数据帧是否为关键帧，本发明对如何判断数据帧是否是关键帧也进行详细的说明，由于不同编码方式关键帧的判断方法不同，而264编码是实时媒体流传输的一种常用格式，所以，此处以该编码方式为例说明判断数据帧是否是关键帧的方法，如图5所示，其包括步骤：

S401、获取一帧264数据后，读取该264数据查找帧开始标记start_code，该start_code一般为00000001；

S402、查找到帧开始标记后，开始读取该帧开始标记之后的第5个字节nalu_type（NAL（网络提取层）是以Nalunit为单元来支持编码数据在基于包交换技术网络中传输的；Nal中包含标头（Header），此Header内又有许多资讯，包括该Nal的类型，nalu_type就是对Nal的类型的说明），如果该字节是6，则进入步骤S403，如果该字节是5，则说明该数据帧为关键帧，即转入步骤S404，而如果是5和6以外的值，则说明该数据帧不是关键帧，即转入步骤S405；

S403、获取Recoery_Frame_count的值；如果第5个字节nalu_type是6，则说明该数据帧是SEI（补充增强信息，可以存放影片简介，版权信息、使用者自行定义的资料等），通过SEI中包含的信息获取Recoery_Frame_count（恢复帧计数，关键帧中该值大于0，可作为判断关键帧的依据）的值，如果该值大于0，则说明是关键帧，即转入步骤S404，反之，则说明不是关键帧，即转入步骤S405；

S404、判断该数据帧是关键帧；

S405、判断该数据帧不是关键帧。

基于上述方法，本发明还提供一种实时媒体流传输系统，如图6所示，其包括服务器端100和客户端200，所述服务器端100包括关键帧包生成模块110、关键帧包发送模块120以及关键帧包重传模块130；

所述关键帧包生成模块110，用于判断需传输的媒体流的数据帧是否是关键帧，当判断数据帧为关键帧时，将所述数据帧拆分为数据包的同时在该数据帧中添加关键帧标识成为关键帧包；

所述关键帧包发送模块120，用于将所述关键帧包发送至客户端，并监听客户端是否返回了接收到所述关键帧包的确认信息；

所述关键帧包重传模块130，用于在预定时间内没有监听到客户端返回的确认信息时，重新将所述关键帧包发送至客户端。关于上述功能模块的作用在前面的方法中已有详述，故不再赘述。

进一步，如图7所示，所述关键帧包发送模块120包括：

监听建立单元121，用于与客户端建立监听；

关键帧包发送单元122，用于获取所述关键帧包，并将所述关键帧包发送至客户端；

确认信息监听单元123，用于监听所述客户端是否返回了接收到所述关键帧包的确认信息。关于上述功能模块的作用在前面的方法中已有详述，故不再赘述。

进一步，如图8所示，所述客户端200包括：

关键帧包判断模块210，用于判断接收到的数据包是否为关键帧包；

数据包ID提取模块220，用于当所述数据包是关键帧包时，提取所述关键帧包的数据包ID；

数据包ID匹配模块230，用于将所述数据包ID与客户端的关键帧包ID列表匹配，查找所述关键帧包ID列表是否含有该数据包ID；

确认信息发送模块240，用于当所述关键帧包ID列表没有该数据包ID时，将该数据包ID添加至所述关键帧包ID列表，并将含有该数据包ID的确认信息发送至服务器端。关于上述功能模块的作用在前面的方法中已有详述，故不再赘述。

进一步，所述客户端200还包括：

关键帧包丢弃模块，用于当所述关键帧包ID列表中含有该数据包ID时，则将客户端接收到的关键帧包丢弃。

综上所述，本发明通过在需传输的媒体流的关键帧拆分为RTP包的时候，添加关键帧标识，并针对具有关键帧标识的RTP包进行重传确认机制，有效的减少了传输过程中的丢包率，确保了关键帧的完整性，提高了媒体流在客户端的解码效果，并且由于本发明只对关键帧进行重传确认，而非对整个传输过程加入重传确认机制，因而减少了对网络负载开销的影响，对媒体流实时传输的影响也很小，不会造成过多的网络负载负担。

应当理解的是，本发明的应用不限于上述的举例，对本领域普通技术人员来说，可以根据上述说明加以改进或变换，所有这些改进和变换都应属于本发明所附权利要求的保护范围。

Claims (9)

1.一种实时媒体流传输方法，其特征在于，包括步骤：

A、服务器端判断需传输的媒体流的数据帧是否是关键帧，当判断数据帧为关键帧时，将所述数据帧拆分为数据包的同时在该数据帧中添加关键帧标识成为关键帧包，所述关键帧标识为6个字节的IFRAME标识；

B、将所述关键帧包发送至客户端，并监听客户端是否返回了接收到所述关键帧包的确认信息；

C、当服务器端在预定时间内没有监听到客户端返回的确认信息时，重新将所述关键帧包发送至客户端；

当所述媒体流的编码方式为264编码时，所述步骤A中判断数据帧是否为关键帧的步骤具体包括：

A1、获取一帧264数据，查找所述264数据的帧开始标记；

A2、查找到帧开始标记后，开始读取该帧开始标记之后的第5个字节，若该字节是6，则转入步骤A3，若该字节是5，则判断该数据帧为关键帧，若该字节是5和6以外的值，则判断该数据帧不是关键帧；

A3、获取所述数据帧中的恢复帧计数的值，若该值大于0，则判断是关键帧，否则判断不是关键帧。

2.根据权利要求1所述实时媒体流传输方法，其特征在于，所述步骤B具体包括：

B1、服务器端与客户端建立监听；

B2、获取所述关键帧包，并将所述关键帧包发送至客户端；

B3、监听所述客户端是否返回了接收到所述关键帧包的确认信息。

3.根据权利要求1所述实时媒体流传输方法，其特征在于，所述步骤B中还包括：

C1、客户端判断接收到的数据包是否为关键帧包；

C2、当所述数据包是关键帧包时，提取所述关键帧包的数据包ID；

C3、将所述数据包ID与客户端的关键帧包ID列表匹配，查找所述关键帧包ID列表是否含有该数据包ID；

C4、当所述关键帧包ID列表没有该数据包ID时，将该数据包ID添加至所述关键帧包ID列表，并将含有该数据包ID的确认信息发送至服务器端。

4.根据权利要求3所述实时媒体流传输方法，其特征在于，所述步骤步骤C4还包括：

当所述关键帧包ID列表中含有该数据包ID时，则将客户端接收到的关键帧包丢弃。

5.根据权利要求3所述实时媒体流传输方法，其特征在于，所述方法还包括步骤：

D、当服务器端在预定时间内监听到客户端返回的确认信息时，判断该确认信息中的数据包ID与最近发送的关键帧包的数据包ID是否相同，当是时，返回步骤A，否则重新发送该关键帧包。

6.一种实时媒体流传输系统，包括服务器端和客户端，其特征在于，所述服务器端包括关键帧包生成模块、关键帧包发送模块以及关键帧包重传模块；

所述关键帧包生成模块，用于判断需传输的媒体流的数据帧是否是关键帧，当判断数据帧为关键帧时，将所述数据帧拆分为数据包的同时在该数据帧中添加关键帧标识成为关键帧包，所述关键帧标识为6个字节的IFRAME标识，当所述媒体流的编码方式为264编码时，判断数据帧是否为关键帧的步骤为：获取一帧264数据，查找所述264数据的帧开始标记；查找到帧开始标记后，开始读取该帧开始标记之后的第5个字节，若该字节是6，则获取所述数据帧中的恢复帧计数的值，若该值大于0，则判断是关键帧，否则判断不是关键帧；若该字节是5，则判断该数据帧为关键帧，若该字节是5和6以外的值，则判断该数据帧不是关键帧；

所述关键帧包发送模块，用于将所述关键帧包发送至客户端，并监听客户端是否返回了接收到所述关键帧包的确认信息；

所述关键帧包重传模块，用于在预定时间内没有监听到客户端返回的确认信息时，重新将所述关键帧包发送至客户端。

7.根据权利要求6所述实时媒体流传输系统，其特征在于，所述关键帧包发送模块包括：

监听建立单元，用于与客户端建立监听；

关键帧包发送单元，用于获取所述关键帧包，并将所述关键帧包发送至客户端；

确认信息监听单元，用于监听所述客户端是否返回了接收到所述关键帧包的确认信息。

8.根据权利要求6所述实时媒体流传输系统，其特征在于，所述客户端包括：

关键帧包判断模块，用于判断接收到的数据包是否为关键帧包；

数据包ID提取模块，用于当所述数据包是关键帧包时，提取所述关键帧包的数据包ID；

数据包ID匹配模块，用于将所述数据包ID与客户端的关键帧包ID列表匹配，查找所述关键帧包ID列表是否含有该数据包ID；

确认信息发送模块，用于当所述关键帧包ID列表没有该数据包ID时，将该数据包ID添加至所述关键帧包ID列表，并将含有该数据包ID的确认信息发送至服务器端。

9.根据权利要求6所述实时媒体流传输系统，其特征在于，所述客户端还包括：

关键帧包丢弃模块，用于当所述关键帧包ID列表中含有该数据包ID时，则将客户端接收到的关键帧包丢弃。