一、簡介
1.RTP和RTCP
RTP全名是Real-time Transport Protocol（實時傳輸協議）。它是IETF提出的一個標準，對應的RFC文檔爲RFC3550（RFC1889爲其過期版本）。RFC3550不僅定義了RTP，而且定義了配套的相關協議RTCP（Real-time Transport Control Protocol，即實時傳輸控制協議）。RTP被定義爲在一對一或一對多的傳輸情況下工作，其目的是提供時間信息和實現流同步。RTP的典型應用建立在UDP（User Datagram Protocol，用戶數據包協議）上，但也可以在TCP（Transfer Control Protocol，傳輸控制協議）或ATM（Asynchronous Transfer Mode，異步傳輸模式）等其他協議之上工作。應用程序通常在 UDP 上運行 RTP 以便使用其多路結點和校驗服務。RTP本身只保證實時數據的傳輸，並不能爲按順序傳送數據包提供可靠的傳送機制，也不提供流量控制或擁塞控制，它依靠RTCP提供這些服務。
RTP協議詳細說明了在互聯網上傳遞音頻和視頻的標準數據包格式。它一開始被設計爲一個多播協議，但後來被用在很多單播應用中。RTP協議常用於流媒體系統（配合RTSP協議）、視頻會議和一鍵通（Push to Talk）系統（配合H.323或SIP），使它成爲IP電話產業的技術基礎。RTP廣泛應用於流媒體相關的通訊和娛樂，包括電話、視頻會議、電視和基於網絡的一鍵通業務（類似對講機的通話）。
RTCP全名是Realtime Transport Control Protocol（實時傳輸控制協議）。它負責管理傳輸質量，在當前應用進程之間交換控制信息。在RTP會話期間，各參與者週期性地傳送RTCP包，包中含有已發送的數據包的數量、丟失的數據包的數量等統計資料，因此，服務器可以利用這些信息動態地改變傳輸速率，甚至改變有效載荷類型。RTP和RTCP配合使用，能以有效的反饋和最小的開銷使傳輸效率最佳化，故特別適合傳送網上的實時數據。相對於RTP來說，RTCP所佔的帶寬非常小，通常只有5%。
2.流媒體
流媒體是指Internet上使用流式傳輸技術的連續時基媒體。當前在Internet上傳輸音頻和視頻等信息主要有兩種方式：下載和流式傳輸兩種方式。
下載情況下，用戶需要先下載整個媒體文件到本地，然後才能播放媒體文件。在視頻直播等應用場合，由於生成整個媒體文件要等直播結束，也就是用戶至少要在直播結束後才能看到直播節目，所以用下載方式不能實現直播。
流式傳輸是實現流媒體的關鍵技術。使用流式傳輸可以邊下載邊觀看流媒體節目。由於Internet是基於分組傳輸的，所以接收端收到的數據包往往有延遲和亂序（流式傳輸構建在UDP上）。要實現流式傳輸，就是要從降低延遲和恢復數據包時序入手。在發送端，爲降低延遲，往往對傳輸數據進行預處理（降低質量和高效壓縮）。在接收端爲了恢復時序，採用了接收緩衝；而爲了實現媒體的流暢播放，則採用了播放緩衝。
使用接收緩衝，可以將接收到的數據包緩存起來，然後根據數據包的封裝信息（如包序號和時戳等），將亂序的包重新排序，最後將重新排序了的數據包放入播放緩衝播放。
爲什麼需要播放緩衝呢？容易想到，由於網絡不可能很理想，並且對數據包排序需要處理時耗，我們得到排序好的數據包的時間間隔是不等的。如果不用播放緩衝，那麼播放節目會很卡，這叫時延抖動。相反，使用播放緩衝，在開始播放時，花費幾十秒鐘先將播放緩衝填滿（例如PPLIVE），可以有效地消除時延抖動，從而在不太損失實時性的前提下實現流媒體的順暢播放。
到目前爲止，Internet 上使用較多的流式視頻格式主要有以下三種:RealNetworks 公司的RealMedia，Apple 公司的QuickTime 以及Microsoft 公司的Advanced Streaming Format (ASF) 。
上面在談接收緩衝時，說到了流媒體數據包的封裝信息（包序號和時戳等），這在後面的RTP封裝中會有體現。另外，RealMedia這些流式媒體格式只是編解碼有不同，但對於RTP來說，它們都是待封裝傳輸的流媒體數據而沒有什麼不同。
3.工作流程
RTP協議從上層接收流媒體信息碼流（如H.263），裝配成RTP數據包發送給下層，下層協議提供RTP和RTCP的分流。如在UDP中，RTP使用一個偶數號端口，則相應的RTCP使用其後的奇數號端口。RTP數據包沒有長度限制，它的最大包長只受下層協議的限制。
RTP用於在單播或多播網絡中傳送實時數據。它們典型的應用場合有如下幾個。
簡單的多播音頻會議：語音通信通過一個多播地址和一對端口來實現。一個用於音頻數據（RTP），另一個用於控制包（RTCP）。
音頻和視頻會議：如果在一次會議中同時使用了音頻和視頻會議，這兩種媒體將分別在不同的RTP會話中傳送，每一個會話使用不同的傳輸地址（IP地址＋端口）。如果一個用戶同時使用了兩個會話，則每個會話對應的RTCP包都使用規範化名字CNAME（Canonical Name）。與會者可以根據RTCP包中的CNAME來獲取相關聯的音頻和視頻，然後根據RTCP包中的計時信息(Network time protocol)來實現音頻和視頻的同步。
二、RTP協議格式
RTP報文由報文頭和報文體組成，報文頭格式如下圖所示。
V：RTP協議的版本號，佔2位，當前協議版本號爲2。
P：填充標誌，佔1位，如果P=1，則在該報文的尾部填充一個或多個額外的八位組，它們不是有效載荷的一部分。
X：擴展標誌，佔1位，如果X=1，則在RTP報頭後跟有一個擴展報頭。
CC：CSRC計數器，佔4位，指示CSRC 標識符的個數。
M：標記，佔1位，不同的有效載荷有不同的含義，對於視頻，標記一幀的結束；對於音頻，標記會話的開始。
PT：有效載荷類型，佔7位，用於說明RTP報文中有效載荷的類型，如GSM音頻、JPEM圖像等,在流媒體中大部分是 用來區分音頻流和視頻流的，這樣便於客戶端進行解析。
SN：序列號，佔16位，發送方在每發送完一個RTP包後就將該域的值增加1，接收方可以由該域檢測包的丟失及恢 復包序列。序列號的初始值是隨機的。
timestamp：時間戳，佔32位，記錄了該包中數據的第一個字節的採樣時刻。它是去除抖動和實現同步不可缺少的。
SSRC：同步源標識符，佔32位，同步源就是指RTP包流的來源。在同一個RTP會話中不能有兩個相同的SSRC值。 該標識符是隨機選取的 RFC1889推薦了MD5隨機算法。
CSRC：特約信源標識符，每個CSRC標識符佔32位，可以有0～15個。每個CSRC標識了包含在該RTP報文有效載荷中 的所有特約信源。
三、時間戳與同步
時間戳段是RTP報文頭中說明數據包時間的同步信息，是數據能以正確的時間順序恢復的關鍵。時間戳的值給出了分組中數據的第一個字節的採樣時間(Sampling Instant)，要求發送方時間戳的時鐘是連續、單調增長的，即使在沒有數據輸入或發送數據時也是如此。在靜默時，發送方不必發送數據，保持時間戳的增長，在接收端，由於接收到的數據分組的序號沒有丟失，就知道沒有發生數據丟失，而且只要比較前後分組的時間戳的差異，就可以確定輸出的時間間隔。
RTP規定一次會話的初始時間戳必須隨機選擇，但協議沒有規定時間戳的單位，也沒有規定該值的精確解釋，而是由負載類型來確定時鐘的顆粒，這樣各種應用類型可以根據需要選擇合適的輸出計時精度。
在RTP傳輸音頻數據時，一般選定邏輯時間戳速率與採樣速率相同，但是在傳輸視頻數據時，必須使時間戳速率大於每幀的一個滴答。如果數據是在同一時刻採樣的，協議標準還允許多個分組具有相同的時間戳值。
RTCP的一個關鍵作用就是能讓接收方同步多個RTP流，例如：當音頻與視頻一起傳輸的時候，由於編碼的不同，RTP使用兩個流分別進行傳輸，這樣兩個流的時間戳以不同的速率運行，接收方必須同步兩個流，以保證聲音與影像的一致。爲能進行流同步，RTCP要求發送方給每個傳送一個唯一的標識數據源的規範名(Canonical Name），儘管由一個數據源發出的不同的流具有不同的同步源標識(SSRC)，但具有相同的規範名，這樣接收方就知道哪些流是有關聯的。
1、SSRC的作用
SSRC相當於一個RTP傳輸session的ID，就象每個人都有一個名字一樣，每一個RTP傳輸也都有一個名字。這個數字是隨機產生，並且要保證唯一。當RTP session改變（如IP等）時，這個ID也要改變。
2、序列號字段是否可以作爲流內的同步標時
我在上面已經說過，序列號只表示了包發出的先後順序，它表示不了任何時間上的其它概念，所有嚴格的說，序列號並不能作爲流內的同步標誌。但是，由於一般來說，包的發送時間都會有嚴格限制，比如音頻包是每秒種發送30個數據包，也就是說，每個包間隔1000/30MS，而這個時間就可以作爲一個同步時間來播放。也就是說，按照序列號，每1000/30MS間隔播放一個數據包，這樣也能保證同步，但是這時候請考慮丟包問題。
3、絕對時間戳和相對時間戳在進行同步處理時有什麼不同
當我們取得絕對時間後，我們就可以根據這個絕對時間來播放這些數據包。這個絕對時間，加上我們需要的延時（用於數據傳輸，解碼等等的時間）就是我們的播放時間，這樣我們可以保證時間的嚴格同步（相當於把對方的動作延時一段時間後原原本本的再現出來）。目前，在RTP中，能得到這個絕對時間的辦法只有RTCP。
對於相對時間戳，我們更關心的是兩個時間戳之間的時間間隔，依靠這個時間間隔，來確定兩個包的播放時間間隔。
4、單個媒體內的同步和不同媒體流之間的同步在處理方式上有什麼不同
應該說，不同媒體之間同步比單媒體同步要複雜得多，除了要保證本身的播放要和時間同步外，還要保證兩個或多個媒體間同步（比如音視頻的同步）。這種不同更關心的兩個時間戳時間的換算統一，前面我已經說過，不同編碼有不同的採樣頻率，那麼時間戳的增長速度就不同。另外，兩個時間戳也需要有一個標準時間來表示時間戳的同步。最簡單的方法是兩個媒體的第一個時間戳相同，表示兩個流的採集開始時間統一。另外還可以通過RTCP來做不同流之間的同步，這在下個問題中會提到。
5、時間戳字段如何用於作爲流間同步標識
在RTP協議中，我們取得時間戳的方法有兩個：一個是RTP包中的時間戳，另外一個是RTCP包中的絕對時間戳和相對時間戳。絕對時間戳的概念上面我已經說了，它可以表示系統的絕對時間。而RTCP包中的相對時間就是RTP包中的時間。根據這兩個時間，不同流都可以糾正自己播放時間和真正時間的偏差以達到和絕對時間同步的目的。
RTP payload類型
PT Encoding Name Audio/Video (A/V) Clock Rate (Hz) Channels Reference
0 PCMU A 8000 1 [RFC3551]
1 Reserved
2 Reserved
3 GSM A 8000 1 [RFC3551]
4 G723 A 8000 1 [Vineet_Kumar][RFC3551]
5 DVI4 A 8000 1 [RFC3551]
6 DVI4 A 16000 1 [RFC3551]
7 LPC A 8000 1 [RFC3551]
8 PCMA A 8000 1 [RFC3551]
9 G722 A 8000 1 [RFC3551]
10 L16 A 44100 2 [RFC3551]
11 L16 A 44100 1 [RFC3551]
12 QCELP A 8000 1 [RFC3551]
13 CN A 8000 1 [RFC3389]
14 MPA A 90000 [RFC3551][RFC2250]
15 G728 A 8000 1 [RFC3551]
16 DVI4 A 11025 1 [Joseph_Di_Pol]
17 DVI4 A 22050 1 [Joseph_Di_Pol]
18 G729 A 8000 1 [RFC3551]
19 Reserved A
20 Unassigned A
21 Unassigned A
22 Unassigned A
23 Unassigned A
24 Unassigned V
25 CelB V 90000 [RFC2029]
26 JPEG V 90000 [RFC2435]
27 Unassigned V
28 nv V 90000 [RFC3551]
29 Unassigned V
30 Unassigned V
31 H261 V 90000 [RFC4587]
32 MPV V 90000 [RFC2250]
33 MP2T AV 90000 [RFC2250]
34 H263 V 90000 [Chunrong_Zhu]
35-71 Unassigned ?
72-76 Reserved for RTCP conflict avoidance [RFC3551]
77-95 Unassigned ?
96-127 dynamic ? [RFC3551]
除了上表中明確指定PT值的負載類型，還有些負載類型由於誕生的較晚，沒有具體的PT值，只能使用動態（dynamic）PT值，即96到127，這就是爲什麼大家普遍指定H264的PT值爲96。具體PT值的負載類型可以在這裏查詢到： RTP Payload Type
RTP Payload H264詳細文檔可以參考：
https://tools.ietf.org/html/rfc6184
https://datatracker.ietf.org/doc/rfc6184/?include_text=1
RTP負載爲H.264定義了三種不同的基本的負載結構，接收端可能通過RTP負載的首字節來識別它們。這一個字節類似NALU頭的格式，它的類型字段則指出了代表的是哪一種結構，這個字節的結構如下：
±--------------+
|0|1|2|3|4|5|6|7|
±±±±±±±±+
|F|NRI| Type |
±--------------+
Type定義如下：
0 沒有定義
1-23 NAL單元 單個NAL單元包.
24 STAP-A 單一時間的組合包
25 STAP-B 單一時間的組合包
26 MTAP16 多個時間的組合包
27 MTAP24 多個時間的組合包
28 FU-A 分片的單元
29 FU-B 分片的單元
30-31 沒有定義
首字節的類型字段和H.264的NALU頭中類型字段的區別是，當Type的值爲2431表示這是一個特別格式的NAL單元，而H.264中，只取123是有效的值。下面分別說明這三種負載結構。
一.Single NALU Packet（單一NAL單元模式）
即一個RTP負載僅由首字節和一個NALU負載組成，對於小於1400字節的NALU便採用這種打包方案。這種情況下首字節類型字段和原始的H.264的NALU頭類型字段是一樣的。也就是說，在這種情況下RTP的負載是一個完整的NALU。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±+
|F|NRI| Type | |
±±±±±±±±+ |
| |
| Bytes 2…n of a single NAL unit |
| |
| ±±±±±±±±±±±±±±±±+
| :…OPTIONAL RTP padding |
±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±+
二. Aggregation Packet（組合封包模式）
在一個RTP中封裝多個NALU，對於較小的NALU可以採用這種打包方案，從而提高傳輸效率。即可能是由多個NALU組成一個RTP包。分別有4種組合方式，STAP-A、STAP-B、MTAP16和MTAP24。那麼這裏的RTP負載首字節類型值分別是24、25、26和27。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±+
|F|NRI| Type | |
±±±±±±±±+ |
| |
| one or more aggregation units |
| |
| ±±±±±±±±±±±±±±±±+
| :…OPTIONAL RTP padding |
±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±+
三.Fragmentation Units（分片封包模式FUs）
一個NALU封裝在多個RTP中，每個RTP負載由首字節（這裏實際上是FU indicator，但是它和原首字節的結構一樣，這裏仍然稱首字節）、FU header和NALU負載的一部分組成。對於大於1400字節的NALU便採用這種方案進行拆包處理。存在兩種類型FU-A和FU-B，類型值分別是28和29。
FU-A類型如下圖所示：
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±+
| FU indicator | FU header | |
±±±±±±±±±±±±±±±±+ |
| |
| FU payload |
| |
| ±±±±±±±±±±±±±±±±+
| :…OPTIONAL RTP padding |
±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±+
FU-B類型如下圖所示
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±+
| FU indicator | FU header | DON |
±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±|
| |
| FU payload |
| |
| ±±±±±±±±±±±±±±±±+
| :…OPTIONAL RTP padding |
±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±+
與FU-A相比，FU-B多了一個DON（decoding order number），DON使用的是網絡字節序。FU-B只能用於隔行掃描封包模式，不能用於其他方面。
FU indicator字節結構如下所示：
±--------------+
|0|1|2|3|4|5|6|7|
±±±±±±±±+
|F|NRI| Type |
±--------------+
Type=28或29
FU header字節結構如下所示：
±--------------+
|0|1|2|3|4|5|6|7|
±±±±±±±±+
|S|E|R| Type |
±--------------+
S（Start）: 1 bit，當設置成1，該位指示分片NAL單元的開始。當隨後的FU負載不是分片NAL單元的開始，該位設爲0。
E（End）: 1 bit，當設置成1, 該位指示分片NAL單元的結束，此時荷載的最後字節也是分片NAL單元的最後一個字節。當隨後的FU荷載不是分片NAL單元的結束,該位設爲0。
R（Reserved）: 1 bit，保留位必須設置爲0，且接收者必須忽略該位。
Type：與NALU頭中的Type值相同
本文由網上多篇博客整理而來。
版權聲明：本文爲CSDN博主「li_wen01」的原創文章，遵循CC 4.0 by-sa版權協議，轉載請附上原文出處鏈接及本聲明。
原文鏈接：https://blog.csdn.net/li_wen01/article/details/68944149