CN109150410B

CN109150410B - 数据传输方法和装置

Info

Publication number: CN109150410B
Application number: CN201811299973.4A
Authority: CN
Inventors: 熊天作; 覃炳达; 黄桂泉
Original assignee: Comba Network Systems Co Ltd
Current assignee: Comba Network Systems Co Ltd
Priority date: 2018-10-30
Filing date: 2018-10-30
Publication date: 2021-09-24
Anticipated expiration: 2038-10-30
Also published as: CN109150410A

Abstract

本申请涉及一种数据传输方法和装置；其中，数据传输方法包括：将FEC包传输给接收端；FEC包包括有效数据包和冗余包；有效数据包为删除无效数据后的数据包；FEC包用于指示接收端基于冗余包的数据长度、对有效数据包进行无效数据补入。FEC包为经过FEC编码得到的，进而FEC包中数据包的长度是固定的，数据包中包括有效数据和为了达到固定长度而补充的无效数据，因此，本申请将删除无效数据后的有效数据包传输给接收端，减少了传输所需的数据量，节省了网络带宽。

Description

数据传输方法和装置

技术领域

本申请涉及网络数据传输技术领域，特别是涉及一种数据传输方法和装置。

背景技术

前向纠错(Forward Error Correction，FEC)是一种数据编码的技术，数据的接收方可以根据编码检查传输过程中的误码。在FEC编码中，发送方一般在要发送的数据前加上一段冗余的数据，这样接收方就可以根据这些冗余数据和提前设计好的算法发现数据中的误码并且确定具体错误码子的位置，从而纠正错误。当误码被确定后，不需要通知发送端重新发送，而是自动纠正错误。这种机制不同于自动重传(Automatic Repeat-reQuest，ARQ)需要通知发送端重新发送没有送达的数据。

在实现过程中，发明人发现传统技术中至少存在如下问题：在FEC编码中，编码的长度必须是固定的，因此，在传输过程中，经过FEC编码后的数据会占用大量网络带宽。

发明内容

基于此，有必要针对上述技术问题，提供一种能够节省网络带宽的数据传输方法和装置。

为了实现上述目的，一方面，本发明实施例提供了一种数据传输方法，包括：

将FEC包传输给接收端；FEC包包括有效数据包和冗余包；有效数据包为删除无效数据后的数据包；

FEC包用于指示接收端基于冗余包的数据长度、对有效数据包进行无效数据补入。

在其中一个实施例中，将FEC包传输给接收端的步骤之前还包括步骤：

区分待发送RTP包的数据类型；

采用与数据类型对应的编码长度，对待发送RTP包进行FEC编码，得到FEC包。

在其中一个实施例中，区分待发送RTP包的数据类型的步骤包括：

根据待发送RTP包头部的负载类型PT，区分待发送RTP包的数据类型。

在其中一个实施例中，在区分待发送RTP包的数据类型之前还包括步骤：

对获取到的数据流进行RTP封包，得到待发送RTP包；数据流为视频流、音频流或音视频混合流；数据类型为音频流RTP包、视频流RTP包或音视频混合流RTP包。

在其中一个实施例中，采用与数据类型对应的编码长度，对待发送RTP包进行FEC编码，得到FEC包的步骤包括：

在数据类型为音视频混合流RTP包时，采用视频流编码长度对音视频混合流RTP包中的视频帧RTP包进行FEC编码、采用音频流编码长度对音视频混合流RTP包中的音频帧RTP包进行FEC编码，得到FEC包。

另一方面，本发明实施例还提供了一种数据传输方法，包括：

接收发送端传输的FEC包；FEC包包括有效数据包和冗余包；有效数据包为删除无效数据后的数据包；

基于冗余包的数据长度，对有效数据包进行无效数据补入。

一种数据传输装置，包括：

传输模块，用于将FEC包传输给接收端；FEC包包括有效数据包和冗余包；有效数据包为删除无效数据后的数据包；

一种数据传输装置，包括：

接收模块，用于接收发送端传输的FEC包；FEC包包括有效数据包和冗余包；有效数据包为删除无效数据后的数据包；

补入模块，用于基于冗余包的数据长度，对有效数据包进行无效数据补入。

一种发送端，该发送端用于执行各实施例中从接收端角度实施的数据传输方法的步骤。

一种接收端，该接收端用于执行各实施例中从接收端角度实施的数据传输方法的步骤。

一种数据传输系统，包括发送端和连接发送端的接收端；

发送端用于执行各实施例中从发送端角度实施的数据传输方法的步骤；

接收端用于执行各实施例中从接收端角度实施的数据传输方法的步骤。

一种计算机可读存储介质，其上存储有计算机程序，计算机程序被处理器执行时实现各实施例中的方法的步骤。

上述技术方案中的一个技术方案具有如下优点和有益效果：

FEC包为经过FEC编码得到，进而FEC包中数据包的长度是固定的，数据包中包括有效数据和为了达到固定长度而补充的无效数据；本申请将删除无效数据后的有效数据包传输给接收端，减少了传输所需的数据量，节省了网络带宽。

附图说明

通过阅读参照以下附图所作的对非限制性实施例所作的详细描述，本申请的其它特征、目的和优点将会变得更明显：

图1为一个实施例中从发送端角度实施的数据传输方法的第一示意性流程示意图；

图2为一个实施例中从发送端角度实施的数据传输方法的第二示意性流程示意图；

图3为一个实施例中从发送端角度实施的数据传输方法的示意性流程示意图；

图4为一个具体的例子中从发送端角度和接收端角度实施的数据传输方法的示意性流程示意图；

图5为一个具体的例子中从发送端角度和接收端角度实施的数据传输方法中对于原始视频帧流进行传输的示意性流程示意图；

图6为一个具体的例子中从发送端角度和接收端角度实施的数据传输方法中对于原始音频帧进行传输的示意性流程示意图；

图7为一个实施例中从发送端角度实施的数据传输装置的结构框图；

图8为一个实施例中从接收端角度实施的数据传输装置的结构框图。

具体实施方式

为了使本申请的目的、技术方案及优点更加清楚明白，以下结合附图及实施例，对本申请进行进一步详细说明。应当理解，此处描述的具体实施例仅仅用以解释本申请，并不用于限定本申请。

在一个实施例中，如图1所示，提供了一种数据传输方法，以该方法应用于发送端为例进行说明，包括以下步骤：

步骤102，将FEC包传输给接收端；FEC包包括有效数据包和冗余包；有效数据包为删除无效数据后的数据包。

其中，FEC包用于指示接收端基于冗余包的数据长度、对有效数据包进行无效数据补入。FEC包可以是指通过FEC编码得到的包；无效数据可以取不同的数值表示，一般在FEC编码中，无效数据为0；经FEC编码后得到的数据包一般包括真实有效数据和无效数据。

在FEC编码中，编码的长度必须是固定的，如果不固定，则必须在后面补0使长度一定，即在传输过程中，经过FEC编码后补0的无效数据会占用大量网络带宽。而上述从发送端角度实施的数据传输方法中，FEC包为经过FEC编码得到的，进而FEC包中数据包的长度是固定的，数据包中包括有效数据和为了达到固定长度而补充的无效数据，因此，本申请将删除无效数据后的有效数据包传输给接收端，减少了传输所需的数据量，节省了网络带宽。

在一个实施例中，如图2所示，提供了一种数据传输方法，以该方法应用于发送端为例进行说明，包括以下步骤：

步骤S202，对获取到的数据流进行RTP(Real-time Transport Protocol，实时传输协议)封包，得到待发送RTP包。

其中，数据流可以为视频流、音频流或音视频混合流。

步骤S204，区分待发送RTP包的数据类型。

其中，数据类型可以为音频流RTP包、视频流RTP包或音视频混合流RTP包。

具体地，待发送RTP包头部的负载类型PT可以有效区分待发送RTP包对应的是音频流还是视频流,比如负载类型PT为96时可以表示H264格式的视频流，负载类型PT为9可以表示G722格式的音频流，进一步的，负载类型PT的取值范围可以为0至127。

步骤S206，采用与数据类型对应的编码长度，对待发送RTP包进行FEC编码，得到FEC包。

其中，编码长度可以有两种：一是对应音频流RTP包的音频流编码长度；二是对应视频流RTP包的视频流编码长度。因为针对不同数据类型有不同的编码长度，而不是采用固定不变的编码长度，使得某种数据类型的待发送RTP包能够采用更小的编码长度进行FEC编码，减少编码得到的FEC包的数据量，进而节省传输时占用的网络带宽。

步骤S208，将FEC包传输给接收端。

在一个具体的实施例中，根据待发送RTP包头部的负载类型PT(Payload Type)，区分待发送RTP包的数据类型。

在一个具体的实施例中，采用与数据类型对应的编码长度，对待发送RTP包进行FEC编码，得到FEC包的步骤包括：

其中，音频流编码长度可以小于视频流编码长度，进而可以减少编码得到的FEC包的数据量。

对于与上一实施例中相同的特征，这里不再赘述。

上述从发送端角度实施的数据传输方法中，在FEC编码时，采用与数据类型对应的编码长度，对待发送RTP包进行FEC编码，得到FEC包，进而可以使数据类型为音频帧RTP包的待发送RTP包能够用更小的编码长度进行FEC编码，避免音频包和视频包都用同一编码长度进行FEC编码，减少编码得到的FEC包的数据量；

FEC包为经过FEC编码得到的，进而FEC包中数据包的长度是固定的，数据包中包括有效数据和为了达到固定长度而补充的无效数据，因此，本申请将删除无效数据后的有效数据包传输给接收端；

综上，利用不同的编码长度对不同类型的待发送RTP包(音频帧RTP包或视频帧RTP包)，减小了FEC包的数据量，再通过删除FEC包中数据包的无效数据，进一步减少了所需传输的数据量，极大地节省了网络带宽。

在一个实施例中，如图3所示，提供了一种数据传输方法，以该方法应用于接收端为例进行说明，包括以下步骤：

步骤S302，接收发送端传输的FEC包。

其中，FEC包包括有效数据包和冗余包；有效数据包为删除无效数据后的数据包。

步骤S304，基于冗余包的数据长度，对有效数据包进行无效数据补入。

其中，冗余包的数据长度和数据包的数据长度是一样的，因此，能够根据冗余包的数据长度对有效数据包进行无效数据补入。FEC包的头部可以包括数据包中有效数据的长度、FEC包的数据长度以及FEC包需要编解码的长度(编码长度，等同于冗余包或数据包的数据长度)。

对于与上述各实施例中相同的特征，这里不再赘述。

上述从接收端角度实施的数据传输方法中，接收到的FEC包中的数据包没有无效数据，需要对数据包中的无效数据进行补充后才能对FEC包进行FEC解码，因此，上述方法能够传输不带无效数据的数据包，可以减小FEC包的数据量，节省了传输时占用的网络带宽。

下面结合具体的例子，从发送端和接收端的角度进行阐述，对各实施例中的一个实施例进行详细地说明。

在FEC编码中，编码的长度必须是固定的，如果不固定，则必须在后面补0使长度一定。由于在网络传输中，将音视频帧的裸流经过RTP封包后不会超过MTU值的长度(假设为1400Bytes(字节))，音频帧的RTP包的长度更小(假设为320Bytes)。如果音视频的FEC编码长度是固定的，那么将意味着经过FEC编码后的每个音频帧冗余包长度将会多出1080Bytes(1400-320＝1080)；而且实际的每个音视频RTP包的大小是不一样，可能有些视频包的大小只有十几个字节；如果以这样的长度传输RTP包，则必然会造成带宽的大量浪费。

在音视频通信中，音频流和视频流的区别是比较大的。以视频流来说，假设1秒钟20帧图片，摄像头捕捉一帧高清1080p*720p原始RGB32格式的图片存储需要1080*720*4＝3110400bit(比特)＝380k，则1秒钟为7.42m；转成YUV420格式的图片存储需要1080*720*1.5＝1166400bit＝142k(千比特)，则1秒钟为2.77m(兆比特)；经过H264编码成视频帧，I帧来说压缩比不会太大，压缩比主要体现在B帧和P帧；如果H264的某个压缩算法的压缩比为2：1，则1秒钟为1.38m；

根据RTP包头部的负载类型PT可以有效区分音频流和视频流,比如PT为96标示是H264格式的视频,PT为9标示是G722格式的音频；PT的取值为0-127；

以音频流来说，某音频信号的采样率为8kHz，声道数为2，采样位数为16，时长为1s，则音频数据的大小为：8000*16*2*1/8＝256000/8byte(字节)＝32000byte＝31.25KB(千字节)；如果以AAC(Advanced Audio Coding，高级音频编码)格式来编码，压缩比为18：1，则最终大小为1.7k；一个AAC原始帧包含一段时间内1024个采样以及相关数据(mp3为1152个),即当前AAC一帧的播放时间为1024*1000/8000＝128ms,一帧的大小大约为(31.25/18)*(128/1000)＝228字节；由于一帧的大小已经远小于MTU大小(MTU大小为1500)，那么加上RTP头部(十几个字节)后也不会超过MTU的大小,所以这里计算出的RTP包的长度大致在300字节；

以视频流来说，如果每5帧视频帧的有一帧I帧，I帧假设为130k，则B帧和P帧约为55k，已经远大于MTU值的长度，这里需要通过将视频帧进行RTP封包到不超过MTU值的长度，(除了RTP头和其他的协议头的开销，RTP的payload(有效载荷)的大小一般设定在不超过1100时，可以是其他的值，只要最终所有的长度不超过MTU值，一般情况下我们用接近RTP包最大长度的某个值)。这里会特定将I帧的第一个RTP包封的比较小，不会超过50Bytes，后面的封包大部分都在1000Bytes左右。

进一步的，FEC编码的规则是：需要所有的RTP包的长度一致；所以FEC编码需要设定一个固定的长度；而不同长度的RTP包必须在固定长度以内补0以满足FEC编码的条件；最后经过FEC编码后的数据就是长度固定的一串码流,于是经过FEC编码后得到的FEC包的头部将会记录FEC包的真实有效长度，FEC包的长度，以及FEC包需要编解码的长度，以便网络传输前后编解码的使用。

综上，对于音频帧，RTP包的长度大致在300字节；对于视频帧，RTP包的长度在1000Bytes左右。传统的FEC编码方法对所有的RTP包采用固定的编码长度，使得音频包经过FEC编码后有大量的无效数据，而且这些无效数据还需要传输给接收端，导致占用大量网络带宽。

而如图4至图6所示的一种数据传输方法，能够灵活针对音频包或视频包采用不同的编码长度，同时删除无效数据，减少所需传输的数据量，节省网络带宽，该数据传输方法包括：

步骤S402，发送端对原始视频帧流进行RTP封包，得到视频帧RTP包；发送端对原始音频帧进行RTP封包，得到音频帧RTP包。

其中，原始视频帧流可以是H264格式，原始音频帧可以是AAC格式，进一步的，无效数据针对的是H264编解码和AAC编解码，但是针对FEC编解码来说，因为FEC编解码需要补0才能完成，所以补上的无效数据实际上还是有效数据。

视频帧RTP包为图5中的六个包，l：20、l：890、l：1020、l：1014、l：1029和l：1007分别表示视频帧RTP包的长度为20、890、1020、1014、1029和1007；

音频帧RTP包为图6中的六个包，l：280、l：320、l：320、l：300、l：320和l：320分别表示音频帧RTP包的长度为280、320、320、300、320和320。

步骤S404，发送端采用视频编码长度对视频帧RTP包进行FEC编码、采用音频编码长度对音频帧RTP包进行FEC编码，得到FEC包。

其中，图5中设置的视频编码长度为1100；图6中设置的音频编码长度为320。

具体地，可以按照数据包与冗余包比例为5:4进行FEC编码(每次只对5个音频帧RTP包或5个音频帧RTP包进行编码，剩下的1个视频帧RTP包或音频帧RTP包和对下一原始视频帧流进行RTP封包产生的音频帧RTP包或视频帧RTP包进行编码)，如图5中，FEC编码后得到上面五个数据包和下面四个冗余包，同样，图6中，FEC编码后得到上面五个数据包和下面四个冗余包。

需要说明的是，图5表示的FEC包中的l：1100表示长度为1100(视频编码长度)，也即所有数据包和所有冗余包的长度为1100；ul：20、ul：890、ul：1020、ul：1014、ul：1029和ul：1007表示五个数据包的真实有效数据长度分别为20、890、1020、1014、1029和1007。

图6表示的FEC包中的l：320表示长度为320(音频编码长度)，也即所有数据包和音频冗余包的长度为320；ul：280、ul：320、ul：320、ul：300、ul：320和ul：320表示五个数据包的真实有效数据长度分别为280、320、320、300、320和320。

步骤S406，发送端删除FEC包中数据包的无效数据，得到包含于FEC包的有效数据包。

需要说明的是，冗余包是用来和数据包一起来解码得到有可能会丢失的数据包，所以冗余包的长度不做处理。

步骤S408，发送端将FEC包传输给接收端。

步骤S410，接收端接收到FEC包后，根据FEC包中冗余包的编码长度，对FEC包的有效数据包补入无效数据；

其中，无效数据为0。

具体地，对视频数据包补入0直至长度与视频编码长度等同；对音频数据包补入0直至长度与音频编码长度等同。

步骤S412，接收端对补入无效数据后的FEC包进行解码。

按图5和图6可知，如果不经过上述数据传输方法的处理，传输FEC包的总带宽将会是1100*9*2＝19800Bytes。在基于音频编码长度为320和视频编码长度为1100这两种不同的编码长度分别进行FEC编码后，传输FEC包的总带宽将会是1100*9+320*9＝12780Bytes。如果删除无效数据，传输FEC包的总带宽将会是：

1100*4+20+890+1020+1014+1029+320*4+280+320+320+300+320＝11213Bytes。从上面数据可知，上述数据传输方法总共节省43％的网络带宽。

应该理解的是，虽然图1至图4的流程图中的各个步骤按照箭头的指示依次显示，但是这些步骤并不是必然按照箭头指示的顺序依次执行。除非本文中有明确的说明，这些步骤的执行并没有严格的顺序限制，这些步骤可以以其它的顺序执行。而且，图1至图4中的至少一部分步骤可以包括多个子步骤或者多个阶段，这些子步骤或者阶段并不必然是在同一时刻执行完成，而是可以在不同的时刻执行，这些子步骤或者阶段的执行顺序也不必然是依次进行，而是可以与其它步骤或者其它步骤的子步骤或者阶段的至少一部分轮流或者交替地执行。

在一个实施例中，如图7所示，提供了一种从发送端角度实施的数据传输装置，包括：

传输模块710，用于将FEC包传输给接收端；FEC包包括有效数据包和冗余包；有效数据包为删除无效数据后的数据包。

在一个具体的示例中，还包括：

区分模块，用于区分待发送RTP包的数据类型；

编码模块，用于采用与数据类型对应的编码长度，对待发送RTP包进行FEC编码，得到FEC包。

在一个具体的示例中，区分模块用于根据待发送RTP包头部的负载类型PT，区分待发送RTP包的数据类型。

在一个具体的示例中，还包括：

封包模块，用于对获取到的数据流进行RTP封包，得到待发送RTP包；数据流为视频流、音频流或音视频混合流；数据类型为音频流RTP包、视频流RTP包或音视频混合流RTP包。

在一个具体示例中，编码模块用于在数据类型为音视频混合流RTP包时，采用视频流编码长度对音视频混合流RTP包中的视频帧RTP包进行FEC编码、采用音频流编码长度对音视频混合流RTP包中的音频帧RTP包进行FEC编码，得到FEC包。

在一个实施例中，如图8所示，提供了一种从接收端角度实施的数据传输装置，包括：

接收模块810，用于接收发送端传输的FEC包；FEC包包括有效数据包和冗余包；有效数据包为删除无效数据后的数据包；

补入模块820，用于基于冗余包的数据长度，对有效数据包进行无效数据补入。

关于从发送端角度实施的数据传输装置的具体限定可以参见上文中对于从发送端角度实施的数据传输方法的限定，从接收端角度实施的数据传输装置的具体限定可以参见上文中对于从接收端角度实施的数据传输方法的限定，在此不再赘述。上述从发送端角度实施的数据传输装置和从接收端角度实施的数据传输装置中的各个模块可全部或部分通过软件、硬件及其组合来实现。上述各模块可以硬件形式内嵌于或独立于计算机设备中的处理器中，也可以以软件形式存储于计算机设备中的存储器中，以便于处理器调用执行以上各个模块对应的操作。

在一个实施例中，提供了一种发送端，该发送端用于执行实现以下步骤：

在一个具体的示例中，将FEC包传输给接收端的步骤之前还包括步骤：

区分待发送RTP包的数据类型；

在一个具体的示例中，区分待发送RTP包的数据类型的步骤包括：

在一个具体的示例中，在区分待发送RTP包的数据类型之前还包括步骤：

在一个具体的示例中，采用与数据类型对应的编码长度，对待发送RTP包进行FEC编码，得到FEC包的步骤包括：

在一个实施例中，提供了一种接收端，该接收端用于执行实现以下步骤：

基于冗余包的数据长度，对有效数据包进行无效数据补入。

在一个实施例中，提供了一种数据传输系统，包括发送端和连接发送端的接收端；

发送端用于执行实现以下步骤：

接收端用于执行实现以下步骤：

基于冗余包的数据长度，对有效数据包进行无效数据补入。

在一个具体的示例中，发送端用于在将FEC包传输给接收端的步骤之前还执行以下步骤：

区分待发送RTP包的数据类型；

在一个具体的示例中，发送端在执行区分待发送RTP包的数据类型的步骤时包括以下步骤：

在一个具体的示例中，发送端用于在区分待发送RTP包的数据类型之前还执行以下步骤：

在一个具体的示例中，发送端在执行采用与数据类型对应的编码长度，对待发送RTP包进行FEC编码，得到FEC包的步骤时包括以下步骤：

在一个实施例中，提供了一种应用于发送端的计算机可读存储介质，其上存储有计算机程序，计算机程序被处理器执行时实现以下步骤：

在一个具体的示例中，计算机程序被处理器执行时实现将FEC包传输给接收端的步骤之前还包括步骤：

区分待发送RTP包的数据类型；

在一个具体的示例中，计算机程序被处理器执行时实现区分待发送RTP包的数据类型的步骤包括：

在一个具体的示例中，计算机程序被处理器执行时实现在区分待发送RTP包的数据类型之前还包括步骤：

在一个具体的示例中，计算机程序被处理器执行时实现采用与数据类型对应的编码长度，对待发送RTP包进行FEC编码，得到FEC包的步骤包括：

在一个实施例中，提供了一种应用于接收端的计算机可读存储介质，其上存储有计算机程序，计算机程序被处理器执行时实现以下步骤：

基于冗余包的数据长度，对有效数据包进行无效数据补入。

本领域普通技术人员可以理解实现上述实施例方法中的全部或部分流程，是可以通过计算机程序来指令相关的硬件来完成，的计算机程序可存储于一非易失性计算机可读取存储介质中，该计算机程序在执行时，可包括如上述各方法的实施例的流程。其中，本申请所提供的各实施例中所使用的对存储器、存储、数据库或其它介质的任何引用，均可包括非易失性和/或易失性存储器。非易失性存储器可包括只读存储器(ROM)、可编程ROM(PROM)、电可编程ROM(EPROM)、电可擦除可编程ROM(EEPROM)或闪存。易失性存储器可包括随机存取存储器(RAM)或者外部高速缓冲存储器。作为说明而非局限，RAM以多种形式可得，诸如静态RAM(SRAM)、动态RAM(DRAM)、同步DRAM(SDRAM)、双数据率SDRAM(DDRSDRAM)、增强型SDRAM(ESDRAM)、同步链路(Synchlink)DRAM(SLDRAM)、存储器总线(Rambus)直接RAM(RDRAM)、直接存储器总线动态RAM(DRDRAM)、以及存储器总线动态RAM(RDRAM)等。

以上实施例的各技术特征可以进行任意的组合，为使描述简洁，未对上述实施例中的各个技术特征所有可能的组合都进行描述，然而，只要这些技术特征的组合不存在矛盾，都应当认为是本说明书记载的范围。

以上实施例仅表达了本申请的几种实施方式，其描述较为具体和详细，但并不能因此而理解为对发明专利范围的限制。应当指出的是，对于本领域的普通技术人员来说，在不脱离本申请构思的前提下，还可以做出若干变形和改进，这些都属于本申请的保护范围。因此，本申请专利的保护范围应以所附权利要求为准。

Claims

1.一种数据传输方法，其特征在于，包括：

区分待发送RTP包的数据类型；所述数据类型包括音频流RTP包、视频流RTP包或音视频混合流RTP包；

采用与所述数据类型对应的编码长度，对所述待发送RTP包进行FEC编码，得到FEC包；

将FEC包传输给接收端；所述FEC包包括有效数据包和冗余包；所述有效数据包为删除无效数据后的数据包；所述冗余包的长度与未删除无效数据的数据包的长度相同；

所述FEC包用于指示所述接收端基于所述冗余包的数据长度、对所述有效数据包进行无效数据补入。

2.根据权利要求1所述的数据传输方法，其特征在于，区分待发送RTP包的数据类型的步骤包括：

根据所述待发送RTP包头部的负载类型PT，区分所述待发送RTP包的数据类型。

3.根据权利要求1或2所述的数据传输方法，其特征在于，在区分待发送RTP包的数据类型之前还包括步骤：

对获取到的数据流进行RTP封包，得到所述待发送RTP包；所述数据流为视频流、音频流或音视频混合流。

4.根据权利要求3所述的数据传输方法，其特征在于，采用与所述数据类型对应的编码长度，对所述待发送RTP包进行FEC编码，得到所述FEC包的步骤包括：

在所述数据类型为所述音视频混合流RTP包时，采用视频流编码长度对所述音视频混合流RTP包中的视频帧RTP包进行FEC编码、采用音频流编码长度对所述音视频混合流RTP包中的音频帧RTP包进行FEC编码，得到所述FEC包。

5.一种数据传输方法，其特征在于，包括：

接收发送端传输的FEC包；所述FEC包包括有效数据包和冗余包；所述有效数据包为删除无效数据后的数据包；所述FEC包是通过所述发送端区分待发送RTP包的数据类型；所述数据类型包括音频流RTP包、视频流RTP包或音视频混合流RTP包；采用与所述数据类型对应的编码长度，对所述待发送RTP包进行FEC编码而得到所述FEC包；所述冗余包的长度与未删除无效数据的数据包的长度相同；

基于所述冗余包的数据长度，对所述有效数据包进行无效数据补入。

6.一种数据传输装置，其特征在于，包括：

区分模块，用于区分待发送RTP包的数据类型；所述数据类型包括音频流RTP包、视频流RTP包或音视频混合流RTP包；

编码模块，用于采用与所述数据类型对应的编码长度，对所述待发送RTP包进行FEC编码，得到FEC包；

传输模块，用于将FEC包传输给接收端；所述FEC包包括有效数据包和冗余包；所述有效数据包为删除无效数据后的数据包；所述冗余包的长度与未删除无效数据的数据包的长度相同；

7.一种数据传输装置，其特征在于，包括：

接收模块，用于接收发送端传输的FEC包；所述FEC包包括有效数据包和冗余包；所述有效数据包为删除无效数据后的数据包；所述FEC包是通过所述发送端区分待发送RTP包的数据类型；所述数据类型包括音频流RTP包、视频流RTP包或音视频混合流RTP包；采用与所述数据类型对应的编码长度，对所述待发送RTP包进行FEC编码而得到所述FEC包；所述冗余包的长度与未删除无效数据的数据包的长度相同；

补入模块，用于基于所述冗余包的数据长度，对所述有效数据包进行无效数据补入。

8.一种发送端，包括处理器和存储器，所述存储器存储有计算机程序，其特征在于，所述处理器执行所述计算机程序时用于执行权利要求1至4任意一项中所述数据传输方法的步骤。

9.一种接收端，包括处理器和存储器，所述存储器存储有计算机程序，其特征在于，所述处理器执行所述计算机程序时用于执行权利要求5中所述数据传输方法的步骤。

10.一种数据传输系统，其特征在于，包括发送端和连接所述发送端的接收端；

所述发送端用于执行权利要求1至4任意一项中所述数据传输方法的步骤；

所述接收端用于执行权利要求5中所述数据传输方法的步骤。

11.一种计算机可读存储介质，其上存储有计算机程序，其特征在于，所述计算机程序被处理器执行时实现权利要求1至5任意一项所述的方法的步骤。