流媒體協議之RTSP詳解20170922

1、RTSP協議介紹

1.什麼是rtsp?

         RTSP協議以客戶服務器方式工做，，如：暫停/繼續、後退、前進等。它是一個多媒體播放控制協議，用來使用戶在播放從因特網下載的實時數據時可以進行控制,

所以 RTSP 又稱爲「因特網錄像機遙控協議」。

         RTSP(Real-Time Stream Protocol)是一種基於文本的應用層協議，在語法及一些消息參數等方面，RTSP協議與HTTP協議相似。

是TCP/IP協議體系中的一個應用層協議, 由哥倫比亞大學, 網景和RealNetworks公司提交的IETF RFC標準. 對應的RFC編號是2326，能夠在這裏搜索 RFC Editor

         該協議定義了一對多應用程序如何有效地經過IP網絡傳送多媒體數據. RTSP在體系結構上位於RTP和RTCP之上, 它使用TCP或RTP完成數據傳輸. RTSP被用於創建的控制媒體流的傳輸，它爲多媒體服務扮演「網絡遠程控制」的角色。儘管有時能夠把RTSP控制信息和媒體數據流交織在一塊兒傳送，但通常狀況RTSP自己並不用於轉送媒體流數據。

媒體數據的傳送可經過RTP/RTCP等協議來完成。

         該協議用於C/S模型, 是一個基於文本的協議, 用於在客戶端和服務器端創建和協商實時流會話.

         雖然RTSP服務器一樣也使用標識符來區別每一流鏈接會話（Session），但RTSP鏈接並無被綁定到傳輸層鏈接（如TCP等），也就是說在整個 RTSP鏈接期間，

RTSP用戶可打開或者關閉多個對RTSP服務器的可靠傳輸鏈接以發出RTSP 請求。此外，RTSP鏈接也能夠基於面向無鏈接的傳輸協議（如UDP等）。

 

2.網絡體系

RTSP是相似http的應用層協議，一個典型的流媒體框架網絡體系可參考下圖:

 

3.一次基本的RTSP操做過程

1).首先，客戶端鏈接到流服務器併發送一個RTSP描述命令（DESCRIBE）。

2).流服務器經過一個SDP描述來進行反饋，反饋信息包括流數量、媒體類型等信息。

3).客戶端再分析該SDP描述，併爲會話中的每個流發送一個RTSP創建命令(SETUP)，RTSP創建命令告訴服務器客戶端用於接收媒體數據的端口。流媒體鏈接創建完成後，

4).客戶端發送一個播放命令(PLAY)，服務器就開始在UDP上傳送媒體流（RTP包）到客戶端。 在播放過程當中客戶端還能夠向服務器發送命令來控制快進、快退和暫停等。

5).最後，客戶端可發送一個終止命令(TERADOWN)來結束流媒體會話

sequenceDiagram

客戶端->>服務器:DESCRIBE

服務器->>客戶端: 200 OK (SDP)

客戶端->>服務器:SETUP

服務器->>客戶端: 200 OK

客戶端->>服務器:PLAY

服務器->>客戶端: (RTP包)

 

4.協議特色

1).可擴展性: 新方法和參數很容易加入RTSP.

2).易解析: RTSP可由標準HTTP或MIME解析器解析.

3).安全: RTSP使用網頁安全機制.

4).獨立於傳輸: RTSP可以使用不可靠數據報協議(EDP), 可靠數據報協議(RDP); 如要實現應用級可靠, 可以使用可靠流協議.

5).多服務器支持: 每一個流可放在不一樣服務器上, 用戶端自動與不一樣服務器創建幾個併發控制鏈接, 媒體同步在傳輸層執行.

6).記錄設備控制: 協議可控制記錄和回放設備.

7).流控與會議開始分離: 僅要求會議初始化協議提供, 或可用來建立唯一會議標識號. 特殊狀況下, 可用SIP或H.323來邀請服務器入會.

8).適合專業應用: 經過SMPTE時標, RTSP支持幀級精度, 容許遠程數字編輯.

9).演示描述中立: 協議沒強加特殊演示或元文件, 可傳送所用格式類型; 然而, 演示描述至少必須包括一個RTSP URL.

10).代理與防火牆友好: 協議可由應用和傳輸層防火牆處理. 防火牆須要理解SETUP方法, 爲UDP媒體流打開一個「缺口」.

11).HTTP友好: 此處, RTSP明智地採用HTTP觀念, 使如今結構均可重用. 結構包括Internet內容選擇平臺(PICS). 因爲在大多數狀況下控制連續媒體須要服務器狀態, RTSP不只僅向HTFP添加方法.

12).適當的服務器控制: 如用戶啓動一個流, 必須也能夠中止一個流.

13).傳輸協調: 實際處理連續媒體流前, 用戶可協調傳輸方法.

14).性能協調: 如基本特徵無效, 必須有一些清理機制讓用戶決定哪一種方法沒生效. 這容許用戶提出適合的用戶界面.

 

5.RTSP協議與HTTP協議區別

1).RTSP引入了幾種新的方法，好比DESCRIBE、PLAY、SETUP 等，而且有不一樣的協議標識符，RTSP爲rtsp 1.0,HTTP爲http 1.1；

2).HTTP是無狀態的協議，而RTSP爲每一個會話保持狀態；

3).RTSP協議的客戶端和服務器端均可以發送Request請求，而在HTTPF 協議中，只有客戶端能發送Request請求。

4).在RTSP協議中，載荷數據通常是經過帶外方式來傳送的(除了交織的狀況)，及經過RTP協議在不一樣的通道中來傳送載荷數據。而HTTP協議的載荷數據都是經過帶內方式傳送的，好比請求的網頁數據是在迴應的消息體中攜帶的。

5).使用ISO 10646(UTF-8) 而不是ISO 8859-1，以配合當前HTML的國際化；

6).RTSP使用URI請求時包含絕對URI。而因爲歷史緣由形成的向後兼容性問題，HTTP/1.1只在請求中包含絕對路徑，把主機名放入單獨的標題域中；

 

2、RTSP重要術語

1.   集合控制(Aggregatecontrol ):

對多個流的同時控制。對音頻/視頻來說，客戶端僅需發送一條播放或者暫停消息就可同時控制音頻流和視頻流。

2.   實體(Entity)：

做爲請求或者回應的有效負荷傳輸的信息。由以實體標題域（entity-header field）形式存在的元信息和以實體主體（entity body）形式存在的內容組成

3.   容器文件（Containerfile）：

能夠容納多個媒體流的文件。RTSP服務器能夠爲這些容器文件提供集合控制。

4.   RTSP會話(RTSP session )：

RTSP交互的全過程。對一個電影的觀看過程,會話(session)包括由客戶端創建媒體流傳輸機制(SETUP)，使用播放(PLAY)或錄製(RECORD)開始傳送流，用中止(TEARDOWN)關閉流。

 

3、RTSP 的報文結構

1.RTSP URL的語法結構

一個終端用戶是經過在播放器中輸入URL地址開始進行觀看流媒體業務的第一步，而對於使用RTSP協議的移動流媒體點播而言，URL的通常寫法以下：

一個以「rtsp」或是「rtspu」開始的URL連接用於指定當前使用的是RTSP 協議。RTSP URL的語法結構以下：

rtsp_url    =       (「rtsp:」| 「rtspu:」) 「//」 host [「:」port」] /[abs_path]/content_name

host：能夠是一個有效的域名或是IP地址。

port：端口號，對於RTSP協議來講，缺省的端口號爲554。當咱們在確認流媒體服務器提供的端口號爲554時，此項能夠省略 說明：當HMS服務器使用的端口號爲554時，咱們在寫點播連接時，能夠不用寫明端口號，但當使用非554端口時，在RTSP URL中必定要指定相應的端口。

abs_path: 爲RTSPServer中的媒體流資源標識

RTSPURL用來標識RTSPServer的媒體流資源，能夠標識單一的媒體流資源，也能夠標 識多個媒體流資源的集合。

 

2.RTSP的報文結構

    RTSP是一種基於文本的協議，用CRLF做爲一行的結束符。使用基於文本協議的好處在於咱們能夠隨時在使用過程當中的增長自定義的參數，也能夠隨便將協議包抓住很直觀的進行分析。

    RTSP有兩類報文：請求報文和響應報文。請求報文是指從客戶向服務器發送請求報文，響應報文是指從服務器到客戶的回答。

    因爲 RTSP 是面向正文的(text-oriented)，所以在報文中的每個字段都是一些 ASCII 碼串，於是每一個字段的長度都是不肯定的。

    RTSP報文由三部分組成，即開始行、首部行和實體主體。在請求報文中，開始行就是請求行.

2.1.請求報文

請求報文的結構以下圖所示

 

也就是說：

方法 URI RTSP版本       CR LF

消息頭 CR LF          CR LF        

消息體 CR LF

 

1).請求消息的第一行的語法結構以下：

Request-Line   =       Method 空格 Request-URI 空格 RTSP-Version CRLF

其中方法包括OPIONS、DESCRIBE、SETUP、PLAY、TEARDOWN等,URI是接受方的地址,例如:rtsp://192.168.0.1/video1.3gp。

RTSP版本通常都是 RTSP/1.0。每行後面的CR LF表示回車換行，須要接受端有相應的解析，

 

2).在消息頭中除了第一行的內容外，還有一些需求提供附加信息。其中有些是必定要的，後續咱們會詳細介紹常常用到的幾個域的含義。

  消息頭           =       Accept

                        |       Accept-Encoding

                        |       Accept-Language

                        |       Authorization

                        |       From

                        |       If-Modified-Since

                        |       Range

                        |       Referer

                        |       User-Agent

3).最後一個消息頭須要有兩個CR LF。消息體是可選的，有的Request消息並不帶消息體。

 

2.2.響應報文

響應報文的開始行是狀態行，RTSP響應報文的結構以下圖所示

 

也就是說：

RTSP版本狀態碼解釋      CR LF

消息頭 CR LF          CR LF

消息體 CR LF

 

1).響應消息的第一行是狀態行（status-line），每一個元素之間用空格分開。除了最後的CRLF以外，在此行的中間不得有CR或是LF的出現。它的語法格式以下，

Status-Line = RTSP-Version 空格 Status-Code 空格 Reason-Phrase CRLF

 

狀態碼（Status-Code） 是一個三位數的整數，用於描述接收方對所收到請求消息的執行結果，

Status-Code的第一位數字指定了這個回覆消息的種類，一共有5類：

 1XX: Informational – 請求被接收到，繼續處理

 2XX: Success – 請求被成功的接收，解析並接受

 3XX: Redirection – 爲完成請求須要更多的操做

 4XX: Client Error – 請求消息中包含語法錯誤或是不可以被有效執行

 5XX: Server Error – 服務器響應失敗，沒法處理正確的有效的請求消息

咱們在處理問題時常常會遇到的狀態碼有以下：

| | |

---|---|---|---|--- Status-Code | = |「200」|          : OK . || | 「400」|      : Bad Request . || | 「404」|      : Not Found . || |     「500」|      : Internal Server Error

2).在響應消息的域中存放的是沒法放在Status-Line中,而又須要傳送給請求者的一些附加信息。

  消息頭            =       Location

                         |       Proxy-Authenticate

                         |       Public

                         |       Retry-After

                         |       Server

                         |       Vary

                         |       WWW-Authenticate

3.RTSP的主要方法

方法	方向	對象	要求	含義
DESCRIBE	C->S	P,S	推薦	檢查演示或媒體對象的描述，也容許使用接收頭指定用戶理解的描述格式。DESCRIBE的答覆-響應組成媒體RTSP初始階段
ANNOUNCE	C->S  S->C	P,S	可選	當從用戶發往服務器時，ANNOUNCE將請求URL識別的演示或媒體對象描述發送給服務器；反之，ANNOUNCE實時更新鏈接描述。如新媒體流加入演示，整個演示描述再次發送，而不只僅是附加組件，使組件能被刪除
GET_PARAMETER	C->S  S->C	P,S	可選	GET_PARAMETER請求檢查RUL指定的演示與媒體的參數值。沒有實體體時，GET_PARAMETER也許能用來測試用戶與服務器的連通狀況
OPTIONS	C->S  S->C	P,S	要求	可在任意時刻發出OPTIONS請求，如用戶打算嘗試非標準請求，並不影響服務器狀態
PAUSE	C->S	P,S	推薦	PAUSE請求引發流發送臨時中斷。如請求URL命名一個流，僅回放和記錄被中止；如請求URL命名一個演示或流組，演示或組中全部當前活動的流發送都中止。恢復回放或記錄後，必須維持同步。在SETUP消息中鏈接頭超時參數所指定時段期間被暫停後，儘管服務器可能關閉鏈接並釋放資源，但服務器資源會被預訂
PLAY	C->S	P,S	要求	PLAY告訴服務器以SETUP指定的機制開始發送數據；直到一些SETUP請求被成功響應，客戶端纔可發佈PLAY請求。PLAY請求將正常播放時間設置在所指定範圍的起始處，發送流數據直到範圍的結束處。PLAY請求可排成隊列，服務器將PLAY請求排成隊列，順序執行
RECORD	C->S	P,S	可選	該方法根據演示描述初始化媒體數據記錄範圍，時標反映開始和結束時間；如沒有給出時間範圍，使用演示描述提供的開始和結束時間。如鏈接已經啓動，當即開始記錄，服務器數據請求URL或其餘URL決定是否存儲記錄的數據；如服務器沒有使用URL請求，響應應爲201（建立），幷包含描述請求狀態和參考新資源的實體與位置頭。支持現場演示記錄的媒體服務器必須支持時鐘範圍格式，smpte格式沒有意義
REDIRECT	S->C	P,S	可選	重定向請求通知客戶端鏈接到另外一服務器地址。它包含強制頭地址，指示客戶端發佈URL請求；也可能包括參數範圍，以指明重定向什麼時候生效。若客戶端要繼續發送或接收URL媒體，客戶端必須對當前鏈接發送TEARDOWN請求，而對指定主執新鏈接發送SETUP請求
SETUP	C->S	S	要求	對URL的SETUP請求指定用於流媒體的傳輸機制。客戶端對正播放的流發佈一個SETUP請求，以改變服務器容許的傳輸參數。如不容許這樣作，響應錯誤爲"455 Method Not Valid In This State」。爲了透過防火牆，客戶端必須指明傳輸參數，即便對這些參數沒有影響
SET_PARAMETER	C->S S->C	P,S	可選	請求設置演示或URL指定流的參數值。請求僅應包含單個參數，容許客戶端決定某個特殊請求爲什麼失敗。如請求包含多個參數，全部參數可成功設置，服務器必須只對該請求起做用。服務器必須容許參數可重複設置成同一值，但不讓改變參數值。注意：媒體流傳輸參數必須用SETUP命令設置。將設置傳輸參數限制爲SETUP有利於防火牆。將參數劃分紅規則排列形式，結果有更多有意義的錯誤指示
TEARDOWN	C->S	P,S	要求	TEARDOWN請求中止給定URL流發送，釋放相關資源。如URL是此演示URL，任何RTSP鏈接標識再也不有效。除非所有傳輸參數是鏈接描述定義的，SETUP請求必須在鏈接可再次播放前發佈

注：P---演示，C---客戶端,S---服務器， S（對象欄）---流

信令指的是在Request-URI中指定的須要被接收者完成的操做。信令（The method）大小寫敏感，不能以字符」$」開始，而且必定要是一個標記符。

 

4.RTSP重要頭字段參數

1).Accept: 用於指定客戶端能夠接受的媒體描述信息類型。好比: Accept: application/rtsl, application/sdp;level=2

2).Bandwidth: 用於描述客戶端可用的帶寬值。

3).CSeq： 指定了RTSP請求迴應對的序列號，在每一個請求或迴應中都必須包括這個頭字段。對每一個包含一個給定序列號的請求消息，都會有一個相同序列號的迴應消息。

4).Rang： 用於指定一個時間範圍，可使用SMPTE、NTP或clock時間單元。

5).Session: Session頭字段標識了一個RTSP會話。Session ID 是由服務器在SETUP的迴應中選擇的，客戶端一當獲得Session ID後，在之後的對Session 的操做請求消息中都要包含Session ID.

6).Transport: Transport頭字段包含客戶端能夠接受的轉輸選項列表，包括傳輸協議，地址端口，TTL等。服務器端也經過這個頭字段返回實際選擇的具體選項。如: Transport: RTP/AVP;multicast;ttl=127;mode="PLAY", RTP/AVP;unicast;client_port=3456-3457;mode="PLAY"

 

4、簡單的RTSP消息交互過程

C表示RTSP客戶端,S表示RTSP服務端

 

1.第一步：查詢服務器端可用方法

C->S OPTION request //詢問S有哪些方法可用

S->C OPTION response //S迴應信息的public頭字段中包括提供的全部可用方法

 

2.第二步：獲得媒體描述信息

C->S DESCRIBE request //要求獲得S提供的媒體描述信息

S->C DESCRIBE response //S迴應媒體描述信息，通常是sdp信息

 

3.第三步：創建RTSP會話

C->S SETUP request //經過Transport頭字段列出可接受的傳輸選項，請求S創建會話

S->C SETUP response //S創建會話，經過Transport頭字段返回選擇的具體轉輸選項，並返回創建的Session ID;

 

4.第四步：請求開始傳送數據

C->S PLAY request //C請求S開始發送數據

S->C PLAY response //S迴應該請求的信息

 

5.第五步： 數據傳送播放中

S->C 發送流媒體數據 // 經過RTP協議傳送數據

 

6.第六步：關閉會話，退出

C->S EARDOWN request //C請求關閉會話

S->C TEARDOWN response //S迴應該請求

 

上述的過程只是標準的、友好的rtsp流程，但實際的需求中並不必定按此過程。

其中第三和第四步是必需的！第一步，只要服務器和客戶端約定好有哪些方法可用，則option請求能夠不要。第二步，

若是咱們有其餘途徑獲得媒體初始化描述信息（好比http請求等等），則咱們也不須要經過rtsp中的describe請求來完成。

 

5、RTSP的請求響應示例

其中C是客戶端，S是服務端。

1.        OPTIONS:

用於獲得服務器提供的可用方法；

如:

OPTIONS rtsp://192.168.20.136:5000/xxx666 RTSP/1.0

CSeq: 1

       

服務器的迴應信息會在Public字段列出提供的方法。如:

RTSP/1.0 200 OK

CSeq: 1        //每一個迴應消息的cseq數值和請求消息的cseq相對應

Public: OPTIONS, DESCRIBE, SETUP, TEARDOWN, PLAY, PAUSE

 

2.        DESCRIBE：

客戶端向服務器端發送DESCRIBE，用於獲得URI所指定的媒體描述信息，通常是SDP信息。客戶端經過Accept頭指定客戶端能夠接受的媒體述信息類型。

如：

C->S: DESCRIBE rtsp://server.example.com/fizzle/fooRTSP/1.0

CSeq: 312

Accept: application/sdp, application/rtsl,application/mheg)

 

服務器迴應URI指定媒體的描述信息:

如:

S->C: RTSP/1.0 200 OK

CSeq: 312

Date: 23 Jan 1997 15:35:06 GMT

Content-Type: application/sdp  //表示迴應爲SDP信息

Content-Length: 376

//這裏爲一個空行

//如下爲具體的SDP信息

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

e=mjh@isi.edu (Mark Handley)

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

//字段解釋

V=0     ;Version 給定了SDP協議的版本

o=<username><session id> <version> <network type> <address type>

<address>； Origin ,給定了會話的發起者信息

s=<sessionname> ;給定了Session Name

i=<sessiondescription> ; Information 關於Session的一些信息

u=<URI> ; URI

e=<emailaddress>    ;Email

c=<networktype> <address type> <connection address> ;Connect Data包含鏈接數據

t=<start time><stop time> ;Time

a=<attribute>     ; Attribute

a=<attribute>:<value>

m=<media><port> <transport> <fmt list> ; MediaAnnouncements

 

媒體初始化是任何基於RTSP系統的必要條件，但RTSP規範並無規定它必須經過DESCRIBE方法完成。RTSP客戶端能夠經過如下方法來接收媒體描述信息：

a)  經過DESCRIBE方法；

b)  其它一些協議（HTTP，email附件，等）；

c)  經過命令行或標準輸入設備

 

另外一個例子：

命令名稱：DESCRIBE

命令做用：請求SDP

命令格式：

DESCRIBE<BLANK><RTSP URI><BLANK>RTSP/<RTSP VERSION>\r\nCSeq:<BLANK><COMMAND SEQUENCE>\r\n\r\n

（Note：<BLANK>：空格；<COMMAND SEQUENCE>：命令序列，每一次發送命令該數字加1）

命令示例：

DESCRIBE rtsp://127.0.0.1/ansersion RTSP/1.0

CSeq: 1

（Note：雖然看不見，但示例中最後是有空行的，必不可少哦！看看「命令格式」最後連着兩個"\r\n"你就明白了。空行（\r\n）是RTSP數據包的結束標識。）

服務端返回信息格式：

RTSP/<RTSP VERSION><BLANK><STATE ID><BLANK><STATE DESCRIBE>\r\nCSeq:<BLANK><COMMAND SEQUENCE>\r\n<OTHER>\r\n\r\n<SDP>

（Note：<OTHER>: 其餘描述信息；<SDP>: SDP描述信息，SDP不屬於RTSP的打包數據，這裏能夠看到空行（\r\n）在SDP以前）

服務端返回信息示例：

RTSP/1.0 200 OK

CSeq: 1

Date: Sun, Dec 27 2015 02:16:50 GMT

Content-Base: rtsp://127.0.0.1/ansersion/

Content-Type: application/sdp

Content-Length: 510

v=0

o=- 1451182595570866 1 IN IP4 192.168.81.145

s=Session streamed by "testOnDemandRTSPServer"

i=ansersion

t=0 0

a=tool:LIVE555 Streaming Media v2015.11.09

a=type:broadcast

a=control:*

a=range:npt=0-

a=x-qt-text-nam:Session streamed by "testOnDemandRTSPServer"

a=x-qt-text-inf:ansersion

m=video 0 RTP/AVP 96

c=IN IP4 0.0.0.0

b=AS:500

a=rtpmap:96 H264/90000

a=fmtp:96 packetization-mode=1;profile-level-id=4D4033;sprop-parameter-sets=Z01AM5JUDAS0IAAAAwBAAAAM0eMGVA==,aO48gA==

a=control:track1

（Note：以RTSP客戶端的角度，以上紅字部分信息必須理解。

首先是"RTSP/1.0 200 OK"，這個表示RTSP服務端成功受理客戶端的請求。

再者是「m=video 0 RTP/AVP 96」，該信息指出了RTSP客戶端提供傳輸的流媒體類型，「a=control:track1」指出了訪問該流媒體的方式，是後續SETUP命令的重要參數，這是一個簡化的版本，有時候服務端會返回完整版本：「a=control:rtsp://127.0.0.1/ansersion/track1」。

最後是「Z01AM5JUDAS0IAAAAwBAAAAM0eMGVA==」和「aO48gA==」，這是H264的SPS和PPS的Base64編碼。老實說，要讓RTSP客戶端去考慮具體編碼格式的問題，着實是一個設計上的瑕疵。後續我打算把這部分改掉，如今咱們將其看做H264的重要參數便可）

 

在SDP中也說明了本次會話的屬性

SDP 參數

下面描述瞭如何在 SDP 中表示一個 H.264 流:

. "m=" 行中的媒體名必須是 "video"

. "a=rtpmap" 行中的編碼名稱必須是 "H264".

. "a=rtpmap" 行中的時鐘頻率必須是 90000.

. 其餘參數都包括在 "a=fmtp" 行中.

如:

m=video 49170 RTP/AVP 98

a=rtpmap:98 H264/90000

a=fmtp:98 profile-level-id=42A01E; packetization-mode=1; sprop-parameter-sets=Z0IACpZTBYmI,aMljiA==

下面介紹一些經常使用的參數.

1). packetization-mode:

表示支持的封包模式.

當 packetization-mode 的值爲 0 時或不存在時, 必須使用單一 NALU 單元模式.

當 packetization-mode 的值爲 1 時必須使用非交錯(non-interleaved)封包模式.

當 packetization-mode 的值爲 2 時必須使用交錯(interleaved)封包模式.

每一個打包方式容許的NAL單元類型總結(yes = 容許, no = 不容許, ig = 忽略)

      Type   Packet    Single NAL    Non-Interleaved    Interleaved

                       Unit Mode           Mode             Mode

      -------------------------------------------------------------

      0      undefined     ig               ig               ig

      1-23   NAL unit     yes              yes               no

      24     STAP-A        no              yes               no

      25     STAP-B        no               no              yes

      26     MTAP16        no               no              yes

      27     MTAP24        no               no              yes

      28     FU-A          no              yes              yes

      29     FU-B          no               no              yes

      30-31  undefined     ig               ig               ig

這個參數不能夠取其餘的值.

2). sprop-parameter-sets: SPS,PPS

這個參數能夠用於傳輸 H.264 的序列參數集和圖像參數 NAL 單元. 這個參數的值採用 Base64 進行編碼. 不一樣的參數集間用","號隔開.

3).profile-level-id:

這個參數用於指示 H.264 流的 profile 類型和級別. 由 Base16(十六進制) 表示的 3 個字節. 第一個字節表示 H.264 的 Profile 類型, 第三個字節表示 H.264 的 Profile 級別:

4).max-mbps:

這個參數的值是一個整型, 指出了每一秒最大的宏塊處理速度.

 

3.        SETUP：

用於肯定轉輸機制，創建RTSP會話。客戶端可以發出一個SETUP請求爲正在播放的媒體流改變傳輸參數，服務器可能贊成這些參數的改變。如果不一樣意，它必須響應錯誤"455 Method Not Valid In This State"。

Request中的Transport頭字段指定了客戶端可接受的數據傳輸參數；Response中的Transport 頭字段包含了由服務器選出的傳輸參數。

如:

C->S: SETUP rtsp://example.com/foo/bar/baz.rm RTSP/1.0

CSeq: 302

Transport: RTP/AVP;unicast;client_port=4588-4589

 

服務器端對SETUPRequest產生一個Session Identifiers。

如:

S->C: RTSP/1.0 200 OK

CSeq: 302

Date: 23 Jan 1997 15:35:06 GMT

Session: 47112344 //產生一個SessionID

Transport: RTP/AVP;unicast;

client_port=4588-4589;server_port=6256-6257

另外一個例子:

命令名稱：SETUP

命令做用：創建流媒體會話，告知RTSP服務端準備資源，以待後續進一步操做（好比「PLAY」）

命令格式：

SETUP<BLANK><RTSP URI>/<SDP ATTRIBUTE CONTROL>RTSP/<RTSP VERSION>\r\nTransport:<BLANK><PROTOCOL>;<CAST METHOD>;client_port=<RTP PORT>-<RTCP PORT>\r\nCSeq:<BLANK><COMMAND SEQUENCE>\r\n\r\n

（Note：<SDP ATTRIBUTE CONTROL>：SDP中「a=control:track1」；<PROTOCOL>：實時流傳輸協議，通常爲RTP+UDP；<CAST METHOD>：傳輸方式，單播或組播；）

命令示例：

SETUP rtsp://127.0.0.1/ansersion/track1 RTSP/1.0

Transport: RTP/AVP/UDP;unicast;client_port=10330-10331

CSeq: 2

（Note：使用RTP傳輸（RTP/AVP/UDP），傳輸方式爲單播（unicast），RTP和RTCP的端口號分別爲10330和10331（client_port=10330-10331））

服務端返回信息格式：

RTSP/<RTSP VERSION><BLANK><STATE ID><BLANK><STATE DESCRIBE>\r\nCSeq:<BLANK><COMMAND SEQUENCE>\r\n<OTHER>\r\n<SESSION ID>\r\n\r\n

（Note：<SESSION ID>：服務端創建好資源後，經過該標識訪問其媒體流資源。）

服務端返回信息示例：

RTSP/1.0 200 OK

CSeq: 2

Date: Sun, Dec 27 2015 02:28:01 GMT

Transport: RTP/AVP;unicast;destination=127.0.0.1;source=127.0.0.1;client_port=10330-10331;server_port=6970-6971

Session: ABF519D9;timeout=65

（Note：其中「ABF519D9」爲SESSION ID，PLAY命令以此爲參數，告知服務端以SETUP命令中指定的方式（RTP、unicast、client_port=10330-10331）進行媒體流傳輸）

 

4.        PLAY：

PLAY方法告知服務器經過SETUP中指定的機制開始發送數據 。在還沒有收到SETUP請求的成功應答以前，客戶端不能夠發出PLAY請求。

PLAY請求將正常播放時間（normal play time）定位到指定範圍的起始處，而且傳輸數據流直到播放範圍結束。PLAY請求可能被管道化（pipelined），即放入隊列中（queued）；

服務器必須將PLAY請求放到隊列中有序執行。也就是說，後一個PLAY請求須要等待前一個PLAY請求完成才能獲得執行。

好比，在下例中，無論到達的兩個PLAY請求之間有多緊湊，服務器首先play第10到15秒，而後當即第20到25秒，最後是第30秒直到結束。

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-

 

Range頭可能包含一個時間參數。該參數以UTC格式指定了播放開始的時間。若是在這個指定時間後收到消息，那麼播放當即開始。時間參數可能用來幫助同步從不一樣數據源獲取的數據流。

不含Range頭的PLAY請求也是合法的。它從媒體流開頭開始播放，直到媒體流被暫停。若是媒體流經過PAUSE暫停，媒體流傳輸將在暫停點（the pause point）從新開始。若是媒體流正在播放，那麼這樣一個PLAY請求將不起更多的做用，只是客戶端能夠用此來測試服務器是否存活。

 

5.        PAUSE：

PAUSE請求引發媒體流傳輸的暫時中斷。若是請求URL中指定了具體的媒體流，那麼只有該媒體流的播放和記錄被暫停（halt）。

好比，指定暫停音頻，播放將會無聲。若是請求URL指定了一組流，那麼在該組中的全部流的傳輸將被暫停。如：

C->S: PAUSE rtsp://example.com/fizzle/foo RTSP/1.0

CSeq: 834

Session: 12345678

 

S->C: RTSP/1.0 200 OK

CSeq: 834

Date: 23 Jan 1997 15:35:06 GMT

 

PAUSE請求中可能包含一個Range頭用來指定什麼時候媒體流暫停，咱們稱這個時刻爲暫停點（pause point）。該頭必須包含一個精確的值，而不是一個時間範圍。媒體流的正常播放時間設置成暫停點。

當服務器遇到在任何當前掛起（pending）的PLAY請求中指定的時間點後，暫停請求生效。

若是Range頭指定了一個時間超出了任何一個當前掛起的PLAY請求，將返回錯誤"457 Invalid Range" 。

若是一個媒體單元（好比一個音頻或視頻禎）正好在一個暫停點開始，那麼表示將不會被播放或記錄。

若是Range頭缺失，那麼在收到暫停消息後媒體流傳輸當即中斷，而且暫停點設置成當前正常播放時間。

 

6.        TEARDOWN：

TEARDOWN請求終止了給定URI的媒體流傳輸，並釋放了與該媒體流相關的資源。如：

C->S: TEARDOWN rtsp://example.com/fizzle/foo RTSP/1.0

CSeq: 892

Session: 12345678

 

S->C: RTSP/1.0 200 OK

CSeq: 892

 

6、參考的原文:

https://github.com/EasyDarwin/Course/tree/master/流媒體開發實戰進階(RTSP視頻播放器)

http://blog.csdn.net/leixiaohua1020/article/details/11955341

http://blog.csdn.net/pu1030/article/details/7619908

http://www.cnblogs.com/ansersion/p/5079758.html

http://blog.csdn.net/ajiva/article/details/276909

http://www.rfc-editor.org/info/rfc2326

http://blog.csdn.net/zblue78/article/details/5948538