RTP/RTCP的 NACK, PLI，SLI,FIR

1，概述

在网络环境不是太好的情况下，比如网络拥塞比较严重，丢包率可能比较高，简单实用NACK重传的机制，这样就会有大量的RTCP NACK报文，发送端收到相应的报文，又会发送大量指定的RTP报文，反而会增加网络的拥塞程度，可能导致更高的丢包率，导致接收端解码失败，导致花屏等马赛克现象。这时采用申请I帧的方式可能会解决马赛克等现象，申请的I帧方式主要PLI（Picture Loss Indication）和FIR（Full Intra Request）两种方式，FIR又包括RFC2032和RFC5104规定的两种方式，其中RFC5104规定的FIR报文比较常用。一般发送端在收到接收端发送过来的RTCP PLI报文，按申请I帧处理，当然收到FIR报文，就是申请I帧,NACK如下：

2，PLI 是Picture Loss IndicationPLI

图片丢失提示消息表明突发性的丢包影响到了一个或多个帧中的多个包。发送方可以通过重传这些包或者生成一个新的I帧以作出回应。但一般来说，PLI同时表现得像一个NACK和一个FIR，因此，通过使用PLI，接收端为发送端如何对该请求作出响应提供了更大的灵活度

3，SLI 是Slice Loss Indication。

切片丢失提示消息表明该包丢失影响到单个帧的部分（即，多个macroblock）。因此，当发送端接收到SLI消息时，它可以通过重新编码的方式纠正切片，停止部分帧解码错误的传播。

发送方接收到接收方反馈的PLI或SLI需要重新让编码器生成帧并发送给接收端。

4，FIR  

FIR 是Full Intra Request视频在WebRTC的会话中总是以一个I帧开始，然后发送P帧。但是，当有新的参与者中途加入会议会话时，很有可能接收到一系列P帧，但因缺少相应的I帧，它并不能解码。这种情况下，该接收端会发送一个FIR以请求一个I帧。
 

5，FIR和PLI区别

当解码端需要刷新时，可以发送FIR消息给编码端，编码端此时发送关键帧，刷新解码端。这有点类似PLI消息，但是PLI消息是用于丢包情况下的通知，而FIR却不是，在有些非丢包情况下，FIR就要用到。举两个例子：
1）解码端需要切换到另一路不同视频时，由于需要新的解码参数，所以可通过发送FIR消息，通知编码端生成关键帧，获取新的解码参数，刷新视频解码器；
2）在视频会议中，新用户随机时刻加入，各个编码端发送的视频不一定都是关键帧，所以新用户不一定能正常解码。此时该新加入用户发送FIR消息，通知各个编码端给它发关键帧，获取关键帧后即可正常解码。