1. 引言
H.264/AVC 是ITU-T 視頻編碼專家組（VCEG）和ISO/IEC 動態圖像專家組（MPEG ）聯合組成的聯合視頻組（JVT）共同努力制訂的新一代視頻編碼標準，它最大的優勢是具有很高的數據壓縮比率，在同等圖像質量的條件下，H.264 的壓縮比是MPEG-2 的2 倍以上,是 MPEG-4的1.5～2 倍。同時，採用視頻編碼層（VCL）和網絡提取層（NAL ）的分層設計，非常適用於流媒體技術進行實時傳輸。本文就是基於 RTP 協議，對 H.264 視頻進行流式打包傳輸，實現了一個基本的流媒體服務器功能，同時利用開源播放器VLC 作爲接收端，構成一個完整的H.264 視頻傳輸系統。
RTP 協議是 IETF 在 1996 年提出的適合實時數據傳輸的新型協議。RTP 協議實際上是由實時傳輸協議RTP（Real-time Transport Protocol）和實時傳輸控制協議RTCP（Real-time Transport Control Protocol）兩部分組成。RTP 協議基於多播或單播網絡爲用戶提供連續媒體數據的實時傳輸服務；RTCP 協議是 RTP 協議的控制部分，用於實時監控數據傳輸質量，爲系統提供擁塞控制和流控制。RTP 協議在RFC3550 中有詳細介紹。每一個 RTP 數據包都由固定包頭（Header ）和載荷（Payload）兩個部分組成，其中包頭前12個字節的含義是固定的，而載荷則可以是音頻或視頻數據。RTP 固定包頭的格式如圖1所示：
（1）標示位（M ）：1 位，該標示位的含義一般由具體的媒體應用框架（profile ）定義， 目的在於標記處RTP 流中的重要事件。
（3）序號:16 位，每發送一個 RTP 數據包，序號加 1。接受者可以用它來檢測分組丟失和恢復分組順序。
從 RTP 數據包的格式不難看出，它包含了傳輸媒體的類型、格式、序列號、時間戳以及是否有附加數據等信息。這些都爲實時的流媒體傳輸提供了相應的基礎。而傳輸控制協議RTCP爲 RTP傳輸提供了擁塞控制和流控制，它的具體包結構和各字段的含義可參考RFC3550，此處不再贅述。
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，以便接收方丟掉該單元。
Type：5 位，指出NALU 的類型。具體如表1 所示：
![]()
需要特別指出的是，NRI
值爲 7 和 8 的NALU 分別爲序列參數集（sps）和圖像參數集（pps）。參數集是一組很少改變的，爲大量VCL NALU 提供解碼信息的數據。其中序列參數集作用於一系列連續的編碼圖像，而圖像參數集作用於編碼視頻序列中一個或多個獨立的圖像。如果解碼器沒能正確接收到這兩個參數集，那麼其他NALU 也是無法解碼的。因此它們一般在發送其它 NALU 之前發送，並且使用不同的信道或者更加可靠的傳輸協議（如TCP）進行傳輸，也可以重複傳輸。
3.2 適用於 H.264 視頻的傳輸機制
完整的 RTP 固定包頭的格式在前面圖 1 中已經指出，根據RFC3984[3]，這裏詳細給出各個位的具體設置。
P：填充位，1 位。當前不使用特殊的加密算法，因此該位設爲 0。
CC：CSRC 計數，4 位。表示跟在 RTP 固定包頭後面CSRC 的數目，對於本文所要實現的基本的流媒體服務器來說，沒有用到混合器，該位也設爲 0x0。
PT：載荷類型，7 位。對於H.264 視頻格式，當前並沒有規定一個默認的PT 值。因此選用大於 95 的值可以。此處設爲0x60（十進制96）。
TS：時間戳，32 位。同序號一樣，時間戳的起始值也爲隨機值，此處設爲0。根據RFC3984， 與時間戳相應的時鐘頻率必須爲90000HZ。
對於每一個NALU，根據其包含的數據量的不同，其大小也有差異。在IP網絡中，當要傳輸的IP 報文大小超過最大傳輸單元MTU（Maximum Transmission Unit ）時就會產生IP分片情況。在以太網環境中可傳輸的最大 IP 報文（MTU）的大小爲 1500 字節。如果發送的IP數據包大於MTU，數據包就會被拆開來傳送，這樣就會產生很多數據包碎片，增加丟包率，降低網絡速度。對於視頻傳輸而言，若RTP 包大於MTU 而由底層協議任意拆包，可能會導致接收端播放器的延時播放甚至無法正常播放。因此對於大於MTU 的NALU 單元，必須進行拆包處理。
（1）Single NALU Packet:在一個RTP 包中只封裝一個NALU，在本文中對於小於 1400字節的NALU 便採用這種打包方案。
H.264/AVC 是ITU-T 視頻編碼專家組（VCEG）和ISO/IEC 動態圖像專家組（MPEG ）聯合組成的聯合視頻組（JVT）共同努力制訂的新一代視頻編碼標準，它最大的優勢是具有很高的數據壓縮比率，在同等圖像質量的條件下，H.264 的壓縮比是MPEG-2 的2 倍以上,是 MPEG-4的1.5～2 倍。同時，採用視頻編碼層（VCL）和網絡提取層（NAL ）的分層設計，非常適用於流媒體技術進行實時傳輸。本文就是基於 RTP 協議，對 H.264 視頻進行流式打包傳輸，實現了一個基本的流媒體服務器功能，同時利用開源播放器VLC 作爲接收端，構成一個完整的H.264 視頻傳輸系統。
RTP 協議是 IETF 在 1996 年提出的適合實時數據傳輸的新型協議。RTP 協議實際上是由實時傳輸協議RTP（Real-time Transport Protocol）和實時傳輸控制協議RTCP（Real-time Transport Control Protocol）兩部分組成。RTP 協議基於多播或單播網絡爲用戶提供連續媒體數據的實時傳輸服務；RTCP 協議是 RTP 協議的控制部分，用於實時監控數據傳輸質量，爲系統提供擁塞控制和流控制。RTP 協議在RFC3550 中有詳細介紹。每一個 RTP 數據包都由固定包頭（Header ）和載荷（Payload）兩個部分組成，其中包頭前12個字節的含義是固定的，而載荷則可以是音頻或視頻數據。RTP 固定包頭的格式如圖1所示：
（1）標示位（M ）：1 位，該標示位的含義一般由具體的媒體應用框架（profile ）定義， 目的在於標記處RTP 流中的重要事件。
（3）序號:16 位，每發送一個 RTP 數據包，序號加 1。接受者可以用它來檢測分組丟失和恢復分組順序。
從 RTP 數據包的格式不難看出，它包含了傳輸媒體的類型、格式、序列號、時間戳以及是否有附加數據等信息。這些都爲實時的流媒體傳輸提供了相應的基礎。而傳輸控制協議RTCP爲 RTP傳輸提供了擁塞控制和流控制，它的具體包結構和各字段的含義可參考RFC3550，此處不再贅述。
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，以便接收方丟掉該單元。
Type：5 位，指出NALU 的類型。具體如表1 所示：
需要特別指出的是，NRI
值爲 7 和 8 的NALU 分別爲序列參數集（sps）和圖像參數集（pps）。參數集是一組很少改變的，爲大量VCL NALU 提供解碼信息的數據。其中序列參數集作用於一系列連續的編碼圖像，而圖像參數集作用於編碼視頻序列中一個或多個獨立的圖像。如果解碼器沒能正確接收到這兩個參數集，那麼其他NALU 也是無法解碼的。因此它們一般在發送其它 NALU 之前發送，並且使用不同的信道或者更加可靠的傳輸協議（如TCP）進行傳輸，也可以重複傳輸。3.2 適用於 H.264 視頻的傳輸機制
完整的 RTP 固定包頭的格式在前面圖 1 中已經指出，根據RFC3984[3]，這裏詳細給出各個位的具體設置。
P：填充位，1 位。當前不使用特殊的加密算法，因此該位設爲 0。
CC：CSRC 計數，4 位。表示跟在 RTP 固定包頭後面CSRC 的數目，對於本文所要實現的基本的流媒體服務器來說，沒有用到混合器，該位也設爲 0x0。
PT：載荷類型，7 位。對於H.264 視頻格式，當前並沒有規定一個默認的PT 值。因此選用大於 95 的值可以。此處設爲0x60（十進制96）。
TS：時間戳，32 位。同序號一樣，時間戳的起始值也爲隨機值，此處設爲0。根據RFC3984， 與時間戳相應的時鐘頻率必須爲90000HZ。
對於每一個NALU，根據其包含的數據量的不同，其大小也有差異。在IP網絡中，當要傳輸的IP 報文大小超過最大傳輸單元MTU（Maximum Transmission Unit ）時就會產生IP分片情況。在以太網環境中可傳輸的最大 IP 報文（MTU）的大小爲 1500 字節。如果發送的IP數據包大於MTU，數據包就會被拆開來傳送，這樣就會產生很多數據包碎片，增加丟包率，降低網絡速度。對於視頻傳輸而言，若RTP 包大於MTU 而由底層協議任意拆包，可能會導致接收端播放器的延時播放甚至無法正常播放。因此對於大於MTU 的NALU 單元，必須進行拆包處理。
（1）Single NALU Packet:在一個RTP 包中只封裝一個NALU，在本文中對於小於 1400字節的NALU 便採用這種打包方案。
（3）Fragmentation Unit:一個NALU 封裝在多個RTP包中，在本文中，對於大於1400字節的NALU 便採用這種方案進行拆包處理。
