1 RTP 的協(xié)議描述

實時傳輸協(xié)議RTP（Real-time Transport Protocol）是一個網絡傳輸協(xié)議，它是由IETF的多媒體傳輸工作小組1996年在RFC 1889中公布的，后在RFC3550中進行更新。

?????????RTP協(xié)議詳細說明了在互聯(lián)網上傳遞音頻和視頻的標準數據包格式。它一開始被設計為一個多播協(xié)議，但后來被用在很多單播應用中。RTP協(xié)議常用于流媒體系統(tǒng)（配合RTSP協(xié)議），視頻會議和一鍵通（Push toTalk）系統(tǒng)（配合H.323或SIP），使它成為IP電話產業(yè)的技術基礎。RTP協(xié)議和RTP控制協(xié)議RTCP一起使用，而且它是建立在用戶數據報協(xié)議上的（UDP）。

????????RTP廣泛應用于流媒體相關的通訊和娛樂，包括電話、視頻會議、電視和基于網絡的一鍵通業(yè)務（類似對講機的通話）。

具體見?https://blog.csdn.net/machh/article/details/51868569。這里不詳細描述。

2 RTP 傳輸中要關注的問題

由于RTP基于UDP非可靠信道傳輸，面臨著UDP 丟包，亂序，延時帶來的問題：

延時

“延時”指的是每輛車從鳥巢開到東方明珠花的平均時間。顯然，車隊走高速公路肯定要比走各種小公路快很多，而且從鳥巢出發(fā)沿著怎樣的路線開上高速公路也有很大影響，萬一堵在了三環(huán)可就要多花好幾個小時了。所以這個值和車隊選擇的行駛路線有關?；ヂ?lián)網傳輸也是一樣的道理，需要傳輸數據的兩點之間經常是有很多可選路徑的，而這些路徑的延時往往相差很大。

丟包

“丟包”指的是有的車無法在有效時間內無法達到終點，甚至可能永遠也到不了終點。有的車可能永遠堵在北京的三環(huán)上了，有的車可能中途出了車禍。假如我們的一百輛車里有五輛車因為各種原因沒能按時到達上海，我們這次車隊傳輸的“丟包率”就是5%。是的，互聯(lián)網傳輸也一樣，它并不是百分百可靠的，總有數據無法按時傳輸到目的地。

抖動

“抖動”指的是車子到達的順序、間隔和出發(fā)時的差異。雖然我們的一百輛車在北京是等間隔的一分鐘一輛出發(fā)的，但是它們到達上海時卻并不是按順序一分鐘一輛到達的，甚至可能有晚出發(fā)的車比早出發(fā)的車先到的情況?；ヂ?lián)網傳輸也一樣，如果簡單地按照收到的音視頻數據順序直接播放出來，就會出現(xiàn)失真的現(xiàn)象。

3 RTP 累計眾多經驗總結的策略

為了對抗網絡擁塞、網絡波動，解決丟包、延時、抖動的問題，前人總結出了如下四大類策略：

（1）重傳請求

檢查到丟失的數據包，讓對方重新傳輸。用在此處的協(xié)議有NACK, RTX, RPSI

NACK: 現(xiàn)聊一下ack：?ACK實際上就是到達通知技術。大家都知道TCP是可靠的連接，他之所以可靠，那是因為接收方在收到數據后會給發(fā)送方返回一個“已收到數據”的消息（ACK），告訴發(fā)送方“我已經收到了”，確保消息的可靠。

NACK也是一種通知技術，只是觸發(fā)通知的條件剛好的ACK相反，在未收到消息時，通知發(fā)送方“我未收到消息”，即通知未達。那么問題來了，接受者怎么知道自己未收到消息？

音視頻數據包都是按時間順序發(fā)送的，一般都帶序號（升序排列的時間戳）。例如發(fā)送方按順序發(fā)送了時間戳為60,120,180,240，320共五個包，接收者已經收到了60包，本來預期下一個接收的包的序號應該是序號120的包，但序號是120的包一直沒收到，后面的包卻收到了。那么接收者就可以判斷，120這個包丟了，這時候接收方需要向發(fā)送方發(fā)出NACK消息（消息中帶有丟包的序號，這里是120），讓發(fā)送方重新發(fā)送丟失的包。

實時音視頻傳輸都基于udp，包到達的順序是不定的，具體是收不到包就馬上出發(fā)NACK，還是說需要等待一小段時間看沒到達的包是否會到達再決定是否發(fā)送NACK，這個具體要帶webrtc的代碼實現(xiàn)。

RTX:?webrtc中默認開啟rtx用于丟包重傳，rtx的介紹可以參考rfc4588，https://tools.ietf.org/html/rfc4588#section-4

rtx使用額外的ssrc傳輸，ssrc在sdp中會標識出來。

?a=rtpmap:97rtx/90000?a=ssrc-group:FID2736695910239189782

類似這樣。

一個RTX包，在turnserver中是這樣的，原始udp數據->turn/stun協(xié)議頭->RTP header1 ->RTP header2

在RTP header1中根據payload type進行區(qū)別RTP、RTX數據，如果是RTX的話，需要srtp解出后面的數據，再解析。

在客戶端中，RTX封包的關鍵函數是：

https://code.google.com/p/webrtc/source/detail?r=4692Channel::IsPacketRetransmitted

Channel::HandleRtxPacket

rtp_payload_registry_->IsRtx

RTPPayloadRegistry::RestoreOriginalPacket? ? 移除RTX頭, 還原原始的RTP

鏈接是，webrtc加入rtx的issue

（2）擁塞控制

擁塞控制策略主要基于兩種方式：基于丟包檢測的擁塞控制 和 基于延時檢測的擁塞控制。檢測完成之后再根據實際情況進行動態(tài)的升、降。

1）基于延遲（delay-based）的擁塞控制算法：

由數據的接收方實現(xiàn)，接收方需要記錄每個數據包到達的時間和大小，并計算每個數據分組之間（inter-group）的延遲的變化，由此判斷當前網絡的擁塞情況，并最終輸出碼率估計值由RTCP feedback（TMMBR或 REMB）反饋給發(fā)送方。

2）基于丟包（loss-based）的擁塞控制算法：

則由數據的發(fā)送方來實現(xiàn)，發(fā)送方通過從接收方周期性發(fā)來的RTCP RR（Receiver Report）中獲取丟包信息以及計算RTT，并結合TMMBR或REMB中攜帶的碼率信息算得最終的碼率值，然后由媒體引擎根據碼率來配置編碼器，從而實現(xiàn)碼率的自適應調整。

rate control:

狀態(tài) Increase： 表明當前沒有檢測到網絡擁塞，在此狀態(tài)下傳輸速率需要逐步增加；它先是通過乘性增加來調整速率（乘性因子為1.08），當速率接近臨界值時再通過加性增加逐步收斂，而這里所謂的臨界值是指上一次在狀態(tài)Decrease時統(tǒng)計的下行碼率；

狀態(tài) Decrease： 表明當前檢測到了網絡擁塞，在此狀態(tài)下傳輸速率需要逐步下降；在這里，WebRTC所采用的方法是乘性下降，其乘性因子為0.85；

狀態(tài) Hold： 表明保持當前的速率不做改變。

速率控制子系統(tǒng)最終會輸出一個帶寬估計值A_hat，并通過RTCP Feedback（TMMBR/REMB）請求發(fā)送方進行速率調整

（3）關鍵幀請求

FIR PLI/PLS 協(xié)議包配合實現(xiàn)關鍵幀請求：

FIR: RFC 2032 5.2.1. Full intra-frame Request (FIR) .作用是在關鍵幀丟失無法解碼時，請求發(fā)送方重新生成并發(fā)送一個關鍵幀。（Intra Frame其實就是指I幀，Inter Frame指P幀或B幀）。FIR更多是在一個中心化的Video Conference中，新的參與者加入，就需要發(fā)送一個FIR，其他的參與者給他發(fā)送一個關鍵幀這樣才能解碼.

PLI:Picture Loss Indication

PLS:Slice Loss Indication

PLI/PLS?發(fā)送方接收到接收方反饋的PLI或SLI需要重新讓編碼器生成關鍵幀并發(fā)送給接收端，PLI和SLI的含義更多是在發(fā)生丟包或解碼錯誤時使用。

（4）丟包恢復

主要是通過 FEC協(xié)議實現(xiàn)：

冗余編碼 / 前向糾錯 FEC

改進型的vandermonde矩陣FEC(Forward Error/Erasure Correction）前向糾錯技術來進行丟包恢復，由發(fā)送方進行FEC編碼引入冗余包，接收方進行FEC解碼并恢復丟失的數據包。

發(fā)送額外的包來輔助恢復丟失包

FEC技術是一種廣泛應用于通信系統(tǒng)中的編碼技術。以典型的分組碼為例，其基本原理是：在發(fā)送端，通過將k bit信息作為一個分組進行編碼，加入（n-k）bit的冗余校驗信息，組成長度為n bit的碼字。碼字經過信道到達接收端之后，如果錯誤在可糾范圍之內，通過譯碼即可檢查并糾正錯誤bit，從而抵抗信道帶來的干擾，提高通信系統(tǒng)的可靠性。在光通信系統(tǒng)中，通過FEC的處理，可以以很小的冗余開銷代價，有效降低系統(tǒng)的誤碼率，延長傳輸距離，實現(xiàn)降低系統(tǒng)成本的目的。

編碼開銷是校驗位長度（n-k）與信息位長度k的比值，稱為編碼開銷。開銷越大，F(xiàn)EC方案的理論極限性能越高，但增加并不是線性的，開銷越大，開銷增加帶來的性能提高越小。開銷的選擇，需要根據具體系統(tǒng)設計的需求來確定。

4 相關的基礎知識

視頻編碼? &? IBP 幀

碼率 、 幀率 、 分辨率

視頻編碼

幀內（Intraframe）壓縮也稱為空間壓縮（Spatial compression）。當壓縮一幀圖像時，僅考慮本幀的數據而不考慮相鄰幀之間的冗余信息，這實際上與靜態(tài)圖像壓縮類似。幀內一般采用有損壓縮算法，由于幀內壓縮是編碼一個完整的圖像，所以可以獨立的解碼、顯示。幀內壓縮一般達不到很高的壓縮，跟編碼jpeg差不多。

幀間（Interframe）壓縮的原理是：相鄰幾幀的數據有很大的相關性，或者說前后兩幀信息變化很小的特點。也即連續(xù)的視頻其相鄰幀之間具有冗余信息,根據這一特性，壓縮相鄰幀之間的冗余量就可以進一步提高壓縮量，減小壓縮比。幀間壓縮也稱為時間壓縮（Temporal compression），它通過比較時間軸上不同幀之間的數據進行壓縮。幀間壓縮一般是無損的。幀差值（Frame differencing）算法是一種典型的時間壓縮法，它通過比較本幀與相鄰幀之間的差異，僅記錄本幀與其相鄰幀的差值，這樣可以大大減少數據

無損壓縮也即壓縮前和解壓縮后的數據完全一致。多數的無損壓縮都采用RLE行程編碼算法

有損壓縮意味著解壓縮后的數據與壓縮前的數據不一致。在壓縮的過程中要丟失一些人眼和人耳所不敏感的圖像或音頻信息,而且丟失的信息不可恢復。幾乎所有高壓縮的算法都采用有損壓縮,這樣才能達到低數據率的目標。

H264 編解碼 及IBP

H264 基于運動畫面編碼 ： 參照一段時間內圖像的統(tǒng)計結果表明，在相鄰幾幅圖像畫面中，一般有差別的像素只有10%以內的點,亮度差值變化不超過2%，而色度差值的變化只有1%以內。所以對于一段變化不大圖像畫面，我們可以先編碼出一個完整的圖像幀A，隨后的B幀就不編碼全部圖像，只寫入與A幀的差別，這樣B幀的大小就只有完整幀的1/10或更??！B幀之后的C幀如果變化不大，我們可以繼續(xù)以參考B的方式編碼C幀，這樣循環(huán)下去。這段圖像我們稱為一個序列（序列就是有相同特點的一段數據），當某個圖像與之前的圖像變化很大，無法參考前面的幀來生成，那我們就結束上一個序列，開始下一段序列，也就是對這個圖像生成一個完整幀A1，隨后的圖像就參考A1生成，只寫入與A1的差別內容。

I 幀

幀內編碼幀（intra picture）,I幀通常是每個GOP（MPEG所使用的一種視頻壓縮技術）的第一幀，經過適度地壓縮，作為隨機訪問的參考點可以當成靜態(tài)圖像。I幀可以看做一個圖像經過壓縮后覺得產物，I幀壓縮可以得6：1的壓縮比而不會產生任何可覺察的模糊現(xiàn)象。I幀壓縮可去掉視頻的空間冗余信息，下面即將介紹P幀和B幀是為了去掉時間冗余信息。

B 幀

雙向預測內插編碼幀（bi-directionalinterpolated prediction frame）,既考慮源圖像序列前面的已編碼幀，又估計源圖像序列后面的已編碼幀之間的時間冗余信息，來壓縮傳輸數據量的編碼圖像，也成為雙向預測幀

P 幀

前向預測編碼在幀(predictive-frame),通過將圖像序列中前面已編碼幀的時間冗余信息去充分去除壓縮傳輸數據量的編碼圖像，也成為預測幀。