FEC之我见三

  1. 云栖社区>
  2. 博客>
  3. 正文

FEC之我见三

double2li 2017-05-16 21:00:00 浏览620
展开阅读全文

继续上文讲解:

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的代价之一。
 
0

网友评论

登录后评论
0/500
评论
double2li
+ 关注