RTP傳輸視頻數據的兩個細節

最近接到一個工做，爲視頻會議的視頻編碼增長一種VP8格式。整個流程包括VP8的編碼，封包，發送，接收，解包，解碼。在學習這一部分的代碼時，注意到兩個細節：一，對於壓縮後大於1000字節的視頻數據進行了拆包，既把較大的視頻數據封裝成多個RTP包進行發送。二，視頻數據並非拆包後當即發出，而是進入一個隊列，根據必定條件進行等待後再發出。
那麼，爲何要進行這兩個處理呢？

背景

視頻數據的特徵

觀察項目中的音頻數據，是並無這兩個處理的。那麼音頻和視頻有什麼不一樣呢？
音頻數據是每20ms獲得一幀數據，每一幀比較小。以48000K，單聲道爲例，48000 * 20 / 1000,也就960個採樣，每一個採樣16位，也就1920字節，通過壓縮，確定是小於1000字節的。
而視頻數據不一樣，視頻的數據量遠遠大於音頻(幾十甚至上百倍)，特別是關鍵幀，一幀數據壓縮後依然很是大。也就是一瞬間，會產生大量的數據待發。

RTP一般是基於UDP的

另外一方面，RTP（實時傳輸協議）雖然能夠基於不一樣的網絡，但爲了提升實時性，仍是基於UDP爲多。咱們項目中，就是基於UDP發送的。UDP是一個無鏈接，不保障的網絡協議。

緣由解析

爲何須要拆包

UDP能接受的最大包，大約是64K左右。若是向UDP發送一個大包，會在下層自動拆分紅多個包（網絡底層對於包大小是有限制的，大約1500字節。）。接收端把全部拆分包都收齊之後，從新組裝成UDP大包，交給應用層。然而UDP是不可靠鏈接，包有可能丟。若是一個大包，須要在底層拆爲10個包，那麼10個包裏的任意一個丟失，UDP包都沒法組裝，從而致使整個包被丟棄。因此，能夠看出，越大的包越容易丟包。而若是在應用層拆爲10個包發送，丟了其中一個，不論是重傳，仍是經過其餘方式恢復，掩蓋被丟掉的那一個，都比對整個大包進行處理更容易。

爲何須要等待

UDP沒有流量控制，應用程序向UDP發起發送，UDP就會馬上把數據發出去。然而，若是此時接收端的緩存滿了，雖然接收端收到了數據，可是由於沒地方放，就會丟掉這個數據，造成丟包。而因爲視頻一幀，尤爲是I幀的數據量很大，若是不進行等待，一股腦全丟給網絡，則很容易出現接收端到收到了前幾個包，然後幾個包怎麼也收不到的狀況。因此在發送視頻數據時，應當有等待機制，發送必定量的包後，稍微等待一下，再接着發剩下的包。

UDP vs TCP

在這裏順便補充一下UDP與TCP的差異

	TCP	UDP
數據	面向流	面向消息
鏈接	面向鏈接	無鏈接
順序	保序	不保序
到達	保證到達	不保證到達
流量控制	有	無
擁塞控制	有	無
延遲	高	低