WebRTC采用UDP传输流媒体数据，不可避免存在丢包情况。WebRTC主要采用FEC（Forward Error Correction，前向纠错）以及NACK（negative-acknowledge character，否定应答）对抗网络丢包。对于NACK，遇到丢包了才通知发送端重传对应数据包，但不是所有情况下某个包丢了就一定重传该包，有些场景下，重传该包会带来其它问题，例如增大延时，缓存过大，同时也可能发送端没有该数据包缓存，导致无法重传，此时会放弃重传该包。由于关键帧可以单独解码出图像，不参考前后视频帧，所以会采取请求关键帧这种更便捷的方式替代重传该数据包，使解码端能立刻刷新出新图像，避免丢包过多，长时间等待重传数据包导致的画面停顿问题，以及获取不到重传包导致后续数据解码花屏问题。除了丢包，在WebRTC还存在其他请求关键帧的场景。 关键帧请求场景 下面结合代码列举几种常见场景。 H264解码无sps,pps信息 解码H264时无法获取sps，pps，导致无法解码，此时就需要请求获取关键帧，在H264SpsPpsTracker中，相关处理代码如下： [crayon-69dde43218663007540129/] 丢失包过多 在非常高的丢包率情况下，丢失的包太多，若都一一重传，将造成延时增大（等帧数据完整了才会去解码渲染），此时新来的数据也只能一直缓存，所以jitterbuffer大小也会不断增大，此时不如直接请求发送一个关键帧来得实际，以前丢的那些包都不管了，由于关键帧可以单独解码，所以不会造成解码端花屏马赛克现象。但是由于前面那些视频帧都丢弃了，此时生成的关键帧会与之前播放的视频存在不连贯性，所以画面变化大时会有轻微卡顿现象，相当于跳帧了。NackModule中相关处理代码如下： [crayon-69dde43218671953527889/] 上面代码中，要重传的包数量nack_list_.size()在进行RemovePacketsUntilKeyFrame()操作后若还超过规定大小，就开始清空要重传的数据包列表：nack_list_.clear()，然后请求关键帧。 丢失包过旧 发送端默认缓存600个RTP包，如果丢失的包太旧，超出缓存范围，此时发送端就没有该数据包的缓存，就无法重传该包。在VCMJitterBuffer中，相关处理代码如下： [crayon-69dde43218677729002995/] 获取帧数据超时 要解码的帧数据存放在FrameBuffer中，解码器解码时如果超过规定时间一直无法从FrameBuffer中获取解码数据，此时就会请求关键帧。相关处理代码如下： [crayon-69dde4321867a101168731/] 解码出错 当解码器返回解码失败，或者解码器返回请求关键帧结果时，需要请求关键帧。相关处理代码如下： [crayon-69dde4321867d568461891/] 在上面我们列举了几种需要关键帧请求的情况，我们只需要规定好RTCP报文格式，就能通知编码发送端发送关键帧。关键帧请求RTCP报文格式比较简单，在RFC4585（RTP/AVPF）以及RFC5104（AVPF）规定了两种不同的关键帧请求报文格式：Picture Loss Indication (PLI)、Full Intra Request (FIR)。WebRTC中关键帧请求也只用到了这两种消息，相关代码如下： [crayon-69dde43218681162355089/] Picture Loss Indication (PLI) 在RFC4585中定义，属于RTCP反馈消息中的一种。RTCP反馈消息数据包格式按如下规定： [crayon-69dde43218684006077760/] 其中PT字段按如下规定： [crayon-69dde43218687695887695/] 对于PLI，由于只需要通知发送关键帧，无需携带其他消息，所以FCI部分为空。对于FMT规定为1，PT规定为PSFB。 在WebRTC源码中，PLI相关解析封装代码位于webrtc::Pli中。相关代码如下： [crayon-69dde4321868b879839251/] PLI消息用于解码端通知编码端我要解码的图像的编码数据丢失了。对于基于帧间预测的视频编码类型，编码端收到PLI消息就要知道视频数据丢失了，由于帧间预测需要基于前后完整的视频帧才能解码（例如H264中，存在B帧，需要参考前后帧才能解码），前面的数据丢失了，后面的视频帧不能正常解码出图像，此时编码端可以直接生成一个关键帧，然后发送给解码端。 Full Intra Request (FIR) 在RFC5104中定义。参照上一小节RTCP反馈消息数据包格式，对于FMT规定为4，PT规定为PSFB。由于FIR可用于通知多个编码发送端（例如多点视频会议情况），所以用到了FCI部分，填充多个发送端的ssrc信息。具体包格式如下： [crayon-69dde4321868e116485128/] 在WebRTC源码中，FIR相关解析封装代码位于webrtc::Fir中。相关处理代码就不贴出来了，类似PLI处理，除了FCI部分要填充一些信息。 当解码端需要刷新时，可以发送FIR消息给编码端，编码端此时发送关键帧，刷新解码端。这有点类似PLI消息，但是PLI消息是用于丢包情况下的通知，而FIR却不是，在有些非丢包情况下，FIR就要用到。举两个例子： 1）解码端需要切换到另一路不同视频时，由于需要新的解码参数，所以可通过发送FIR消息，通知编码端生成关键帧，获取新的解码参数，刷新视频解码器； 2）在视频会议中，新用户随机时刻加入，各个编码端发送的视频不一定都是关键帧，所以新用户不一定能正常解码。此时该新加入用户发送FIR消息，通知各个编码端给它发关键帧，获取关键帧后即可正常解码。 总结 本文主要介绍了几种关键帧请求场景，讲了AVPF中定义的两种关键帧请求消息，虽然这两种消息获取的结果一样，但是表达的意义却不一样，用于不同场景，使用时需要区分下。