H264 RTP封包原理

1. 引言

2. rtp 協議關鍵引數的設定

其中比較關鍵的引數設定解釋如下：

（1）標示位（m ）：1 位，該標示位的含義一般由具體的**應用框架（profile ）定義，目的在於標記處rtp 流中的重要事件。

（3）序號:16 位，每傳送乙個 rtp 資料報，序號加 1。接受者可以用它來檢測分組丟失和恢復分組順序。

（4）時間戳：32 位，時間戳表示了 rtp 資料分組中第乙個位元組的取樣時間，反映出各rtp 包相對於時間戳初始值的偏差。對於rtp 傳送端而言，取樣時間必須**於乙個線性單調遞增的時鐘。

從 rtp 資料報的格式不難看出，它包含了傳輸**的型別、格式、序列號、時間戳以及是否有附加資料等資訊。這些都為實時的流**傳輸提供了相應的基礎。而傳輸控制協議rtcp為 rtp傳輸提供了擁塞控制和流控制，它的具體包結構和各字段的含義可參考rfc3550，此處不再贅述。

3. h.264 基本流結構及其傳輸機制

3.1 h.264 基本流的結構

h.264 的基本流由一系列nalu （network abstraction layer unit ）組成，不同的nalu資料量各不相同。h.264 草案指出[2]，當資料流是儲存在介質上時，在每個nalu 前新增起始碼：0x000001，用來指示乙個 nalu的起始和終止位置。在這樣的機制下，解碼器在碼流中檢測起始碼，作為乙個nalu得起始標識，當檢測到下乙個起始碼時，當前nalu結束。每個 nalu單元由乙個位元組的 nalu頭（nalu header）和若干個位元組的載荷資料（rbsp）組成。其中nalu 頭的格式如圖2 所示：

f：forbidden_zero_bit.1 位，如果有語法衝突，則為 1。當網路識別此單元存在位元錯誤時，可將其設為 1，以便接收方丟掉該單元。

nri：nal_ref_idc.2 位，用來指示該nalu 的重要性等級。值越大，表示當前nalu越重要。具體大於0 時取何值，沒有具體規定。

type：5 位，指出nalu 的型別。具體如表1 所示：

完整的 rtp 固定包頭的格式在前面圖 1 中已經指出，根據rfc3984[3]，這裡詳細給出各個位的具體設定。

v：版本號，2 位。根據rfc3984，目前使用的rtp 版本號應設為0x10。

p：填充位，1 位。當前不使用特殊的加密演算法，因此該位設為 0。

x：擴充套件位，1 位。當前固定頭後面不跟隨頭擴充套件，因此該位也為 0。

m：標示位，1 位。如果當前 nalu為乙個接入單元最後的那個nalu，那麼將m位置 1；或者當前rtp 資料報為乙個nalu 的最後的那個分片時（nalu 的分片在後面講述），m位置 1。其餘情況下m 位保持為 0。

sq：序號，16 位。序號的起始值為隨機值，此處設為 0，每傳送乙個rtp 資料報，序號值加 1。

ts：時間戳，32 位。同序號一樣，時間戳的起始值也為隨機值，此處設為0。根據rfc3984，與時間戳相應的時鐘頻率必須為90000hz。

ssrc：同步源標示，32 位。ssrc應該被隨機生成，以使在同乙個rtp會話期中沒有任何兩個同步源具有相同的ssrc 識別符。此處僅有乙個同步源，因此將其設為0x12345678。

rfc3984 給出了3 中不同的rtp 打包方案：

（1）single nalu packet:在乙個rtp 包中只封裝乙個nalu，在本文中對於小於 1400位元組的nalu 便採用這種打包方案。

（2）aggregation packet:在乙個rtp 包中封裝多個nalu，對於較小的nalu 可以採用這種打包方案，從而提高傳輸效率。

（3）fragmentation unit:乙個nalu 封裝在多個rtp包中，在本文中，對於大於1400位元組的nalu 便採用這種方案進行拆包處理。

頂 0 踩

H264 RTP封包原理

H 264RTP封包原理

H264 RTP封包原理

對H264進行RTP封包原理

H264 RTP封包原理

H 264RTP封包原理

H264 RTP封包原理

對H264進行RTP封包原理

相關推薦