1 視頻編碼的原理

1.1 一個(gè)圖像或者一個(gè)視頻序列進(jìn)行壓縮，產(chǎn)生碼流。

對(duì)圖像的處理即是:幀內(nèi)預(yù)測(cè)編碼

其預(yù)測(cè)值P，是由已編碼的圖像做參考，經(jīng)運(yùn)動(dòng)補(bǔ)償?shù)玫降摹ｎA(yù)測(cè)圖像P和當(dāng)前幀Fn相減，得到兩圖像的殘差值Dn，Dn在經(jīng)過轉(zhuǎn)換T，量化Q，去處空間冗余，得到系數(shù)X，將X重排（使數(shù)據(jù)更加緊湊），熵編碼（加入運(yùn)動(dòng)矢量。。。一些圖像相關(guān)得信息），得到nal數(shù)據(jù)。

對(duì)視頻序列的處理:幀間預(yù)測(cè)編碼

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

?

1.2 場(chǎng)?、幀、圖像

場(chǎng)：隔行掃描的圖像，偶數(shù)行成為頂場(chǎng)行。奇數(shù)行成為底場(chǎng)行。

所有頂場(chǎng)行稱為頂場(chǎng)。所有底場(chǎng)行稱為底場(chǎng).

幀：逐行掃描的圖像。

圖像：場(chǎng)和幀都可認(rèn)為是圖像。

1.3 宏塊、片

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

片（slice）：一個(gè)圖像可以劃分成一個(gè)或多個(gè)片，一個(gè)片由一個(gè)或多個(gè)宏塊組成。

2 H.264結(jié)構(gòu)

2.1 H.264的編碼格式

H.264從框架結(jié)構(gòu)上分為視頻編碼層（VCL）和網(wǎng)絡(luò)抽象層（NAL），VCL功能是進(jìn)行視頻編解碼，包括運(yùn)動(dòng)補(bǔ)償預(yù)測(cè)，變換編碼和熵編碼等功能；NAL用于采用適當(dāng)?shù)母袷綄?duì)VCL視頻數(shù)據(jù)進(jìn)行封裝打包。這樣劃分主要有兩個(gè)目的：

??????其一，可以定義VCL視頻壓縮處理與NAL網(wǎng)絡(luò)傳輸機(jī)制的接口，這樣允許視頻編碼層VCL的設(shè)計(jì)可以在不同的處理器平臺(tái)進(jìn)行移植，而與NAL層的數(shù)據(jù)封裝格式無關(guān)；
??????其二，VCL和NAL都被設(shè)計(jì)成工作于不同的傳輸環(huán)境，異構(gòu)的網(wǎng)絡(luò)環(huán)境并不需要對(duì)VCL比特流進(jìn)行重構(gòu)和重編碼。

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

2.1.1 NAL單元格式

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

Nal頭

Rbsp

Nal頭

Rbsp

Nal頭

Rbsp

由于NAL的語(yǔ)法中沒有給出長(zhǎng)度信息，實(shí)際的傳輸、存儲(chǔ)系統(tǒng)需要增加額外的頭實(shí)現(xiàn)各個(gè)NAL單元的定界。

其中，AVI文件和MPEG TS廣播流采取的是字節(jié)流的語(yǔ)法格式，即在NAL單元之前增加 0x00000001 的同步碼，則從AVI文件或MPEG TS PES包中讀出的一個(gè)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對(duì)應(yīng)的Slice為一幀的開始，則用4字節(jié)表示，即0x00000001；否則用3字節(jié)表示，0x000001。?

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

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

上例中長(zhǎng)度計(jì)算如下：

0x0019 ?= 25

0x24aa = 9386

NALU頭格式如下：

NALU 頭由一個(gè)字節(jié)組成, 它的格式如下:

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

F（禁止位）: 1 個(gè)比特.

? ? 禁止位在編碼中默認(rèn)值為0，當(dāng)網(wǎng)絡(luò)識(shí)別此單元中存在比特錯(cuò)誤時(shí)，可將其設(shè)為1，以便接收方丟掉該單元，主要用于適應(yīng)不同種類的網(wǎng)絡(luò)環(huán)境（比如有線無線相結(jié)合的環(huán)境）。例如對(duì)于從無線到有線的網(wǎng)關(guān)，一邊是無線的非IP環(huán)境，一邊是有線網(wǎng)絡(luò)的無比特錯(cuò)誤的環(huán)境。假設(shè)一個(gè)NAL單元到達(dá)無線那邊時(shí)，校驗(yàn)和檢測(cè)失敗，網(wǎng)關(guān)可以選擇從NAL流中去掉這個(gè)NAL單元，也可以把已知被破壞的NAL單元前傳給接收端。在這種情況下，智能的解碼器將嘗試重構(gòu)這個(gè)NAL單元（已知它可能包含比特錯(cuò)誤）。而非智能的解碼器將簡(jiǎn)單地拋棄這個(gè)NAL單元。

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

H.264采用上述嚴(yán)格的接入單元，不僅使H.264可自適應(yīng)于多種網(wǎng)絡(luò)，而且進(jìn)一步提高其抗誤碼能力。序列號(hào)的設(shè)置可發(fā)現(xiàn)丟的是哪一個(gè)VCL單元，冗余編碼圖像使得即使基本編碼圖像丟失，仍可得到較“粗糙”的圖像。

NRI: 2 個(gè)比特.
? nal_ref_idc. 取 00 ~ 11, 指示這個(gè) NALU 的重要性,?用于在重構(gòu)過程中標(biāo)記一個(gè)NAL單元的重要性，值越大，越重要。值為0表示這個(gè)NAL單元沒有用于預(yù)測(cè)，因此可被解碼器拋棄而不會(huì)有錯(cuò)誤擴(kuò)散；值高于0表示此NAL單元要用于無漂移重構(gòu)，且值越高，對(duì)此NAL單元丟失的影響越大。

Type: 5 個(gè)比特，如下：

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

這用來標(biāo)識(shí)NAL單元中的RBSP數(shù)據(jù)類型，其中，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：視頻數(shù)據(jù)封裝在整數(shù)字節(jié)的NALU中，它的第一個(gè)字節(jié)標(biāo)志該單元中數(shù)據(jù)的類型，H.264定義了兩種封裝格式：

基于包交換的網(wǎng)絡(luò)（如H.323系統(tǒng)）可以使用RTP封裝格式封裝NALU。

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

每個(gè)NAL單元是一個(gè)一定語(yǔ)法元素的可變長(zhǎng)字節(jié)字符串，包括一個(gè)字節(jié)的頭信息（用來表示數(shù)據(jù)類型），以及若干整數(shù)字節(jié)的負(fù)荷數(shù)據(jù)。一個(gè)NAL單元可以攜帶一個(gè)編碼片、A/B/C型數(shù)據(jù)分割或一個(gè)序列或圖像參數(shù)集。NAL單元按RTP序列號(hào)按序傳送。

（2）參數(shù)集：以往視頻編解碼標(biāo)準(zhǔn)中GOB\GOP\圖像等頭信息是至關(guān)重要的，包含這些信息的包的丟失常導(dǎo)致與這些信息相關(guān)的圖像不能解碼。為此H.264將這些很少變化并且對(duì)大量VCL NALU起作用的信息放在參數(shù)集中傳送。參數(shù)集分為兩種，即序列參數(shù)集和圖像參數(shù)集。為適應(yīng)多種網(wǎng)絡(luò)環(huán)境，參數(shù)集可以帶內(nèi)傳送，也可以采用帶外方式傳送。

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

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

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

如下圖：

2.1.2 I幀判斷

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

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

2.2 H.264的網(wǎng)絡(luò)傳輸

H.264能夠在基于RTP/UDP/IP、H.323/M、MPEG-2傳輸和H.320協(xié)議的網(wǎng)絡(luò)中使用

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

?

2.3數(shù)據(jù)的劃分

??????通常情況下，一個(gè)宏塊的數(shù)據(jù)是存放在一起而組成片的，數(shù)據(jù)劃分使得一個(gè)片中的宏塊數(shù)據(jù)重新組合，把宏塊語(yǔ)義相關(guān)的數(shù)據(jù)組成一個(gè)劃分，由劃分來組裝片。在H.264中有三種不同的數(shù)據(jù)劃分。

?(1)頭信息劃分：包含片中宏塊的類型，量化參數(shù)和運(yùn)動(dòng)矢量，是片中最重要的信息。

?(2)幀內(nèi)信息劃分：包含幀內(nèi)CBPs和幀內(nèi)系數(shù)，幀內(nèi)信息可以阻止錯(cuò)誤的蔓延。

?(3)幀間信息劃分：包含幀間CBPs和幀間系數(shù)，通常比前兩個(gè)劃分要大得多。

??????幀內(nèi)信息劃分結(jié)合頭信息解出幀內(nèi)宏塊，幀間信息劃分結(jié)合頭信息解出幀間宏塊。幀間信息劃分的重要性最低，對(duì)重同步?jīng)]有貢獻(xiàn)。當(dāng)使用數(shù)據(jù)劃分時(shí)，片中的數(shù)據(jù)根據(jù)其類型被保存到不同的緩存，同時(shí)片的大小也要調(diào)整，使得片中最大的劃分小于MTU尺寸。

??????解碼端若獲得所有的劃分，就可以完整重構(gòu)片；解碼端若發(fā)現(xiàn)幀內(nèi)信息或幀間信息劃分丟失，可用的頭信息仍然有很好的錯(cuò)誤恢復(fù)性能。這是因?yàn)楹陦K類型和宏塊的運(yùn)動(dòng)矢量含有宏塊的基本特征。

?

2.4靈活的宏塊次序(FMO)

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

3、RTP概述

RTP應(yīng)用環(huán)境

RTP用于在單播或多播網(wǎng)絡(luò)中傳送實(shí)時(shí)數(shù)據(jù)。它們典型的應(yīng)用場(chǎng)合有如下幾個(gè)：

簡(jiǎn)單的多播音頻會(huì)議。語(yǔ)音通信通過一個(gè)多播地址和一對(duì)端口來實(shí)現(xiàn)。一個(gè)用于音頻數(shù)據(jù)（RTP），另一個(gè)用于控制包（RTCP）。

音頻和視頻會(huì)議。如果在一次會(huì)議中同時(shí)使用了音頻和視頻會(huì)議，這兩種媒體將分別在不同的RTP會(huì)話中傳送，每一個(gè)會(huì)話使用不同的傳輸?shù)刂?#xff08;IP地址＋2個(gè)端口）。如果一個(gè)用戶同時(shí)使用了兩個(gè)會(huì)話，則每個(gè)會(huì)話對(duì)應(yīng)的RTCP包都使用規(guī)范化名字CNAME（Canonical Name）。與會(huì)者可以根據(jù)RTCP包中的CNAME來獲取相關(guān)聯(lián)的音頻和視頻，然后根據(jù)RTCP包中的計(jì)時(shí)信息(Network time protocol)來實(shí)現(xiàn)音頻和視頻的同步。

?RTP會(huì)話(RTP session):

RTP傳輸服務(wù)使用者之間的連接被稱為RTP會(huì)話，就每一個(gè)會(huì)話參加者而言，會(huì)話由一對(duì)傳輸層地址(即一個(gè)網(wǎng)絡(luò)層地址加上?兩個(gè)端口地址,一個(gè)端口為?RTP?報(bào)文的發(fā)送/接收所占用,另一個(gè)端口為?RTCP?報(bào)文的發(fā)送/接收所占用)標(biāo)識(shí)。在?IP?多播方式中，每個(gè)參與者的目的地運(yùn)輸層地址對(duì)可以都相同；在單播方式中，每個(gè)參與者的地址對(duì)均不相同，因?yàn)槊總€(gè)人的網(wǎng)絡(luò)層地址都不相同。在多媒體會(huì)話中，每個(gè)媒體信號(hào)由不同的?RTP?會(huì)話傳送，有其自己的?RTCP?分組。各?RTP?會(huì)話由不同的端口對(duì) （和/或） 不同的多播地址區(qū)分。

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

翻譯器和混合器都是RTP級(jí)的中繼系統(tǒng)。

翻譯器用在通過IP多播不能直接到達(dá)的用戶區(qū)，例如發(fā)送者和接收者之間存在防火墻。

當(dāng)與會(huì)者能接收的音頻編碼格式不一樣，比如有一個(gè)與會(huì)者通過一條低速鏈路接入到高速會(huì)議，這時(shí)就要使用混合器。在進(jìn)入音頻數(shù)據(jù)格式需要變化的網(wǎng)絡(luò)前，混合器將來自一個(gè)源或多個(gè)源的音頻包進(jìn)行重構(gòu)，并把重構(gòu)后的多個(gè)音頻合并，采用另一種音頻編碼進(jìn)行編碼后，再轉(zhuǎn)發(fā)這個(gè)新的RTP包。從一個(gè)混合器出來的所有數(shù)據(jù)包要用混合器作為它們的同步源（SSRC，見RTP的封裝）來識(shí)別，可以通過貢獻(xiàn)源列表（CSRC表，見RTP的封裝）可以確認(rèn)談話者。

流媒體

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

下載情況下，用戶需要先下載整個(gè)媒體文件到本地，然后才能播放媒體文件。在視頻直播等應(yīng)用場(chǎng)合，由于生成整個(gè)媒體文件要等直播結(jié)束，也就是用戶至少要在直播結(jié)束后才能看到直播節(jié)目，所以用下載方式不能實(shí)現(xiàn)直播。

流式傳輸是實(shí)現(xiàn)流媒體的關(guān)鍵技術(shù)。使用流式傳輸可以邊下載邊觀看流媒體節(jié)目。由于Internet是基于分組傳輸?shù)?#xff0c;所以接收端收到的數(shù)據(jù)包往往有延遲和亂序（流式傳輸構(gòu)建在UDP上）。要實(shí)現(xiàn)流式傳輸，就是要從降低延遲和恢復(fù)數(shù)據(jù)包時(shí)序入手。在發(fā)送端，為降低延遲，往往對(duì)傳輸數(shù)據(jù)進(jìn)行預(yù)處理（降低質(zhì)量和高效壓縮）。在接收端為了恢復(fù)時(shí)序，采用了接收緩沖；而為了實(shí)現(xiàn)媒體的流暢播放，則采用了播放緩沖。

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

為什么需要播放緩沖呢？容易想到，由于網(wǎng)絡(luò)不可能很理想，并且對(duì)數(shù)據(jù)包排序需要處理時(shí)耗，我們得到排序好的數(shù)據(jù)包的時(shí)間間隔是不等的。如果不用播放緩沖，那么播放節(jié)目會(huì)很卡，這叫時(shí)延抖動(dòng)。相反，使用播放緩沖，在開始播放時(shí)，花費(fèi)幾十秒鐘先將播放緩沖填滿（例如PPLIVE），可以有效地消除時(shí)延抖動(dòng)，從而在不太損失實(shí)時(shí)性的前提下實(shí)現(xiàn)流媒體的順暢播放。

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

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

上面在談接收緩沖時(shí)，說到了流媒體數(shù)據(jù)包的封裝信息（包序號(hào)和時(shí)戳等），這在后面的RTP封裝中會(huì)有體現(xiàn)。另外，RealMedia這些流式媒體格式只是編解碼有不同，但對(duì)于RTP來說，它們都是待封裝傳輸?shù)牧髅襟w數(shù)據(jù)而沒有什么不同。

RTP是傳輸層的子層

RTP（實(shí)時(shí)傳輸協(xié)議），顧名思義它是用來提供實(shí)時(shí)傳輸?shù)?#xff0c;因而可以看成是傳輸層的一個(gè)子層。下圖給出了流媒體應(yīng)用中的一個(gè)典型的協(xié)議體系結(jié)構(gòu)。

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

RTP是應(yīng)用層的一部分

不少人也把RTP歸為應(yīng)用層的一部分，這是從應(yīng)用開發(fā)者的角度來說的。操作系統(tǒng)中的TCP/IP等協(xié)議棧所提供的是我們最常用的服務(wù)，而RTP的實(shí)現(xiàn)還是要靠開發(fā)者自己。因此從開發(fā)的角度來說，RTP的實(shí)現(xiàn)和應(yīng)用層協(xié)議的實(shí)現(xiàn)沒有不同，所以可將RTP看成應(yīng)用層協(xié)議。

RTP實(shí)現(xiàn)者在發(fā)送RTP數(shù)據(jù)時(shí)，需先將數(shù)據(jù)封裝成RTP包，而在接收到RTP數(shù)據(jù)包，需要將數(shù)據(jù)從RTP包中提取出來。

RTP的會(huì)話過程

當(dāng)應(yīng)用程序建立一個(gè)RTP會(huì)話時(shí)，應(yīng)用程序?qū)⒋_定一對(duì)目的傳輸?shù)刂贰Ｄ康膫鬏數(shù)刂酚梢粋€(gè)網(wǎng)絡(luò)地址和一對(duì)端口組成，有兩個(gè)端口：一個(gè)給RTP包，一個(gè)給RTCP包，使得RTP/RTCP數(shù)據(jù)能夠正確發(fā)送。RTP數(shù)據(jù)發(fā)向偶數(shù)的UDP端口，而對(duì)應(yīng)的控制信號(hào)RTCP數(shù)據(jù)發(fā)向相鄰的奇數(shù)UDP端口（偶數(shù)的UDP端口＋1），這樣就構(gòu)成一個(gè)UDP端口對(duì)。?RTP的發(fā)送過程如下，接收過程則相反。

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

2)????????RTP將RTP?數(shù)據(jù)包發(fā)往UDP端口對(duì)中偶數(shù)端口；RTCP將RTCP控制包發(fā)往UDP端口對(duì)中的接收端口。

實(shí)時(shí)流協(xié)議RTSP

實(shí)時(shí)流協(xié)議RTSP（Real-Time Streaming Protocol）是IETF提出的協(xié)議，對(duì)應(yīng)的RFC文檔為RFC2362。

從圖?1可以看出，RTSP是一個(gè)應(yīng)用層協(xié)議（TCP/IP網(wǎng)絡(luò)體系中）。它以C/S模式工作，它是一個(gè)多媒體播放控制協(xié)議，主要用來使用戶在播放流媒體時(shí)可以像操作本地的影碟機(jī)一樣進(jìn)行控制，即可以對(duì)流媒體進(jìn)行暫停/繼續(xù)、后退和前進(jìn)等控制。

資源預(yù)定協(xié)議RSVP

資源預(yù)定協(xié)議RSVP(Resource Reservation Protocol)是IETF提出的協(xié)議，對(duì)應(yīng)的RFC文檔為RFC2208。

從圖?1可以看出，RSVP工作在IP層之上傳輸層之下，是一個(gè)網(wǎng)絡(luò)控制協(xié)議。RSVP通過在路由器上預(yù)留一定的帶寬，能在一定程度上為流媒體的傳輸提供服務(wù)質(zhì)量。在某些試驗(yàn)性的系統(tǒng)如網(wǎng)絡(luò)視頻會(huì)議工具vic中就集成了RSVP。

聲音和圖像怎么同步

（這里和上面的說法有一點(diǎn)點(diǎn)區(qū)別）

根據(jù)聲音流和圖像流的相對(duì)時(shí)間（即RTP包的時(shí)間戳），以及它們的絕對(duì)時(shí)間（即對(duì)應(yīng)的RTCP包中的RTCP）（應(yīng)該還有RTCP中的CNAME），可以實(shí)現(xiàn)聲音和圖像的同步。

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字節(jié)是固定的，CSRC可以有多個(gè)。

1)????????V：RTP協(xié)議的版本號(hào)，占2位，當(dāng)前協(xié)議版本號(hào)為2

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

3)????????X：擴(kuò)展標(biāo)志，占1位，如果X=1，則在RTP報(bào)頭后跟有一個(gè)擴(kuò)展報(bào)頭

4)????????CC：CSRC計(jì)數(shù)器，占4位，指示CSRC 標(biāo)識(shí)符的個(gè)數(shù)

5)????????M: 標(biāo)記，占1位，不同的有效載荷有不同的含義，對(duì)于視頻，標(biāo)記一幀的結(jié)束；對(duì)于音頻，標(biāo)記會(huì)話的開始。

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

7)????????序列號(hào)：占16位，用于標(biāo)識(shí)發(fā)送者所發(fā)送的RTP報(bào)文的序列號(hào)，每發(fā)送一個(gè)報(bào)文，序列號(hào)增1。這個(gè)字段當(dāng)下層的承載協(xié)議用UDP的時(shí)候，網(wǎng)絡(luò)狀況不好的時(shí)候可以用來檢查丟包。當(dāng)出現(xiàn)網(wǎng)絡(luò)抖動(dòng)的情況可以用來對(duì)數(shù)據(jù)進(jìn)行重新排序。序列號(hào)的初始值是隨機(jī)的，同時(shí)音頻包和視頻包的sequence 是分別記數(shù)的。

8)????????時(shí)戳(Timestamp)：占32位，必須使用90 kHz 時(shí)鐘頻率（程序中的90000）。時(shí)戳反映了該RTP報(bào)文的第一個(gè)八位組的采樣時(shí)刻。接收者使用時(shí)戳來計(jì)算延遲和延遲抖動(dòng)，并進(jìn)行同步控制。可以根據(jù)RTP包的時(shí)間戳來獲得數(shù)據(jù)包的時(shí)序。

9)????????同步信源(SSRC)標(biāo)識(shí)符：占32位，用于標(biāo)識(shí)同步信源。同步信源是指產(chǎn)生媒體流的信源，它通過RTP報(bào)頭中的一個(gè)32位數(shù)字SSRC標(biāo)識(shí)符來標(biāo)識(shí)，而不依賴于網(wǎng)絡(luò)地址，接收者將根據(jù)SSRC標(biāo)識(shí)符來區(qū)分不同的信源，進(jìn)行RTP報(bào)文的分組。

該標(biāo)識(shí)符是隨機(jī)選擇的，參加同一視頻會(huì)議的兩個(gè)同步信源不能有相同的SSRC。

此標(biāo)識(shí)不是隨機(jī)選擇的，目的在于使同一RTP包連接中沒有兩個(gè)同步源有相同的SSRC標(biāo)識(shí)。盡管多個(gè)源選擇同一個(gè)標(biāo)識(shí)的概率很低，所有RTP實(shí)現(xiàn)都必須探測(cè)并解決沖突。如源改變?cè)磦鬏數(shù)刂?#xff0c;也必須選擇一個(gè)新SSRC標(biāo)識(shí)以避免插入成環(huán)行源。

10) ? ?提供信源(CSRC)標(biāo)識(shí)符：每個(gè)CSRC標(biāo)識(shí)符占32位，可以有0～15個(gè)CSRC。每個(gè)CSRC標(biāo)識(shí)了包含在該RTP報(bào)文有效載荷中的所有提供信源。

提供信源用來標(biāo)志對(duì)一個(gè)RTP混合器產(chǎn)生的新包有貢獻(xiàn)的所有RTP包的源。是指當(dāng)混合器接收到一個(gè)或多個(gè)同步信源的RTP報(bào)文后，經(jīng)過混合處理產(chǎn)生一個(gè)新的組合RTP報(bào)文，并把混合器作為組合RTP報(bào)文的SSRC，而將原來所有的SSRC都作為CSRC傳送給接收者，使接收者知道組成組合報(bào)文的各個(gè)SSRC。

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

如果擴(kuò)展標(biāo)志被置位則說明緊跟在報(bào)頭后面是一個(gè)頭擴(kuò)展，其格式如下：

0 1 2 30 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

把前兩字節(jié) 80 e0 換成二進(jìn)制如下 1000 0000 1110 0000 按順序解釋如下： 10 ? ? ? ? ? ? ? 是V； 0 ? ? ? ? ? ? ? ? 是P； 0 ? ? ? ? ? ? ? ? 是X； 0000 ? ? ? ? ? 是CC； 1 ? ? ? ? ? ? ? ? 是M； 110 0000 ? ?是PT；

RTP抓包實(shí)例

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

從中可以看出承載RTP的為UDP的數(shù)據(jù)報(bào)，這個(gè)包中有x標(biāo)志位為1，則說明其有 header extensions。其header extensions為最下面。extension 的 profile為23128,長(zhǎng)度為：2。內(nèi)容如上圖最后兩部分。

5、RTP載荷H264碼流

RTP頭后是RTP載荷，RTP載荷第一個(gè)字節(jié)格式跟NALU頭一樣：

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

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

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

載荷格式定義三個(gè)不同的基本荷載結(jié)構(gòu)，接收者可以通過RTP荷載的第一個(gè)字節(jié)后5位（Type）識(shí)別荷載結(jié)構(gòu)：

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

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

3) ? 分片包：用于分片單個(gè)NAL單元到多個(gè)RTP包。現(xiàn)存兩個(gè)版本FU-A，FU-B,用NAL單元類型 （Type）28，29標(biāo)識(shí)。

常用的打包時(shí)的分包規(guī)則是：如果小于MTU采用單個(gè)NAL單元包，如果大于MTU就采用FUs分片方式。

2.2、單個(gè)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

? ? ? 對(duì)于 NALU（NAL單元）的長(zhǎng)度小于 MTU 大小的包, 一般采用單一 NAL 單元模式.??

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

? ? ??對(duì)于一個(gè)原始的 H.264 NALU 單元常由 [Start Code] [NALU Header] [NALU Payload] 三部分組成, 其中 Start Code 用于標(biāo)示這是一個(gè)?NALU 單元的開始, 必須是 "00 00 00 01" 或 "00 00 01", NALU 頭僅一個(gè)字節(jié), 其后都是 NALU 單元載荷。

? ?打包時(shí)去除 "00 00 01" 或 "00 00 00 01" 的開始碼, 把其他數(shù)據(jù)封裝成 RTP 包即可。

? ?如有一個(gè) H.264 的 NALU 是這樣的:

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

? 這是一個(gè)序列參數(shù)集 NAL 單元。?[00 00 00 01] 是四個(gè)字節(jié)的開始碼, 67 是 NALU 頭, 42 開始的數(shù)據(jù)是 NALU 載荷.

??封裝成 RTP 包將如下:

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

? 即只要去掉 4 個(gè)字節(jié)的開始碼就可以了.

2.3 組合封包格式

??當(dāng) NALU 的長(zhǎng)度特別小時(shí), 可以把幾個(gè) NALU 單元封在一個(gè) 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??????? |
????? +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

這種模式下，有多個(gè)NALU載荷，多個(gè)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

當(dāng) NALU 的長(zhǎng)度超過 MTU 時(shí), 就必須對(duì) NALU 單元進(jìn)行分片封包. 也稱為 Fragmentation Units (FUs).

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

?? 當(dāng)一個(gè)NAL單元被分片運(yùn)送在分片單元(FUs)中時(shí)，被引用為分片NAL單元。STAPs，MTAPs不可以被分片。 FUs不可以嵌套。 即, 一個(gè)FU 不可以包含另一個(gè)FU。運(yùn)送FU的RTP時(shí)戳被設(shè)置成分片NAL單元的NALU時(shí)刻。

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

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

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

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

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

打包時(shí)，原始的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字節(jié)是RTP Header 7c是FU indicator 85是FU Header FU indicator（0x7C）和FU Header（0x85）換成二進(jìn)制如下 0111 1100 1000 0101 按順序解析如下： 0 ? ? ? ? ? ? ? ? ? ? ? ? ? ?是F 11 ? ? ? ? ? ? ? ? ? ? ? ? ?是NRI 11100 ? ? ? ? ? ? ? ? ? ?是FU Type，這里是28，即FU-A 1 ? ? ? ? ? ? ? ? ? ? ? ? ? ?是S，Start，說明是分片的第一包 0 ? ? ? ? ? ? ? ? ? ? ? ? ? ?是E，End，如果是分片的最后一包，設(shè)置為1，這里不是 0 ? ? ? ? ? ? ? ? ? ? ? ? ? ?是R，Remain，保留位，總是0 00101 ? ? ? ? ? ? ? ? ? ?是NAL Type，這里是5，說明是關(guān)鍵幀（不知道為什么是關(guān)鍵幀請(qǐng)自行谷歌）

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

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

摘抄（不好怎么命名）

RTP，RTCP數(shù)據(jù)和RTSP數(shù)據(jù)共享TCP數(shù)據(jù)通道，所以必須有一個(gè)標(biāo)識(shí)來區(qū)別三種數(shù)據(jù)。RTP和RTCP數(shù)據(jù)會(huì)以$符號(hào)＋1個(gè)字節(jié)的通道編號(hào)＋4個(gè) 字節(jié)的數(shù)據(jù)長(zhǎng)度（有說2字節(jié)長(zhǎng)），共6個(gè)字節(jié)的前綴開始，流數(shù)據(jù)緊跟其后，沒有CRLF，但包括高層協(xié)議頭。每個(gè)$塊包含一個(gè)高層協(xié)議數(shù)據(jù)單元。?RTSP數(shù)據(jù)是沒有前綴數(shù)據(jù)的。RTP數(shù)據(jù)和RTCP數(shù)據(jù)的區(qū)別在于第二個(gè)字節(jié)的通道編號(hào)，據(jù)觀察RTP通道編號(hào)是偶數(shù)，RTCP通道編號(hào)是奇數(shù)。
? ? ? 當(dāng)傳輸選擇為RTP，RTCP信息也被服務(wù)器通過TCP連接插入。缺省情況下，RTCP包在比RTP通道高的第一個(gè)可用通道上發(fā)送。客戶端可能在另一通道顯式請(qǐng)求RTCP包，這可通過指定傳輸頭插入?yún)?shù)中的兩個(gè)通道來做到。當(dāng)兩個(gè)或更多流交叉時(shí)，為取得同步，需要RTCP。而且，這為當(dāng)網(wǎng)絡(luò)設(shè)置需要通過TCP控制連接透過RTP/RTCP提供了一條方便的途徑，可能時(shí)，在UDP上進(jìn)行傳輸。?
http://www.cuplayer.com/player/PlayerCode/RTSP/2015/0729/2021.html
http://www.cppblog.com/gtwdaizi/articles/65515.html

6、RTP荷載PS流

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

? ? ? ? GB28181 對(duì)RTP 傳輸?shù)臄?shù)據(jù)負(fù)載類型有規(guī)定（參考GB28181 附錄B），負(fù)載類型中96-127

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

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

? ? ? ? 注：此方法不一定準(zhǔn)確，取決于打包格式是否標(biāo)準(zhǔn)

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的位串，用來標(biāo)志一個(gè)包的開始。

2)????????System clock reference base，system clock reference extenstion：系統(tǒng)時(shí)鐘參考字段。

3)????????Pack stuffing length ：包填充長(zhǎng)度字段，3 位整數(shù)，規(guī)定該字段后填充字節(jié)的個(gè)數(shù)

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），定義了是否有擴(kuò)展，二進(jìn)制如下

1111 1000

前5位跳過，后3位指示了擴(kuò)展長(zhǎng)度，這里是0.

3.2、系統(tǒng)標(biāo)題

? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?圖8 Systemheader當(dāng)且僅當(dāng)pack是第一個(gè)數(shù)據(jù)包時(shí)才存在，即PS包頭之后就是系統(tǒng)標(biāo)題。取值0x000001BB的位串，指出系統(tǒng)標(biāo)題的開始，暫時(shí)不需要處理，讀取Header Length直接跳過即可。

3.3、節(jié)目映射流

Systemheader當(dāng)且僅當(dāng)pack是第一個(gè)數(shù)據(jù)包時(shí)才存在，即系統(tǒng)標(biāo)題之后就是節(jié)目流映射。取值0x000001BC的位串，指出節(jié)目流映射的開始，暫時(shí)不需要處理，讀取Header Length直接跳過即可。前5字節(jié)的結(jié)構(gòu)同系統(tǒng)標(biāo)題，見圖8。

取一段碼流分析系統(tǒng)標(biāo)題和節(jié)目映射流

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個(gè)字節(jié)是PS包頭（注意，沒有擴(kuò)展）；

接下來的00 00 01 bb是系統(tǒng)標(biāo)題起始碼；

接下來的00 0c說明了系統(tǒng)標(biāo)題的長(zhǎng)度（不包括起始碼和長(zhǎng)度字節(jié)本身）；

接下來的12個(gè)字節(jié)是系統(tǒng)標(biāo)題的具體內(nèi)容，這里不做解析；

繼續(xù)看到00 00 01 bc，這是節(jié)目映射流起始碼；

緊接著的00 1e同樣代表長(zhǎng)度；

跳過e1 ff，基本沒用；

接下來是00 18，代表基本流長(zhǎng)度，說明了后面還有24個(gè)字節(jié)；

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

下一個(gè)字節(jié)e0，意思是視頻流；

接下里00 0c，同樣代表接下的長(zhǎng)度12個(gè)字節(jié)；

跳過這12個(gè)字節(jié)，看到90，這是G.711音頻格式；

下一個(gè)字節(jié)是c0，代表音頻流；

接下來的00 00同樣代表長(zhǎng)度，這里是0；

接下來4個(gè)字節(jié)是CRC，循環(huán)冗余校驗(yàn)。

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

好戲還在后頭呢。

3.4、PES分組頭部

? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?圖9

別被這么長(zhǎng)的圖嚇到，其實(shí)原理相同，但是，你必須處理其中的每一位。

1)????????Packet start code prefix：值為0x000001的位串，它和后面的stream id 構(gòu)成了標(biāo)識(shí)分組開始的分組起始碼，用來標(biāo)志一個(gè)包的開始。

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

3)????????PES packet length：16 位字段，指出了PES 分組中跟在該字段后的字節(jié)數(shù)目。值為0 表示PES 分組長(zhǎng)度要么沒有規(guī)定要么沒有限制。這種情況只允許出現(xiàn)在有效負(fù)載包含來源于傳輸流分組中某個(gè)視頻基本流的字節(jié)的PES 分組中。

4)????????PTS_DTS：2 位字段。當(dāng)值為'10'時(shí)，PTS 字段應(yīng)出現(xiàn)在PES 分組標(biāo)題中；當(dāng)值為'11'時(shí)，PTS 字段和DTS 字段都應(yīng)出現(xiàn)在PES 分組標(biāo)題中；當(dāng)值為'00'時(shí)，PTS 字段和DTS 字段都不出現(xiàn)在PES分組標(biāo)題中。值'01'是不允許的。

5)????????ESCR：1位。置'1'時(shí)表示ESCR 基礎(chǔ)和擴(kuò)展字段出現(xiàn)在PES 分組標(biāo)題中；值為'0'表示沒有ESCR 字段。

6)????????ESrate：1 位。置'1'時(shí)表示ES rate 字段出現(xiàn)在PES 分組標(biāo)題中；值為'0'表示沒有ES rate 字段。

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

8)????????Additionalinfo：1 位。附加版權(quán)信息標(biāo)志字段。置'1'時(shí)表示有附加拷貝信息字段；值為'0'表示沒有該字段。

9)????????CRC：1 位。置'1'時(shí)表示CRC 字段出現(xiàn)在PES 分組標(biāo)題中；值為'0'表示沒有該字段。

10)????Extensionflag：1 位標(biāo)志。置'1'時(shí)表示PES 分組標(biāo)題中有擴(kuò)展字段；值為'0'表示沒有該字段。

PES header data length： 8 位。PES 標(biāo)題數(shù)據(jù)長(zhǎng)度字段。指出包含在PES 分組標(biāo)題中的可選字段和任何填充字節(jié)所占用的總字節(jié)數(shù)。該字段之前的字節(jié)指出了有無可選字段。

老規(guī)矩，上碼流：

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 是幀長(zhǎng)度；

接下來的兩個(gè)80 80見下面的二進(jìn)制解析；

下一個(gè)字節(jié)05指出了可選字段的長(zhǎng)度，前一字節(jié)指出了有無可選字段；

接下來的5字節(jié)是PTS；

第7、8字節(jié)的二進(jìn)制如下：

1000 0000 1000 0000

按順序解析：

第7個(gè)字節(jié)：

10 ? ? ? ? ? ? ? ? ? ? ? ? 是標(biāo)志位，必須是10；

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

0 ? ? ? ? ? ? ? ? ? ? ? ? ? 是優(yōu)先級(jí)，1為高，0為低；

0 ? ? ? ? ? ? ? ? ? ? ? ? ? 是數(shù)據(jù)對(duì)齊指示字段；

0 ? ? ? ? ? ? ? ? ? ? ? ? ? 是版權(quán)字段；

0 ? ? ? ? ? ? ? ? ? ? ? ? ? 是原始或拷貝字段。置'1'時(shí)表示相關(guān)PES分組有效負(fù)載的內(nèi)容是原始的；'0'表示內(nèi)容是一份拷貝；

第8個(gè)字節(jié)：

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

0 ? ? ? ? ? ? ? ? ? ? ? ? ? 是ESCR標(biāo)志字段，這里為0，表示沒有該段；

0 ? ? ? ? ? ? ? ? ? ? ? ? ? 是ES速率標(biāo)志字段，，這里為0，表示沒有該段；

0 ? ? ? ? ? ? ? ? ? ? ? ? ? 是DSM特技方式標(biāo)志字段，，這里為0，表示沒有該段；

0 ? ? ? ? ? ? ? ? ? ? ? ? ? 是附加版權(quán)信息標(biāo)志字段，，這里為0，表示沒有該段；

0 ? ? ? ? ? ? ? ? ? ? ? ? ? 是PESCRC標(biāo)志字段，，這里為0，表示沒有該段；

0 ? ? ? ? ? ? ? ? ? ? ? ? ? 是PES擴(kuò)展標(biāo)志字段，，這里為0，表示沒有該段；

本段碼流只有PTS，貼一下解析函數(shù)

[cpp]?view plaincopy

unsigned?long?parse_time_stamp?(const?unsigned?char?*p)??

{??

????unsigned?long?b;??

????//共33位，溢出后從0開始??

????unsigned?long?val;??

??

????//第1個(gè)字節(jié)的第5、6、7位??

????b?=?*p++;??

????val?=?(b?&?0x0e)?<<?29;??

??

????//第2個(gè)字節(jié)的8位和第3個(gè)字節(jié)的前7位??

????b?=?(*(p++))?<<?8;??

????b?+=?*(p++);??

????val?+=?((b?&?0xfffe)?<<?14);??

??

????//第4個(gè)字節(jié)的8位和第5個(gè)字節(jié)的前7位??

????b?=?(*(p++))?<<?8;??

????b?+=?*(p++);??

????val?+=?((b?&?0xfffe)?>>?1);??

??

????return?val;??

}??

其他字段可參考協(xié)議解析

ps：

遇到00 00 01 bd的，這個(gè)是私有流的標(biāo)識(shí)

ps:

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

寫在后面：

第一次發(fā)原創(chuàng)，在這里感謝 ?@cmengwei ?的無私幫助，提供了很多幫助，非常感謝。

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

《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

請(qǐng)不要跟我要源碼，參考我提供的這些，你足以寫出一個(gè)可以正常運(yùn)行的程序。

授人以魚不如授人以漁。

其他參考：

http://blog.csdn.net/duanbeibei/article/details/1698183

http://blog.csdn.net/wwyyxx26/article/details/15224879

原文：http://blog.csdn.net/chen495810242/article/details/39207305

http://blog.csdn.net/dreamxiang68/article/details/7183889

http://blog.chinaunix.net/uid-23883288-id-3034586.html

http://m.blog.csdn.net/blog/CodeFoxTiger/13767545

http://blog.csdn.net/jefry_xdz/article/details/8461343

http://www.cnblogs.com/foxmin/archive/2012/03/13/2393349.html

總結(jié)

以上是生活随笔為你收集整理的RTP协议全解（H264码流和PS流）的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。