1、android rtsp 流媒體播放介紹一、 rtsp 協(xié)議介紹：1二、 RTP 協(xié)議介紹：7三、 Android rtsp 播放的設計：8四、時間戳同步：10一、 rtsp 協(xié)議介紹：該協(xié)議用于 C/S 模型，是一個基于文本的協(xié)議，用于在客戶端和服務器端建立和協(xié)商實時流會話。實時流協(xié)議（ RTSP ）是應用級協(xié)議，控制實時數(shù)據(jù)的發(fā)送。 RTSP 提供了一個可擴展框架，使實時數(shù)據(jù)，如音頻與視頻，的受控、點播成為可能。數(shù)據(jù)源包括現(xiàn)場數(shù)據(jù)與存儲在剪輯中數(shù)據(jù)。 該協(xié)議目的在于控制多個數(shù)據(jù)發(fā)送連接， 為選擇發(fā)送通道，如 UDP 、組播 UDP 與 TCP ，提供途徑，并為選擇基于 RTP 上發(fā)送機制提

2、供方法。實時流協(xié)議（ RTSP ）建立并控制一個或幾個時間同步的連續(xù)流媒體。盡管連續(xù)媒體流與控制流交換是可能的，通常它本身并不發(fā)送連續(xù)流。 換言之，RTSP充當多媒體服務器的網(wǎng)絡遠程控制。 RTSP 連接沒有綁定到傳輸層連接， 如 TCP 。在 RTSP 連接期間，RTSP 用戶可打開或關閉多個對服務器的可傳輸連接以發(fā)出RTSP 請求。此外，可使用無連接傳輸協(xié)議，如UDP 。RTSP 流控制的流可能用到 RTP ，但 RTSP 操作并不依賴用于攜帶連續(xù)媒體的傳輸機制。協(xié)議支持的操作如下：(1）從媒體服務器上檢索媒體： 用戶可通過 HTTP 或其它方法提交一個演示描述。如演示是組播， 演示式就包

3、含用于連續(xù)媒體的的組播地址和端口。 如演示僅通過單播發(fā)送給用戶，用戶為了安全應提供目的地址。(2）媒體服務器邀請進入會議：媒體服務器可被邀請參加正進行的會議，或回放媒體，或記錄其中一部分，或全部。這種模式在分布式教育應用上很有用，會議中幾方可輪流按遠程控制按鈕。(3）將媒體加到現(xiàn)成講座中：如服務器告訴用戶可獲得附加媒體內(nèi)容，對現(xiàn)場講座顯得尤其有用。如 HTTP/1.1 中類似， RTSP 請求可由代理、通道與緩存處理。RFC 2326ProtocolmethodReal Time StreamingApril 1998directionobjectrequirementDESCRIBEC-&g

4、t;SP,SrecommendedANNOUNCEC->S,S->CP,SoptionalGET_PARAMETERC->S,S->CP,SoptionalOPTIONSC->S,S->CP,Srequired(S->C: optional)PAUSEC->SP,SrecommendedPLAYC->SP,SrequiredRECORDC->SP,SoptionalREDIRECTS->CP,SoptionalSETUPC->SSrequiredSET_PARAMETERC->S,S->CP,Soptional

5、TEARDOWNC->SP,SrequiredRTSP 命令的狀態(tài)轉換表Example:C->S:OPTIONS * RTSP/1.0CSeq: 1S->C:RTSP/1.0 200 OKCSeq: 1Public:DESCRIBE,SETUP, TEARDOWN,PLAY,PAUSEExample:C->S: DESCRIBE rtsp:/ RTSP/1.0CSeq: 312Accept: application/sdp, application/rtsl,pplication/mhegS->C: RTSP/1.0 200 OKCSeq: 312Date: 23

6、 Jan 1997 15:35:06 GMTContent-Type: application/sdpContent-Length: 376v=0o=mhandley 2890844526 2890842807 IN IP4s=SDP Seminari=A Seminar on the session descriptionprotocolu=http:/www.cs.ucl.ac.uk/staff/M.Handley/sdp.03.pse=(Mark Handley)c=IN IP4 2/127t=2873397496 28734

7、04696a=recvonlym=audio 3456 RTP/AVP 0m=video 2232 RTP/AVP 31m=whiteboard 32416 UDP WBa=orient:portraitC->S: SETUP rtsp:/ RTSP/1.0CSeq: 302Transport:RTP/AVP;unicast;client_port=4588-4589S->C: RTSP/1.0 200 OKCSeq: 302Date: 23 Jan 1997 15:35:06 GMTSession: 47112344Transport: RTP/AVP;unicast;clien

8、t_port=4588-4589;server_port=6256-6257C->S: PLAY rtsp:/ RTSP/1.0CSeq: 835Session: 12345678Range: npt=10-15C->S: PLAY rtsp:/ RTSP/1.0CSeq: 836Session: 12345678Range: npt=20-25C->S: PLAY rtsp:/ RTSP/1.0CSeq: 837Session: 12345678Range: npt=30-S->C: RTSP/1.0 200 OKCSeq: 835Date: 23 Jan 1997

9、15:35:06 GMTC->S: TEARDOWN rtsp:/ RTSP/1.0CSeq: 892Session: 12345678S->C: RTSP/1.0 200 OKCSeq: 892二、 RTP 協(xié)議介紹：RTP 報文格式RTP 報文由兩部分組成：報頭和有效載荷。RTP 報頭格式如圖 6.7 所示，其中：V ：RTP 協(xié)議的版本號，占2 位，當前協(xié)議版本號為2。P ：填充標志，占 1 位，如果 P=1 ，則在該報文的尾部填充一個或多個額外的八位組，它們不是有效載荷的一部分。X ：擴展標志，占 1 位，如果 X=1 ，則在 RTP 報頭后跟有一個擴展報頭。CC ：CSR

10、C 計數(shù)器，占 4 位，指示 CSRC 標識符的個數(shù)。M: 標記，占 1 位，不同的有效載荷有不同的含義，對于視頻，標記一幀的結束；對于音頻，標記會話的開始。同步信源 (SSRC) 標識符：占 32 位，用于標識同步信源。該標識符是隨機選擇的，參加同一視頻會議的兩個同步信源不能有相同的SSRC 。特約信源 (CSRC) 標識符：每個 CSRC 標識符占 32 位，可以有 015 個。每個 CSRC 標識了包含在該RTP 報文有效載荷中的所有特約信源。PT: 有效載荷類型，占 7 位，用于說明 RTP 報文中有效載荷的類型， 如 GSM 音頻、 JPEM 圖像等。序列號：占 16 位，用于標識發(fā)

11、送者所發(fā)送的 RTP 報文的序列號，每發(fā)送一個報文，序列號增 1。接收者通過序列號來檢測報文丟失情況，重新排序報文，恢復數(shù)據(jù)。時戳 (Timestamp) ：占 32 位，時戳反映了該 RTP 報文的第一個八位組的采樣時刻。接收者使用時戳來計算延遲和延遲抖動，并進行同步控制。VPXCC MPT序列號時戳同步信源 (SSRC) 標識符特約信源 (CSRC) 標識符···這里的同步信源是指產(chǎn)生媒體流的信源，它通過RTP 報頭中的一個 32 位數(shù)字SSRC 標識符來標識，而不依賴于網(wǎng)絡地址，接收者將根據(jù)SSRC 標識符來區(qū)分不同的信源，進行 RTP 報文的分組。特約信源

12、是指當混合器接收到一個或多個同步信源的 RTP 報文后，經(jīng)過混合處理產(chǎn)生一個新的組合RTP 報文，并把混合器作為組合 RTP 報文的 SSRC ，而將原來所有的 SSRC 都作為 CSRC 傳送給接收者，使接收者知道組成組合報文的各個SSRC 。在發(fā)送端，上層應用程序以分組形式將編碼后的媒體數(shù)據(jù)傳給RTP 通信模塊，作為 RTP 報文的有效載荷， RTP 通信模塊將根據(jù)上層應用提供的參數(shù)在有效載荷前添加 RTP 報頭，形成 RTP 報文，通過 Socket 接口選擇 UDP 協(xié)議發(fā)送出去。在接收端， RTP 通信模塊通過 Socket 接口接收到 RTP 報文后，將 RTP 報頭分離出來作相應

13、處理，再將 RTP 報文的有效載荷作為數(shù)據(jù)分組傳遞給上層應用。三、 Android rtsp 播放的設計：Rtsp 播放涉及到rtsp 與 rtp/rtcp 兩個協(xié)議， rtsp 用于控制流的交互，rtp 用于數(shù)據(jù)流的包的封裝 ;在 android 里 MyHandle 做為一個引擎控制這兩路流，ARTSPConnection 用于 rtsp 的處理， ARTPConnection 用于接收rtp 數(shù)據(jù)， ARTPAssembler 的子類負責對rtp 數(shù)據(jù)解析。解析完的數(shù)據(jù)上傳到MyHandle的緩沖中， RTSPSource 從緩沖列表里讀取數(shù)據(jù)給解碼器使用。數(shù)據(jù)流圖NuPlayer:RT

14、SPSourceMyHandlerARTPConnectionARTSPConnectionARTPSourceRtsp 流程處理ARTPAssembler注：黑色的是tcp 方式，藍色的udp 方式來接收。下面以 h264 的流的 rtp 封裝的方式來說明rtp 協(xié)議對音視頻數(shù)據(jù)的封裝 ,rfc3984 定義對 h264 的打包方式， 對 h264 的流的解析與打包都必須遵守這個協(xié)議， h264 的數(shù)據(jù)以 nal 單元為單位打包， H.264 Payload 格式定義了三種不同的基本的負載 (Payload) 結構 .接收端可能通過RTP Payload的第一個字節(jié)來識別它們 .這一個字節(jié)類

15、似NALU 頭的格式 ,而這個頭結構的NAL 單元類型字段則指出了代表的是哪一種結構,這個字節(jié)的結構如下 ,可以看出它和 H.264的 NALU 頭結構是一樣的 .+-+|0|1|2|3|4|5|6|7|+-+-+-+-+-+-+-+-+|F|NRI|Type|1. 單一 NAL 單元模式即一個 RTP 包僅由一個完整的 NALU 組成 . 這種情況下 RTP NAL 頭類型字段和原始的 H.264 的NALU 頭類型字段是一樣的 .2. 組合封包模式即可能是由多個NAL 單元組成一個 RTP 包.分別有 4 種組合方式 :STAP-A, STAP-B, MTAP16, MTAP24.那么這里

16、的類型值分別是 24, 25, 26以及 27.3. 分片封包模式用于把一個 NALU 單元封裝成多個RTP 包.存在兩種類型 FU-A 和FU-B. 類型值分別是 28和29.在android的代碼處理了在AA VCAssembler:addNALUnit里面處理了單一NAL單元 ,STAP-A和 FU-A三種包。 這個類將會把接收的數(shù)據(jù)包處理成上層解碼器能解碼幀的數(shù)據(jù)上傳給上層。四、時間戳同步：對于 rtsp 的流媒體播放， 時間多戳同步是十分重要的， 根據(jù) RTP規(guī)范，不同的 RTP媒體流是分開傳輸?shù)模?且使用各自獨立的時間戳進行同步。 假設在一次視頻點播中，傳輸兩路 RTP媒體流，一路

17、視頻，一路音頻。根據(jù)視頻幀時間戳，可以實現(xiàn)視頻流內(nèi)同步， 這很好理解，通過視頻幀時間戳可以計算出相鄰視頻幀的時間間隔，也就是視頻幀之間的相對時間關系很容易通過時間戳來確定， 按照這個間隔去呈現(xiàn)視頻， 就可以獲得較好的效果。 同理，音頻流也可以實現(xiàn)自身的同步。 那么音頻和視頻這兩路媒體間如何實現(xiàn)同步呢？我們只使用音視頻的RTP時間戳，看能否實現(xiàn)媒體間的同步。音視頻的 RTP時間戳的增長速率一般是不同的，但沒關系，知道了具體的單位后， 兩者是可以通過單位換算聯(lián)系起來的。把音視頻被映射到同一個時間軸上，音頻和視頻幀間的相對關系很清楚。慢著，RTP規(guī)范要求時間戳的初始值應該是一個隨機值， 那么假設音頻

18、幀時間戳的初始值是隨機值 1234，視頻幀時間戳的初始值是隨機值 5678，看起來應該是下面這樣：這么做合適嗎？我們把音頻幀時間戳 1234 和視頻幀時間戳 5678對應到絕對時間軸的 0 上，我們這么做的理由是什么？你可能會說， 因為那是第一個音頻幀和第一個視頻幀， 所以可以對應到同一個點上， 在第一幅圖中我們就是這么做的， 把音頻幀時間戳 0 和視頻幀時間戳 0 對應到絕對時間軸的 0 上。但是 RTP規(guī)范并沒有規(guī)定第一個視頻幀的時間戳和第一個音頻幀的時間戳必須或者應該對應到絕對時間軸的同一個點上， 從整個 RTP規(guī)范中不能直接得出這樣的結論， 也推導不出這樣的結論。 上圖所做的轉換是不正

19、確的， 為什么呢？因為在做轉換時， 隱含了一個假設，我們想當然地認為這個假設是成立的。 這個假設就是第一個視頻幀和第一個音頻幀的時間戳應該對應到同一個點上， 即無論它們時間戳是多少， 都應該在同一時間播放。 僅僅使用 RTP時間戳是無法實現(xiàn)媒體間同步的， 根本的原因是音頻時間軸和視頻時間軸是完全獨立的， 通過音頻幀和視頻幀的時間戳， 無法確定一個視頻幀和一個音頻幀的相對時間關系， 也就是無法把它們都準確定位在絕對時間軸上，只能準確定位一個。在 rtp 的規(guī)范里，要實現(xiàn) RTP媒體間同步，需要借助于 RTCP，在 RTCP的 SR包中，包含有 <NTP時間， RTP時間戳 >對，音頻幀 RTP時間戳和視頻幀 RTP時間戳通過 <NTP時間， RTP時間戳 >對，都可以準確定位到絕對時間軸 NTP上，