轉自：http://blog.163.com/liu_nongfu/blog/static/19079414220139169225333/
一、流媒體簡介
流媒體是指在internet中使用流媒體技術的連續時基媒體，例如視頻、音頻或多媒體文件。流式傳輸方式是將音視頻、動畫等多媒體文件經過壓縮后分成一個個小數據包，當用戶端發出請求時，由服務器端向用戶端實時、連續傳送這些小數據包，動態變化的網絡可能使各個包選擇不同的路由，故到達用戶端的時間延遲也就不同。在用戶端用播放器播放時，需要為接收數據開辟緩存區，以彌補時延和時延抖動的影響和保證數據包傳輸順序的正確，經解壓縮后，只需要在緩沖區充滿前等待幾秒鍾，就可以連續觀看。而同時，后續數據包繼續在后台從服務器端以穩定的速率向客戶端發送，不影響前台播放。所以從理論上講，播放前的延時主要是由於播放器接收、處理前幾個數據包引起的，一旦播放就能夠保證連續性和穩定性。流式傳輸的實現不僅需要高效的壓縮算法和緩存，而且需要合適的傳輸協議。由於tcp需要較多的開銷，不太適合傳輸實時數據。在流式傳輸的實現方案中，一般采用http/tcp來傳輸控制信息，而用RTP/UDP來傳輸實時視音頻數據。實現流式傳輸一般都需要專用的媒體服務器和媒體播放器。
二、流媒體傳輸的網絡協議：RTP與RTCP介紹
1.實時傳輸協議RTP( Real-time Transport Protocol)
RTP被定義在一對一或一對多傳輸下工作，其目的是提供時間信息和實現流同步。RTP封裝了多媒體應用的數據塊。RTP不建立連接，不保證交付，也不進行資源預留。RTP本身並不能為按順序傳送數據包提供可靠的傳送機制，也不提供流量控制或擁塞控制，它依靠RTCP提供這些服務。RTP屬於應用層協議，在應用發送端，開發者必須編寫用RTP封裝分組的程序代碼。RTP由IETF定義在 RFC 3550和3551中。
2.實時傳輸控制協議RTCP(RTP Control Ptotocol)
RTCP的主要功能是：服務質量的監視與反饋、媒體間的同步，以及多播組中成員的標識。在RTP會話期間，各參與者周期性地傳送RTCP包。RTCP包中含有已發送的數據包的數量、丟失的數據包的數量、數據包到達的平均時間間隔等統計信息，因此，各參與者可以利用這些信息動態地改變傳輸速率，甚至改變有效載荷類型。RTP和RTCP配合使用，它們能以有效的反饋和最小的開銷使傳輸效率最佳化，因而特別適合傳送網上的實時數據。
三、RTP與RTCP的協議層次及封裝
RTP位於傳輸層（通常是UDP）之上，應用程序之下，實時語音、視頻數據經過模數轉換和壓縮編碼處理后，先送給RTP封裝成為RTP數據單元，RTP數據單元被封裝為UDP數據報，然后再向下遞交給IP封裝為IP數據包。
RTP分組只包含RTP數據，而控制是由另一個配套協議RTCP提供。RTP在端口號1024到65535之間選擇一個未使用的偶數UDP端口號，而在同一次會話中的RTCP則使用下一個奇數UDP端口號。
RTP通常和RTCP一起工作，在RTP會話期間，各參與者周期的發送RTCP消息。RTCP消息也被封裝為UDP數據報進行傳輸。
四、RTP協議頭信息
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|V=2|P|X| CC |M| PT | sequence number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| timestamp |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| synchronization source (SSRC) identifier |
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
| contributing source (CSRC) identifiers |
| .... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
version (V): 2 bits
標明RTP版本號。協議初始版本為0，RFC3550中規定的版本號為2。
padding (P): 1 bit
如果該位被設置，則在該packet末尾包含了額外的附加信息，附加信息的最后一個字節表示額外附加信息的長度（包含該字節本身）。該字段之所以存在是因為一些加密機制需要固定長度的數據塊，或者為了在一個底層協議數據單元中傳輸多個RTP packets。
extension (X): 1 bit
如果該位被設置，則在固定的頭部后存在一個擴展頭部，格式定義在RFC3550 5.3.1節。
CSRC count (CC): 4 bits
在固定頭部后存在多少個CSRC標記。
marker (M): 1 bit
該位的功能依賴於profile的定義。profile可以改變該位的長度，但是要保持marker和payload type總長度不變（一共是8 bit）。
payload type (PT): 7 bits
標記着RTP packet所攜帶信息的類型，標准類型列出在RFC3551中。如果接收方不能識別該類型，必須忽略該packet。負載類型主要用來告訴接收端(或者播放器)傳輸的是哪種類型的媒體（例如G.729，H.264，MPEG-4等），這樣接收端（或者播放器）才知 道了數據流的格式，才會調用適當的編解碼器去解碼或者播放，這就是負載類型的主要作用。
sequence number: 16 bits
序列號，每個RTP packet發送后該序列號加1，接收方可以根據該序列號重新組合數據包順序，判斷包是否丟失等操作。注意：它只是表示了包的先后順序，它不能表示時間上的任何其它信息。
timestamp: 32 bits
時間戳。反映RTP packet所攜帶信息包中第一個字節的采樣時間(詳見下文)。
SSRC: 32 bits
數據源標識。在一個RTP Session其間每個數據流都應該有一個不同的SSRC。
CSRC list: 0 to 15 items, 每個源標識32 bits
貢獻數據源標識。只有存在Mixer的時候才有效。如一個將多聲道的語音流合並成一個單聲道的語音流，在這里就列出原來每個聲道的SSRC。
關於RTP的時間戳(timestamp):
時間戳單位：時間戳計算的單位不是秒，而是采用采樣頻率的倒數，這樣做的目的是為了使時間戳單位更為精准。比如說一個音頻的采樣頻率為8000Hz，那么我們可以把時間戳單位設為1/8000s。
時間戳增量：相鄰兩個RTP包之間的時間差(以時間戳單位為基准)
采樣頻率： 每秒鍾抽取樣本的次數，例如音頻的采樣率一般為8000Hz，即每秒采樣8000次，產生8000個樣本
幀率： 每秒傳輸或者顯示幀數，例如25f/s時間戳反映了RTP分組中的數據的第一個字節的采樣時刻。在一次會話開始時的時間戳初值也是隨機選擇的。即使是沒有信號發送時，時間戳的數值也要隨時間不 斷的增加。接收端使用時間戳可准確知道應當在什么時間還原哪一個數據塊，從而消除傳輸中的抖動。時間戳還可用來使視頻應用中聲音和圖像同步。
在RTP協議中並沒有規定時間戳的粒度，這取決於有效載荷的類型。因此RTP的時間戳又稱為媒體時間戳，以強調這種時間戳的粒度取決於信號的類型。例如，對於8kHz采樣的音頻信號，若每隔20ms構成一個數據塊，則一個數據塊中包含有160個樣本（0.02×8000=160）。因此每發送一個RTP分 組，其時間戳的值就增加160。
如果采樣頻率為90000Hz，則時間戳單位為1/90000，我們就假設1s鍾被划分了90000個時間塊，那么，如果每秒發送25幀，那么，每一個幀的發送占多少個時間塊呢？當然是 90000/25 = 3600。因此，我們根據定義“時間戳增量是發送第二個RTP包相距發送第一個RTP包時的時間間隔”，故時間戳增量應該為3600。時間戳可用來使視頻應用中聲音和圖像同步，為什么呢？
首先，時間戳就是一個值，用來反映某個數據塊的產生(采集)時間點的， 后采集的數據塊的時間戳肯定是大於先采集的數據塊的。有了這樣一個時間戳，就可以標記數據塊的先后順序。
第二，在實時流傳輸中，數據采集后立刻傳遞到RTP 模塊進行發送，那么，其實，數據塊的采集時間戳就直接作為RTP包的時間戳。
第三，如果用RTP來傳輸固定的文件，則這個時間戳 就是讀文件的時間點，依次遞增。這個不再我們當前的討論范圍內，暫時不考慮。
五、RTCP協議
RTCP協議處理機定義了五種類型的報文，它們完成接收、分析、產生和發送控制報文的功能。
1.SR(sender report)發送者報告分組：用來使發送端周期的向所有接收端用多播方式進行報告。內容包括：
該RTP流的SSRC；該RTP流中最新產生的RTP分組的時間戳和絕對時鍾時間(或稱牆上時間：wall clock time);該RTP流包含的分組數；該RTP流包含的字節數。
絕對時鍾時間是必要的。因為RTP要求每一種媒體使用一個流。有了絕對時鍾時間就可以進行圖形和聲音的同步。
2.RR(receiver report)接收者報告分組：用來使接收端周期性的向所有的點用多播方式進行報告。內容包括所接收到的RTP流的SSRC；該RTP流的分組丟失率；在該RTP流中的最后一個RTP分組的序號；分組到達時間間隔的抖動等。
發送RR分組有兩個目的。第一，可以使所有的接收端和發送端了解當前網絡的狀態。
第二，可以使所有發送RTCP分組的站點自適應的調整自己發送RTCP分組的速率，RTCP分組的通信量不超過網絡中的數據分組的通信量的5%，而接收端分組報告分組的通信量又應小於所有RTCP分組的通信量的75%。
3.SDES(source description items)源描述分組：給出會話中參加者的描述，包括參加者的規范名(CNAME)
4.BYE(indicates end of participation)分組：關閉一個數據流。
5.APP(application specific functions)分組：應用程序能夠定義新的分組類型。
在RTCP中，還有兩個比較重要的東西，一個64位的絕對時間戳和一個32位的相對時間戳。64 位時間戳也叫NTP時間戳，它的前 32位是從1900 年1 月1 日0 時開始到現在的以秒為單位的整數部分，后32位是此時間的小數部，因此，它可以肯定的表示了數據發送出去的絕對時間。32位的時間戳和RTP中的時間戳是一樣的，沒有任何區別。
六、媒體流的同步：流內同步和流間同步
多媒體通信同步方法，主要有時間戳同步法、同步標記法、多路復用同步法三種。下面主要討論時間戳同步法，特別是RTP時間戳同步。內容包括RTP媒 體間同步的實現，為什么需要RTCP的NTP時間來實現媒體間同步？沒有RTCP，能實現RTP媒體間的同步嗎？
序列號字段是否可以作為流內的同步標識？序列號只表示了包發出的先后順序，它表示不了任何時間上的其它概念，所以嚴格的說，序列號並不能作為流內的同步標志。但是，由於一般來說，包的發送時間都會有嚴格限制，比如音頻包是每秒種發送30個數據包，也就是說，每個包間隔1000/30MS，而這個時間就可以 作為一個同步時間來播放。也就是說，按照序列號，每1000/30MS間隔播放一個數據包，這樣也能保證同步，但是這時候請考慮丟包問題。
根據RTP規范，不同的RTP媒體流是分開傳輸的，且使用各自獨立的時間戳進行同步。假設在一次視頻點播中，傳輸兩路RTP媒體流，一路視頻，一路音頻。根據視頻幀時間戳，可以實現視頻流內同步，這很好理解，通過視頻幀時間戳可以計算出相鄰視頻幀的時間間隔，也就是視頻幀之間的相對時間關系很容易通過時間戳來確定，按照這個間隔去呈現視頻，就可以獲得較好的效果。同理，音頻流也可以實現自身的同步。那么音頻和視頻這兩路媒體間如何實現同步呢？我們只使用音視頻的RTP時間戳，看能否實現媒體間的同步。音視頻的RTP時間戳的增長速率一般是不同的，但沒關系，知道了具體的單位后，兩者是可以通過單位換算聯系起來的。如下：
視頻幀時間戳單位：90000Hz，幀率：25fps
音頻幀時間戳單位：8000Hz，幀率：50fps
A:音頻幀 V:視頻幀 A/V:音頻幀和視頻幀
音頻幀時間戳：0 160 320 480 640 ...... 音頻時間軸
視頻幀時間戳：0 3600 7200 ...... 視頻時間軸
A/V A A/V A A/V
絕對時間軸： 0 20 40 60 80 ...... 單位：ms
現在來看，這種方法好像可以實現同步，因為音視頻被映射到同一個時間軸上了，音頻和視頻幀間的相對關系很清楚。慢着，RTP規范要求時間戳的初 始值應該是一個隨機值，那么假設音頻幀時間戳的初始值是隨機值1234，視頻幀時間戳的初始值是隨機值5678，看起來應該是下面這樣：
音頻幀時間戳：1234 1394 1554 1714 1874 ...... 音頻時間軸 視頻幀時間戳：5678 9278 12878 ...... 視頻時間軸 A/V A A/V A A/V 絕對時間軸： 0 20 40 60 80 ...... 單位：ms
這么做合適嗎？我們把音頻幀時間戳1234和視頻幀時間戳5678對應到絕對時間軸的0上，我們這么做的理由是什么？你可能會說，因為那是第一個音頻幀和第一個視頻幀，所以可以對應到同一個點上，在第一幅圖中我們就是這么做的，把音頻幀時間戳0和視頻幀時間戳0對應到絕對時間軸的0上。但是RTP規范並沒有規定第一個視頻幀的時間戳和第一個音頻幀的時間戳必須或者應該對應到絕對時間軸的同一個點上，從整個RTP規范中不能直接得出這樣的結論，也推導不出這樣的結論。
我們上面兩幅圖所做的轉換是不正確的，為什么呢？因為在做轉換時，隱含了一個假設，我們想當然地認為這個假設是成立的，實際上它並不總是成立。這個假設就是第一個視頻幀和第一個音頻幀的時間戳應該對應到同一個點上，即無論它們時間戳是多少，都應該在同一時間播放。
僅僅使用RTP時間戳是無法實現媒體間同步的，根本的原因是音頻時間軸和視頻時間軸是完全獨立的，通過音頻幀和視頻幀的時間戳，無法確定一個視頻幀和一個音頻幀的相對時間關系，也就是無法把它們都准確定位在絕對時間軸上。
要實現RTP媒體間同步，需要借助於RTCP，在RTCP的SR包中，包含有對，音頻幀RTP時間戳和視頻幀RTP時間戳通過對，都可以准確定位到絕對時間軸NTP上，音頻幀和視頻幀的相對時間關系就可以確定下來 了。
上面提到，我們的那個隱含的假設並不總是成立，那就是說它有成立的時候。那是不是說當它成立時，我們就可以不用RTCP來做媒體間同步了？答案是，基本上可以這么認為。例如，對於RTP實時流，在發送端媒體間就同步的很好，在接收端只需做少許處理，不需要RTCP，就可以實現媒體間同步。當然，這只是少數例外。因為RTP規范並不包括這個假設，所以我們還是按照RTP規范來做吧。
Sourceurl: http://hongdow.com/rtp%E3%80%81rtcp%E5%8F%8A%E5%AA%92%E4%BD%93%E6%B5%81%E5%90%8C%E6%AD%A5.html