h264 RTP頭解析流程 結合NALDecoder.c分析

協議分析 ：每一個RTP數據報都由頭部（Header）和負載（Payload）兩個部分組成，其中頭部前 12 個字節的含義是固定的，而負載則可以是音頻或者視頻數據。

一個活動順序參數集在一個編碼視頻序列中保持不變,一個活動圖像參數集在一個編碼圖像里保持不變。

?

H.264編碼器必須根據H.264規范設置NRI值(subclause 7.4.1)當nal_unit_type 范圍的是1到12. 特別是,H.264規范， 要求對于nal_unit_type為6，9，10，11，12的NAL單元的NRI的值應該為0。

?

      對于nal_unit_type等于7，8 (指示順序參數集或圖像參數集)的NAL單元,H.264編碼器應該設置NRI為11 (二進制格式）對于nal_unit_type等于5的主編碼圖像的編碼片NAL單元(指示編碼片屬于一個IDR圖像), H.264編碼器應設置NRI為11。

?

打開H264文件，讀取流

找到 NALU 標致startcode，即00 00 01 或 00 00 00 01 串

判斷UALU單元數據段大小，（UDP一次能發送最大數據為64K字節）

使用何種發送方式（單一發送、聚合發送、分片發送）

如果UALU數據＜1500（自己設定），使用單一包發送：

填充RTP頭（12 BYTE），payload(7 bit)：96 marker(1 bit)：0 seq_no(16 bit)：隨機取 timestamp(32 bit)：

第13字節填充NALU頭（startcode 的下一個字節），

如果NALU數據＞1500，使用分片發送：（分三種情況設備：第一次RTP，中間的RTP，最后一次RTP）

填充RTP頭，類似單一包發送，發送整個NALU，timestamp只曾加一次。

不同的是，第13字節填FU INDICATOR，它的type要成28；第14字節才填FU HEADER，

• 第一次RTP：第13 BYTE 是FU INDICATOR ，其中它的TYPE設置成 28 ；第14 BYTE 是 FU HEADER ，S：E：R ＝ 1：0：0，之后才是視頻數據。
• 中間的RTP：第13 BYTE 是FU INDICATOR，其中它的TYPE設置成 28 ；第14 BYTE 是 FU HEADER ，S：E：R ＝ 0：0：0，之后才是視頻數據。
• 最后一次RTP：第13 BYTE 是FU INDICATOR，其中它的TYPE設置成 28 ；第14 BYTE 是 FU HEADER ，S：E：R ＝ 0：1：0，之后才是視頻數據。

NALU數據很小時，用組合封裝：

組合封裝：NALU payload = NALU payload size + NALU payload header + NALU payload data

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

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

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

封裝成 RTP 包可能如下:

[ RTP Header ] [78, STAP-A NAL HDR, 一個字節 ] [長度, 兩個字節] [ 67 42 A0 1E 23 56 0E 2F ...] [長度, 兩個字節] [ 67 42 A0 1E 23 56 0E 2F... ]

---

讀rfc 3984搞混了的幾個TYPE：

• RTP 中的PT 負載類型 Payload type (PT) : 7 bits －－發送H264視頻，此值固定設成 96
• NALU 中的TYPE 描述了NALU的屬性，如：7指示順序參數集，8指示圖像參數集
• RTP之后的TYPE，即13 BYTE開始，單一打包的TYPE，與NALU中的TYPE一樣；FU 分片打包方式，TYPE設成28；

參考：

http://bbs.chinavideo.org/viewthread.php?tid=2451&highlight=rtp%2Bh264

?

http://www.cppblog.com/czanyou/archive/2010/02/09/67940.html#107573