1.  引言 
       隨著信息產(chǎn)業(yè)的發(fā)展，人們對信息資源的要求已經(jīng)逐漸由文字和圖片過渡到音頻和視頻，并越來越強調獲取資源的實時性和互動性。但人們又面臨著另外一種不可避 免的尷尬，就是在網(wǎng)絡上看到生動清晰的媒體演示的同時，不得不為等待傳輸文件而花費大量時間。為了解決這個矛盾，一種新的媒體技術應運而生，這就是流媒體 技術。流媒體由于具有啟動時延小、節(jié)省客戶端存儲空間等優(yōu)勢，逐漸成為人們的首選，流媒體網(wǎng)絡應用也在全球范圍內得到不斷的發(fā)展。其中實時流傳輸協(xié)議 RTP 詳細說明了在互聯(lián)網(wǎng)上傳遞音頻和視頻的標準數(shù)據(jù)包格式，它與傳輸控制協(xié)議 RTCP 配合使用，成為流媒體技術最普遍采用的協(xié)議之一。 
        H.264/AVC 是ITU-T 視頻編碼專家組（VCEG）和ISO/IEC 動態(tài)圖像專家組（MPEG ）聯(lián)合組成的聯(lián)合視頻組（JVT）共同努力制訂的新一代視頻編碼標準，它最大的優(yōu)勢是具有很高的數(shù)據(jù)壓縮比率，在同等圖像質量的條件下，H.264 的壓縮比是MPEG-2 的2 倍以上,是 MPEG-4的1.5～2 倍。同時，采用視頻編碼層（VCL）和網(wǎng)絡提取層（NAL ）的分層設計，非常適用于流媒體技術進行實時傳輸。本文就是基于 RTP 協(xié)議，對 H.264 視頻進行流式打包傳輸，實現(xiàn)了一個基本的流媒體服務器功能，同時利用開源播放器VLC 作為接收端，構成一個完整的H.264 視頻傳輸系統(tǒng)。
2.  RTP 協(xié)議關鍵參數(shù)的設置
         RTP 協(xié)議是 IETF 在 1996 年提出的適合實時數(shù)據(jù)傳輸?shù)男滦蛥f(xié)議。RTP 協(xié)議實際上是由實時傳輸協(xié)議RTP（Real-time Transport Protocol）和實時傳輸控制協(xié)議RTCP（Real-time Transport Control Protocol）兩部分組成。RTP 協(xié)議基于多播或單播網(wǎng)絡為用戶提供連續(xù)媒體數(shù)據(jù)的實時傳輸服務；RTCP 協(xié)議是 RTP 協(xié)議的控制部分，用于實時監(jiān)控數(shù)據(jù)傳輸質量，為系統(tǒng)提供擁塞控制和流控制。RTP 協(xié)議在RFC3550 中有詳細介紹。每一個 RTP 數(shù)據(jù)包都由固定包頭（Header ）和載荷（Payload）兩個部分組成，其中包頭前12個字節(jié)的含義是固定的，而載荷則可以是音頻或視頻數(shù)據(jù)。RTP 固定包頭的格式如圖1所示： 

       其中比較關鍵的參數(shù)設置解釋如下： 
      （1）標示位（M ）：1 位，該標示位的含義一般由具體的媒體應用框架（profile ）定義， 目的在于標記處RTP 流中的重要事件。
      （2）載荷類型（PT）：7 位，用來指出RTP負載的具體格式。在RFC3551中，對常用的音視頻格式的RTP 傳輸載荷類型做了默認的取值規(guī)定，例如，類型2 表明該RTP數(shù)據(jù)包中承載的是用ITU G.721 算法編碼的語音數(shù)據(jù)，采用頻率為 8000HZ，并且采用單聲道。 
      （3）序號:16 位，每發(fā)送一個 RTP 數(shù)據(jù)包，序號加 1。接受者可以用它來檢測分組丟失和恢復分組順序。
      （4）時間戳：32 位，時間戳表示了 RTP 數(shù)據(jù)分組中第一個字節(jié)的采樣時間，反映出各RTP 包相對于時間戳初始值的偏差。對于RTP 發(fā)送端而言，采樣時間必須來源于一個線性單調遞增的時鐘。 
       從 RTP 數(shù)據(jù)包的格式不難看出，它包含了傳輸媒體的類型、格式、序列號、時間戳以及是否有附加數(shù)據(jù)等信息。這些都為實時的流媒體傳輸提供了相應的基礎。而傳輸控制 協(xié)議RTCP為 RTP傳輸提供了擁塞控制和流控制，它的具體包結構和各字段的含義可參考RFC3550，此處不再贅述。 
3.  H.264 基本流結構及其傳輸機制
3.1  H.264 基本流的結構
H.264 的基本流（elementary stream,ES）的結構分為兩層，包括視頻編碼層（VCL）和網(wǎng)絡適配層（NAL）。視頻編碼層負責高效的視頻內容表示，而網(wǎng)絡適配層負責以網(wǎng)絡所要 求的恰當?shù)姆绞綄?shù)據(jù)進行打包和傳送。引入NAL并使之與VCL分離帶來的好處包括兩方面：其一、使信號處理和網(wǎng)絡傳輸分離，VCL 和NAL 可以在不同的處理平臺上實現(xiàn)；其二、VCL 和NAL 分離設計，使得在不同的網(wǎng)絡環(huán)境內，網(wǎng)關不需要因為網(wǎng)絡環(huán)境不同而對VCL比特流進行重構和重編碼。
       H.264 的基本流由一系列NALU （Network Abstraction Layer Unit ）組成，不同的NALU數(shù)據(jù)量各不相同。H.264 草案指出[2]，當數(shù)據(jù)流是儲存在介質上時，在每個NALU 前添加起始碼：0x000001，用來指示一個 NALU的起始和終止位置。在這樣的機制下，解碼器在碼流中檢測起始碼，作為一個NALU得起始標識，當檢測到下一個起始碼時，當前NALU結束。每個 NALU單元由一個字節(jié)的 NALU頭（NALU Header）和若干個字節(jié)的載荷數(shù)據(jù)（RBSP）組成。其中NALU 頭的格式如圖2 所示：


        F：forbidden_zero_bit.1 位，如果有語法沖突，則為 1。當網(wǎng)絡識別此單元存在比特錯誤時，可將其設為 1，以便接收方丟掉該單元。 
        NRI：nal_ref_idc.2 位，用來指示該NALU 的重要性等級。值越大，表示當前NALU越重要。具體大于0 時取何值，沒有具體規(guī)定。
Type：5 位，指出NALU 的類型。具體如表1 所示：


       需要特別指出的是，NRI 值為 7 和 8 的NALU 分別為序列參數(shù)集（sps）和圖像參數(shù)集（pps）。參數(shù)集是一組很少改變的，為大量VCL NALU 提供解碼信息的數(shù)據(jù)。其中序列參數(shù)集作用于一系列連續(xù)的編碼圖像，而圖像參數(shù)集作用于編碼視頻序列中一個或多個獨立的圖像。如果解碼器沒能正確接收到這兩 個參數(shù)集，那么其他NALU 也是無法解碼的。因此它們一般在發(fā)送其它 NALU 之前發(fā)送，并且使用不同的信道或者更加可靠的傳輸協(xié)議（如TCP）進行傳輸，也可以重復傳輸。

3.2  適用于 H.264 視頻的傳輸機制 
       前面分別討論了RTP 協(xié)議及H.264基本流的結構，那么如何使用RTP協(xié)議來傳輸H.264視頻了?一個有效的辦法就是從H.264視頻中剝離出每個NALU，在每個 NALU前添加相應的RTP包頭，然后將包含RTP 包頭和NALU 的數(shù)據(jù)包發(fā)送出去。下面就從RTP包頭和NALU兩方面分別闡述。 
      完整的 RTP 固定包頭的格式在前面圖 1 中已經(jīng)指出，根據(jù)RFC3984[3]，這里詳細給出各個位的具體設置。 
      V：版本號，2 位。根據(jù)RFC3984，目前使用的RTP 版本號應設為0x10。 
      P：填充位，1 位。當前不使用特殊的加密算法，因此該位設為 0。 
      X：擴展位，1 位。當前固定頭后面不跟隨頭擴展，因此該位也為 0。 
      CC：CSRC 計數(shù)，4 位。表示跟在 RTP 固定包頭后面CSRC 的數(shù)目，對于本文所要實現(xiàn)的基本的流媒體服務器來說，沒有用到混合器，該位也設為 0x0。 
       M：標示位，1 位。如果當前 NALU為一個接入單元最后的那個NALU，那么將M位置 1；或者當前RTP 數(shù)據(jù)包為一個NALU 的最后的那個分片時（NALU 的分片在后面講述），M位置 1。其余情況下M 位保持為 0。 
       PT：載荷類型，7 位。對于H.264 視頻格式，當前并沒有規(guī)定一個默認的PT 值。因此選用大于 95 的值可以。此處設為0x60（十進制96）。 
      SQ：序號，16 位。序號的起始值為隨機值，此處設為 0，每發(fā)送一個RTP 數(shù)據(jù)包，序號值加 1。 
      TS：時間戳，32 位。同序號一樣，時間戳的起始值也為隨機值，此處設為0。根據(jù)RFC3984， 與時間戳相應的時鐘頻率必須為90000HZ。 
      SSRC：同步源標示，32 位。SSRC應該被隨機生成，以使在同一個RTP會話期中沒有任何兩個同步源具有相同的SSRC 識別符。此處僅有一個同步源，因此將其設為0x12345678。
      對于每一個NALU，根據(jù)其包含的數(shù)據(jù)量的不同，其大小也有差異。在IP網(wǎng)絡中，當要傳輸?shù)腎P 報文大小超過最大傳輸單元MTU（Maximum Transmission Unit ）時就會產(chǎn)生IP分片情況。在以太網(wǎng)環(huán)境中可傳輸?shù)淖畲?IP 報文（MTU）的大小為 1500 字節(jié)。如果發(fā)送的IP數(shù)據(jù)包大于MTU，數(shù)據(jù)包就會被拆開來傳送，這樣就會產(chǎn)生很多數(shù)據(jù)包碎片，增加丟包率，降低網(wǎng)絡速度。對于視頻傳輸而言，若RTP 包大于MTU 而由底層協(xié)議任意拆包，可能會導致接收端播放器的延時播放甚至無法正常播放。因此對于大于MTU 的NALU 單元，必須進行拆包處理。
RFC3984 給出了3 中不同的RTP 打包方案：
（1）Single NALU Packet:在一個RTP 包中只封裝一個NALU，在本文中對于小于 1400字節(jié)的NALU 便采用這種打包方案。 
       （2）Aggregation Packet:在一個RTP 包中封裝多個NALU，對于較小的NALU 可以采用這種打包方案，從而提高傳輸效率。 
       （3）Fragmentation Unit:一個NALU 封裝在多個RTP包中，在本文中，對于大于1400字節(jié)的NALU 便采用這種方案進行拆包處理。