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

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


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


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

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