本文主要介紹WebRTC視頻通信中的錯誤恢復機制（我們翻譯和整理的，譯者：jiangpeng），最早發表在【這里】
支持原創，轉載必須注明出處，歡迎關注我的微信公眾號blacker（微信ID：blackerteam）。
道路交通與網絡交通有很相似之處。就像道路上的車輛一樣，網絡分包也可能轉錯了彎，或者因為堵塞導致延遲。但是，網絡分包經常會發生丟失，而道路上的車輛很少會出現這張狀況。在這篇文章中，我們將討論媒體流是如何被壓縮、通過網絡進行傳輸以及各種錯誤恢復機制。
1、視頻傳輸、編碼與解碼
在開始討論視頻壓縮和錯誤恢復機制前，我們先快速回顧一下視頻和音頻是如何從發送者的攝像頭和麥克風傳送到接收者的屏幕和音頻輸出的。
原始碼流在發送端捕獲，使用選擇好的編碼方式對幀進行編碼后，以包的形式通過網絡發送。數據包在接收端被拼裝成幀。然后解碼器將這些幀解碼為原始碼流，並進行播放。
如果部分數據包在傳輸過程中丟失，接收端的解碼器會請求發送端重傳，同時等待這些包的到來。這對於低延遲的網絡很有效，接收端的去抖動緩沖小，足以保持交互性。當延遲較大時，重傳的包可能需要比較久的時間才能到達，這時就需要依賴更加復雜的錯誤恢復機制，如：向前糾錯，全內請求等等。
2、視頻壓縮方法
為了視頻盡可能的保持高效，視頻數據通過不同的編碼進行壓縮。以幀為單位進行壓縮，按照壓縮中的不同作用可分類為：內幀（Intra-frames，I幀），預測幀（Predictive-frames，P幀），和雙向預測幀（Bipredictive-frames，B幀）。B幀利用過去的和將來的包進行編碼，在實時交互的視頻中不會使用。
一個I幀包含一個完整的圖片（經過空間壓縮），像傳統的靜態圖片文件。因此，I幀是獨立的幀，解碼時不依賴其他的幀。
P幀則是依賴性的幀，僅包含與之前一幀相比在圖像上有所變化的部分（即，時序壓縮）。所以，與I幀相比，P幀的壓縮率更高，至於高多少，得取決於幀之間的變化量。因此，這減少了視頻流傳輸的比特數。舉個例子，下面的剪輯來自於一場下坡賽車比賽。視頻中的絕大部分保持不變，除了移動部分，即汽車和觀眾，需要被編碼為P幀的視頻不變。
I幀以作為P幀的新參考點而被生成。通常在圖像變化很大的時候創建一個I幀，如：平移、場景切換、大量動作、突然消失等場景發生時。
3、錯誤恢復機制
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消息時，它可以通過重新編碼的方式糾正切片，停止部分幀解碼錯誤的傳播。
4、儀表盤上的新圖
為了幫助我們的客戶看到他們的應用程序如何發送和接收實時視頻，我們增加了圖表顯示如下：
1.發送端從所有media track接收NACK的頻率；
2.發送端從視頻track接收到FIR/PLI/SLI請求的頻率。
部分指標目前只在所報告的斷點在Chrome瀏覽器中的情況下適用。
原文：http://www.callstats.io/2015/10/30/error-resilience-mechanisms-webrtc-video/
譯者：jiangpeng，具體詳見：http://befo.io/1340.html