H264視頻傳輸、編解碼----RTP/RTCP協議

RTSP對流媒體提供了控制方法，使得實時流數據變得可控。但是它並不負責實時流數據的傳輸。實時流數據的傳輸和傳輸過程的同步、優化由RTP/RTCP來負責。

實時傳輸協議RTP（ Real-time Transport Protocol）和實時傳輸控制協議(Real-time ControlProtocol，RTCP)，在RTP會話期間，每個會話參與者週期性地向所有其他參與者發送RTCP控制信息包，如下圖所示。對於RTP會話或者廣播，通常使用單個多目標廣播地址，屬於這個會話的所有RTP和RTCP信息包都使用這個多目標廣播地址，通過使用不同的端口號可把RTP信息包和RTCP信息包區分開來。他們一般通過UDP協議發送相應的數據。

RTP

RTP數據協議負責對流媒體數據進行封包並實現媒體流的實時傳輸，每一個RTP數據報都由頭部（Header）和負載（Payload）兩個部分組成，其中頭部前12個字節的含義是固定的，而負載則可以是音頻或者視頻數據。

下面是 RFC 3550 中規定的 RTP 頭的結構.

 

       0             1             2               3               4
       0 1 2 3 4 5 6 7 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |V=2|P|X|  CC   |M|     PT    |       sequence number         |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                           timestamp                         |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |           synchronization source (SSRC) identifier          |
      +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
      |            contributing source (CSRC) identifiers           |
      |                             ....                            |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

 

負載類型 Payload type (PT): 7 bits

序列號 Sequence number (SN): 16 bits

時間戳 Timestamp: 32 bits

一張網上的圖：

 

（1）IP是屬於網絡層部分的，UDP和RTP都是屬於傳輸層部分的。

（2）RTP首部

 

 1) V：RTP協議的版本號，佔2位，當前協議版本號爲2

 2)P：填充標誌，佔1位，如果P=1，則在該報文的尾部填充一個或多個額外的八位組，它們不是有效載荷的一部分。

 3)X：擴展標誌，佔1位，如果X=1，則在RTP報頭後跟有一個擴展報頭

 4)CC：CSRC計數器，佔4位，指示CSRC 標識符的個數（作用信源CSRC計數器）

 5)M: 標記，佔1位，不同的有效載荷有不同的含義，對於視頻，標記一幀的結束；對於音頻，標記會話的開始。（對於分組中的重要事件可用該位標識）

 6)PT: 有效荷載類型，佔7位，用於說明RTP報文中有效載荷的類型，如GSM音頻、JPEM圖像等,在流媒體中大部分是用來區分音頻流和視頻流的，這樣便於客戶端進行解析。

 7)序列號：佔16位，用於標識發送者所發送的RTP報文的序列號，每發送一個報文，序列號增1。這個字段當下層的承載協議用UDP的時候，網絡狀況不好的時候可以用來檢查丟包。同時出現網絡抖動的情況可以用來對數據進行重新排序，序列號的初始值是隨機的，同時音頻包和視頻包的sequence是分別記數的。

 8)時戳(Timestamp)：佔32位，必須使用90 kHz 時鐘頻率。時戳反映了該RTP報文的第一個八位組的採樣時刻。接收者使用時戳來計算延遲和延遲抖動，並進行同步控制。

 9)同步信源(SSRC)標識符：佔32位，用於標識同步信源。該標識符是隨機選擇的，參加同一視頻會議的兩個同步信源不能有相同的SSRC。

 10)特約信源(CSRC)標識符：每個CSRC標識符佔32位，可以有0～15個。每個CSRC標識了包含在該RTP報文有效載荷中的所有特約信源。

 

取一段碼流如下：

 

80 e0 00 1e 00 00 d2 f0 00 00 00 00 41 9b 6b 49  €?....??....A?kI

e1 0f 26 53 02 1a ff06 59 97 1d d2 2e 8c 50 01  ?.&S....Y?.?.?P.

cc 13 ec 52 77 4e e50e 7b fd 16 11 66 27 7c b4  ?.?RwN?.{?..f'|?

f6 e1 29 d5 d6 a4 ef3e 12 d8 fd 6c 97 51 e7 e9  ??)????>.??l?Q??

cfc7 5e c8 a9 51 f6 82 65 d6 48 5a 86 b0 e0 8c ??^??Q??e?HZ????

其中，

80               是V_P_X_CC

e0               是M_PT

00 1e          是SequenceNum

00 00 d2 f0 是Timestamp

00 00 00 00是SSRC

把前兩字節換成二進制如下

1000 0000 1110 0000

按順序解釋如下：

10               是V；

0                 是P；

0                 是X；

0000           是CC；

1                 是M；

110 0000    是PT；

 

RTP協議的目的是提供實時數據（如交互式的音頻和視頻）的端到端傳輸服務，因此在RTP中沒有連接的概念，它可以建立在底層的面向連接（TCP）或面向非連接（UDP）的傳輸協議之上；RTP也不依賴於特別的網絡地址格式，而僅僅只需要底層傳輸協議支持組幀（Framing）和分段（Segmentation）就足夠了；

另外RTP本身還不提供任何可靠性機制，這些都要由傳輸協議或者應用程序自己來保證。在典型的應用場合下，RTP一般是在傳輸協議之上作爲應用程序的一部分加以實現的，

RTP擴展頭：

很多時候，在傳輸H264數據的時候，也需要傳輸其他的協議數據信息，這個時候，就可以放在RTP的擴展頭部分傳輸。根據上面RTP協議格式，第一個字節的bit2(X)，這個字段如果是1的話，就表示當前RTP協議帶着擴展頭。

這個擴展頭就跟在RTP確定的頭部後面。如果有CSRC，就跟在CSRC後面，CSRC的個數，可以看第一個字節的bit4~bit7(CC)，每一個CSRC 4個字節。這樣就可以確定擴展頭的位置了。

擴展頭的內部格式：

       0             1             2               3               4
       0 1 2 3 4 5 6 7 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |       defined by profile    |            length             |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                           header extension                  |
                                  ......  ......
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

•  defined by profile ：按照私有的協議文檔自己定義就行了，相當於一個標識。
• length：擴展頭長度，更確切地說，是擴展頭個數，比如length == 2，標識有兩個，每個擴展頭4字節，則共 2 * 4 = 8字節。即擴展頭內容長度爲 4 * length（字節）。

RTCP

一、RTCP協議作用

 

1、爲應用程序提供會話質量或者廣播性能質量的信息　

RTCP的主要功能是爲應用程序提供會話質量或者廣播性能質量的信息。每個RTCP信息包不封裝聲音數據或者電視數據，而是封裝發送端（和 / 或者）接收端的統計報表。這些信息包括發送的信息包數目、丟失的信息包數目和信息包的抖動等情況，這些反饋信息反映了當前的網絡狀況，對發送端、接收端或者網絡管理員都非常有用。RTCP規格沒有指定應用程序應該使用這些反饋信息做什麼，這完全取決於應用程序開發人員。例如，發送端可以根據反饋信息來調整傳輸速率，接收端可以根據反饋信息判斷問題是本地的、區域性的還是全球性的，網絡管理員也可以使用RTCP信息包中的信息來評估網絡用於多目標廣播的性能。

2、確定 RTP用戶源　

RTCP爲每個RTP用戶提供了一個全局唯一的規範名稱 (Canonical Name)標誌符 CNAME，接收者使用它來追蹤一個RTP進程的參加者。當發現衝突或程序重新啓動時，RTP中的同步源標識符SSRC可能發生改變，接收者可利用CNAME來跟蹤參加者。同時，接收者也需要利用CNAME在相關RTP連接中的幾個數據流之間建立聯繫。當 RTP需要進行音視頻同步的時候，接受者就需要使用 CNAME來使得同一發送者的音視頻數據相關聯，然後根據RTCP包中的計時信息(Network time protocol)來實現音頻和視頻的同步。

3、控制 RTCP傳輸間隔

由於每個對話成員定期發送RTCP信息包，隨着參加者不斷增加，RTCP信息包頻繁發送將佔用過多的網絡資源，爲了防止擁塞，必須限制RTCP信息包的流量，控制信息所佔帶寬一般不超過可用帶寬的 5%，因此就需要調整 RTCP包的發送速率。由於任意兩個RTP終端之間都互發 RTCP包，因此終端的總數很容易估計出來，應用程序根據參加者總數就可以調整RTCP包的發送速率。

4、傳輸最小進程控制信息　

這項功能對於參加者可以任意進入和離開的鬆散會話進程十分有用，參加者可以自由進入或離開，沒有成員控制或參數協調。

二、RTCP協議格式

RTCP也是用UDP來傳送的，但RTCP封裝的僅僅是一些控制信息，因而分組很短，所以可以將多個RTCP分組封裝在一個UDP包中。

 

 RTCP協議的功能是通過不同的RTCP數據報來實現的，主要有如下幾種類型：

• SR：發送端報告，所謂發送端是指發出RTP數據報的應用程序或者終端，發送端同時也可以是接收端。
• RR：接收端報告，所謂接收端是指僅接收但不發送RTP數據報的應用程序或者終端。
• SDES：源描述，主要功能是作爲會話成員有關標識信息的載體，如用戶名、郵件地址、電話號碼等，此外還具有向會話成員傳達會話控制信息的功能。
• BYE：通知離開，主要功能是指示某一個或者幾個源不再有效，即通知會話中的其他成員自己將退出會話。
• APP：由應用程序自己定義，解決了RTCP的擴展性問題，並且爲協議的實現者提供了很大的靈活性。

接下來看一下SR包，其他包大同小異：

 

 

 

 

版本（V）：同RTP包頭域。

填充（P）：同RTP包頭域。

接收報告計數器（RC）：5比特，該SR包中的接收報告塊的數目，可以爲零。

包類型（PT）：8比特，SR包是200。

長度域（Length）：16比特，其中存放的是該SR包以32比特爲單位的總長度減一。

同步源（SSRC）：SR包發送者的同步源標識符。與對應RTP包中的SSRC一樣。

NTP Timestamp（Network time protocol）：SR包發送時的絕對時間值。NTP的作用是同步不同的RTP媒體流。

RTP Timestamp：與NTP時間戳對應，與RTP數據包中的RTP時間戳具有相同的單位和隨機初始值。

Sender’s packet count：從開始發送包到產生這個SR包這段時間裏，發送者發送的RTP數據包的總數. SSRC改變時，這個域清零。

Sender`s octet count：從開始發送包到產生這個SR包這段時間裏，發送者發送的淨荷數據的總字節數（不包括頭部和填充）。發送者改變其SSRC時，這個域要清零。

同步源n的SSRC標識符：該報告塊中包含的是從該源接收到的包的統計信息。

丟失率（Fraction Lost）：表明從上一個SR或RR包發出以來從同步源n(SSRC_n)來的RTP數據包的丟失率。

累計的包丟失數目：從開始接收到SSRC_n的包到發送SR,從SSRC_n傳過來的RTP數據包的丟失總數。

收到的擴展最大序列號：從SSRC_n收到的RTP數據包中最大的序列號，

接收抖動（Interarrival jitter）：RTP數據包接受時間的統計方差估計

上次SR時間戳（Last SR,LSR）：取最近從SSRC_n收到的SR包中的NTP時間戳的中間32比特。如果目前還沒收到SR包，則該域清零。

上次SR以來的延時（Delay since last SR,DLSR）：上次從SSRC_n收到SR包到發送本報告的延時。

 

 

 

不同類型的RTCP信息包可堆疊，不需要插入任何分隔符就可以將多個RTCP包連接起來形成一個RTCP組合包，然後由低層協議用單一包發送出去。由於需要低層協議提供整體長度來決定組合包的結尾，在組合包中沒有單個RTCP包的顯式計數。

組合包中每個RTCP包可獨立處理，而不需要按照包組合的先後順序處理。在組合包中有以下幾條強制約束：

1、只要帶寬允許，在SR包或RR包中的接收統計應該經常發送，因此每個週期發送的組合RTCP 包中應包含報告包。

2、每個組合包中都應該包含SDES CNAME，因爲新接收者需要通過接收CNAME來識別源，並與媒體聯繫進行同步。

3、組合包前面是包類型數量，其增長應該受到限制。

 

所有RTCP包至少必須以兩個包組合形式發送，推薦格式如下：

加密前綴（Encryption prefix）：

僅當組合包被加密，才加上一個32位隨機數用於每個組合包發送。

SR或RR：

組合包中第一個RTCP包必須是一個報告包，以幫助分組頭的確認。即使沒有數據發送，也沒有接收到數據，也要發送一個空RR，那怕組合包中RTCP包爲BYE。

附加RR：

如報告統計源數目超過31，在初始報告包後應該有附加RR包。

SDES：

包含CNAME 項的SDES包必須包含在每個組合RTCP包中。SDES包可能包括其他源描述項，這要根據特別的應用需要，並同時考慮帶寬限制。

BYE或APP：

除了BYE應作爲最後一個包發送，其它RTCP包類型可以任意順序排列，包類型出現可不止一次。

混合器從多個源組合單個RTCP包，如組合包整體長度超過網絡路徑最大傳輸單元，可分成多個較短組合包用低層協議以單個包形式發送。注意，每個組合包必須以SR或RR包開始。附加RTCP包類型可在Internet Assigned NumbersAuthority (IANA)處註冊，以獲得合法的類型號。

RTCP傳輸間隔

由於RTP設計成允許應用自動擴展，可從幾個人的小規模系統擴展成上千人的大規模系統。而每個會話參與者週期性地向所有其他參與者發送RTCP控制信息包，如每個參與者以固定速率發送接收報告，控制流量將隨參與者數量線性增長。由於網絡資源有限，相應的數據包就要減少，直接影響用戶關心的數據傳輸。爲了限制控制信息的流量，RTCP控制信息包速率必須按比例下降。

一旦確認加入到RTP會話中，即使後來被標記成非活動站，地址的狀態仍會被保留，地址應繼續計入共享RTCP帶寬地址的總數中，時間要保證能掃描典型網絡分區，建議爲30分鐘。注意，這仍大於RTCP報告間隔最大值的五倍。

SR源報告包和RR接收者報告包

SR源報告包和RR接收者報告包用於提供接收質量反饋，除包類型代碼外，SR與RR間唯一的差別是源報告包含有一個20字節發送者信息段。RR針對每個信源都提供信息包丟失數、已收信息包最大序列號、到達時間抖動、接收最後一個SR的時間、接收最後一個SR的延遲等信息。SR不僅提供接收質量反饋信息（與RR相同），而且提供SSRC標識符、NTP時間戳、RTP時間戳、發送包數以及發送字節數等。根據接收者是否爲發送者來決定使用SR還是RR包，活動源在發出最後一個數據包之後或前一個數據包與下一個數據包間隔期間發送SR；否則，就發送RR；SR和RR包都可沒有接收報告塊也可以包括多個接收報告塊，其發佈報告表示的源不一定是在CSRC列表上的起作用的源，每個接收報告塊提供從特殊源接收數據的統計。最大可有31個接收報告塊嵌入在SR 或 RR包中，丟失包累計數差別給出間隔期間丟包的數量，而系列號的差別給出間隔期間希望發送的包數量，兩者之比等於經過間隔期間包丟失百分比。從發送者信息，第三方監控器可計算載荷平均數據速率與沒收到數據間隔的平均包速率，兩者比值給出平均載荷大小。如假設包丟失與包大小無關，那麼特殊接收者收到的包數量給出此接收者收到的表觀流量。

SDES源描述包

SDES源描述包提供了直觀的文本信息來描述會話的參加者，包括CNAME、NAME、EMAIL、PHONE、LOC等源描述項，這些爲接收方獲取發送方的有關信息提供了方便。SDES 包由包頭與數據塊組成，數據塊可以沒有，也可有多個。包頭由版本（V）、填充（P）、長度指示、包類型（PT）和源計數（SC）組成。PT佔8位，用於識別RTCP的SDES包，SC佔5位，指示包含在SDES包中的SSRC/CSRC塊數量，零值有效，但沒有意義。數據塊由源描述項組成，源描述項的內容如下：

CNAME: 規範終端標識SDES項

類似SSRC標識，RTCP爲RTP連接中每一個參加者賦予唯一一個CNAME標識。在發生衝突或重啓程序時，由於隨機分配的SSRC標識可能發生變化，CNAME項可以提供從SSRC標識到仍爲常量的源標識的綁定。

爲方便第三方監控，CNAME應適合程序或人員定位源。

NAME：用戶名稱SDES項

這是用於描述源的真正的名稱，如"John Doe, Bit Recycler, Megacorp"，可以是用戶想要的任意形式。由於採用文本信息來描述，對諸如會議應用，可以對參加者直接列表顯示，NAME項是除CNAME項以外發送最頻繁的項目。NAME值在一次RTP會話期間應該保持爲常數，但它不該成爲連接的所有參加者中唯一依賴。

EMAIL：電子郵件地址SDES項

郵件地址格式由RFC822規定，如"[email protected]"。一次RTP會話期間，EMAIL項的內容希望保持不變。

PHONE：電話號碼SDES項

電話號碼應帶有加號，代替國際接入代碼，如"[phone]"即爲美國電話號碼。　

LOC：用戶地理位置SDES項

根據應用，此項具有不同程度的細節。對會議應用，字符串如"Murray Hill, New Jersey"就足夠了。然而，對活動標記系統，字符串如"Room 2A244, AT&T BL MH"也許就適用。細節留給實施或用戶，但格式和內容可用設置指示。在一次RTP會話期間，除移動主機外，LOC值期望保持不變。

TOOL：應用或工具名稱SDES項

TOOL項包含一個字符串，表示產生流的應用的名稱與版本，如"videotool 1.2"。這部分信息對調試很有用，類似於郵件或郵件系統版本SMTP頭。TOOL值在一次RTP會話期間保持不變。

NOTE: 通知/狀態SDES項

NOTE 項旨在描述源當前狀態的過渡信息，如"on the phone, can't talk"，或在講座期間用於傳送談話的題目，它的語法可在設置中顯式定義。NOTE項一般只用於攜帶例外信息，而不應包含在全部參加者中，因爲這將降低接收報告和CNAME發送的速度，損害協議的性能。一般NOTE 項不作爲用戶設置文件的項目，也不會自動產生。

由於NOTE項對顯示很重要，當會話的參加者處於活動狀態時，其它非CNAME項（如NAME）傳輸速率將會降低，結果使NOTE項佔用RTCP部分帶寬。若過渡信息不活躍，NOTE項繼續以同樣的速度重複發送幾次，並以一個串長爲零的字符串通知接收者。

PRIV: 專用擴展SDES項

PRIV項用於定義實驗或應用特定的SDES擴展，它由長字符串對組成的前綴，後跟填充該項其他部分和攜帶所需信息的字符串值組成。前綴長度段爲8位。前綴字符串是定義PRIV項人員選擇的名稱，唯一對應應用接收到的其它PRIV項。應用實現者可選擇使用應用名稱，如有必要，外加附加子類型標識。另外，推薦其它人根據其代表的實體選擇名稱，然後，在實體內部協調名稱的使用。

注意，前綴應儘可能的短。SDES的PRIV項前綴沒在IANA處註冊。如證實某些形式的PRIV項具有通用性， IANA應給它分配一個正式的SDES項類型，這樣就不再需要前綴，從而簡化應用，並提高傳輸的效率。

BYE斷開RTCP包

如混合器接收到一個BYE包，混合器轉發BYE包，而不改變SSRC/CSRC 標識。如混合器關閉，在關閉之前它應該發出一個BYE包，列出混合器處理的所有源，而不只是自己的SSRC標識。作爲可選項，BYE包可包括一個8位八進制計數，後跟文本信息，表示離開原因，如："cameramalfunction"或"RTPloop detected"。字符串的編碼與在SDES 項中所描述的相同。如字符串信息至BYE包下32位邊界結束處，字符串就不以空結尾；否則，BYE包以空八進制填充。

APP特殊應用包

APP包用於開發新應用和新特徵的實驗，不要求註冊包類型值。帶有不可識別名稱的APP包應被忽略掉。測試後，如確定應用廣泛，推薦重新定義每個APP包，而不用向IANA註冊子類型和名稱段。

RTP/ RTCP的不足之處

RTP與RTCP相結合雖然保證了實時數據的傳輸，但也有自己的缺點。最顯著的是當有許多用戶一起加入會話進程的時候，由於每個參與者都週期發送RTCP信息包，導致RTCP包氾濫(flooding)。

 

 

 

參考：

http://blog.csdn.net/bytxl/article/details/50400987

 

https://www.zhihu.com/question/20278635