道路交通與網(wǎng)絡(luò)交通有很相似之處。就像道路上的車輛一樣，網(wǎng)絡(luò)分包也可能轉(zhuǎn)錯(cuò)了彎，或者因?yàn)槎氯麑?dǎo)致延遲。但是，網(wǎng)絡(luò)分包經(jīng)常會(huì)發(fā)生丟失，而道路上的車輛很少會(huì)出現(xiàn)這張狀況。在這篇文章中，我們將討論媒體流是如何被壓縮、通過網(wǎng)絡(luò)進(jìn)行傳輸以及各種錯(cuò)誤恢復(fù)機(jī)制。
視頻傳輸、編碼與解碼
在開始討論視頻壓縮和錯(cuò)誤恢復(fù)機(jī)制前，我們先快速回顧一下視頻和音頻是如何從發(fā)送者的攝像頭和麥克風(fēng)傳送到接收者的屏幕和音頻輸出的。
原始碼流在發(fā)送端捕獲，使用選擇好的編碼方式對(duì)幀進(jìn)行編碼后，以包的形式通過網(wǎng)絡(luò)發(fā)送。數(shù)據(jù)包在接收端被拼裝成幀。然后解碼器將這些幀解碼為原始碼流，并進(jìn)行播放。
如果部分?jǐn)?shù)據(jù)包在傳輸過程中丟失，接收端的解碼器會(huì)請(qǐng)求發(fā)送端重傳，同時(shí)等待這些包的到來。這對(duì)于低延遲的網(wǎng)絡(luò)很有效，接收端的去抖動(dòng)緩沖小，足以保持交互性。當(dāng)延遲較大時(shí)，重傳的包可能需要比較久的時(shí)間才能到達(dá)，這時(shí)就需要依賴更加復(fù)雜的錯(cuò)誤恢復(fù)機(jī)制，如：向前糾錯(cuò)，全內(nèi)請(qǐng)求等等。
視頻壓縮方法
為了視頻盡可能的保持高效，視頻數(shù)據(jù)通過不同的編碼進(jìn)行壓縮。以幀為單位進(jìn)行壓縮，按照壓縮中的不同作用可分類為：內(nèi)幀（Intra-frames，I幀），預(yù)測(cè)幀（Predictive-frames，P幀），和雙向預(yù)測(cè)幀（Bipredictive-frames，B幀）。B幀利用過去的和將來的包進(jìn)行編碼，在實(shí)時(shí)交互的視頻中不會(huì)使用。
一個(gè)I幀包含一個(gè)完整的圖片（經(jīng)過空間壓縮），像傳統(tǒng)的靜態(tài)圖片文件。因此，I幀是獨(dú)立的幀，解碼時(shí)不依賴其他的幀。
P幀則是依賴性的幀，僅包含與之前一幀相比在圖像上有所變化的部分（即，時(shí)序壓縮）。所以，與I幀相比，P幀的壓縮率更高，至于高多少，得取決于幀之間的變化量。因此，這減少了視頻流傳輸?shù)谋忍財(cái)?shù)。舉個(gè)例子，下面的剪輯來自于一場(chǎng)下坡賽車比賽。視頻中的絕大部分保持不變，除了移動(dòng)部分，即汽車和觀眾，需要被編碼為P幀的視頻不變。
I幀以作為P幀的新參考點(diǎn)而被生成。通常在圖像變化很大的時(shí)候創(chuàng)建一個(gè)I幀，如：平移、場(chǎng)景切換、大量動(dòng)作、突然消失等場(chǎng)景發(fā)生時(shí)。
錯(cuò)誤恢復(fù)機(jī)制
IETF已經(jīng)定義了可用于幫助解決丟失媒體數(shù)據(jù)的錯(cuò)誤恢復(fù)機(jī)制。接下來，我們依次過一遍在rtcweb-RTP-usage中定義的各種機(jī)制：否定確認(rèn)（NACK）、全內(nèi)要求（FIR）、照片丟失提示（PLI）、切片丟失提示（SLI）。
接收端在丟失單個(gè)包或者突發(fā)性丟包時(shí)向發(fā)起端發(fā)出信號(hào)。發(fā)起端收到這些信號(hào)時(shí)，做出適當(dāng)?shù)姆磻?yīng)。對(duì)這類請(qǐng)求的一個(gè)典型響應(yīng)是：
1.發(fā)起端重新發(fā)送一個(gè)RTP包：
·在丟失單個(gè)包的情況下，發(fā)送端重新發(fā)送所請(qǐng)求的包。
·在發(fā)生突發(fā)性丟包，或者有新的參與方加入時(shí)，接收端此時(shí)不能繼續(xù)解碼，這時(shí)發(fā)送方會(huì)選擇發(fā)送一個(gè)I幀。發(fā)送一個(gè)I幀會(huì)產(chǎn)生大量的包，因此通常作為最后一招使用。
2.通過發(fā)送其中包含了源RTP分組集合的前向修復(fù)（FEC）包進(jìn)行修復(fù)。
下圖顯示了部分運(yùn)用于實(shí)時(shí)交互視頻流的錯(cuò)誤恢復(fù)方案：
其適用于各種丟包數(shù)量和鏈路延遲的錯(cuò)誤恢復(fù)機(jī)制。
否定確認(rèn)（NACK）
NACK在一多媒體數(shù)據(jù)流的分組丟失（這是一個(gè)通用的機(jī)制可以適用于音頻和視頻流）時(shí)由接收端產(chǎn)生。發(fā)送者以重發(fā)所請(qǐng)求的（如果仍然在其發(fā)送緩存中的）包的方式響應(yīng)NACK ，并基于觀察到的往返時(shí)間確認(rèn)該數(shù)據(jù)包能在解碼時(shí)及時(shí)到達(dá)接收端。
全內(nèi)請(qǐng)求（FIR）
視頻在WebRTC的會(huì)話中總是以一個(gè)I幀開始，然后發(fā)送P幀。但是，當(dāng)有新的參與者中途加入會(huì)議會(huì)話時(shí)，很有可能接收到一系列P幀，但因缺少相應(yīng)的I幀，它并不能解碼。這種情況下，該接收端會(huì)發(fā)送一個(gè)FIR以請(qǐng)求一個(gè)I幀。
因此，在大的會(huì)議平臺(tái)中，例如與會(huì)方達(dá)到100人時(shí)，在很短的時(shí)間間隔內(nèi)加入或重新加入會(huì)議，每個(gè)參與者都會(huì)請(qǐng)求I幀以開始解碼，取決于重新加入的頻率，可能會(huì)導(dǎo)致發(fā)送方創(chuàng)建大量的I幀。
圖片丟失提示（PLI）
圖片丟失提示消息表明突發(fā)性的丟包影響到了一個(gè)或多個(gè)幀中的多個(gè)包。發(fā)送方可以通過重傳這些包或者生成一個(gè)新的I幀以作出回應(yīng)。但一般來說，PLI同時(shí)表現(xiàn)得像一個(gè)NACK和一個(gè)FIR，因此，通過使用PLI，接收端為發(fā)送端如何對(duì)該請(qǐng)求作出響應(yīng)提供了更大的靈活度。
切片丟失提示（SLI）
切片丟失提示消息表明該包丟失影響到單個(gè)幀的部分（即，多個(gè)macroblock）。因此，當(dāng)發(fā)送端接收到SLI消息時(shí)，它可以通過重新編碼的方式糾正切片，停止部分幀解碼錯(cuò)誤的傳播。
儀表盤上的新圖
為了幫助我們的客戶看到他們的應(yīng)用程序如何發(fā)送和接收實(shí)時(shí)視頻，我們?cè)黾恿藞D表顯示如下：
1.發(fā)送端從所有media track接收NACK的頻率；
2.發(fā)送端從視頻track接收到FIR/PLI/SLI請(qǐng)求的頻率。
部分指標(biāo)目前只在所報(bào)告的斷點(diǎn)在Chrome瀏覽器中的情況下適用。
更多WebRTC優(yōu)秀資源可登陸編風(fēng)網(wǎng)http://befo.io/
微信公眾號(hào)：WebRTC中文網(wǎng)，微信ID：webrtcorgcn
