RTP協議全解（H264碼流和PS流）——看完這篇可以畢業

本文轉載自查看原文 2017-08-01 11:41 1367 tcp/udp/rtp

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

1 視頻編碼的原理

1.1 一個圖像或者一個視頻序列進行壓縮，產生碼流。

對圖像的處理即是:幀內預測編碼

其預測值P，是由已編碼的圖像做參考，經運動補償得到的。預測圖像P和當前幀Fn相減，得到兩圖像的殘差值Dn，Dn在經過轉換T，量化Q，去處空間冗余，得到系數X，將X重排（使數據更加緊湊），熵編碼（加入運動矢量。。。一些圖像相關得信息），得到nal數據。

對視頻序列的處理:幀間預測編碼

預測值P，是由當前片中，己編碼的宏塊預測得到的（亮度4×4或者16×16預測，色度8×8預測）。當前待處理的塊，減去預測值P，得殘差值Dn，Dn在經過轉換T，量化Q，得到系數X，將X重排（使數據更加緊湊），熵編碼，得到nal數據

1.2 場、幀、圖像

場：隔行掃描的圖像，偶數行成為頂場行。奇數行成為底場行。

所有頂場行稱為頂場。所有底場行稱為底場.

幀：逐行掃描的圖像。

圖像：場和幀都可認為是圖像。

1.3 宏塊、片

宏塊（MB）：一個宏塊由一個16×16亮度塊、一個8×8Cb和一個8×8Cr組成。

片（slice）：一個圖像可以划分成一個或多個片，一個片由一個或多個宏塊組成。

2 H.264結構

2.1 H.264的編碼格式

H.264從框架結構上分為視頻編碼層（VCL）和網絡抽象層（NAL），VCL功能是進行視頻編解碼，包括運動補償預測，變換編碼和熵編碼等功能；NAL用於采用適當的格式對VCL視頻數據進行封裝打包。這樣划分主要有兩個目的：

其一，可以定義VCL視頻壓縮處理與NAL網絡傳輸機制的接口，這樣允許視頻編碼層VCL的設計可以在不同的處理器平台進行移植，而與NAL層的數據封裝格式無關；
其二，VCL和NAL都被設計成工作於不同的傳輸環境，異構的網絡環境並不需要對VCL比特流進行重構和重編碼。

VCL數據即被壓縮編碼后的視頻數據序列，在VCL數據封裝到NAL單元中之后，才可以用來傳輸或存儲。

2.1.1 NAL單元格式

NAL單元（NALU）是NAL的基本語法結構，它包含一個字節的頭信息和一系列來自VCL的稱為原始字節序列載荷（RBSP）的字節流。

Nal頭

Rbsp

Nal頭

Rbsp

Nal頭

Rbsp

由於NAL的語法中沒有給出長度信息，實際的傳輸、存儲系統需要增加額外的頭實現各個NAL單元的定界。

其中，AVI文件和MPEG TS廣播流采取的是字節流的語法格式，即在NAL單元之前增加 0x00000001 的同步碼，則從AVI文件或MPEG TS PES包中讀出的一個H.264視頻幀以下面的形式存在：

00 00 00 01 06 ... 00 00 00 01 67 ... 00 00 00 01 68 ... 00 00 00 01 65 ...
SEI信息             SPS                PPS                IDR Slice

如果NALU對應的Slice為一幀的開始，則用4字節表示，即0x00000001；否則用3字節表示，0x000001。

而對於MP4文件，NAL單元之前沒有同步碼，卻有若干字節的長度碼(從下面的例子來看是2字節長度碼)，來表示NAL單元的長度，這個長度碼所占用的字節數由MP4文件頭給出；此外，從MP4讀出來的視頻幀不包含PPS和SPS，這些信息位於MP4的文件頭中，解析器必須在打開文件的時候就獲取它們。從MP4文件讀出的一個H.264幀往往是下面的形式（假設長度碼為2字節）：

00 19 06 [... 25 字節...] 24 aa 65 [... 9386 字節...]
SEI信息                   IDR Slice

上例中長度計算如下：

0x0019 = 25

0x24aa = 9386

NALU頭格式如下：

NALU 頭由一個字節組成, 它的格式如下:

      +---------------+
      |0|1|2|3|4|5|6|7|
      +-+-+-+-+-+-+-+-+
      |F|NRI| Type   |
      +---------------+

F（禁止位）: 1 個比特.

禁止位在編碼中默認值為0，當網絡識別此單元中存在比特錯誤時，可將其設為1，以便接收方丟掉該單元，主要用於適應不同種類的網絡環境（比如有線無線相結合的環境）。例如對於從無線到有線的網關，一邊是無線的非IP環境，一邊是有線網絡的無比特錯誤的環境。假設一個NAL單元到達無線那邊時，校驗和檢測失敗，網關可以選擇從NAL流中去掉這個NAL單元，也可以把已知被破壞的NAL單元前傳給接收端。在這種情況下，智能的解碼器將嘗試重構這個NAL單元（已知它可能包含比特錯誤）。而非智能的解碼器將簡單地拋棄這個NAL單元。

NAL單元結構規定了用於面向分組或用於流的傳輸子系統的通用格式。在H.320和MPEG-2系統中，NAL單元的流應該在NAL單元邊界內，每個NAL單元前加一個3字節的起始前綴碼。在分組傳輸系統中，NAL單元由系統的傳輸規程確定幀界，因此不需要上述的起始前綴碼。一組NAL單元被稱為一個接入單元，定界后加上定時信息（SEI），形成基本編碼圖像。該基本編碼圖像（PCP）由一組已編碼的NAL單元組成，其后是冗余編碼圖像（RCP），它是PCP同一視頻圖像的冗余表示，用於解碼中PCP丟失情況下恢復信息。如果該編碼視頻圖像是編碼視頻序列的最后一幅圖像，應出現序列NAL單元的end，表示該序列結束。一個圖像序列只有一個序列參數組，並被獨立解碼。如果該編碼圖像是整個NAL單元流的最后一幅圖像，則應出現流的end。

H.264采用上述嚴格的接入單元，不僅使H.264可自適應於多種網絡，而且進一步提高其抗誤碼能力。序列號的設置可發現丟的是哪一個VCL單元，冗余編碼圖像使得即使基本編碼圖像丟失，仍可得到較“粗糙”的圖像。

NRI: 2 個比特.
nal_ref_idc. 取 00 ~ 11, 指示這個 NALU 的重要性, 用於在重構過程中標記一個NAL單元的重要性，值越大，越重要。值為0表示這個NAL單元沒有用於預測，因此可被解碼器拋棄而不會有錯誤擴散；值高於0表示此NAL單元要用於無漂移重構，且值越高，對此NAL單元丟失的影響越大。

Type: 5 個比特，如下：

0：未規定
1：非IDR圖像中不采用數據划分的片段
2：非IDR圖像中A類數據划分片段
3：非IDR圖像中B類數據划分片段
4：非IDR圖像中C類數據划分片段
5：IDR圖像的片段
6：補充增強信息（SEI）
7：序列參數集（SPS）
8：圖像參數集（PPS）
9：分割符
10：序列結束符
11：流結束符
12：填充數據
13：序列參數集擴展
14：帶前綴的NAL單元
15：子序列參數集
16 – 18：保留
19：不采用數據划分的輔助編碼圖像片段
20：編碼片段擴展
21 – 23：保留
24 – 31：未規定

這用來標識NAL單元中的RBSP數據類型，其中，nal_unit_type為1， 2， 3， 4， 5的NAL單元稱為VCL的NAL單元，其他類型的NAL單元為非VCL的NAL單元。

常用的NAL頭的取值如：

0x67: SPS 
0x68: PPS 
0x65: IDR   
0x61: non-IDR Slice
0x01: B Slice
0x06: SEI
0x09: AU Delimiter

（1）NAL Units：視頻數據封裝在整數字節的NALU中，它的第一個字節標志該單元中數據的類型，H.264定義了兩種封裝格式：

基於包交換的網絡（如H.323系統）可以使用RTP封裝格式封裝NALU。

而另外一些系統可能要求將NALU作為順序比特流傳送，為此H.264定義了一種比特流格式的傳輸機制，使用start_code_prefix將NALU封裝起來，從而確定NAL邊界。

每個NAL單元是一個一定語法元素的可變長字節字符串，包括一個字節的頭信息（用來表示數據類型），以及若干整數字節的負荷數據。一個NAL單元可以攜帶一個編碼片、A/B/C型數據分割或一個序列或圖像參數集。NAL單元按RTP序列號按序傳送。

（2）參數集：以往視頻編解碼標准中GOB\GOP\圖像等頭信息是至關重要的，包含這些信息的包的丟失常導致與這些信息相關的圖像不能解碼。為此H.264將這些很少變化並且對大量VCL NALU起作用的信息放在參數集中傳送。參數集分為兩種，即序列參數集和圖像參數集。為適應多種網絡環境，參數集可以帶內傳送，也可以采用帶外方式傳送。

序列的參數集(SPS)：包括了一個圖像序列的所有信息，

圖像的參數集(PPS)：包括了一個圖像所有片的信息。

在實際的H264數據幀中，往往幀前面帶有00 00 00 01 或 00 00 01分隔符，一般來說編碼器編出的首幀數據為PPS與SPS，接着為I幀……

如下圖：

2.1.2 I幀判斷

綜上，判斷是否為I幀的算法為：（NALU類型 & 0001 1111） = 5 即 NALU類型 & 31 = 5

比如0x65 & 31 = 5，為I幀。

2.2 H.264的網絡傳輸

H.264能夠在基於RTP/UDP/IP、H.323/M、MPEG-2傳輸和H.320協議的網絡中使用

H.264的RTP封裝參考RFC 3550，載荷類型（PT）域未作規定。

2.3數據的划分

通常情況下，一個宏塊的數據是存放在一起而組成片的，數據划分使得一個片中的宏塊數據重新組合，把宏塊語義相關的數據組成一個划分，由划分來組裝片。在H.264中有三種不同的數據划分。

(1)頭信息划分：包含片中宏塊的類型，量化參數和運動矢量，是片中最重要的信息。

(2)幀內信息划分：包含幀內CBPs和幀內系數，幀內信息可以阻止錯誤的蔓延。

(3)幀間信息划分：包含幀間CBPs和幀間系數，通常比前兩個划分要大得多。

幀內信息划分結合頭信息解出幀內宏塊，幀間信息划分結合頭信息解出幀間宏塊。幀間信息划分的重要性最低，對重同步沒有貢獻。當使用數據划分時，片中的數據根據其類型被保存到不同的緩存，同時片的大小也要調整，使得片中最大的划分小於MTU尺寸。

解碼端若獲得所有的划分，就可以完整重構片；解碼端若發現幀內信息或幀間信息划分丟失，可用的頭信息仍然有很好的錯誤恢復性能。這是因為宏塊類型和宏塊的運動矢量含有宏塊的基本特征。

2.4靈活的宏塊次序(FMO)

通過設置宏塊次序映射表(MBAmap)來任意地指配宏塊到不同的片組，FMO模式打亂了原宏塊順序，降低了編碼效率，增加了時延，但增強了抗誤碼性能。FMO模式划分圖像的模式各種各樣，重要的有棋盤模式、矩形模式等。當然FMO模式也可以使一幀中的宏塊順序分割，使得分割后的片的大小小於無線網絡的MTU尺寸。經過FMO模式分割后的圖像數據分開進行傳輸，以棋盤模式為例，當一個片組的數據丟失時可用另一個片組的數據(包含丟失宏塊的相鄰宏塊信息)進行錯誤掩蓋。實驗數據顯示，當丟失率為(視頻會議應用時)10%時，經錯誤掩蓋后的圖像仍然有很高的質量。

3、RTP概述

RTP應用環境

RTP用於在單播或多播網絡中傳送實時數據。它們典型的應用場合有如下幾個：

簡單的多播音頻會議。語音通信通過一個多播地址和一對端口來實現。一個用於音頻數據（RTP），另一個用於控制包（RTCP）。

音頻和視頻會議。如果在一次會議中同時使用了音頻和視頻會議，這兩種媒體將分別在不同的RTP會話中傳送，每一個會話使用不同的傳輸地址（IP地址＋2個端口）。如果一個用戶同時使用了兩個會話，則每個會話對應的RTCP包都使用規范化名字CNAME（Canonical Name）。與會者可以根據RTCP包中的CNAME來獲取相關聯的音頻和視頻，然后根據RTCP包中的計時信息(Network time protocol)來實現音頻和視頻的同步。

RTP會話(RTP session):

RTP傳輸服務使用者之間的連接被稱為RTP會話，就每一個會話參加者而言，會話由一對傳輸層地址(即一個網絡層地址加上兩個端口地址,一個端口為 RTP 報文的發送/接收所占用,另一個端口為 RTCP 報文的發送/接收所占用)標識。在 IP 多播方式中，每個參與者的目的地運輸層地址對可以都相同；在單播方式中，每個參與者的地址對均不相同，因為每個人的網絡層地址都不相同。在多媒體會話中，每個媒體信號由不同的 RTP 會話傳送，有其自己的 RTCP 分組。各 RTP 會話由不同的端口對（和/或）不同的多播地址區分。

混合器(Mixer)和翻譯器(Translator):

翻譯器和混合器都是RTP級的中繼系統。

翻譯器用在通過IP多播不能直接到達的用戶區，例如發送者和接收者之間存在防火牆。

當與會者能接收的音頻編碼格式不一樣，比如有一個與會者通過一條低速鏈路接入到高速會議，這時就要使用混合器。在進入音頻數據格式需要變化的網絡前，混合器將來自一個源或多個源的音頻包進行重構，並把重構后的多個音頻合並，采用另一種音頻編碼進行編碼后，再轉發這個新的RTP包。從一個混合器出來的所有數據包要用混合器作為它們的同步源（SSRC，見RTP的封裝）來識別，可以通過貢獻源列表（CSRC表，見RTP的封裝）可以確認談話者。

流媒體

流媒體是指Internet上使用流式傳輸技術的連續時基媒體。當前在Internet上傳輸音頻和視頻等信息主要有兩種方式：下載和流式傳輸兩種方式。

下載情況下，用戶需要先下載整個媒體文件到本地，然后才能播放媒體文件。在視頻直播等應用場合，由於生成整個媒體文件要等直播結束，也就是用戶至少要在直播結束后才能看到直播節目，所以用下載方式不能實現直播。

流式傳輸是實現流媒體的關鍵技術。使用流式傳輸可以邊下載邊觀看流媒體節目。由於Internet是基於分組傳輸的，所以接收端收到的數據包往往有延遲和亂序（流式傳輸構建在UDP上）。要實現流式傳輸，就是要從降低延遲和恢復數據包時序入手。在發送端，為降低延遲，往往對傳輸數據進行預處理（降低質量和高效壓縮）。在接收端為了恢復時序，采用了接收緩沖；而為了實現媒體的流暢播放，則采用了播放緩沖。

使用接收緩沖，可以將接收到的數據包緩存起來，然后根據數據包的封裝信息（如包序號和時戳等），將亂序的包重新排序，最后將重新排序了的數據包放入播放緩沖播放。

為什么需要播放緩沖呢？容易想到，由於網絡不可能很理想，並且對數據包排序需要處理時耗，我們得到排序好的數據包的時間間隔是不等的。如果不用播放緩沖，那么播放節目會很卡，這叫時延抖動。相反，使用播放緩沖，在開始播放時，花費幾十秒鍾先將播放緩沖填滿（例如PPLIVE），可以有效地消除時延抖動，從而在不太損失實時性的前提下實現流媒體的順暢播放。

到目前為止,Internet 上使用較多的流式視頻格式主要有以下三種：

RealNetworks 公司的RealMedia ，Apple 公司的QuickTime 以及Microsoft 公司的Advanced Streaming Format (ASF) 。

上面在談接收緩沖時，說到了流媒體數據包的封裝信息（包序號和時戳等），這在后面的RTP封裝中會有體現。另外，RealMedia這些流式媒體格式只是編解碼有不同，但對於RTP來說，它們都是待封裝傳輸的流媒體數據而沒有什么不同。

RTP是傳輸層的子層

RTP（實時傳輸協議），顧名思義它是用來提供實時傳輸的，因而可以看成是傳輸層的一個子層。下圖給出了流媒體應用中的一個典型的協議體系結構。

從圖中可以看出， RTP被划分在傳輸層，它建立在UDP（一般實際情況是基於UDP，基於TCP效率太低）上。同UDP協議一樣，為了實現其實時傳輸功能，RTP也有固定的封裝形式。RTP用來為端到端的實時傳輸提供時間信息和流同步，但並不保證服務質量。服務質量由RTCP來提供。這些特點，在第4章可以看到。

RTP是應用層的一部分

不少人也把RTP歸為應用層的一部分，這是從應用開發者的角度來說的。操作系統中的TCP/IP等協議棧所提供的是我們最常用的服務，而RTP的實現還是要靠開發者自己。因此從開發的角度來說，RTP的實現和應用層協議的實現沒有不同，所以可將RTP看成應用層協議。

RTP實現者在發送RTP數據時，需先將數據封裝成RTP包，而在接收到RTP數據包，需要將數據從RTP包中提取出來。

RTP的會話過程

當應用程序建立一個RTP會話時，應用程序將確定一對目的傳輸地址。目的傳輸地址由一個網絡地址和一對端口組成，有兩個端口：一個給RTP包，一個給RTCP包，使得RTP/RTCP數據能夠正確發送。RTP數據發向偶數的UDP端口，而對應的控制信號RTCP數據發向相鄰的奇數UDP端口（偶數的UDP端口＋1），這樣就構成一個UDP端口對。 RTP的發送過程如下，接收過程則相反。

1) RTP協議從上層接收流媒體信息碼流（如H.263），封裝成RTP數據包；RTCP從上層接收控制信息，封裝成RTCP控制包。

2) RTP將RTP 數據包發往UDP端口對中偶數端口；RTCP將RTCP控制包發往UDP端口對中的接收端口。

實時流協議RTSP

實時流協議RTSP（Real-Time Streaming Protocol）是IETF提出的協議，對應的RFC文檔為RFC2362。

從圖 1可以看出，RTSP是一個應用層協議（TCP/IP網絡體系中）。它以C/S模式工作，它是一個多媒體播放控制協議，主要用來使用戶在播放流媒體時可以像操作本地的影碟機一樣進行控制，即可以對流媒體進行暫停/繼續、后退和前進等控制。

資源預定協議RSVP

資源預定協議RSVP(Resource Reservation Protocol)是IETF提出的協議，對應的RFC文檔為RFC2208。

從圖 1可以看出，RSVP工作在IP層之上傳輸層之下，是一個網絡控制協議。RSVP通過在路由器上預留一定的帶寬，能在一定程度上為流媒體的傳輸提供服務質量。在某些試驗性的系統如網絡視頻會議工具vic中就集成了RSVP。

聲音和圖像怎么同步

（這里和上面的說法有一點點區別）

根據聲音流和圖像流的相對時間（即RTP包的時間戳），以及它們的絕對時間（即對應的RTCP包中的RTCP）（應該還有RTCP中的CNAME），可以實現聲音和圖像的同步。

4、RTP Header解析

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
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |V=2|P|X| CC   |M|     PT      |       sequence number         |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                           timestamp                           |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |           synchronization source (SSRC) identifier            |
      +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
      |            contributing source (CSRC) identifiers             |
      |                             ....                              |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

圖1

前12字節是固定的，CSRC可以有多個。

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

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

3) X：擴展標志，占1位，如果X=1，則在RTP報頭后跟有一個擴展報頭

4) CC：CSRC計數器，占4位，指示CSRC 標識符的個數

5) M: 標記，占1位，不同的有效載荷有不同的含義，對於視頻，標記一幀的結束；對於音頻，標記會話的開始。

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

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

8) 時戳(Timestamp)：占32位，必須使用90 kHz 時鍾頻率（程序中的90000）。時戳反映了該RTP報文的第一個八位組的采樣時刻。接收者使用時戳來計算延遲和延遲抖動，並進行同步控制。可以根據RTP包的時間戳來獲得數據包的時序。

9) 同步信源(SSRC)標識符：占32位，用於標識同步信源。同步信源是指產生媒體流的信源，它通過RTP報頭中的一個32位數字SSRC標識符來標識，而不依賴於網絡地址，接收者將根據SSRC標識符來區分不同的信源，進行RTP報文的分組。

該標識符是隨機選擇的，參加同一視頻會議的兩個同步信源不能有相同的SSRC。

此標識不是隨機選擇的，目的在於使同一RTP包連接中沒有兩個同步源有相同的SSRC標識。盡管多個源選擇同一個標識的概率很低，所有RTP實現都必須探測並解決沖突。如源改變源傳輸地址，也必須選擇一個新SSRC標識以避免插入成環行源。

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

提供信源用來標志對一個RTP混合器產生的新包有貢獻的所有RTP包的源。是指當混合器接收到一個或多個同步信源的RTP報文后，經過混合處理產生一個新的組合RTP報文，並把混合器作為組合RTP報文的SSRC，而將原來所有的SSRC都作為CSRC傳送給接收者，使接收者知道組成組合報文的各個SSRC。

注：基本的RTP說明並不定義任何頭擴展本身，如果遇到X=1，需要特殊處理

如果擴展標志被置位則說明緊跟在報頭后面是一個頭擴展，其格式如下：

    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |      defined by profile       |           length              |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                        header extension                       |
   |                             ....                              |

取一段碼流如下：

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

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

1000 0000 1110 0000

按順序解釋如下：

10 是V；

0 是P；

0 是X；

0000 是CC；

1 是M；

110 0000 是PT；

RTP抓包實例

上面是某省IPTV２.０早期的一個數據包的情況。從包中可以看出RTP是怎么和RTSP配合一起使用的。從包402到411為RTSP的協商過程，RTSP在PLAYer命令后數據包就到來。緊跟其后412包就是一個mpeg 的PES包，它是有由rtp來承載的TS來形成。從在420包中就可以更加清析的看出這個RTP流的情況。其PT即payload type為mpeg2 transport streams 也就是ts流，其SSRC為：0x65737D6c，其Seq號為15764，從中也可以看出對於一個RTP流其SEQ號可以開始於一個隨機的數值，但是肯定是逐包遞增的。下圖為420包的展開圖：

從中可以看出承載RTP的為UDP的數據報，這個包中有x標志位為1，則說明其有 header extensions。其header extensions為最下面。extension 的 profile為23128,長度為：2。內容如上圖最后兩部分。

5、RTP載荷H264碼流

RTP頭后是RTP載荷，RTP載荷第一個字節格式跟NALU頭一樣：

+---------------+
      |0|1|2|3|4|5|6|7|
      +-+-+-+-+-+-+-+-+
      |F|NRI| Type   |
      +---------------+

F和NRI也跟NALU頭一樣，只有Type有些不一樣：

0     沒有定義
1-23 NAL單元單個 NAL 單元包.
24    STAP-A   單一時間的組合包
25    STAP-B   單一時間的組合包
26    MTAP16   多個時間的組合包
27    MTAP24   多個時間的組合包
28    FU-A     分片的單元
29    FU-B     分片的單元
30-31 沒有定義

載荷格式定義三個不同的基本荷載結構，接收者可以通過RTP荷載的第一個字節后5位（Type）識別荷載結構：

1) 單個NAL單元包：荷載中只包含一個NAL單元。NAL頭類型域等於原始 NAL單元（NALU）類型，即Type在范圍1到23之間。

2) 聚合包（組合包）：本類型用於聚合多個NAL單元到單個RTP荷載中。本包有四種版本，單時間聚合包類型A (STAP-A)，單時間聚合包類型B (STAP-B)，多時間聚合包類型(MTAP)16位位移(MTAP16), 多時間聚合包類型(MTAP)24位位移(MTAP24)。賦予STAP-A, STAP-B, MTAP16, MTAP24的NAL單元類型號（Type）分別是 24,25, 26, 27

3) 分片包：用於分片單個NAL單元到多個RTP包。現存兩個版本FU-A，FU-B,用NAL單元類型（Type）28，29標識。

常用的打包時的分包規則是：如果小於MTU采用單個NAL單元包，如果大於MTU就采用FUs分片方式。

2.2、單個NAL單元包格式

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

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                          RTP Header                           |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |F|NRI| type   |                                               |
      +-+-+-+-+-+-+-+-+                                               |
      |                                                               |
      |               Bytes 2..n of a Single NAL unit                 |
      |                                                               |
      |                               +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                               :...OPTIONAL RTP padding        |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

圖3

對於 NALU（NAL單元）的長度小於 MTU 大小的包, 一般采用單一 NAL 單元模式.

定義在此的NAL單元包必須只包含一個。RTP序號必須符合NAL單元的解碼順序。這種情況下，NAL單元的第一字節和RTP荷載頭第一個字節重合。如上圖。

對於一個原始的 H.264 NALU 單元常由 [Start Code] [NALU Header] [NALU Payload] 三部分組成, 其中 Start Code 用於標示這是一個 NALU 單元的開始, 必須是 "00 00 00 01" 或 "00 00 01", NALU 頭僅一個字節, 其后都是 NALU 單元載荷。

打包時去除 "00 00 01" 或 "00 00 00 01" 的開始碼, 把其他數據封裝成 RTP 包即可。

如有一個 H.264 的 NALU 是這樣的:

[00 00 00 01 67 42 A0 1E 23 56 0E 2F ... ]

這是一個序列參數集 NAL 單元。 [00 00 00 01] 是四個字節的開始碼, 67 是 NALU 頭, 42 開始的數據是 NALU 載荷.

封裝成 RTP 包將如下:

[ RTP Header ] [ 67 42 A0 1E 23 56 0E 2F ... ]

即只要去掉 4 個字節的開始碼就可以了.

2.3 組合封包格式

當 NALU 的長度特別小時, 可以把幾個 NALU 單元封在一個 RTP 包中.

       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
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                          RTP Header                           |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |STAP-A NAL HDR |         NALU 1 Size           | NALU 1 HDR    |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                         NALU 1 Data                           |
      :                                                               :
      +               +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |               | NALU 2 Size                   | NALU 2 HDR    |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                         NALU 2 Data                           |
      :                                                               :
      |                               +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                               :...OPTIONAL RTP padding        |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

這種模式下，有多個NALU載荷，多個NALU頭。

2.4、分片單元（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

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                          RTP Header                           |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      | FU indicator |   FU header   |                               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                               |
      |                                                               |
      |                         FU payload                            |
      |                                                               |
      |                               +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                               :...OPTIONAL RTP padding        |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

FU-A RTP 載荷格式

其中 FU indicator 8位格式為：

      +---------------+
      |0|1|2|3|4|5|6|7|
      +-+-+-+-+-+-+-+-+
      |F|NRI| Type   |
      +---------------+

FU header 格式:

      +---------------+
      |0|1|2|3|4|5|6|7|
      +-+-+-+-+-+-+-+-+
      |S|E|R| Type   |
      +---------------+

圖4

當 NALU 的長度超過 MTU 時, 就必須對 NALU 單元進行分片封包. 也稱為 Fragmentation Units (FUs).

NAL單元的一個分片由整數個連續NAL單元字節組成。每個NAL單元字節必須正好是該NAL單元一個分片的一部分。相同NAL單元的分片必須使用遞增的RTP序號連續順序發送(第一和最后分片之間沒有其他的RTP包）。同時，NAL單元必須按照RTP順序號的順序裝配。

當一個NAL單元被分片運送在分片單元(FUs)中時，被引用為分片NAL單元。STAPs，MTAPs不可以被分片。 FUs不可以嵌套。 即, 一個FU 不可以包含另一個FU。運送FU的RTP時戳被設置成分片NAL單元的NALU時刻。

圖 4 表示FU-A的RTP荷載格式。FU-A由1字節的分片單元指示（FU indicator）、1字節的分片單元頭（FU header）和分片單元荷載組成。

S（開始位）: 1 bit，當設置成1，指示分片NAL單元的開始。當跟隨的FU荷載不是分片NAL單元荷載的開始，開始位設為0。

E（結束位）: 1 bit，當設置成1，指示分片NAL單元的結束，即,荷載的最后字節也是分片NAL單元的最后一個字節。當跟隨的 FU荷載不是分片NAL單元的最后分片，結束位設置為0。

R（保留位）: 1 bit，保留位必須設置為0，接收者必須忽略該位。

Type（類型）：5 bit，是NAL Header中的Type。

打包時，原始的NAL頭的前三位為FU indicator的前三位，原始的NAL頭的后五位（Type）為FU header的后五位（Type）。

取一段碼流分析如下：

80 60 01 0f 00 0e 10 00 00 00 00 00 7c 85 88 82 €`..........|???

00 0a 7f ca 94 05 3b7f 3e 7f fe 14 2b 27 26 f8 ...??.;.>.?.+'&?

89 88 dd 85 62 e1 6dfc 33 01 38 1a 10 35 f2 14 ????b?m?3.8..5?.

84 6e 21 24 8f 72 62f0 51 7e 10 5f 0d 42 71 12 ?n!$?rb?Q~._.Bq.

17 65 62 a1 f1 44 dc df 4b 4a 38 aa 96 b7 dd 24 .eb??D??KJ8????$

前12字節是RTP Header

7c是FU indicator

85是FU Header

FU indicator（0x7C）和FU Header（0x85）換成二進制如下

0111 1100 1000 0101

按順序解析如下：

0 是F

11 是NRI

11100 是FU Type，這里是28，即FU-A

1 是S，Start，說明是分片的第一包

0 是E，End，如果是分片的最后一包，設置為1，這里不是

0 是R，Remain，保留位，總是0

00101 是NAL Type，這里是5，說明是關鍵幀（不知道為什么是關鍵幀請自行谷歌）

打包時，FU indicator的F、NRI是NAL Header中的F、NRI，Type是28（FU-A）；FU Header的S、E、R分別按照分片起始位置設置，Type是NAL Header中的Type。

解包時，取FU indicator的前三位和FU Header的后五位，即0110 0101（0x65）為NAL類型。

摘抄（不好怎么命名）

RTP，RTCP數據和RTSP數據共享TCP數據通道，所以必須有一個標識來區別三種數據。RTP和RTCP數據會以$符號＋1個字節的通道編號＋4個字節的數據長度（有說2字節長），共6個字節的前綴開始，流數據緊跟其后，沒有CRLF，但包括高層協議頭。每個$塊包含一個高層協議數據單元。 RTSP數據是沒有前綴數據的。RTP數據和RTCP數據的區別在於第二個字節的通道編號，據觀察RTP通道編號是偶數，RTCP通道編號是奇數。

當傳輸選擇為RTP，RTCP信息也被服務器通過TCP連接插入。缺省情況下，RTCP包在比RTP通道高的第一個可用通道上發送。客戶端可能在另一通道顯式請求RTCP包，這可通過指定傳輸頭插入參數中的兩個通道來做到。當兩個或更多流交叉時，為取得同步，需要RTCP。而且，這為當網絡設置需要通過TCP控制連接透過RTP/RTCP提供了一條方便的途徑，可能時，在UDP上進行傳輸。

http://www.cuplayer.com/player/PlayerCode/RTSP/2015/0729/2021.html

http://www.cppblog.com/gtwdaizi/articles/65515.html

6、RTP荷載PS流

針對H264 做如下PS 封裝：每個IDR NALU 前一般都會包含SPS、PPS 等NALU，因此將SPS、PPS、IDR 的NALU 封裝為一個PS 包，包括ps 頭，然后加上PS system header，PS system map，PES header+h264 raw data。所以一個IDR NALU PS 包由外到內順序是：PSheader| PS system header | PS system Map | PES header | h264 raw data。對於其它非關鍵幀的PS 包，就簡單多了，直接加上PS頭和PES 頭就可以了。順序為：PS header | PES header | h264raw data。以上是對只有視頻video 的情況，如果要把音頻Audio也打包進PS 封裝，也可以。當有音頻數據時，將數據加上PES header 放到視頻PES 后就可以了。順序如下：PS 包=PS頭|PES(video)|PES(audio)，再用RTP 封裝發送就可以了。

GB28181 對RTP 傳輸的數據負載類型有規定（參考GB28181 附錄B），負載類型中96-127

RFC2250 建議96 表示PS 封裝，建議97 為MPEG-4，建議98 為H264

即我們接收到的RTP 包首先需要判斷負載類型，若負載類型為96，則采用PS 解復用，將音視頻分開解碼。若負載類型為98，直接按照H264 的解碼類型解碼。

注：此方法不一定准確，取決於打包格式是否標准

PS 包中的流類型（stream type）的取值如下：

1) MPEG-4 視頻流： 0x10；

2) H.264 視頻流： 0x1B；

3) SVAC 視頻流： 0x80；

4) G.711 音頻流： 0x90；

5) G.722.1 音頻流： 0x92；

6) G.723.1 音頻流： 0x93；

7) G.729 音頻流： 0x99；

8) SVAC音頻流： 0x9B。

3.1、PS包頭

圖7

1) Pack start code：包起始碼字段，值為0x000001BA的位串，用來標志一個包的開始。

2) System clock reference base，system clock reference extenstion：系統時鍾參考字段。

3) Pack stuffing length ：包填充長度字段，3 位整數，規定該字段后填充字節的個數

80 60 53 1f 00 94 89 00 00 0000 00 00 00 01 ba €`S..??........?

7e ff 3e fb 44 01 00 5f 6b f8 00 00 01 e0 14 53 ~.>?D.._k?...?.S

80 80 05 2f bf cf bed1 1c 42 56 7b 13 58 0a 1e €€./????.BV{.X..

08 b1 4f 33 69 35 0453 6d 33 a8 04 15 58 d9 21 .?O3i5.Sm3?..X?!

9741 b9 f1 75 3d 94 2b 1f bc 0b b2 b4 97 bf 93 ?A??u=?+.?.?????

前12位是RTP Header，這里不再贅述；

000001ba是包頭起始碼；

接下來的9位包括了SCR，SCRE，MUXRate，具體看圖7

最后一位是保留位（0xf8），定義了是否有擴展，二進制如下

1111 1000

前5位跳過，后3位指示了擴展長度，這里是0.

3.2、系統標題

圖8

Systemheader當且僅當pack是第一個數據包時才存在，即PS包頭之后就是系統標題。取值0x000001BB的位串，指出系統標題的開始，暫時不需要處理，讀取Header Length直接跳過即可。

3.3、節目映射流

Systemheader當且僅當pack是第一個數據包時才存在，即系統標題之后就是節目流映射。取值0x000001BC的位串，指出節目流映射的開始，暫時不需要處理，讀取Header Length直接跳過即可。前5字節的結構同系統標題，見圖8。

取一段碼流分析系統標題和節目映射流

00 00 01 ba 45 a9 d4 5c 34 0100 5f 6b f8 00 00 ...?E??\4.._k?..

01 bb 00 0c 80 cc f5 04 e1 7f e0 e0 e8 c0 c0 20 .?..€??.?.?????

00 00 01 bc 00 1e e1 ff00 00 00 18 1b e0 00 0c ...?..?......?..

2a 0a 7f ff 00 00 0708 1f fe a0 5a 90 c0 00 00 *........??Z??..

00 00 00 00 00 00 01 e0 7f e0 80 80 0521 6a 75 .......?.?€€.!ju

前14個字節是PS包頭（注意，沒有擴展）；

接下來的00 00 01 bb是系統標題起始碼；

接下來的00 0c說明了系統標題的長度（不包括起始碼和長度字節本身）；

接下來的12個字節是系統標題的具體內容，這里不做解析；

繼續看到00 00 01 bc，這是節目映射流起始碼；

緊接着的00 1e同樣代表長度；

跳過e1 ff，基本沒用；

接下來是00 18，代表基本流長度，說明了后面還有24個字節；

接下來的1b，意思是H264編碼格式；

下一個字節e0，意思是視頻流；

接下里00 0c，同樣代表接下的長度12個字節；

跳過這12個字節，看到90，這是G.711音頻格式；

下一個字節是c0，代表音頻流；

接下來的00 00同樣代表長度，這里是0；

接下來4個字節是CRC，循環冗余校驗。

到這里節目映射流解析完畢。（好累）。

好戲還在后頭呢。

3.4、PES分組頭部

圖9

別被這么長的圖嚇到，其實原理相同，但是，你必須處理其中的每一位。

1) Packet start code prefix：值為0x000001的位串，它和后面的stream id 構成了標識分組開始的分組起始碼，用來標志一個包的開始。

2) Stream id：在節目流中，它規定了基本流的號碼和類型。0x(C0~DF)指音頻，0x(E0~EF)為視頻

3) PES packet length：16 位字段，指出了PES 分組中跟在該字段后的字節數目。值為0 表示PES 分組長度要么沒有規定要么沒有限制。這種情況只允許出現在有效負載包含來源於傳輸流分組中某個視頻基本流的字節的PES 分組中。

4) PTS_DTS：2 位字段。當值為'10'時，PTS 字段應出現在PES 分組標題中；當值為'11'時，PTS 字段和DTS 字段都應出現在PES 分組標題中；當值為'00'時，PTS 字段和DTS 字段都不出現在PES分組標題中。值'01'是不允許的。

5) ESCR：1位。置'1'時表示ESCR 基礎和擴展字段出現在PES 分組標題中；值為'0'表示沒有ESCR 字段。

6) ESrate：1 位。置'1'時表示ES rate 字段出現在PES 分組標題中；值為'0'表示沒有ES rate 字段。

7) DSMtrick mode：1 位。置'1'時表示有8 位特技方式字段；值為'0'表示沒有該字段。

8) Additionalinfo：1 位。附加版權信息標志字段。置'1'時表示有附加拷貝信息字段；值為'0'表示沒有該字段。

9) CRC：1 位。置'1'時表示CRC 字段出現在PES 分組標題中；值為'0'表示沒有該字段。

10) Extensionflag：1 位標志。置'1'時表示PES 分組標題中有擴展字段；值為'0'表示沒有該字段。

PES header data length： 8 位。PES 標題數據長度字段。指出包含在PES 分組標題中的可選字段和任何填充字節所占用的總字節數。該字段之前的字節指出了有無可選字段。

老規矩，上碼流：

00 00 01 e0 21 33 80 80 05 2b 5f df 5c 95 71 84 ...?!3€€.+_?\?q?

aa e4 e9 e9 ec 40 cc17 e0 68 7b 23 f6 89 df 90 ?????@?.?h{#????

a9d4 be 74 b9 67 ad 34 6d f0 92 0d 5a 48 dd 13 ???t?g?4m??.ZH?.

00 00 01是起始碼；

e0是視頻流；

21 33 是幀長度；

接下來的兩個80 80見下面的二進制解析；

下一個字節05指出了可選字段的長度，前一字節指出了有無可選字段；

接下來的5字節是PTS；

第7、8字節的二進制如下：

1000 0000 1000 0000

按順序解析：

第7個字節：

10 是標志位，必須是10；

00 是加擾控制字段，‘00’表示沒有加密，剩下的01,10,11由用戶自定義；

0 是優先級，1為高，0為低；

0 是數據對齊指示字段；

0 是版權字段；

0 是原始或拷貝字段。置'1'時表示相關PES分組有效負載的內容是原始的；'0'表示內容是一份拷貝；

第8個字節：

10 是PTS_DTS字段，這里是10，表示有PTS,沒有DTS；

0 是ESCR標志字段，這里為0，表示沒有該段；

0 是ES速率標志字段，，這里為0，表示沒有該段；

0 是DSM特技方式標志字段，，這里為0，表示沒有該段；

0 是附加版權信息標志字段，，這里為0，表示沒有該段；

0 是PESCRC標志字段，，這里為0，表示沒有該段；

0 是PES擴展標志字段，，這里為0，表示沒有該段；

本段碼流只有PTS，貼一下解析函數

[cpp] view plain copy

unsigned long parse_time_stamp (const unsigned char *p)
{
unsigned long b;
//共33位，溢出后從0開始
unsigned long val;
//第1個字節的第5、6、7位
b = *p++;
val = (b & 0x0e) << 29;
//第2個字節的8位和第3個字節的前7位
b = (*(p++)) << 8;
b += *(p++);
val += ((b & 0xfffe) << 14);
//第4個字節的8位和第5個字節的前7位
b = (*(p++)) << 8;
b += *(p++);
val += ((b & 0xfffe) >> 1);
return val;
}

其他字段可參考協議解析

ps：

遇到00 00 01 bd的，這個是私有流的標識

ps:

另外，有的hk攝像頭回調然后解讀出來的原始h.264碼流，有的一包里只有分界符數據(nal_unit_type=9)或補充增強信息單元(nal_unit_type=6)，如果直接送入解碼器，有可能會出現問題，這里的處理方式要么丟棄這兩個部分，要么和之后的數據合起來，再送入解碼器里，如有遇到的朋友可以交流一下:)

寫在后面：

第一次發原創，在這里感謝 @cmengwei 的無私幫助，提供了很多幫助，非常感謝。

文檔我都放在了我的資源里面，有1個下載積分，大家不要吝嗇，絕對值得！

《RTP Payload Format for H.264 Video》

http://download.csdn.net/detail/chen495810242/7904367

《MPEG2-2(13818中文版)》

http://download.csdn.net/detail/chen495810242/7904401

RTP荷載H264的代碼參考：

http://blog.csdn.net/dengzikun/article/details/5807694

RTP荷載PS流的代碼參考：

http://www.pudn.com/downloads33/sourcecode/windows/multimedia/detail105823.html

http://www.oschina.net/code/snippet_99626_23737