道路交通与网络交通有很相似之处。就像道路上的车辆一样，网络分包也可能转错了弯，或者因为堵塞导致延迟。但是，网络分包经常会发生丢失，而道路上的车辆很少会出现这张状况。在这篇文章中，我们将讨论媒体流是如何被压缩、通过网络进行传输以及各种错误恢复机制。
视频传输、编码与解码
在开始讨论视频压缩和错误恢复机制前，我们先快速回顾一下视频和音频是如何从发送者的摄像头和麦克风传送到接收者的屏幕和音频输出的。
原始码流在发送端捕获，使用选择好的编码方式对帧进行编码后，以包的形式通过网络发送。数据包在接收端被拼装成帧。然后解码器将这些帧解码为原始码流，并进行播放。
如果部分数据包在传输过程中丢失，接收端的解码器会请求发送端重传，同时等待这些包的到来。这对于低延迟的网络很有效，接收端的去抖动缓冲小，足以保持交互性。当延迟较大时，重传的包可能需要比较久的时间才能到达，这时就需要依赖更加复杂的错误恢复机制，如：向前纠错，全内请求等等。
视频压缩方法
为了视频尽可能的保持高效，视频数据通过不同的编码进行压缩。以帧为单位进行压缩，按照压缩中的不同作用可分类为：内帧（Intra-frames，I帧），预测帧（Predictive-frames，P帧），和双向预测帧（Bipredictive-frames，B帧）。B帧利用过去的和将来的包进行编码，在实时交互的视频中不会使用。
一个I帧包含一个完整的图片（经过空间压缩），像传统的静态图片文件。因此，I帧是独立的帧，解码时不依赖其他的帧。
P帧则是依赖性的帧，仅包含与之前一帧相比在图像上有所变化的部分（即，时序压缩）。所以，与I帧相比，P帧的压缩率更高，至于高多少，得取决于帧之间的变化量。因此，这减少了视频流传输的比特数。举个例子，下面的剪辑来自于一场下坡赛车比赛。视频中的绝大部分保持不变，除了移动部分，即汽车和观众，需要被编码为P帧的视频不变。
I帧以作为P帧的新参考点而被生成。通常在图像变化很大的时候创建一个I帧，如：平移、场景切换、大量动作、突然消失等场景发生时。
错误恢复机制
IETF已经定义了可用于帮助解决丢失媒体数据的错误恢复机制。接下来，我们依次过一遍在rtcweb-RTP-usage中定义的各种机制：否定确认（NACK）、全内要求（FIR）、照片丢失提示（PLI）、切片丢失提示（SLI）。
接收端在丢失单个包或者突发性丢包时向发起端发出信号。发起端收到这些信号时，做出适当的反应。对这类请求的一个典型响应是：
1.发起端重新发送一个RTP包：
·在丢失单个包的情况下，发送端重新发送所请求的包。
·在发生突发性丢包，或者有新的参与方加入时，接收端此时不能继续解码，这时发送方会选择发送一个I帧。发送一个I帧会产生大量的包，因此通常作为最后一招使用。
2.通过发送其中包含了源RTP分组集合的前向修复（FEC）包进行修复。
下图显示了部分运用于实时交互视频流的错误恢复方案：
其适用于各种丢包数量和链路延迟的错误恢复机制。
否定确认（NACK）
NACK在一多媒体数据流的分组丢失（这是一个通用的机制可以适用于音频和视频流）时由接收端产生。发送者以重发所请求的（如果仍然在其发送缓存中的）包的方式响应NACK ，并基于观察到的往返时间确认该数据包能在解码时及时到达接收端。
全内请求（FIR）
视频在WebRTC的会话中总是以一个I帧开始，然后发送P帧。但是，当有新的参与者中途加入会议会话时，很有可能接收到一系列P帧，但因缺少相应的I帧，它并不能解码。这种情况下，该接收端会发送一个FIR以请求一个I帧。
因此，在大的会议平台中，例如与会方达到100人时，在很短的时间间隔内加入或重新加入会议，每个参与者都会请求I帧以开始解码，取决于重新加入的频率，可能会导致发送方创建大量的I帧。
图片丢失提示（PLI）
图片丢失提示消息表明突发性的丢包影响到了一个或多个帧中的多个包。发送方可以通过重传这些包或者生成一个新的I帧以作出回应。但一般来说，PLI同时表现得像一个NACK和一个FIR，因此，通过使用PLI，接收端为发送端如何对该请求作出响应提供了更大的灵活度。
切片丢失提示（SLI）
切片丢失提示消息表明该包丢失影响到单个帧的部分（即，多个macroblock）。因此，当发送端接收到SLI消息时，它可以通过重新编码的方式纠正切片，停止部分帧解码错误的传播。
仪表盘上的新图
为了帮助我们的客户看到他们的应用程序如何发送和接收实时视频，我们增加了图表显示如下：
1.发送端从所有media track接收NACK的频率；
2.发送端从视频track接收到FIR/PLI/SLI请求的频率。
部分指标目前只在所报告的断点在Chrome浏览器中的情况下适用。
更多WebRTC优秀资源可登陆编风网http://befo.io/
微信公众号：WebRTC中文网，微信ID：webrtcorgcn