CN101867453B

CN101867453B - 一种rtp抗丢包的方法

Info

Publication number: CN101867453B
Application number: CN2010101982979A
Authority: CN
Inventors: 姜圳
Original assignee: Beijing Jiaxun Feihong Electrical Co Ltd
Current assignee: Beijing Jiaxun Feihong Electrical Co Ltd
Priority date: 2010-06-04
Filing date: 2010-06-04
Publication date: 2012-08-22
Anticipated expiration: 2030-06-04
Also published as: CN101867453A

Abstract

本发明公开了计算机通信技术领域中的一种RTP抗丢包的方法。用于解决RTP缺乏重传机制及RTP无法忽略网络丢包的问题。该方法包括在流媒体发送端发送流媒体数据前，在数据包包头的贡献源标识符CSRC字段中存放扩展头；在所述扩展头中，设置前向纠错周期；每发送一帧，序列号加1；每当序列号与前向纠错周期长度取余运算的结果等于前向纠错周期长度减1时，发送纠错帧，同时将序列号加1；当1个前向周期内丢帧数超过1时，则采用反馈重发机制由流媒体接收端请求重发丢掉的帧，或者直接忽略掉无法恢复的帧，防止由于重发而引起的网络拥塞。本发明改进了RTP的传输机制，使RTP具有重传功能，提高了RTP传输流媒体数据的服务质量。

Description

一种RTP抗丢包的方法

技术领域

本发明属于计算机通信技术领域，尤其涉及一种RTP抗丢包的方法。

背景技术

视频数据承载在IP网络上，以视频数据包的形式传输，这不可避免地会遇到网络丢包的问题。丢包会造成视频图像马赛克、图像局部变形、屏幕频繁刷新或闪烁、视音频不同步、帧率下降和图像静止等问题。这些问题将在很大程度上影响使用者的应用感受，如果网络丢包率过大或者过于频繁，还将会使视频数据的传输过度延迟，甚至造成通信中断。

针对流媒体数据的特点，由于音、视频数据少量的差错和丢失对最终播放质量的影响较小，为了避免采用可靠传输带来的时延，提高数据的实时性，目前普遍采用实时传输协议RTP(Real-time Transport Protocol)。

实时传输协议RTP是专门用于因特网上实时多媒体数据传输的一种协议，一般是在UDP(User Datagram Protocol，用户数据包协议)数据包之前建立一个RTP包头，其中包含了一些保证数据实时连续性的信息(如序列号、时间戳等)。RTP被定义为在一对一或一对多的传输模式下工作，提供时间信息和流同步。RTP协议本身不提供流量控制和拥塞控制功能，它靠一个实时传输控制协议RTCP(RTP Control Protocol)来实现。RTCP周期性地统计数据包传输时的丢失情况等信息，服务器根据这些反馈信息来制定流量控制的策略，改变传输码率甚至负载类型，大大提高了实时数据的传输性能。

实时业务是用RTP包承载于UDP来传输的，因此没有重传机制，流媒体系统是无法忽略网络丢包带来的影响的，实时数据的丢包对于一个连续序列的实时视频数据是非常致命的。

针对现有实时传输协议RTP存在的缺陷，本发明通过引入FEC(ForwardError Correction，前向纠错，也叫前向纠错码)，实现传输出现错误时的接收端重建数据功能。本发明能自动实现纠错，不要求检错重发，因而延时小、实时性好。

发明内容

本发明的目的在于，针对RTP没有重传机制，基于RTP的流媒体系统无法忽略网络丢包带来的影响的问题，提出一种RTP抗丢包的方法，利用前向纠错FEC，实现RTP传输出现错误时的接收端重建数据功能。

技术方案是，一种RTP抗丢包的方法，包括流媒体发送端和流媒体接收端的操作过程，其特征在于，

所述流媒体发送端的操作过程是：

步骤11：在流媒体发送端发送流媒体数据前，在数据包包头的贡献源标识符CSRC字段中存放扩展头；在所述扩展头中，设置前向纠错周期；

步骤12：流媒体发送端发送流媒体数据时，指定底层协议不对该流媒体数据进行分帧处理，每发送一帧，序列号加1；

步骤13：每当序列号与前向纠错周期长度取余运算的结果等于前向纠错周期长度减1时，发送纠错帧，同时将序列号加1；

步骤14：当1个前向周期内丢帧数超过1时，则采用反馈重发机制由流媒体接收端请求重发丢掉的帧，或者直接忽略掉无法恢复的帧，防止由于重发而引起的网络拥塞；

所述流媒体接收端的操作过程是：

步骤21：流媒体接收端接收到流媒体数据后，计算正在接收的数据包的抖动时延；

步骤22：判断抖动时延与第一设定值的大小，当抖动时延小于等于第一设定值时，执行步骤23；否则，认为正在接收的数据包已经丢失，执行步骤25；

步骤23：判断抖动时延与第二设定值的大小，当抖动时延小于等于第二设定值时，执行步骤24；否则，执行步骤25；

步骤24：采用前向纠错FEC进行纠错；

步骤25：采用反馈重发机制请求重发数据帧。

所述纠错帧的计算方法具体为：将前向纠错周期内所有帧字节进行异或运算，用于纠正1个前向周期内的1个丢帧。

所述计算正在接收的数据包的抖动时延前，还包括：

步骤31：判断所述正在接收的数据包是否为重复包，如果是重复包，则执行步骤32；否则，执行步骤33；

步骤32：丢弃该正在接收的数据包，返回步骤31，准备接收下一个数据包；

步骤33：判断数据包存储队列的长度，如果数据包存储队列的长度超出数据包存储队列长度预定值，则丢弃该正在接收的数据包并返回步骤31，准备接收下一个数据包；否则，将该正在接收的数据包加入数据包存储队列。

本发明改进了RTP的传输机制，使RTP具有重传功能，提高了RTP传输流媒体数据的服务质量。

附图说明

图1为视频监控系统的原理图；

图2是RTP数据包包头结构示意图；

图3是流媒体发送端工作流程示意图；

图4是流媒体接收端工作流程示意图。

具体实施方式

下面结合附图，对优选实施例作详细说明。应该强调的是，下述说明仅仅是示例性的，而不是为了限制本发明的范围及其应用。

图1为视频监控系统的原理图。在本实施例中，以视频监控系统为对象，说明RTP抗丢包的方法。图1中，视频监控系统包括中心管理服务单元、视频数据分发/转发处理单元、前端设备单元和用户单元。其中，中心管理服务单元是视频监控系统的核心单元，负责实现监控设备和客户端的接入、各单元的信令转发控制处理、报警信息的接收与处理以及业务支撑信息管理。视频数据分发/转发处理单元用于实现音/视频的接收、分发和转发。

整个视频监控系统中，服务器(中心管理服务单元和视频数据分发/转发处理单元)具备固定IP地址，在前端设备上配置有服务器地址信息，当前端设备加电启动之后，它会自动不断连接服务器，直至和服务器建立一条控制通道(见图1中的实线部分)，并且保持控制通道一直建立，如果发生断线前端设备会自动重联。前端设备在和服务器建立控制通道后会将自己的所有设备信息(包含IP地址)注册到服务器上。当有用户要监控某个监控点时，用户通过软件登录到服务器点击他想看的前端监控点，则服务器会通过控制通道通知相应前端设备向服务器建立数据通道(见图1中的虚线部分)并开始发送音/视频数据给用户，客户端(用户单元)播放器则负责解码和播放接收到的媒体数据。当用户关闭监控图像时，服务器会通过控制通道通知前端设备关闭数据通道。由此可知，图1中的视频数据分发/转发处理单元即为流媒体发送端，图1中的用户单元即为流媒体接收端。

在视频监控系统中，经过编码器编码的视频数据需要实时的发送到用户单元，该功能由服务器的视频数据分发/转发处理单元中的分发线程完成。分发线程从系统存储区中读取1440字节的视频数据，封装成RTP包，通过UDP单播或UDP多播发送到网络上去。

图2是RTP数据包包头结构示意图。图2中，RTP数据包包头结构具体为：

V-版本。占用2bits位，用于识别RTP版本。

P-间隙(Padding)。1bit设置时，数据包包含一个或多个附加间隙位组，其中这部分不属于有效载荷。

X-扩展位。1bit设置时，在固定头后面，根据指定格式设置一个扩展头。

CSRC Count-包含CSRC标识符(在固定头后)的编号，占用4bits位。

M-标记。1bit标记由Profile文件定义。允许重要事件如帧边界在数据包流中进行标记。

Payload Type-识别RTP有效载荷的格式，并通过应用程序决定其解释。7bits。Profile文件规定了从Payload编码到Payload格式的缺省静态映射。另外的Payload Type编码可能通过非RTP方法实现动态定义。

Sequence Number 16bits-每发送一个RTP数据包，序列号增加1。接收方可以依次检测数据包的丢失并恢复数据包序列。

Timestamp 32bits-反映RTP数据包中的第一个八位组的采样时间。采样时间必须通过时钟及时提供线性无变化增量获取，以支持同步和抖动计算。

SSRC-32bits同步源。该标识符随机选择，旨在确保在同一个RTP会话中不存在两个同步源具有相同的SSRC标识符。

本系统中采用以下结构表示一个同步源：

Struct{

WORD systemid；//系统号，每个系统中唯一的系统号

BYTE machineid；//编码器号，在一个系统中唯一的

BYTE avsourceid；//编码器的通道号，在这个设备是唯一的

}；

CSRC-32bits贡献源标识符。识别该数据包中的有效载荷的贡献源。

本系统中一个同步源不需要进一步区分贡献源，即一个同步源只对应一个贡献源，所以不再需要CSRC来区分贡献源。因此，可以用一个CSRC来存放扩展头：

Struct{

BYTE version：2；

BYTE type：2；

BYTE payload：4；

BYTE fectype：4；

BYTE feclen：4；

WORD reserved；

}

Version：固定为0

Type：固定为0

Payload：数据包内的数据类型

0：为音频

1：为视频

Fectype：前向纠错类型

0：无前向纠错

1：简单的前向纠错

Feclen：前向纠错周期长度

0：fec len＝4

1：fec len＝8

2：fec len＝16

3：fec len＝32

4：fec len＝64

5：fec len＝128

由于RTP/UDP协议是面向非连接的，所以服务器端只能通过客户端的反馈信息来了解用户是否还要接收数据，以维护服务器端的用户链表。服务器端一旦接收到某个用户的连接请求就把该用户放入用户链表；如果在30秒时间内没有收到该用户的反馈信息，表示该用户已经不存在，则把该用户从用户链表上删除(一般是用户程序非法退出造成)；在正常情况下，客户端如果要连续接收数据，则会在规定时间内返回反馈信息，以确定连接，并在断开连接时发送一个断开请求，服务器一旦收到该断开请求，就把该用户从用户链表上删除。基于上述原理，本发明具体的操作过程如图3和图4所示。

图3是流媒体发送端工作流程示意图。图3中，流媒体发送端的操作过程是：

步骤101：在流媒体发送端发送流媒体数据前，在数据包包头的贡献源标识符CSRC字段中存放扩展头；在所述扩展头中，设置前向纠错周期。

步骤102：流媒体发送端发送流媒体数据时，指定底层协议不对该流媒体数据进行分帧处理，每发送一帧，序列号加1。

之所以不进行分帧处理，是因为链路层对所传输的数据帧的最大长度有限制，通过将流媒体数据每帧都是固定长度1440+16字节，来避免由于数据帧过大而导致底层协议强制将数据分帧。通过指定底层协议不对该流媒体数据的帧进行分帧处理，来保证数据帧的有序。

步骤103：每当序列号与前向纠错周期长度取余运算的结果等于前向纠错周期长度减1时，发送纠错帧，同时将序列号加1。

例如，纠错周期设置为4，数据帧的序列号从1开始使用，当数据帧的序列号为1、2时，不发送纠错帧；当序列号为3时，既满足序列号与前向纠错周期长度取余运算的结果等于前向纠错周期长度减1的条件，此时发送纠错帧，该纠错帧的序列号为4。同理，当数据帧的序列号为5、6时，不发送纠错帧；当序列号为7时，既满足序列号与前向纠错周期长度取余运算的结果等于前向纠错周期长度减1的条件，此时发送纠错帧，该纠错帧的序列号为8，依次类推。

纠错帧的计算方法具体为：将前向纠错周期内所有帧字节进行异或运算，用于纠正1个前向周期内的1个丢帧。例如：如果序列号为2的数据帧丢失，则可以用序列号为1的数据帧，序列号为3的数据帧和序列号为4的纠错帧将序列号为2的数据帧恢复，从而纠正一个前向周期内的丢帧。异或运算法则是，通过d＝a^b^c，可以推出a＝d^b^c。

步骤104：当1个前向周期内丢帧数超过1时，则采用反馈重发机制由流媒体接收端请求重发丢掉的帧，或者直接忽略掉无法恢复的帧，防止由于重发而引起的网络拥塞。

图4是流媒体接收端工作流程示意图。由于报文在网络的传输存在时延，接收端需要缓冲来存储接收到的数据包，进行重新排序和纠错。图4中，流媒体接收端的操作过程是：

步骤201：流媒体接收端接收流媒体数据。

步骤202：判断正在接收的数据包是否为重复包，如果是重复包，则执行步骤203；否则，执行步骤204。

步骤203：丢弃该正在接收的数据包，返回步骤201，准备接收下一个数据包。

步骤204：判断数据包存储队列的长度，如果数据包存储队列的长度超出数据包存储队列长度预定值，则执行步骤205；否则，执行步骤206。

步骤205：丢弃该正在接收的数据包，返回步骤201，准备接收下一个数据包。

步骤206：将该正在接收的数据包加入数据包存储队列。

步骤207：计算正在接收的数据包的抖动时延。

抖动时延的计算公式为：Jitter＝Trcv-Tmean。其中，Jitter为抖动时延，Trcv是数据包的接收时间，Tmean是正在接收的数据包的估计接收时间。

步骤208：判断抖动时延与第一设定值的大小，当抖动时延小于等于第一设定值时，执行步骤209；否则，认为正在接收的数据包已经丢失，执行步骤211。

步骤209：判断抖动时延与第二设定值的大小，当抖动时延小于等于第二设定值时，执行步骤210；否则，执行步骤211。

步骤210：采用前向纠错FEC进行纠错。

步骤211：采用反馈重发机制请求重发数据帧。

以上所述，仅为本发明较佳的具体实施方式，但本发明的保护范围并不局限于此，任何熟悉本技术领域的技术人员在本发明揭露的技术范围内，可轻易想到的变化或替换，都应涵盖在本发明的保护范围之内。因此，本发明的保护范围应该以权利要求的保护范围为准。

Claims

1.一种RTP抗丢包的方法，包括流媒体发送端和流媒体接收端的操作过程，其特征在于，

所述流媒体发送端的操作过程是：

步骤14：当1个前向纠错周期内丢帧数超过1时，则采用反馈重发机制由流媒体接收端请求重发丢掉的帧，或者直接忽略掉无法恢复的帧，防止由于重发而引起的网络拥塞；

所述流媒体接收端的操作过程是：

步骤201：流媒体接收端接收到流媒体数据；

步骤202：判断正在接收的数据包是否为重复包，如果是重复包，则执行步骤203；否则，执行步骤204；

步骤203：丢弃该正在接收的数据包，返回步骤201，准备接收下一个数据包；

步骤204：判断数据包存储队列的长度，如果数据包存储队列的长度超出数据包存储队列长度预定值，则执行步骤205；否则，执行步骤206；

步骤205：丢弃该正在接收的数据包，返回步骤201，准备接收下一个数据包；

步骤206：将该正在接收的数据包加入数据包存储队列；

步骤207：计算正在接收的数据包的抖动时延；

步骤208：判断抖动时延与第一设定值的大小，当抖动时延小于等于第一设定值时，执行步骤209；否则，认为正在接收的数据包已经丢失，执行步骤211；

步骤209：判断抖动时延与第二设定值的大小，当抖动时延小于等于第二设定值时，执行步骤210；否则，执行步骤211；

步骤210：采用前向纠错FEC进行纠错；

步骤211：采用反馈重发机制请求重发数据帧。

2.根据权利要求1所述的一种RTP抗丢包的方法，其特征在于所述纠错帧的计算方法具体为：将前向纠错周期内所有帧字节进行异或运算，用于纠正1个前向纠错周期内的1个丢帧。