Linux下的即時資料流媒體編程(RTP,RTCP,RTSP)

  流媒體指的是在網路中使用流技術傳輸的連續時基媒體，其特點是在播放前不需要下載整個檔案，而是採用邊下載邊播放的方式，它是視頻會議、IP電話等應用場合的技術基礎。RTP是進行即時資料流媒體傳輸的標準協議和關鍵技術，本文介紹如何在Linux下利用JRTPLIB進行即時資料流媒體編程。

一、流媒體簡介
     隨著Internet的日益普及，在網路上傳輸的資料已經不再局限於文字和圖形，而是逐漸向聲音和視頻等多媒體格式過渡。目前在網路上傳輸音頻/視頻（Audio/Video，簡稱A/V）等多媒體檔案時，基本上只有下載和串流兩種選擇。通常說來，A/V檔案佔據的儲存空間都比較大，在頻寬受限的網路環境中下載可能要耗費數分鐘甚至數小時，所以這種處理方法的延遲很大。如果換用串流的話，聲音、影像、動畫等多媒體檔案將由專門的流媒體伺服器負責向使用者連續、即時地發送，這樣使用者可以不必等到整個檔案全部下載完畢，而只需要經過幾秒鐘的啟動延時就可以了，當這些多媒體資料在客戶機上播放時，檔案的剩餘部分將繼續從流媒體伺服器下載。
       流（Streaming）是近年在Internet上出現的新概念，其定義非常廣泛，主要是指通過網路傳輸多媒體資料的技術總稱。流媒體包含廣義和狹義兩種內涵：廣義上的流媒體指的是使音頻和視頻形成穩定和連續的傳輸串流和回放流的一系列技術、方法和協議的總稱，即流媒體技術；狹義上的流媒體是相對於傳統的下載-回放方式而言的，指的是一種從Internet上擷取音頻和視頻等多媒體資料的新方法，它能夠支援多媒體資料流的即時傳輸和即時播放。通過運用流媒體技術，伺服器能夠向客戶機發送穩定和連續的多媒體資料流，客戶機在接收資料的同時以一個穩定的速率回放，而不用等資料全部下載完之後再進行回放。由於受網路頻寬、電腦處理能力和協議規範等方面的限制，要想從Internet上下載大量的音頻和視頻資料，無論從下載時間和儲存空間上來講都是不太現實的，而流媒體技術的出現則很好地解決了這一難題。目前實現流媒體傳輸主要有兩種方法：順序流（progressive
streaming）傳輸和即時資料流（realtime streaming）傳輸，它們分別適合於不同的應用場合。

順序流傳輸 
      順序流傳輸採用順序下載的方式進行傳輸，在下載的同時使用者可以線上回放多媒體資料，但給定時刻只能觀看已經下載的部分，不能跳到尚未下載的部分，也不能在傳輸期間根據網路狀況對下載速度進行調整。由於標準的HTTP伺服器就可以發送這種形式的流媒體，而不需要其他特殊協議的支援，因此也常常被稱作HTTP串流。順序串流比較適合於高品質的多媒體片段，如標題、片尾或者廣告等。

即時資料流傳輸 
      即時資料流式傳輸保證媒體訊號頻寬能夠與當前網路狀況相匹配，從而使得流媒體資料總是被即時地傳送，因此特別適合於現場事件。即時資料流傳輸支援隨機訪問，即使用者可以通過快進或者後退操作來觀看前面或者後面的內容。從理論上講，即時資料流媒體一經播放就不會停頓，但事實上仍有可能發生周期性的暫停現象，尤其是在網路狀況惡化時更是如此。與順序流傳輸不同的是，即時資料流傳輸需要用到特定的流媒體伺服器，而且還需要特定網路通訊協定的支援。

二、流媒體協議
      即時傳輸協議（Real-time Transport Protocol，PRT）是在Internet上處理多媒體資料流的一種網路通訊協定，利用它能夠在一對一（unicast，單播）或者一對多（multicast，多播）的網路環境中實現傳流媒體資料的即時傳輸。RTP通常使用UDP來進行多媒體資料的傳輸，但如果需要的話可以使用TCP或者ATM等其它協議，整個RTP協議由兩個密切相關的部分組成：RTP資料協議和RTP控制協議。即時資料流通訊協定（Real
Time Streaming Protocol，RTSP）最早由Real Networks和Netscape公司共同提出，它位於RTP和RTCP之上，其目的是希望通過IP網路有效地傳輸多媒體資料。

2.1 RTP資料協議 
      RTP資料協議負責對流媒體資料進行封包並實現媒體流的即時傳輸，每一個RTP資料報都由頭部（Header）和負載（Payload）兩個部分組成，其中頭部前12個位元組的含義是固定的，而負載則可以是音頻或者視頻資料。RTP資料報的頭部格式1所示：

      其中比較重要的幾個域及其意義如下： 
      CSRC記數（CC）　　表示CSRC標識的數目。CSRC標識緊跟在RTP固定頭部之後，用來表示RTP資料報的來源，RTP協議允許在同一個會話中存在多個資料來源，它們可以通過RTP混合器合并為一個資料來源。例如，可以產生一個CSRC列表來表示一個電話會議，該會議通過一個RTP混合器將所有講話者的語音資料群組合為一個RTP資料來源。 
      負載類型（PT）　　標明RTP負載的格式，包括所採用的編碼演算法、採樣頻率、承載通道等。例如，類型2表明該RTP資料包中承載的是用ITU G.721演算法編碼的語音資料，採樣頻率為8000Hz，並且採用單聲道。 
      序號　　用來為接收方提供探測資料丟失的方法，但如何處理丟失的資料則是應用程式自己的事情，RTP協議本身並不負責資料的重傳。 
      時間戳記　　記錄了負載中第一個位元組的採樣時間，接收方能夠時間戳記能夠確定資料的到達是否受到了延遲抖動的影響，但具體如何來補償延遲抖動則是應用程式自己的事情。 從RTP資料報的格式不難看出，它包含了傳輸媒體的類型、格式、序號、時間戳記以及是否有附加資料等資訊，這些都為即時的流媒體傳輸提供了相應的基礎。RTP協議的目的是提供即時資料（如互動音頻和視頻）的端到端傳輸服務，因此在RTP中沒有串連的概念，它可以建立在底層的連線導向或面向非串連的傳輸協議之上；RTP也不依賴於特別的網路地址格式，而僅僅只需要底層傳輸協議支援組幀（Framing）和分段（Segmentation）就足夠了；另外RTP本身還不提供任何可靠性機制，這些都要由傳輸協議或者應用程式自己來保證。在典型的應用場合下，RTP一般是在傳輸協議之上作為應用程式的一部分加以實現的，2所示：

2.2 RTCP控制協議 
      RTCP控制協議需要與RTP資料協議一起配合使用，當應用程式啟動一個RTP會話時將同時佔用兩個連接埠，分別供RTP和RTCP使用。RTP本身並不能為按序傳輸資料包提供可靠的保證，也不提供流量控制和擁塞控制，這些都由RTCP來負責完成。通常RTCP會採用與RTP相同的分發機制，向會話中的所有成員周期性地發送控制資訊，應用程式通過接收這些資料，從中擷取會話參與者的相關資料，以及網路狀況、分組丟失機率等反饋資訊，從而能夠對服務品質進行控制或者對網路狀況進行診斷。

 

RTCP協議的功能是通過不同的RTCP資料報來實現的，主要有如下幾種類型： 
SR　　發送端報告，所謂發送端是指發出RTP資料報的應用程式或者終端，發送端同時也可以是接收端。 
RR　　接收端報告，所謂接收端是指僅接收但不發送RTP資料報的應用程式或者終端。 
SDES　　源描述，主要功能是作為會話成員有關標識資訊的載體，如使用者名稱、郵件地址、電話號碼等，此外還具有向會話成員傳達會話控制資訊的功能。 
BYE　　通知離開，主要功能是指示某一個或者幾個源不再有效，即通知會話中的其他成員自己將退出會話。 
APP　　由應用程式自己定義，解決了RTCP的擴充性問題，並且為協議的實現者提供了很大的靈活性。 
RTCP資料報攜帶有服務品質監控的必要資訊，能夠對服務品質進行動態調整，並能夠對網路擁塞進行有效控制。由於RTCP資料報採用的是多播方式，因此會話中的所有成員都可以通過RTCP資料報返回的控制資訊，來瞭解其他參與者的當前情況。
      在一個典型的應用場合下，發送媒體流的應用程式將周期性地產生髮送端報告SR，該RTCP資料報含有不同媒體流間的同步資訊，以及已經發送的資料報和位元組的計數，接收端根據這些資訊可以估計出實際的資料轉送速率。另一方面，接收端會向所有已知的發送端發送接收端報告RR，該RTCP資料報含有已接收資料報的最大序號、丟失的資料報數目、延時抖動和時間戳記等重要訊息，發送端應用根據這些資訊可以估計出往返時延，並且可以根據資料報丟失機率和時延抖動情況動態調整發送速率，以改善網路擁塞狀況，或者根據網路狀況平滑地調整應用程式的服務品質。

2.3 RTSP即時資料流通訊協定 
      作為一個應用程式層協議，RTSP提供了一個可供擴充的架構，它的意義在於使得即時資料流媒體資料的受控和點播變得可能。總的說來，RTSP是一個流媒體表示協議，主要用來控制具有即時特性的資料發送，但它本身並不傳輸資料，而是必須依賴於下層傳輸協議所提供的某些服務。RTSP可以對流媒體提供諸如播放、暫停、快進等操作，它負責定義具體的控制訊息、操作方法、狀態代碼等，此外還描述了與RTP間的互動操作。

      RTSP在制定時較多地參考了HTTP/1.1協議，甚至許多描述與HTTP/1.1完全相同。RTSP之所以特意使用與HTTP/1.1類似的文法和操作，在很大程度上是為了相容現有的Web基礎結構，正因如此，HTTP/1.1的擴充機制大都可以直接引入到RTSP中。
      由RTSP控制的媒體流集合可以用表示描述（Presentation Description）來定義，所謂表示是指流媒體伺服器提供給客戶機的一個或者多個媒體流的集合，而表示描述則包含了一個表示中各個媒體流的相關資訊，如資料編碼/解碼演算法、網路地址、媒體流的內容等。
      雖然RTSP伺服器同樣也使用標識符來區別每一流串連會話（Session），但RTSP串連並沒有被綁定到傳輸層串連（如TCP等），也就是說在整個RTSP串連期間，RTSP使用者可開啟或者關閉多個對RTSP伺服器的可靠傳輸串連以發出RTSP 請求。此外，RTSP串連也可以基於面向不需連線的傳輸協議（如UDP等）。

RTSP協議目前支援以下操作： 
檢索媒體　　允許使用者通過HTTP或者其它方法向媒體伺服器提交一個表示描述。如表示是組播的，則表示描述就包含用於該媒體流的組播地址和連接埠號碼；如果表示是單播的，為了安全在表示描述中應該只提供目的地址。 
邀請加入　　媒體伺服器可以被邀請參加進行中的會議，或者在表示中回放媒體，或者在表示中錄製全部媒體或其子集，非常適合於分布式教學。 
添加媒體　　通知使用者新加入的可利用媒體流，這對現場講座來講顯得尤其有用。與HTTP/1.1類似，RTSP請求也可以交由代理、通道或者緩衝來進行處理。