FEC详解三

FEC详解三,第1张

FEC详解三

转自: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的代价之一。


 

欢迎分享,转载请注明来源:内存溢出

原文地址: https://outofmemory.cn/zaji/588960.html

(0)
打赏 微信扫一扫 微信扫一扫 支付宝扫一扫 支付宝扫一扫
上一篇 2022-04-12
下一篇 2022-04-12

发表评论

登录后才能评论

评论列表(0条)

保存