流媒體相關知識介紹 及其 RTP 應用

随着Internet的日益普及，在網絡上傳輸的資料已經不再局限于文字和圖形，而是逐漸向聲音和視訊等多媒體格式過渡。目前在網絡上傳輸音頻/視訊（Audio/Video，簡稱A/V）等多媒體檔案時，基本上隻有下載下傳和流式傳輸兩種選擇。通常說來，A/V檔案占據的存儲空間都比較大，在帶寬受限的網絡環境中下載下傳可能要耗費數分鐘甚至數小時，是以這種處理方法的延遲很大。如果換用流式傳輸的話，聲音、影像、動畫等多媒體檔案将由專門的流媒體伺服器負責向使用者連續、實時地發送，這樣使用者可以不必等到整個檔案全部下載下傳完畢，而隻需要經過幾秒鐘的啟動延時就可以了，當這些多媒體資料在客戶機上播放時，檔案的剩餘部分将繼續從流媒體伺服器下載下傳。

流（Streaming）是近年在Internet上出現的新概念，其定義非常廣泛，主要是指通過網絡傳輸多媒體資料的技術總稱。流媒體包含廣義和狹義兩種内涵：廣義上的流媒體指的是使音頻和視訊形成穩定和連續的傳輸流和回放流的一系列技術、方法和協定的總稱，即流媒體技術；狹義上的流媒體是相對于傳統的下載下傳-回放方式而言的，指的是一種從Internet上擷取音頻和視訊等多媒體資料的新方法，它能夠支援多媒體資料流的實時傳輸和實時播放。通過運用流媒體技術，伺服器能夠向客戶機發送穩定和連續的多媒體資料流，客戶機在接收資料的同時以一個穩定的速率回放，而不用等資料全部下載下傳完之後再進行回放。

由于受網絡帶寬、計算機處理能力和協定規範等方面的限制，要想從Internet上下載下傳大量的音頻和視訊資料，無論從下載下傳時間和存儲空間上來講都是不太現實的，而流媒體技術的出現則很好地解決了這一難題。目前實作流媒體傳輸主要有兩種方法：順序流（progressive streaming）傳輸和實時流（realtime streaming）傳輸，它們分别适合于不同的應用場合。

順序流傳輸

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

實時流傳輸

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

<a href="http://www-128.ibm.com/developerworks/cn/linux/l-mdst/index.html#main">回頁首</a>

實時傳輸協定（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請求也可以交由代理、通道或者緩存來進行處理。

RTP是目前解決流媒體實時傳輸問題的最好辦法，如果需要在Linux平台上進行實時流媒體程式設計，可以考慮使用一些開放源代碼的RTP庫，如LIBRTP、JRTPLIB等。JRTPLIB是一個面向對象的RTP庫，它完全遵循RFC 1889設計，在很多場合下是一個非常不錯的選擇，下面就以JRTPLIB為例，講述如何在Linux平台上運用RTP協定進行實時流媒體程式設計。

3.1 環境搭建

JRTPLIB是一個用C++語言實作的RTP庫，目前已經可以運作在Windows、Linux、FreeBSD、Solaris、Unix和VxWorks等多種作業系統上。要為Linux 系統安裝JRTPLIB，首先從JRTPLIB的網站（http://lumumba.luc.ac.be/jori/jrtplib/jrtplib.html）下載下傳最新的源碼包，此處使用的是jrtplib-2.7b.tar.bz2。假設下載下傳後的源碼包儲存在/usr/local/src目錄下，執行下面的指令可以對其進行解壓縮：

接下去需要對JRTPLIB進行配置和編譯：

最後再執行如下指令就可以完成JRTPLIB的安裝：

3.2 初始化

在使用JRTPLIB進行實時流媒體資料傳輸之前，首先應該生成RTPSession類的一個執行個體來表示此次RTP會話，然後調用Create()方法來對其進行初始化操作。RTPSession類的Create()方法隻有一個參數，用來指明此次RTP會話所采用的端口号。清單1給出了一個最簡單的初始化架構，它隻是完成了RTP會話的初始化工作，還不具備任何實際的功能。

如果RTP會話建立過程失敗，Create()方法将會傳回一個負數，通過它雖然可以很容易地判斷出函數調用究竟是成功的還是失敗的，但卻很難明白出錯的原因到底什麼。JRTPLIB采用了統一的錯誤處理機制，它提供的所有函數如果傳回負數就表明出現了某種形式的錯誤，而具體的出錯資訊則可以通過調用RTPGetErrorString()函數得到。RTPGetErrorString()函數将錯誤代碼作為參數傳入，然後傳回該錯誤代碼所對應的錯誤資訊。清單2給出了一個更加完整的初始化架構，它可以對RTP會話初始化過程中所産生的錯誤進行更好的處理：

設定恰當的時戳單元，是RTP會話初始化過程所要進行的另外一項重要工作，這是通過調用RTPSession類的SetTimestampUnit()方法來實作的，該方法同樣也隻有一個參數，表示的是以秒為單元的時戳單元。例如，當使用RTP會話傳輸8000Hz采樣的音頻資料時，由于時戳每秒鐘将遞增8000，是以時戳單元相應地應該被設定成1/8000：

3.3 資料發送

當RTP會話成功建立起來之後，接下去就可以開始進行流媒體資料的實時傳輸了。首先需要設定好資料發送的目标位址，RTP協定允許同一會話存在多個目标位址，這可以通過調用RTPSession類的AddDestination()、DeleteDestination()和ClearDestinations()方法來完成。例如，下面的語句表示的是讓RTP會話将資料發送到本地主機的6000端口：

目标位址全部指定之後，接着就可以調用RTPSession類的SendPacket()方法，向所有的目标位址發送流媒體資料。SendPacket()是RTPSession類提供的一個重載函數，它具有下列多種形式：

SendPacket()最典型的用法是類似于下面的語句，其中第一個參數是要被發送的資料，而第二個參數則指明将要發送資料的長度，再往後依次是RTP負載類型、辨別和時戳增量。

對于同一個RTP會話來講，負載類型、辨別和時戳增量通常來講都是相同的，JRTPLIB允許将它們設定為會話的預設參數，這是通過調用RTPSession類的SetDefaultPayloadType()、SetDefaultMark()和SetDefaultTimeStampIncrement()方法來完成的。為RTP會話設定這些預設參數的好處是可以簡化資料的發送，例如，如果為RTP會話設定了預設參數：

之後在進行資料發送時隻需指明要發送的資料及其長度就可以了：

3.4 資料接收

對于流媒體資料的接收端，首先需要調用RTPSession類的PollData()方法來接收發送過來的RTP或者RTCP資料報。由于同一個RTP會話中允許有多個參與者（源），你既可以通過調用RTPSession類的GotoFirstSource()和GotoNextSource()方法來周遊所有的源，也可以通過調用RTPSession類的GotoFirstSourceWithData()和GotoNextSourceWithData()方法來周遊那些攜帶有資料的源。在從RTP會話中檢測出有效的資料源之後，接下去就可以調用RTPSession類的GetNextPacket()方法從中抽取RTP資料報，當接收到的RTP資料報處理完之後，一定要記得及時釋放。下面的代碼示範了該如何對接收到的RTP資料報進行處理：

JRTPLIB為RTP資料報定義了三種接收模式，其中每種接收模式都具體規定了哪些到達的RTP資料報将會被接受，而哪些到達的RTP資料報将會被拒絕。通過調用RTPSession類的SetReceiveMode()方法可以設定下列這些接收模式：

RECEIVEMODE_ALL　　預設的接收模式，所有到達的RTP資料報都将被接受；

RECEIVEMODE_IGNORESOME　　除了某些特定的發送者之外，所有到達的RTP資料報都将被接受，而被拒絕的發送者清單可以通過調用AddToIgnoreList()、DeleteFromIgnoreList()和ClearIgnoreList()方法來進行設定；

RECEIVEMODE_ACCEPTSOME　　除了某些特定的發送者之外，所有到達的RTP資料報都将被拒絕，而被接受的發送者清單可以通過調用AddToAcceptList ()、DeleteFromAcceptList和ClearAcceptList ()方法來進行設定。

3.5 控制資訊

JRTPLIB是一個高度封裝後的RTP庫，程式員在使用它時很多時候并不用關心RTCP資料報是如何被發送和接收的，因為這些都可以由JRTPLIB自己來完成。隻要PollData()或者SendPacket()方法被成功調用，JRTPLIB就能夠自動對到達的RTCP資料報進行處理，并且還會在需要的時候發送RTCP資料報，進而能夠確定整個RTP會話過程的正确性。

而另一方面，通過調用RTPSession類提供的SetLocalName()、SetLocalEMail()、SetLocalLocation()、SetLocalPhone()、SetLocalTool()和SetLocalNote()方法，JRTPLIB又允許程式員對RTP會話的控制資訊進行設定。所有這些方法在調用時都帶有兩個參數，其中第一個參數是一個char型的指針，指向将要被設定的資料；而第二個參數則是一個int型的數值，表明該資料中的前面多少個字元将會被使用。例如下面的語句可以被用來設定控制資訊中的電子郵件位址：

在RTP會話過程中，不是所有的控制資訊都需要被發送，通過調用RTPSession類提供的EnableSendName()、EnableSendEMail()、EnableSendLocation()、EnableSendPhone()、EnableSendTool()和EnableSendNote()方法，可以為目前RTP會話選擇将被發送的控制資訊。

3.6 實際應用

最後通過一個簡單的流媒體發送-接收執行個體，介紹如何利用JRTPLIB來進行實時流媒體的程式設計。清單3給出了資料發送端的完整代碼，它負責向使用者指定的IP位址和端口，不斷地發送RTP資料包：

清單4則給出了資料接收端的完整代碼，它負責從指定的端口不斷地讀取RTP資料包：

随着多媒體資料在Internet上所承擔的作用變得越來越重要，需要實時傳輸音頻和視訊等多媒體資料的場合也将變得越來越多，如IP電話、視訊點播、線上會議等。RTP是用來在Internet上進行實時流媒體傳輸的一種協定，目前已經被廣泛地應用在各種場合，JRTPLIB是一個面向對象的RTP封裝庫，利用它可以很友善地完成Linux平台上的實時流媒體程式設計。

1. 在JRTPLIB的網站http://lumumba.luc.ac.be/jori/jrtplib/jrtplib.html上，可以下載下傳到JRTPLIB最新的源碼包，并且還能找到一些與RTP相關的資源。

2. 顧淑珍等編著，寬帶增值服務開發執行個體，北京：機械工業出版社，2002

3. 黃永峰等編著，IP網絡多媒體通信技術，北京：人民郵電出版社，2003