本文共 1224 字，大约阅读时间需要 4 分钟。
为了视频尽可能的保持高效，视频数据通过不同的编码进行压缩。以帧为单位进行压缩，按照压缩中的不同作用可分类为： 内帧（Intra-frames，I帧），预测帧（Predictive-frames，P帧），和双向预测帧（Bipredictive-frames，B帧） 。B帧利用过去的和将来的包进行编码，在实时交互的视频中不会使用。 一个I帧包含一个完整的图片（经过空间压缩），像传统的静态图片文件。因此，I帧是独立的帧，解码时不依赖其他的帧。 P帧则是依赖性的帧，仅包含与之前一帧相比在图像上有所变化的部分（即，时序压缩）。所以，与I帧相比，P帧的压缩率更高，至于高多少，得取决于帧之间的变化量。因此，这减少了视频流传输的比特数。举个例子，下面的剪辑来自于一场下坡赛车比赛。视频中的绝大部分保持不变，除了移动部分，即汽车和观众，需要被编码为P帧的视频不变。 I帧以作为P帧的新参考点而被生成。通常在图像变化很大的时候创建一个I帧，如：平移、场景切换、大量动作、突然消失等场景发生时。 其适用于各种丢包数量和链路延迟的错误恢复机制。 主要是发生在数据传输过程中。 NACK在一多媒体数据流的 分组丢失 （这是一个通用的机制可以适用于音频和视频流）时由接收端产生。发送者以重发所请求的（如果仍然在其发送缓存中的）包的方式响应NACK ，并基于观察到的往返时间确认该数据包能在解码时及时到达接收端。 视频在WebRTC的会话中总是以一个I帧开始，然后发送P帧。但是，当有新的参与者中途加入会议会话时，很有可能接收到一系列P帧，但因缺少相应的I帧，它并不能解码。这种情况下，该接收端会发送一个FIR以 请求一个I帧 。 因此，在大的会议平台中，例如与会方达到100人时，在很短的时间间隔内加入或重新加入会议，每个参与者都会请求I帧以开始解码，取决于重新加入的频率，可能会导致发送方创建大量的I帧。 图片丢失提示消息表明突发性的丢包影响到了一个或多个帧中的多个包。发送方可以通过 重传 这些包或者 生成一个新的I帧 以作出回应。但一般来说，PLI同时表现得像一个NACK和一个FIR，因此，通过使用PLI，接收端为发送端如何对该请求作出响应提供了更大的灵活度。 切片丢失提示消息表明该包丢失影响到单个帧的部分（即，多个macroblock）。因此，当发送端接收到SLI消息时，它可以通过重新编码的方式纠正切片，停止部分帧解码错误的传播。 来自 “ ITPUB博客 ” ，链接：http://blog.itpub.net/30463247/viewspace-2136893/，如需转载，请注明出处，否则将追究法律责任。
转载于:http://blog.itpub.net/30463247/viewspace-2136893/