H.264RTP封包原理
阿新 • • 發佈：2019-01-23
前面分別討論了RTP 協議及H.264基本流的結構，那麼如何使用RTP協議來傳輸H.264視訊了?一個有效的辦法就是從H.264視訊中剝離出每個NALU，在每個NALU前新增相應的RTP包頭，然後將包含RTP
包頭和NALU 的資料包傳送出去。下面就從RTP包頭和NALU兩方面分別闡述。
完整的 RTP 固定包頭的格式在前面圖 1 中已經指出，根據RFC3984[3]，這裡詳細給出各個位的具體設定。
V：版本號，2 位。根據RFC3984，目前使用的RTP 版本號應設為0x10。
P：填充位，1 位。當前不使用特殊的加密演算法，因此該位設為 0。
X：擴充套件位，1 位。當前固定頭後面不跟隨頭擴充套件，因此該位也為 0。
CC：CSRC 計數，4 位。表示跟在 RTP 固定包頭後面CSRC 的數目，對於本文所要實現的基本的流媒體伺服器來說，沒有用到混合器，該位也設為 0x0。
M：標示位，1 位。如果當前 NALU為一個接入單元最後的那個NALU，那麼將M位置 1；或者當前RTP 資料包為一個NALU 的最後的那個分片時（NALU 的分片在後面講述），M位置 1。其餘情況下M 位保持為 0。
PT：載荷型別，7 位。對於H.264 視訊格式，當前並沒有規定一個預設的PT 值。因此選用大於 95 的值可以。此處設為0x60（十進位制96）。
SQ：序號，16 位。序號的起始值為隨機值，此處設為 0，每傳送一個RTP 資料包，序號值加 1。
TS：時間戳，32 位。同序號一樣，時間戳的起始值也為隨機值，此處設為0。根據RFC3984，與時間戳相應的時鐘頻率必須為90000HZ。
SSRC：同步源標示，32 位。SSRC應該被隨機生成，以使在同一個RTP會話期中沒有任何兩個同步源具有相同的SSRC 識別符。此處僅有一個同步源，因此將其設為0x12345678。
對於每一個NALU，根據其包含的資料量的不同，其大小也有差異。在IP網路中，當要傳輸的IP 報文大小超過最大傳輸單元MTU（Maximum Transmission Unit ）時就會產生IP分片情況。在乙太網環境中可傳輸的最大 IP 報文（MTU）的大小為 1500 位元組。如果傳送的IP資料包大於MTU，資料包就會被拆開來傳送，這樣就會產生很多資料包碎片，增加丟包率，降低網路速度。對於視訊傳輸而言，若RTP 包大於MTU 而由底層協議任意拆包，可能會導致接收端播放器的延時播放甚至無法正常播放。因此對於大於MTU 的NALU 單元，必須進行拆包處理。
完整的 RTP 固定包頭的格式在前面圖 1 中已經指出，根據RFC3984[3]，這裡詳細給出各個位的具體設定。
V：版本號，2 位。根據RFC3984，目前使用的RTP 版本號應設為0x10。
P：填充位，1 位。當前不使用特殊的加密演算法，因此該位設為 0。
X：擴充套件位，1 位。當前固定頭後面不跟隨頭擴充套件，因此該位也為 0。
CC：CSRC 計數，4 位。表示跟在 RTP 固定包頭後面CSRC 的數目，對於本文所要實現的基本的流媒體伺服器來說，沒有用到混合器，該位也設為 0x0。
M：標示位，1 位。如果當前 NALU為一個接入單元最後的那個NALU，那麼將M位置 1；或者當前RTP 資料包為一個NALU 的最後的那個分片時（NALU 的分片在後面講述），M位置 1。其餘情況下M 位保持為 0。
PT：載荷型別，7 位。對於H.264 視訊格式，當前並沒有規定一個預設的PT 值。因此選用大於 95 的值可以。此處設為0x60（十進位制96）。
SQ：序號，16 位。序號的起始值為隨機值，此處設為 0，每傳送一個RTP 資料包，序號值加 1。
TS：時間戳，32 位。同序號一樣，時間戳的起始值也為隨機值，此處設為0。根據RFC3984，與時間戳相應的時鐘頻率必須為90000HZ。
SSRC：同步源標示，32 位。SSRC應該被隨機生成，以使在同一個RTP會話期中沒有任何兩個同步源具有相同的SSRC 識別符。此處僅有一個同步源，因此將其設為0x12345678。
對於每一個NALU，根據其包含的資料量的不同，其大小也有差異。在IP網路中，當要傳輸的IP 報文大小超過最大傳輸單元MTU（Maximum Transmission Unit ）時就會產生IP分片情況。在乙太網環境中可傳輸的最大 IP 報文（MTU）的大小為 1500 位元組。如果傳送的IP資料包大於MTU，資料包就會被拆開來傳送，這樣就會產生很多資料包碎片，增加丟包率，降低網路速度。對於視訊傳輸而言，若RTP 包大於MTU 而由底層協議任意拆包，可能會導致接收端播放器的延時播放甚至無法正常播放。因此對於大於MTU 的NALU 單元，必須進行拆包處理。