實作RTP協定的H.264視訊傳輸系統

<b>1.  </b><b>引言 </b>

       <b>随着資訊産業的發展，人們對資訊資源的要求已經逐漸由文字和圖檔過渡到音頻和視訊，并越來越強調擷取資源的實時性和互動性。但人們又面臨着另外一種不可避免的尴尬，就是在網絡上看到生動清晰的媒體示範的同時，不得不為等待傳輸檔案而花費大量時間。為了解決這個沖突，一種新的媒體技術應運而生，這就是流媒體技術。流媒體由于具有啟動時延小、節省用戶端存儲空間等優勢，逐漸成為人們的首選，流媒體網絡應用也在全球範圍内得到不斷的發展。其中實時流傳輸協定 RTP 詳細說明了在網際網路上傳遞音頻和視訊的标準資料包格式，它與傳輸控制協定 RTCP 配合使用，成為流媒體技術最普遍采用的協定之一。 </b>

       <b> 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 視訊傳輸系統。</b>

<b>2.  RTP 協定關鍵參數的設定</b>

<b>         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所示： </b>

<a target="_blank" href="http://blog.51cto.com/attachment/201012/135522796.jpg"></a>

<b>       其中比較關鍵的參數設定解釋如下： </b>

      （1）标示位（M ）：1 位，該标示位的含義一般由具體的媒體應用架構（profile ）定義， 目的在于标記處RTP 流中的重要事件。

      （2）載荷類型（PT）：7 位，用來指出RTP負載的具體格式。在RFC3551中，對常用的音視訊格式的RTP 傳輸載荷類型做了預設的取值規定，例如，類型2 表明該RTP資料包中承載的是用ITU G.721 算法編碼的語音資料，采用頻率為 8000HZ，并且采用單聲道。 

      （3）序号:16 位，每發送一個 RTP 資料包，序号加 1。接受者可以用它來檢測分組丢失和恢複分組順序。

      （4）時間戳：32 位，時間戳表示了 RTP 資料分組中第一個位元組的采樣時間，反映出各RTP 包相對于時間戳初始值的偏差。對于RTP 發送端而言，采樣時間必須來源于一個線性單調遞增的時鐘。 

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

<b>3.  H.264 基本流結構及其傳輸機制</b>

<b>3.1  H.264 基本流的結構</b>

<b>H.264 的基本流（elementary stream,ES）的結構分為兩層，包括視訊編碼層（VCL）和網絡适配層（NAL）。視訊編碼層負責高效的視訊内容表示，而網絡适配層負責以網絡所要求的恰當的方式對資料進行打包和傳送。引入NAL并使之與VCL分離帶來的好處包括兩方面：其一、使信号處理和網絡傳輸分離，VCL 和NAL 可以在不同的處理平台上實作；其二、VCL 和NAL 分離設計，使得在不同的網絡環境内，網關不需要因為網絡環境不同而對VCL比特流進行重構和重編碼。</b>

       H.264 的基本流由一系列NALU （Network Abstraction Layer Unit ）組成，不同的NALU資料量各不相同。H.264 草案指出[2]，當資料流是儲存在媒體上時，在每個NALU 前添加起始碼：0x000001，用來訓示一個 NALU的起始和終止位置。在這樣的機制下，解碼器在碼流中檢測起始碼，作為一個NALU得起始辨別，當檢測到下一個起始碼時，目前NALU結束。每個NALU單元由一個位元組的 NALU頭（NALU Header）和若幹個位元組的載荷資料（RBSP）組成。其中NALU 頭的格式如圖2 所示：

<a target="_blank" href="http://blog.51cto.com/attachment/201012/135620566.jpg"></a>

<b>        F：forbidden_zero_bit.1 位，如果有文法沖突，則為 1。當網絡識别此單元存在比特錯誤時，可将其設為 1，以便接收方丢掉該單元。 </b>

        NRI：nal_ref_idc.2 位，用來訓示該NALU 的重要性等級。值越大，表示目前NALU越重要。具體大于0 時取何值，沒有具體規定。

<b> Type：5 位，指出NALU 的類型。具體如表1 所示：</b>

<a target="_blank" href="http://blog.51cto.com/attachment/201012/135709960.jpg"></a>

<b>       需要特别指出的是，NRI 值為 7 和 8 的NALU 分别為序列參數集（sps）和圖像參數集（pps）。參數集是一組很少改變的，為大量VCL NALU 提供解碼資訊的資料。其中序列參數集作用于一系列連續的編碼圖像，而圖像參數集作用于編碼視訊序列中一個或多個獨立的圖像。如果解碼器沒能正确接收到這兩個參數集，那麼其他NALU 也是無法解碼的。是以它們一般在發送其它 NALU 之前發送，并且使用不同的信道或者更加可靠的傳輸協定（如TCP）進行傳輸，也可以重複傳輸。</b>

<b>3.2  适用于 H.264 視訊的傳輸機制 </b>

       <b>前面分别讨論了RTP 協定及H.264基本流的結構，那麼如何使用RTP協定來傳輸H.264視訊了?一個有效的辦法就是從H.264視訊中剝離出每個NALU，在每個NALU前添加相應的RTP標頭，然後将包含RTP 標頭和NALU 的資料包發送出去。下面就從RTP標頭和NALU兩方面分别闡述。 </b>

      完整的 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 單元，必須進行拆包處理。

<b>RFC3984 給出了3 中不同的RTP 打包方案：</b>

<b>（1）Single NALU Packet:在一個RTP 包中隻封裝一個NALU，在本文中對于小于 1400位元組的NALU 便采用這種打包方案。 </b>

       （2）Aggregation Packet:在一個RTP 包中封裝多個NALU，對于較小的NALU 可以采用這種打包方案，進而提高傳輸效率。 

       （3）Fragmentation Unit:一個NALU 封裝在多個RTP包中，在本文中，對于大于1400位元組的NALU 便采用這種方案進行拆包處理。 

<b>4.  H.264 流媒體傳輸系統的實作</b>

<b>       一個完整的流媒體傳輸系統包含伺服器端和用戶端兩個部分[5][6]。對于伺服器端，其主要任務是讀取H.264 視訊，從碼流中分離出每個NALU 單元，分析NALU 的類型，設定相應的 RTP 標頭，封裝 RTP 資料包并發送。而對于用戶端來說，其主要任務則是接收 RTP資料包，從RTP 包中解析出NALU 單元，然後送至解碼器進行解碼播放。該流媒體傳輸系統的架構如圖3 所示。</b>

<a target="_blank" href="http://blog.51cto.com/attachment/201012/135853195.jpg"></a>

<b>5. 結論</b>

<b>本文所設計的流媒體傳輸系統伺服器端運作在Windows XP 系統，用VLC 播放器作為用戶端接收H.264 視訊RTP 資料包。經測試，用戶端在經過2 秒的緩沖過後即能流暢播放,傳輸速度設為 30 幀每秒的情況下，未出現丢包拖影等現象，視訊主觀品質良好，與本地播放該H.264 視訊無明顯差別。</b>

<b>AnyChat采用國際領先的視訊編碼标準H.264（MPEG-4 part 10 AVC /H.264）編碼，H.264/AVC 在壓縮效率方面有着特殊的表現，一般情況下達到 MPEG-2 及 MPEG-4 簡化類壓縮效率的大約 2 倍。H.264具有許多與舊标準不同的新功能，它們一起實作了編碼效率的提高。特别是在幀内預測與編碼、幀間預測與編碼、可變矢量塊大小、四分之一像素運動估計、多參考幀預測、自适應環路去塊濾波器、整數變換、量化與變換系數掃描、熵編碼、權重預測等實作上都有其獨特的考慮。</b>

<b></b>

本文轉自 fanxiaojun 51CTO部落格，原文連結：http://blog.51cto.com/2343338/455056，如需轉載請自行聯系原作者