转自：http://blog.csdn.net/Stone_OverLooking/article/details/77752076

 

继续上文讲解：

3）

标准的RTP头结构如下所示：

其中第一个字节中的x标志位是否扩展了RTP头，RTP协议允许用户自定义的扩展，扩展的字段紧挨上述RTP固定头。RTP扩展投中承载如下信息：

1).当前包所在的Group组序号，码流由连续的Group组成，每个Group拥有自己的唯一序号。（仅仅是小范围的唯一，序号大于255时，计数清零）

2).当前包所在的Group组大小

3).当前包在Group内的位置

RTP头中的7bit的PT字段标示负载的类型，对于标准类型如音频AAC、视频H264其参考值列出在RFC3551中。RTP负载除了音视频数据外还包冗余包，为此我们指定一个自定义的FEC冗余包类型，这样方便接收端做区分处理。

发送端对一组待发送的应用层数据进行FEC编码并RTP打包发送，其流程如下所示：

图中P1~P8代表外层传入本模块的原始媒体数据包，r1~r3代表冗余包。本示例中一个Group有8个媒体包外加3个冗余包组成。当模块传入媒体包p时，进行RTP封装后发出，同时存入模块内部队列。当Group的最后一个媒体包P8发送完毕时，

对队列中存放的各P1~P8进行FEC编码生成冗余包r1~r3并RTP打包发送。如此循环，直至处理所有输入数据包，Group与Group之间相互独立的，他们的大小包数可以不同，比如前一个Group为（8,3）组合，下一个Group可以为（8,4）组合，

我们提供了一种动态冗余度的的模式，支持发送端根据接收端的网络接收情况动态调整冗余度，已达到最佳的服务质量。比如信道条件较差，接收方丢包率上升，发送端可以调高冗余度，以增强抗丢包能力；反之，如果接收方丢包率很低，

发送端则可以降低冗余度，以节省网络带宽，所有的这些处理都封装到了本模块中，实现了对用户透明。

接收端进行FEC解码以实现丢包数据的恢复，其处理流程如下所示：

本例子中P4媒体包在网络传输过程中丢失，下面说明其接收端FEC解码的处理流程。

当接收到该Group的P1、P2、P3包时，因为他们没丢失，可以直接输出给应用层，如此同时在本地对流缓存一份，以供后续可能的FEC解码使用（后续Group内若无丢白，则缓存数据清空）。

当收到P5包时，可以根据Group包序号判断出P4包出现丢失，此时停止本Group数据的输出，P5存入本地队列。

当收到P6。。。继续直至收到r1时，满足了丢包恢复的条件：

收到的媒体包数+收到的冗余包数 >= Group原始媒体包数

对P1、P2、P3、P5、P6、P7、P8、r1进行FEC解码处理，得到P4包数据。因为之前已经输出了P1~P3，此处只需输出P4~P8.

当继续收到冗余包r2、r3时，可以直接丢弃。

如果收到的媒体包数加上冗余包数小于Group原始媒体包数，本Group的丢包无法恢复，系统直接按序输出收到的包。

需要说明：当网络没有丢包时，本模块不会引入延时。当网络出现丢包时，将不得不等到本组FEC恢复完成后再继续输出，因此会引入一定延时，这是FEC的代价之一。