第1章 RTP概述

1.1.  RTP是什麼

RTP全名是Real-time Transport Protocol（實時傳輸協議），是IETF提出的一個標準，對應的RFC文件為RFC3550（RFC1889為其過期版本）。RFC3550不僅定義了RTP，而且定義了配套的相關協議RTCP（Real-time Transport Control Protocol，即實時傳輸控制協議）。RTP用來為IP網上的語音、影象、傳真等多種需要實時傳輸的多媒體資料提供端到端的實時傳輸服務。RTP為Internet上端到端的實時傳輸提供時間資訊和流同步，但並不保證服務質量，服務質量由RTCP來提供。

1.2.  RTP的應用環境

RTP用於在單播或多播網路中傳送實時資料。它們典型的應用場合有如下幾個。

簡單的多播音訊會議。語音通訊通過一個多播地址和一對埠來實現。一個用於音訊資料（RTP），另一個用於控制包（RTCP）。

音訊和視訊會議。如果在一次會議中同時使用了音訊和視訊會議，這兩種媒體將分別在不同的RTP會話中傳送，每一個會話使用不同的傳輸地址（IP地址＋埠）。如果一個使用者同時使用了兩個會話，則每個會話對應的RTCP包都使用規範化名字CNAME（Canonical Name）。與會者可以根據RTCP包中的CNAME來獲取相關聯的音訊和視訊，然後根據RTCP包中的計時資訊(Network time protocol)來實現音訊和視訊的同步。

翻譯器和混合器。翻譯器和混合器都是RTP級的中繼系統。翻譯器用在通過IP多 播不能直接到達的使用者區，例如傳送者和接收者之間存在防火牆。當與會者能接收的音訊編碼格式不一樣，比如有一個與會者通過一條低速鏈路接入到高速會議，這 時就要使用混合器。在進入音訊資料格式需要變化的網路前，混合器將來自一個源或多個源的音訊包進行重構，並把重構後的多個音訊合併，採用另一種音訊編碼進 行編碼後，再轉發這個新的RTP包。從一個混合器出來的所有資料包要用混合器作為它們的同步源（SSRC，見RTP的封裝）來識別，可以通過貢獻源列表（CSRC表，見RTP的封裝）可以確認談話者。

1.3.  相關概念

1.3.1.  流媒體

流媒體是指Internet上使用流式傳輸技術的連續時基媒體。當前在Internet上傳輸音訊和視訊等資訊主要有兩種方式：下載和流式傳輸兩種方式。

下載情況下，使用者需要先下載整個媒體檔案到本地，然後才能播放媒體檔案。在視訊直播等應用場合，由於生成整個媒體檔案要等直播結束，也就是使用者至少要在直播結束後才能看到直播節目，所以用下載方式不能實現直播。

流式傳輸是實現流媒體的關鍵技術。使用流式傳輸可以邊下載邊觀看流媒體節目。由於Internet是基於分組傳輸的，所以接收端收到的資料包往往有延遲和亂序（流式傳輸構建在UDP上）。要實現流式傳輸，就是要從降低延遲和恢復資料包時序入手。在傳送端，為降低延遲，往往對傳輸資料進行預處理（降低質量和高效壓縮）。在接收端為了恢復時序，採用了接收緩衝；而為了實現媒體的流暢播放，則採用了播放緩衝。

使用接收緩衝，可以將接收到的資料包快取起來，然後根據資料包的封裝資訊（如包序號和時戳等），將亂序的包重新排序，最後將重新排序了的資料包放入播放緩衝播放。

為什麼需要播放緩衝呢？容易想到，由於網路不可能很理想，並且對資料包排序需要處理時耗，我們得到排序好的資料包的時間間隔是不等的。如果不用播放緩衝，那麼播放節目會很卡，這叫時延抖動。相反，使用播放緩衝，在開始播放時，花費幾十秒鐘先將播放緩衝填滿（例如PPLIVE），可以有效地消除時延抖動，從而在不太損失實時性的前提下實現流媒體的順暢播放。

到目前為止,Internet 上使用較多的流式視訊格式主要有以下三種:RealNetworks 公司的RealMedia ,Apple 公司的QuickTime 以及Microsoft 公司的Advanced Streaming Format (ASF) 。

上面在談接收緩衝時，說到了流媒體資料包的封裝資訊（包序號和時戳等），這在後面的RTP封裝中會有體現。另外，RealMedia這些流式媒體格式只是編解碼有不同，但對於RTP來說，它們都是待封裝傳輸的流媒體資料而沒有什麼不同。

第2章 RTP詳解

2.1.  RTP的協議層次

2.1.1.  傳輸層的子層

RTP（實時傳輸協議），顧名思義它是用來提供實時傳輸的，因而可以看成是傳輸層的一個子層。圖 1給出了流媒體應用中的一個典型的協議體系結構。

圖 1 流媒體體系結構

從圖中可以看出，RTP被劃分在傳輸層，它建立在UDP上。同UDP協議一樣，為了實現其實時傳輸功能，RTP也有固定的封裝形式。RTP用來為端到端的實時傳輸提供時間資訊和流同步，但並不保證服務質量。服務質量由RTCP來提供。這些特點，在第4章可以看到。

2.1.2.  應用層的一部分

不少人也把RTP歸為應用層的一部分，這是從應用開發者的角度來說的。作業系統中的TCP/IP等協議棧所提供的是我們最常用的服務，而RTP的實現還是要靠開發者自己。因此從開發的角度來說，RTP的實現和應用層協議的實現沒不同，所以可將RTP看成應用層協議。

RTP實現者在傳送RTP資料時，需先將資料封裝成RTP包，而在接收到RTP資料包，需要將資料從RTP包中提取出來。

2.2.  RTP的封裝

一個協議的封裝是為了滿足協議的功能需求的。從前面提出的功能需求，可以推測出RTP封裝中應該有同步源和時戳等欄位，但更為完整的封裝是什麼樣子呢？請看圖2。

圖 2 RTP的頭部格式

版本號（V）：2位元，用來標誌使用的RTP版本。

填充位（P）：1位元，如果該位置位，則該RTP包的尾部就包含附加的填充位元組。

擴充套件位（X）：1位元，如果該位置位的話，RTP固定頭部後面就跟有一個擴充套件頭部。

CSRC計數器（CC）：4位元，含有固定頭部後面跟著的CSRC的數目。

標記位（M）：1位元,該位的解釋由配置文件（Profile）來承擔.

載荷型別（PT）：7位元，標識了RTP載荷的型別。

序列號（SN）：16位元，傳送方在每傳送完一個RTP包後就將該域的值增加1，接收方可以由該域檢測包的丟失及恢復包序列。序列號的初始值是隨機的。

時間戳：32位元，記錄了該包中資料的第一個位元組的取樣時刻。在一次會話開始時，時間戳初始化成一個初始值。即使在沒有訊號傳送時，時間戳的數值也要隨時間而不斷地增加（時間在流逝嘛）。時間戳是去除抖動和實現同步不可缺少的。

同步源識別符號(SSRC)：32位元，同步源就是指RTP包流的來源。在同一個RTP會話中不能有兩個相同的SSRC值。該識別符號是隨機選取的 RFC1889推薦了MD5隨機演算法。

貢獻源列表（CSRC List）：0～15項，每項32位元，用來標誌對一個RTP混合器產生的新包有貢獻的所有RTP包的源。由混合器將這些有貢獻的SSRC識別符號插入表中。SSRC識別符號都被列出來，以便接收端能正確指出交談雙方的身份。

2.3.  RTCP的封裝

RTP需要RTCP為其服務質量提供保證，因此下面介紹一下RTCP的相關知識。

RTCP的主要功能是：服務質量的監視與反饋、媒體間的同步，以及多播組中成員的標識。在RTP會話期間，各參與者週期性地傳送RTCP包。RTCP包中含有已傳送的資料包的數量、丟失的資料包的數量等統計資料，因此，各參與者可以利用這些資訊動態地改變傳輸速率，甚至改變有效載荷型別。RTP和RTCP配合使用，它們能以有效的反饋和最小的開銷使傳輸效率最佳化，因而特別適合傳送網上的實時資料。

從圖 1可以看到，RTCP也是用UDP來傳送的，但RTCP封裝的僅僅是一些控制資訊，因而分組很短，所以可以將多個RTCP分組封裝在一個UDP包中。RTCP有如下五種分組型別。

表 1 RTCP的5種分組型別

上述五種分組的封裝大同小異，下面只講述SR型別，而其它型別請參考RFC3550。

傳送端報告分組SR（Sender Report）用來使傳送端以多播方式向所有接收端報告發送情況。SR分組的主要內容有：相應的RTP流的SSRC，RTP流中最新產生的RTP分組的時間戳和NTP，RTP流包含的分組數，RTP流包含的位元組數。SR包的封裝如圖3所示。

圖 3 RTCP頭部的格式

版本（V）：同RTP包頭域。

填充（P）：同RTP包頭域。

接收報告計數器（RC）：5位元，該SR包中的接收報告塊的數目，可以為零。

包型別（PT）：8位元，SR包是200。

長度域（Length）：16位元，其中存放的是該SR包以32位元為單位的總長度減一。

同步源（SSRC）：SR包傳送者的同步源識別符號。與對應RTP包中的SSRC一樣。

NTP Timestamp（Network time protocol）SR包傳送時的絕對時間值。NTP的作用是同步不同的RTP媒體流。

RTP Timestamp：與NTP時間戳對應，與RTP資料包中的RTP時間戳具有相同的單位和隨機初始值。

Sender’s packet count：從開始傳送包到產生這個SR包這段時間裡，傳送者傳送的RTP資料包的總數. SSRC改變時，這個域清零。

Sender`s octet count：從開始傳送包到產生這個SR包這段時間裡，傳送者傳送的淨荷資料的總位元組數（不包括頭部和填充）。傳送者改變其SSRC時，這個域要清零。

同步源n的SSRC識別符號：該報告塊中包含的是從該源接收到的包的統計資訊。

丟失率（Fraction Lost）：表明從上一個SR或RR包發出以來從同步源n(SSRC_n)來的RTP資料包的丟失率。

累計的包丟失數目：從開始接收到SSRC_n的包到傳送SR,從SSRC_n傳過來的RTP資料包的丟失總數。

收到的擴充套件最大序列號：從SSRC_n收到的RTP資料包中最大的序列號，

接收抖動（Interarrival jitter）：RTP資料包接受時間的統計方差估計

上次SR時間戳（Last SR,LSR）：取最近從SSRC_n收到的SR包中的NTP時間戳的中間32位元。如果目前還沒收到SR包，則該域清零。

上次SR以來的延時（Delay since last SR,DLSR）：上次從SSRC_n收到SR包到傳送本報告的延時。

2.4.  RTP的會話過程

當應用程式建立一個RTP會話時，應用程式將確定一對目的傳輸地址。目的傳輸地址由一個網路地址和一對埠組成，有兩個埠：一個給RTP包，一個給RTCP包，使得RTP/RTCP資料能夠正確傳送。RTP資料發向偶數的UDP埠，而對應的控制訊號RTCP資料發向相鄰的奇數UDP埠（偶數的UDP埠＋1），這樣就構成一個UDP埠對。 RTP的傳送過程如下，接收過程則相反。

1)        RTP協議從上層接收流媒體資訊碼流（如H.263），封裝成RTP資料包；RTCP從上層接收控制資訊，封裝成RTCP控制包。

2)        RTP將RTP 資料包發往UDP埠對中偶數埠；RTCP將RTCP控制包發往UDP埠對中的接收埠。

第3章.     相關的協議

3.1.  實時流協議RTSP

實時流協議RTSP（Real-Time Streaming Protocol）是IETF提出的協議，對應的RFC文件為RFC2362。

從圖 1可以看出，RTSP是一個應用層協議（TCP/IP網路體系中）。它以C/S模式工作，它是一個多媒體播放控制協議，主要用來使使用者在播放流媒體時可以像操作本地的影碟機一樣進行控制，即可以對流媒體進行暫停/繼續、後退和前進等控制。

3.2.  資源預定協議RSVP

資源預定協議RSVP(Resource Reservation Protocol)是IETF提出的協議，對應的RFC文件為RFC2208。

從圖 1可以看出，RSVP工作在IP層之上傳輸層之下，是一個網路控制協議。RSVP通過在路由器上預留一定的頻寬，能在一定程度上為流媒體的傳輸提供服務質量。在某些試驗性的系統如網路視訊會議工具vic中就集成了RSVP。

第4章.     常見的疑問

4.1.  怎樣重組亂序的資料包

可以根據RTP包的序列號來排序。

4.2.  怎樣獲得資料包的時序

可以根據RTP包的時間戳來獲得資料包的時序。

4.3.  聲音和影象怎麼同步

根據聲音流和影象流的相對時間（即RTP包的時間戳），以及它們的絕對時間（即對應的RTCP包中的RTCP），可以實現聲音和影象的同步。

4.4.  接收緩衝和播放緩衝的作用

如1.3.1所述，接收緩衝用來排序亂序了的資料包；播放緩衝用來消除播放的抖動，實現等時播放。

第5章.     實現方案

表 2 協議分析要求

表 2給出了協議分析要求。容易看出要獲取RTP音訊包中的音訊資訊很容易，直接將RTP包的包頭去掉即可。當然，要成功地播放解碼獲取到的音訊流，需要知道其編碼，這可從RTP包包頭的有效載荷型別欄位（PT）獲得。

第6章.     參考資料

[1]      RFC文件：RFC3550對應RTP/RTCP，RFC2362對應RTSP，RFC2208對應RSVP

[2]      http://www.faqs.org/rfcs/，上面有全面的英文RFC文件

[3]      http://www.cnpaf.net/，有不少協議分析文件，也有中文RFC文件，但質量不是特別高。

[補充介紹]

RTP與RTCP含同步時間戳

RTP協議通常和UDP結合在一起，作為UDP的上層載體資料的形式傳播。

  typedef struct { 
        UINT32  timestamp;
        BOOL   marker; 
        BYTE   payload;

        UINT32  sSrc; 
        UINT16 sequenceNumber; 
        int   sByte; 
        int    len;
      } rtpParam;

      這是一個RTP頭：

      （1）payload。payload表示了此RTP包的資料是那種型別的資料，不同的數值表示不同的型別。如0是PCMU，8是723，24是視訊263等等。

      （2）SSRC，這個東西並不常用，實際上它是一個隨即生成的ID，表示了一個RTP連線。在應用的時候，確保這個ID唯一就可以了。

      （3）sequence number。也就是序列號，它表示了當前包是第幾個包。傳送方每傳送一個包，就把這個數值加一。接受放可以根據這個數值來重新組合包順序，判斷包是否丟失等操作。注意：它只是表示了包的先後順序，它不能表示時間上的任何其它資訊。這個請和後面的時間戳比較。

      （4）timestamp。時間戳，它的概念稍微有點複雜，我用稍微通俗點的理解去解釋它，雖然這樣有點不太正確。時間戳顧名思義，它表示了一個數據產生的時間，和我們郵遞的郵戳一樣，它是個時間標記（至於這個時間幹什麼用，我後面會詳細的說），通常表示RTP資料包中，第一個位元組資料產生的時間（至於你是不是這麼用就是你寫程式的問題了）。

       如果你上面理解了，那麼我們更進一步：實際上，時間戳增加一併不是我們通常意義上的過了一個微秒，而是增加了一個取樣間隔那麼長的時間。舉個例子來說。不同的採集有不同的取樣頻率，比如一般的音訊是8K的取樣頻率，也就是一毫秒採集8次資料，也就是每次取樣間隔是1/8MS，而timestamp增加1也就意味著增加了一個取樣間隔。也就是過了1/8MS。換個例子，如果令一種編碼的取樣頻率是16K，那麼timestamp增加1也就意味著系統過了1/16MS。也就是說，再同一個系統中，對不同編碼，雖然使用同一個時鐘，但timestamp的增長速度是不同的，在這個例子中，取樣頻率是16K的編碼要比8K的快兩倍，請記住這個區別。

RTCP

       RTCP協議是real-time transport control protocol的縮寫，被設計來做RTP的控制, RTCP實際上是RTP傳輸情況的反饋，通俗的說，它告訴另外一方，在一端時間內（5秒），它傳送多少資料包給對方，接收到了多少對方的包。

      另外，在RTCP中，還有兩個比較重要的東西，一個64位的絕對時間戳和一個32位的相對時間戳。64 位時間戳也叫NTP時間戳，它的前32位是從1900 年1 月1 日0 時開始到現在的以秒為單位的整數部分，後32 位是此時間的小數部，因此，它可以肯定的表示了資料傳送出去的絕對時間。32位的時間戳和RTP中的時間戳是一樣的，沒有任何區別。

         1、SSRC的作用。

        SSRC相當於一個RTP傳輸session的ID，就象每個人都有一個名字一樣，每一個RTP傳輸也都有一個名字。這個數字是隨機產生，並且要保證唯一。當RTP session改變（如IP等）時，這個ID也要改變。

         2、序列號欄位是否可以作為流內的同步標時？

       我在上面已經說過，序列號只表示了包發出的先後順序，它表示不了任何時間上的其它概念，所有嚴格的說，序列號並不能作為流內的同步標誌。但是，由於一般來說，包的傳送時間都會有嚴格限制，比如音訊包是每秒種傳送30個數據包，也就是說，每個包間隔1000/30MS，而這個時間就可以作為一個同步時間來播放。也就是說，按照序列號，每1000/30MS間隔播放一個數據包，這樣也能保證同步，但是這時候請考慮丟包問題。

         3、絕對時間戳和相對時間戳在進行同步處理時有什麼不同

         當我們取得絕對時間後，我們就可以根據這個絕對時間來播放這些資料包。這個絕對時間，加上我們需要的延時（用於資料傳輸，解碼等等的時間）就是我們的播放時間，這樣我們可以保證時間的嚴格同步（相當於把對方的動作延時一段時間後原原本本的再現出來）。目前，在RTP中，能得到這個絕對時間的辦法只有RTCP。

        對於相對時間戳，我們更關心的是兩個時間戳之間的時間間隔，依靠這個時間間隔，來確定兩個包的播放時間間隔。

       4、單個媒體內的同步和不同媒體流之間的同步在處理方式上有什麼不同

       應該說，不同媒體之間同步比單媒體同步要複雜得多，除了要保證本身的播放要和時間同步外，還要保證兩個或多個媒體間同步（比如音視訊的同步）。這種不同更關心的兩個時間戳時間的換算統一，前面我已經說過，不同編碼有不同的取樣頻率，那麼時間戳的增長速度就不同。另外，兩個時間戳也需要有一個標準時間來表示時間戳的同步。最簡單的方法是兩個媒體的第一個時間戳相同，表示兩個流的採集開始時間統一。另外還可以通過RTCP來做不同流之間的同步，這在下個問題中會提到。

      5、時間戳欄位如何用於作為流間同步標識

      在RTP協議中，我們取得時間戳的方法有兩個：一個是RTP包中的時間戳，另外一個是RTCP包中的絕對時間戳和相對時間戳。絕對時間戳的概念上面我已經說了，它可以表示系統的絕對時間。而RTCP包中的相對時間就是RTP包中的時間。根據這兩個時間，不同流都可以糾正自己播放時間和真正時間的偏差以達到和絕對時間同步的目的。反過來說，如果我們沒有辦法拿到這個絕對時間，只有RTP包中的相對時間，那怎我們需要確定兩個流在某一時間點的時間戳的數值。通俗的說，就是在某個時間點，流A的timestamp是多少，B是多少，然後根據這個時間兩個流播放的延時時間，以達到同步的目的。實現這個目的最簡單的辦法是在兩個流開始的時候，使用相同的stamp，拿音視訊來說，在某一絕對時刻，採集相應的資料，並打上相同的時間戳，以後的播放，都以這個時間做基準時間，以保證同步

RTP時間戳相關

通過RTSP建立好會話之後，就可以開始傳輸RTP資料和RTCP SR包了（用來同步音視訊）。

這兩者涉及到很重要的問題：時間戳。下面是《rtp_audio_and_video_for_the_internet》上的一個時間圖。

TimeStamp的初始值是隨即生成的，然後每一幀資料固定增加一 個增量，客戶端在接收到資料時，根據這個時間戳就能以正確的時間恢復（其中被分包的視訊楨是沒有時間戳增加的）。RTCP的SR包裡面除了這個時間戳，還 有一個NTP時間，這是距1900年1月1日的秒數，允許每個系統存在差異，只要同一個系統不同流的該值的生成方式相同就行。以時鐘頻率為90KHz的視 頻為例，若其幀率為30幀，則每一幀的時間戳增量為90000/30=3000；RTCP的SR包的時間戳也可以相應計算出來：增量=（現在時間-上一次 RTP包傳送時間）*單位時間增量，其中單位時間增量=90000*1000000/(2^32)，因為SR包中的微秒時間形式是NTP_frac，因此 要做“/（2^32）”這樣一個轉化。

RFC中說時間戳增量需要滿足線性增長，實際上沒必要嚴格按照諸如3000增量來增長，我是按照實際的幀的時間間隔來打的這個時間戳：

時間戳 = 上一次時間戳 + 取樣頻率（典型值為90000）*0.000001 *  兩幀時間差（單位毫秒）來計算的

 －－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－

時間戳（timestamp） 32位元 時間戳反映了RTP資料包中第一個位元組的取樣時間。（取樣時鐘必須來源於一個及時的單調、線性遞增時鐘，以便允許同步和去除網路引起的資料包抖動。該時鐘的解析度必須滿足理想的同步精度和測量資料包到來時的抖動的需要（一種典型的時鐘解析度不滿足情況是每個視訊幀僅一個時鐘週期）時鐘 頻率依賴於負載資料的格式，並在描述檔案（profile）中或者是在負載格式描述中（payload format speci_cation）進行靜態描述。也可以通過非RTP方法（non-RTP means）對負載格式動態描述。

       如果RTP包是週期性產生的，那麼將使用由取樣時鐘決定的名義上的取樣時刻，而不是讀取系統時間。例如，對一個固定速率的音訊，取樣時鐘（時間戳時鐘）將 在每個週期內增加1。如果一個音訊從輸入裝置中讀取含有160個取樣週期的塊，那麼對每個塊，時間戳的值增加160，而不考慮該塊是否用一個包傳遞或是被 丟棄。

        時間戳的初始值應當是隨機的，就像序號一樣。幾個連續的RTP包如果（邏輯上）是同時產生的，如：屬於同一個視訊幀的RTP包，將有相同的序列號。如果數 據並不是以它取樣的順序進行傳輸，那麼連續的RTP包可以包含不是單調遞增（或遞減）的時間戳（RTP包的序列號仍然是單調變化的）。

  
根據一些文章我自己推敲了一下幾個概念如下：   
       時間戳單位：時間戳計算的單位不為秒之類的單位，而是由取樣頻率所代替的單位，這樣做的目的就是為了是時間戳單位更為精準。比如說一個音訊的取樣頻率為8000HZ，那麼我們可以把時間戳單位設為1/8000。
       時間戳增量：相鄰兩個RTP包之間的時間差（以時間戳單位為基準）。
 
       如何設定時間戳之間的增量呢？
       按照剛才時間戳單位來看，1秒鐘按照時間戳單位就是8000，那麼一秒鐘如果可以播放20幀，也就是傳送30幀（幀率），那麼可以求出相鄰兩幀之間的時間差，也就是時間戳增量，那麼顯而易見是用8000/20，那麼這個時間戳增量就為400.
       網上大多數列舉的一個例子是： 例如MPEG，每幀20ms，取樣頻率8000Hz，設定時間戳單位1/8000，而每個包之間就是160的增量
    這裡又該如何理解呢？可以輕易地看出增量是直接8000與20ms相乘的結果，我們可以知道這裡兩幀之間的時間為20ms，也就是0.02s，這個單位是以秒來衡量的，那麼我們要用時間戳單位來表示那麼就是8000*0.02=160.所以時間戳增量為160.

        還有一點為什麼一般都用90000作為視訊取樣頻率呢？
        90k是用於視訊同步的時間尺度(TimeScale),就是每秒90k個時鐘tick。為什麼採用90k呢？目前視訊的幀速率主要有25fps、29.97fps、30fps等，而90k剛好是它們的倍數，所以就採用了90k。

 －－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－

RTP協議包頭的格式：
            

　　10~16 Bit為PT域，指的就是負載型別（PayLoad），負載型別定義了RTP負載的格式，協議原文說該域由具體應用決定其解釋。
　　目前，負載型別主要用來告訴接收端（或者播放器）傳輸的是哪種型別的媒體（例如G.729，H.264，MPEG-4等），這樣接收端（或者播放器）才知道了資料流的格式，才會呼叫適當的編解碼器去解碼或者播放，這就是負載型別的主要作用。

時間戳單位：時間戳計算的單位不是秒之類的單位，而是由取樣頻率所代替的單位，這樣做的目的就是為了是時間戳單位更為精準。比如說一個音訊的取樣頻率為8000Hz，那麼我們可以把時間戳單位設為1 / 8000。
    時間戳增量：相鄰兩個RTP包之間的時間差（以時間戳單位為基準）。
    取樣頻率：  每秒鐘抽取樣本的次數，例如音訊的取樣率一般為8000Hz
    幀率：      每秒傳輸或者顯示幀數，例如25f/s
    
    再看看RTP時間戳課本中的定義：

    RTP包頭的第2個32Bit即為RTP包的時間戳，Time Stamp ，佔32位。
    時間戳反映了RTP分組中的資料的第一個位元組的取樣時刻。在一次會話開始時的時間戳初值也是隨機選擇的。即使是沒有訊號傳送時，時間戳的數值也要隨時間不 斷的增加。接收端使用時間戳可準確知道應當在什麼時間還原哪一個資料塊，從而消除傳輸中的抖動。時間戳還可用來使視訊應用中聲音和影象同步。
    在RTP協議中並沒有規定時間戳的粒度，這取決於有效載荷的型別。因此RTP的時間戳又稱為媒體時間戳，以強調這種時間戳的粒度取決於訊號的型別。例如， 對於8kHz取樣的話音訊號，若每隔20ms構成一個數據塊，則一個數據塊中包含有160個樣本（0.02×8000=160）。因 此每傳送一個RTP分組，其時間戳的值就增加160。

    官方的解釋看懂沒？沒看懂？沒關係，我剛開始也沒看懂，那就聽我的解釋吧。

    首先，時間戳就是一個值，用來反映某個資料塊的產生（採集）時間點的，後採集的資料塊的時間戳肯定是大於先採集的資料塊的。有了這樣一個時間戳，就可以標記資料塊的先後順序。
    第二，在實時流傳輸中，資料採集後立刻傳遞到RTP模組進行傳送，那麼，其實，資料塊的採集時間戳就直接作為RTP包的時間戳。
    第三，如果用RTP來傳輸固定的檔案，則這個時間戳就是讀檔案的時間點，依次遞增。這個不再我們當前的討論範圍內，暫時不考慮。
    第四，時間戳的單位採用的是取樣頻率的倒數，例如取樣頻率為8000Hz時，時間戳的單位為1 / 8000 ，在Jrtplib庫中，有設定時間戳單位的函式介面，而ORTP庫中根據負載型別直接給定了時間戳的單位（音訊負載1/8000，視訊負載1/90000）
    第五，時間戳增量是指兩個RTP包之間的時間間隔，詳細點說，就是傳送第二個RTP包相距傳送第一個RTP包時的時間間隔（單位是時間戳單位）。
    如果取樣頻率為90000Hz，則由上面討論可知，時間戳單位為1/90000，我們就假設1s鐘被劃分了90000個時間塊，那麼，如果每秒傳送25 幀，那麼，每一個幀的傳送佔多少個時間塊呢？當然是 90000/25 = 3600。因此，我們根據定義“時間戳增量是傳送第二個RTP包相距傳送第一個RTP包時的時間間隔”，故時間 戳增量應該為3600。

      【補充】：最近思考了一下，又有了新的體會和解釋，可能對大家更容易地去理解這個時間戳增量會有所幫助，補充在下面吧：

       其實，網路傳送重點關注的是流量的平衡，即均勻地利用網路頻寬，為了實現這一點，需要滿足：資