最近被RTP的負載類型和時間戳搞郁悶了，一個問題調試了近一周，終于圓滿解決，回頭看看，發現其實主要原因還是自己沒有真正地搞清楚RTP協議中負載類型和時間戳的含義。雖然做RTP傳輸，有著Jrtplib和Ortp這兩個強大的庫支持，一個是c++接口，一個是c語言接口，各有各的特點，各有各的應用環境，但是僅僅有庫就能解決一切問題嗎？可能仿照著一些例子程序，你能夠完成主要的功能，但一旦問題發生了，不清楚原理你是很難定位和解決問題的，所以在此，用我的經驗勸勸大家，磨刀不誤砍柴工，做應用還是先把原理搞清楚再動手吧……
看這篇文章之前，首先你應該知道什么是RTP協議，可以去看RTP協議原文（RFC3550協議），也可以看一些網友對RTP協議的講解的文章，很多，這里我提供一篇我個人覺得寫得還不錯的：http://blog.csdn.net/bripengandre/archive/2008/04/01/2238818.aspx 。
好，下面言歸正傳，首先談談RTP傳輸中的負載類型吧。
首先，看RTP協議包頭的格式：
10~16 Bit為PT域，指的就是負載類型（PayLoad），負載類型定義了RTP負載的格式，協議原文說該域由具體應用決定其解釋。
目前，負載類型主要用來告訴接收端（或者播放器）傳輸的是哪種類型的媒體（例如G.729，H.264，MPEG-4等），這樣接收端（或者播放器）才知道了數據流的格式，才會調用適當的編解碼器去解碼或者播放，這就是負載類型的主要作用。
就ORTP庫（本文用的是ortp-0.9.1）而言，負載類型定義如下：
每一種負載類型都有著其獨特的參數，這里基本上涵蓋了當前主流的一些媒體類型，例如pcmu 、g.729、h.263（很奇怪，竟然沒有定義h.264，注：新版本已經添加了對h.264的支持）、mpeg-4等等。Jrtplib庫應該也有相類似的定義，你可以去找找源碼，在此我就不再贅述了。
在ORTP庫和JRTplib庫中，都提供了設置RTP負載類型的函數，千萬要記得根據實際的應用進行設置，我就是當時沒有注意，使用ORTP默認的pcmu音頻的負載類型，傳輸H.264編碼的視頻數據，結果傳輸中一直有問題，困擾我好久好久。
好了，再說說RTP的時間戳吧。
首先，了解幾個基本概念：
時間戳單位：時間戳計算的單位不是秒之類的單位，而是由采樣頻率所代替的單位，這樣做的目的就是為了是時間戳單位更為精準。比如說一個音頻的采樣頻率為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
在Jrtplib中好像不需要自己管理時間戳的遞增，由庫內部管理。但在ORTP中每次數據的發送都需要自己傳入時間戳的值，即自己需要每次發完一個RTP包后，累加時間戳增量，不是很方便，這就需要自己對RTP的時間戳有比較深刻地理解，我剛開始就是因為沒搞清楚，隨時設置時間戳增量導致傳輸一直有問題，困擾我好久。
好了，關于RTP的負載類型和時間戳的介紹就到這里了，這次通過解決RTP傳輸中的問題學到了不少知識，在此分享希望對大家有用。有說得不正確的地方歡迎高手指教，也可以來信交流：lujun.hust@gmail.com
本文出自 “對影成三人” 博客，請務必保留此出處http://ticktick.blog.51cto.com/823160/350142