原文來自百度文庫

androidrtsp流媒體播放介紹

1. rtsp協議介紹：

　該協議用於C/S模型，是一個基於文字的協議，用於在客戶端和伺服器端建立和協商實時流會話。

　　實時流協議（RTSP）是應用級協議，控制實時資料的傳送。RTSP提供了一個可擴充套件框架，使實時資料，如音訊與視訊，的受控、點播成為可能。資料來源包括現場資料與儲存在剪輯中資料。該協議目的在於控制多個數據傳送連線，為選擇傳送通道，如UDP、組播UDP與TCP，提供途徑，併為選擇基於RTP上傳送機制提供方法。

　　實時流協議（RTSP）建立並控制一個或幾個時間同步的連續流媒體。儘管連續媒體流與控制流交換是可能的，通常它本身並不傳送連續流。換言之，

　　協議支援的操作如下：

(1）從媒體伺服器上檢索媒體：使用者可通過HTTP或其它方法提交一個演示描述。如演示是組播，演示式就包含用於連續媒體的的組播地址和埠。如演示僅通過單播發送給使用者，使用者為了安全應提供目的地址。

(2）媒體伺服器邀請進入會議：媒體伺服器可被邀請參加正進行的會議，或回放媒體，或記錄其中一部分，或全部。這種模式在分散式教育應用上很有用，會議中幾方可輪流按遠端控制按鈕。

(3）將媒體加到現成講座中：如伺服器告訴使用者可獲得附加媒體內容，對現場講座顯得尤其有用。如HTTP/1.1中類似，RTSP請求可由代理、通道與快取處理。

RFC2326             Real Time Streaming Protocol           April 1998
method           direction        object    requirement
DESCRIBE         C->S            P,S       recommended
ANNOUNCE         C->S, S->C       P,S       optional
GET_PARAMETER     C->S, S->C      P,S       optional
OPTIONS          C->S, S->C       P,S       required
                                              (S->C: optional)
PAUSE            C->S            P,S       recommended
PLAY             C->S            P,S       required
RECORD           C->S            P,S       optional
REDIRECT         S->C            P,S       optional
SETUP            C->S            S         required
SET_PARAMETER     C->S, S->C      P,S       optional
TEARDOWN         C->S            P,S        required

RTSP命令的狀態轉換表

 Example:

     C->S: OPTIONS * RTSP/1.0
           CSeq: 1

     S->C: RTSP/1.0 200 OK
           CSeq: 1
           Public: DESCRIBE, SETUP, TEARDOWN, PLAY, PAUSE

 Example:

C->S:DESCRIBE rtsp://server.example.com/fizzle/foo RTSP/1.0
     CSeq:312
     Accept: application/sdp,application/rtsl, pplication/mheg

S->C:RTSP/1.0 200 OK
          CSeq: 312
          Date: 23 Jan 1997 15:35:06 GMT
          Content-Type: application/sdp
          Content-Length: 376

          v=0
          o=mhandley 2890844526 2890842807 IN IP4 126.16.64.4
          s=SDP Seminar
          i=A Seminar on the session description protocol
          u=http://www.cs.ucl.ac.uk/staff/M.Handley/sdp.03.ps
          [email protected](MarkHandley)
          c=IN IP4 224.2.17.12/127
          t=2873397496 2873404696
          a=recvonly
          m=audio 3456 RTP/AVP 0
          m=video 2232 RTP/AVP 31
          m=whiteboard 32416 UDP WB
          a=orient:portrait

C->S:SETUP rtsp://example.com/foo/bar/baz.rm RTSP/1.0
         CSeq: 302
         Transport: RTP/AVP;unicast;client_port=4588-4589

    S->C:RTSP/1.0 200 OK
         CSeq: 302
         Date: 23 Jan 1997 15:35:06 GMT
         Session: 47112344
         Transport: RTP/AVP;unicast;
           client_port=4588-4589;server_port=6256-6257

  C->S:PLAY rtsp://audio.example.com/audio RTSP/1.0
          CSeq: 835
          Session: 12345678
          Range: npt=10-15

     C->S:PLAY rtsp://audio.example.com/audio RTSP/1.0
          CSeq: 836
          Session: 12345678
          Range: npt=20-25

     C->S:PLAY rtsp://audio.example.com/audio RTSP/1.0
          CSeq: 837
          Session: 12345678
          Range: npt=30-

S->C:RTSP/1.0 200 OK          CSeq: 835          Date: 23 Jan 1997 15:35:06 GMT

C->S:TEARDOWN rtsp://example.com/fizzle/foo RTSP/1.0          CSeq: 892          Session: 12345678    S->C: RTSP/1.0 200 OK          CSeq: 892

二、RTP協議介紹：

RTP報文格式

RTP報文由兩部分組成：報頭和有效載荷。RTP報頭格式如圖6.7所示，其中：

       V：RTP協議的版本號，佔2位，當前協議版本號為2。

   P：填充標誌，佔1位，如果P=1，則在該報文的尾部填充一個或多個額外的八位組，它們不是有效載荷的一部分。

   X：擴充套件標誌，佔1位，如果X=1，則在RTP報頭後跟有一個擴充套件報頭。

   CC：CSRC計數器，佔4位，指示CSRC 識別符號的個數。

   M: 標記，佔1位，不同的有效載荷有不同的含義，對於視訊，標記一幀的結束；對於音訊，標記會話的開始。

   同步信源(SSRC)識別符號：佔32位，用於標識同步信源。該識別符號是隨機選擇的，參加同一視訊會議的兩個同步信源不能有相同的SSRC。

   特約信源(CSRC)識別符號：每個CSRC識別符號佔32位，可以有0～15個。每個CSRC標識了包含在該RTP報文有效載荷中的所有特約信源。

   PT: 有效載荷型別，佔7位，用於說明RTP報文中有效載荷的型別，如GSM音訊、JPEM影象等。

   序列號：佔16位，用於標識傳送者所傳送的RTP報文的序列號，每傳送一個報文，序列號增1。接收者通過序列號來檢測報文丟失情況，重新排序報文，恢復資料。

   時戳(Timestamp)：佔32位，時戳反映了該RTP報文的第一個八位組的取樣時刻。接收者使用時戳來計算延遲和延遲抖動，並進行同步控制。

V	P	X	CC	M	PT	序列號
時戳
同步信源(SSRC)識別符號
特約信源(CSRC)識別符號
···

這裡的同步信源是指產生媒體流的信源，它通過RTP報頭中的一個32位數字SSRC識別符號來標識，而不依賴於網路地址，接收者將根據SSRC識別符號來區分不同的信源，進行RTP報文的分組。特約信源是指當混合器接收到一個或多個同步信源的RTP報文後，經過混合處理產生一個新的組合RTP報文，並把混合器作為組合RTP報文的SSRC，而將原來所有的SSRC都作為CSRC傳送給接收者，使接收者知道組成組合報文的各個SSRC。

在傳送端，上層應用程式以分組形式將編碼後的媒體資料傳給RTP通訊模組，作為RTP報文的有效載荷，RTP通訊模組將根據上層應用提供的引數在有效載荷前新增RTP報頭，形成RTP報文，通過Socket介面選擇UDP協議傳送出去。

在接收端，RTP通訊模組通過Socket介面接收到RTP報文後，將RTP報頭分離出來作相應處理，再將RTP報文的有效載荷作為資料分組傳遞給上層應用。

三、Androidrtsp播放的設計：

Rtsp播放涉及到rtsp與rtp/rtcp兩個協議，rtsp用於控制流的互動，rtp用於資料流的包的封裝;在android裡MyHandle做為一個引擎控制這兩路流，ARTSPConnection用於rtsp的處理，ARTPConnection用於接收rtp資料，ARTPAssembler的子類負責對rtp資料解析。

解析完的資料上傳到MyHandle的緩衝中，RTSPSource從緩衝列表裡讀取資料給解碼器使用。

資料流圖

NuPlayer::RTSPSource

MyHandler

注：黑色的是tcp方式，藍色的udp方式來接收。

下面以h264的流的rtp封裝的方式來說明rtp協議對音視訊資料的封裝,rfc3984定義對h264的打包方式，對h264的流的解析與打包都必須遵守這個協議，h264的資料以nal單元為單位打包，H.264Payload 格式定義了三種不同的基本的負載(Payload)結構.接收端可能通過 RTPPayload 的第一個位元組來識別它們.這一個位元組類似 NALU頭的格式,而這個頭結構的 NAL單元型別欄位則指出了代表的是哪一種結構,

  這個位元組的結構如下,可以看出它和 H.264的 NALU頭結構是一樣的.
     +---------------+
     |0|1|2|3|4|5|6|7|
     +-+-+-+-+-+-+-+-+
      |F|NRI| Type   |

1. 單一NAL單元模式即一個 RTP包僅由一個完整的 NALU組成.這種情況下 RTPNAL 頭型別欄位和原始的H.264的
 NALU 頭型別欄位是一樣的.

  2.組合封包模式即可能是由多個 NAL單元組成一個 RTP包.分別有4種組合方式:STAP-A, STAP-B, MTAP16, MTAP24.
  那麼這裡的型別值分別是24,25, 26 以及 27.

  3.分片封包模式用於把一個 NALU單元封裝成多個 RTP包.存在兩種型別 FU-A和 FU-B.型別值分別是 28和 29.

在android的程式碼處理了在AAVCAssembler::addNALUnit裡面處理了單一NAL單元,STAP-A和FU-A三種包。這個類將會把接收的資料包處理成上層解碼器能解碼幀的資料上傳給上層。

四、時間戳同步：

對於rtsp的流媒體播放，時間多戳同步是十分重要的，根據RTP規範，不同的RTP媒體流是分開傳輸的，且使用各自獨立的時間戳進行同步。假設在一次視訊點播中，傳輸兩路RTP媒體流，一路視訊，一路音訊。根據視訊幀時間戳，可以實現視訊流內同步，這很好理解，通過視訊幀時間戳可以計算出相鄰視訊幀的時間間隔，也就是視訊幀之間的相對時間關係很容易通過時間戳來確定，按照這個間隔去呈現視訊，就可以獲得較好的效果。同理，音訊流也可以實現自身的同步。那麼音訊和視訊這兩路媒體間如何實現同步呢？我們只使用音視訊的RTP時間戳，看能否實現媒體間的同步。音視訊的RTP時間戳的增長速率一般是不同的，但沒關係，知道了具體的單位後，兩者是可以通過單位換算聯絡起來的。

把音視訊被對映到同一個時間軸上，音訊和視訊幀間的相對關係很清楚。慢著，RTP規範要求時間戳的初始值應該是一個隨機值，那麼假設音訊幀時間戳的初始值是隨機值1234，視訊幀時間戳的初始值是隨機值5678，看起來應該是下面這樣：

這麼做合適嗎？我們把音訊幀時間戳1234和視訊幀時間戳5678對應到絕對時間軸的0上，我們這麼做的理由是什麼？你可能會說，因為那是第一個音訊幀和第一個視訊幀，所以可以對應到同一個點上，在第一幅圖中我們就是這麼做的，把音訊幀時間戳0和視訊幀時間戳0對應到絕對時間軸的0上。但是RTP規範並沒有規定第一個視訊幀的時間戳和第一個音訊幀的時間戳必須或者應該對應到絕對時間軸的同一個點上，從整個RTP規範中不能直接得出這樣的結論，也推導不出這樣的結論。上圖所做的轉換是不正確的，為什麼呢？因為在做轉換時，隱含了一個假設，我們想當然地認為這個假設是成立的。這個假設就是第一個視訊幀和第一個音訊幀的時間戳應該對應到同一個點上，即無論它們時間戳是多少，都應該在同一時間播放。僅僅使用RTP時間戳是無法實現媒體間同步的，根本的原因是音訊時間軸和視訊時間軸是完全獨立的，通過音訊幀和視訊幀的時間戳，無法確定一個視訊幀和一個音訊幀的相對時間關係，也就是無法把它們都準確定位在絕對時間軸上，只能準確定位一個。

在rtp的規範裡，要實現RTP媒體間同步，需要藉助於RTCP，在RTCP的SR包中，包含有<NTP時間，RTP時間戳>對，音訊幀RTP時間戳和視訊幀RTP時間戳通過<NTP時間，RTP時間戳>對，都可以準確定位到絕對時間軸NTP上，音訊幀和視訊幀的相對時間關係就可以確定下來了。

在androidrtsp的原版的程式碼裡所以也是通過rtcp來的ntp-rtp時間對來同步的，由於ntp是伺服器的時間跟本機時間是一定的誤差，所以這個時間值本身就沒有了價值，它需要兩個時間對的差值才能來計算同步的時間戳，android的計算方式如下：

uint64_tARTPSource::RTP2NTP(uint32_t rtpTime) const {

CHECK_EQ(mNumTimes,2u);

returnmNTPTime[0] + (double)(mNTPTime[1] - mNTPTime[0])

*((double)rtpTime - (double)mRTPTime[0])

/(double)(mRTPTime[1] - mRTPTime[0]);

}

現在我們來分析這樣的一種情況，當我們接收的兩個rtcp的ntp-rtp時間對相差的時間很大或者沒有收到兩個以上的ntp-rtp時間對，那麼我們就無法計算出同步的時間戳，音視訊也就無法定位到ntp上無法同步，很不幸我們除錯過程中遇到了這種情況，在我面前的如何解決這個問題？於是我們回到前面的同步的方法，鑑於目前所有的流媒體服務端都是同時傳送音視訊資料的，所以我們可以不依賴於rtcp直接來同步。目前我們rtsp使用了這種方式來同步。從效果來看這種同步機制是簡單可靠的。

參考文件: