RTP協議分析和詳解

1、RTP協議分析

第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有以下五種分組類型。

類型	縮寫表示	用途
200	SR（Sender Report）	發送端報告
201	RR（Receiver Report）	接收端報告
202	SDES（Source Description Items）	源點描述
203	BYE	結束傳輸
204	APP	特定應用

表 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章.     實現方案

ID	Protocol	Captured contents
		Account	password	Local telephone number	Opponents Telephone Number	audio	login	logout
36	Rtp					√

表 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文檔，但質量不是特別高。

 

 

2、RTP與RTCP解釋.含同步時間戳

RTP協議是real-time transport protocol的縮寫，被設計來傳輸流媒體數據，有着普遍的應用，其它相關介紹本身去看RFC，我不打算討論這些無聊的概念性的東西。

RTP

      能夠說，RTP協議不依賴於底層協議，也就是說，它是獨立的協議。而通常的，因爲UDP包的快速、時實性高的特色，它一般和UDP結合在一塊兒，做爲UDP的上層載體數據的形式傳播。

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

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

      這是一個RTP頭，很簡單，並無你想象的那麼複雜，對不對？咱們來看幾個主要的參數，他們也是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中的時間戳是同樣的，沒有任何區別。

 

）你們感興趣的時間戳的使用和同步的一些話題。

       一、SSRC的做用。

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

         二、序列號字段是否能夠做爲流內的同步標時？

       我在上面已經說過，序列號只表示了包發出的前後順序，它表示不了任什麼時候間上的其它概念，全部嚴格的說，序列號並不能做爲流內的同步標誌。可是，因爲通常來講，包的發送時間都會有嚴格限制，好比音頻包是每秒種發送30個數據包，也就是說，每一個包間隔1000/30MS，而這個時間就能夠做爲一個同步時間來播放。也就是說，按照序列號，每1000/30MS間隔播放一個數據包，這樣也能保證同步，可是這時候請考慮丟包問題。

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

         當咱們取得絕對時間後，咱們就能夠根據這個絕對時間來播放這些數據包。這個絕對時間，加上咱們須要的延時（用於數據傳輸，解碼等等的時間）就是咱們的播放時間，這樣咱們能夠保證時間的嚴格同步（至關於把對方的動做延時一段時間後原本來本的再現出來）。目前，在RTP中，能獲得這個絕對時間的辦法只有RTCP。

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

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

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

      五、時間戳字段如何用於做爲流間同步標識

      在RTP協議中，咱們取得時間戳的方法有兩個：一個是RTP包中的時間戳，另一個是RTCP包中的絕對時間戳和相對時間戳。絕對時間戳的概念上面我已經說了，它能夠表示系統的絕對時間。而RTCP包中的相對時間就是RTP包中的時間。根據這兩個時間，不一樣流均可以糾正本身播放時間和真正時間的誤差以達到和絕對時間同步的目的。反過來講，若是咱們沒有辦法拿到這個絕對時間，只有RTP包中的相對時間，那怎咱們須要肯定兩個流在某一時間點的時間戳的數值。通俗的說，就是在某個時間點，流A的timestamp是多少，B是多少，而後根據這個時間兩個流播放的延時時間，以達到同步的目的。實現這個目的最簡單的辦法是在兩個流開始的時候，使用相同的stamp，拿音視頻來講，在某一絕對時刻，採集相應的數據，並打上相同的時間戳，之後的播放，都以這個時間作基準時間，以保證同步

 

 

3、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。

 

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

       其實，網絡發送重點關注的是流量的平衡，即均勻地利用網絡帶寬，爲了實現這一點，須要知足：數據採集的速率與數據網絡傳輸的速率儘可能保持一致。時間戳增量的設置影響的是RTP包的網絡傳輸的速率，時間戳增量越小，發送速度越快。

     

　　下面再進一步解釋一下時間戳增量是怎麼計算出來的：

       對於PAL制式的視頻而言，每秒攝像頭會採集 25 幀 數據，那麼，每採集到 1幀 耗時 1/25 s ，若是咱們設計爲1個RTP包只包含1幀數據，而且一次發送1幀，那麼，要想網絡流量均勻，則時間戳增量應該設計爲 1/25 s .  而在通常的RTP協議的實現中，時間戳單位不是 秒（s），而約定爲採樣頻率的倒數，因爲通常視頻的採樣頻率是 90000，故時間戳單位爲 1/90000 s，所以，實際的時間戳增量 = 時間戳增量 ( 1/25 s ) / 時間戳單位(1/90000 s) = 3600