FEC前向纠错编码-信道编码

FEC前向纠错编码-信道编码
冗余程度 <-> 丢包率
FEC编码产⽣冗余包过程发送RTP包过程
接收解码，以及FEC恢复丢失包过程
3，PLC
PLC也主要针对丢包因素。

它本质上是⼀种信号处理⽅法，利⽤前⾯收到的⼀个或者⼏个包来近似的产⽣出当前丢的包。

产⽣补偿包的技术有很多种，⽐如基⾳波形复制（G711 Appendix A PLC⽤的就是这种技术）、波形相似叠加技术（WSOLA）、基⾳同步叠加（PSOLA）技术等，这些都很专业，有兴趣可以找相关的⽂章看看。

对codec⽽⾔，如果⽀持PLC功能，如G729，就不需要再在外部加PLC功能了，只需要对codec做相应的配置，让它的PLC功能使能。

如果不⽀持PLC功能，如G711，就需要在外部实现PLC。

PLC对⼩的丢包率（< 15%）有⽐较好的效果，⼤的丢包率效果就不好了，尤其是连续丢包，第⼀个丢的包补偿效果还不错，越到后⾯丢的包效果越差。

把Jitter Buffer、FEC、PLC结合起来就可以得到如下的接收侧针对⽹络环境因素的提⾼⾳质⽅案：
从⽹络收到的RTP包如是原始包不仅要PUT进JB，还要PUT进FEC。

如是冗余包则只PUT进FEC，在FEC中如果⼀组包中原始包的个数加上冗余包的个数达到指定值就开始做FEC解码得到丢失的原始包，并把那些丢失的原始包PUT进JB。

在需要的时候把语⾳帧从JB中GET出解码并有可能做PLC。

4，重传
重传也主要针对丢包这种因素，把丢掉的包再重新传给对⽅，⼀般都是采⽤按需重传的⽅法。

我在⽤重传的⽅法时是这样做的：接收⽅把收到的包排好序后放在buffer⾥，如果收到RTP包头中的sequence number能被5整除（即模5），就统计⼀下这个包前⾯未被播放的包有哪些没收到（即buffer⾥相应位置为空），采⽤⽐特位的⽅式记录下来（当前能被5整除的包的前⼀个包⽤⽐特位0表⽰，丢包置1，不丢包置0，⽐特位共16位（short型），所以最多可以看到前16个包是否有丢包），然后组成⼀个控制包（控制包的payload有两⽅⾯信息：当前能被5整除的包的sequence number（short型）以及上⾯组成的16位的⽐特位）发给对⽅，让对⽅重发这些包。

接收⽅收到这个控制包后就能解析出哪些包丢了，然后重传这些包。

在控制包的payload⾥⾯也可以把每个丢了的包的sequence number发给对⽅，这⾥⽤⽐特位主要是减⼩payload⼤⼩，省流量。

在实际使⽤中重传起的效果不⼤，主要是因为经常重传包来的太迟，已经错过了播放窗⼝⽽只能主动丢弃了。

它是这些⽅法中效果最差的⼀个。

5，RFC2198
RFC2198是RTP Payload for Redundant Audio Data（⽤于冗余⾳频数据的RTP负载格式），⽤了它后在当前RTP包中不仅可以承载当前语⾳的payload，还可以承载前⼏个包的payload，承载以前包的个数越多，在⾼丢包率的情况下效果越好，但是延时也就越⼤，同时消耗的流量也就越多。

相⽐于FEC，它消耗的流量更多，因为FEC⽤⼀组RTP包编码⽣⼀个或多个成冗余包，⽽它⼀个RTP包就带⼀个或多个以前包的payload。

在有线⽹络或者WIFI下可以⽤，在蜂窝⽹络下建议慎⽤。

以上就是我⽤过的提⾼⾳质的⽅法。

还有其他⽅法，我没实践过，就不写了，写出来也是纸上谈兵。

欢迎⼤家补充其他的⽅法。