2. 程式人生 > >RTSP協議 sdp

RTSP協議 sdp

阿新 • • 發佈：2018-11-15

第一部分:RTSP協議

 

一、RTSP協議概述

 

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

 

RTSP被用於建立的控制媒體流的傳輸，它為多媒體服務扮演“網路遠端控制”的角色。儘管有時可以把RTSP控制資訊和媒體資料流交織在一起傳送，但一般情況RTSP本身並不用於轉送媒體流資料。媒體資料的傳送可通過RTP/RTCP等協議來完成。

 

一次基本的RTSP操作過程是:

首先，客戶端連線到流伺服器併發送一個RTSP描述命令（DESCRIBE）。

流伺服器通過一個SDP描述來進行反饋，反饋資訊包括流數量、媒體型別等資訊。

客戶端再分析該SDP描述，併為會話中的每一個流傳送一個RTSP建立命令(SETUP)，RTSP建立命令告訴伺服器客戶端用於接收媒體資料的埠。

流媒體連線建立完成後，客戶端傳送一個播放命令(PLAY)，伺服器就開始在UDP上傳送媒體流（RTP包）到客戶端。

在播放過程中客戶端還可以向伺服器傳送命令來控制快進、快退和暫停等。最後，客戶端可傳送一個終止命令(TERADOWN)來結束流媒體會話

 

二、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.  使用ISO10646(UTF-8) 而不是ISO 8859-1，以配合當前HTML的國際化；

 

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

 

三、RTSP重要術語

 

1.   集合控制(Aggregatecontrol ):

 

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

 

2.   實體(Entity)：

 

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

 

3.   容器檔案（Containerfile）：

 

可以容納多個媒體流的檔案。RTSP伺服器可以為這些容器檔案提供集合控制。

 

4.   RTSP會話(RTSP session )：

 

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

 

四、RTSP請求訊息

 

1.   訊息格式：

 

方法 URI RTSP版本       CR LF

 

訊息頭 CRLF          CRLF         

 

訊息體 CR LF

 

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

 

RTSP版本一般都是 RTSP/1.0。每行後面的CR LF表示回車換行，需要接受端有相應的解析，最後一個訊息頭需要有兩個CR LF

 

訊息體是可選的，有的Request訊息並不帶訊息體。

 

五、RTSP迴應訊息

 

1.   訊息格式：

 

    RTSP版本 狀態碼 解釋      CR LF

 

訊息頭 CR LF          CR LF

 

訊息體 CR LF

 

其中RTSP版本一般都是RTSP/1.0,

狀態碼是一個數值，用於表示Request訊息的執行結果,比如200表示成功,

解釋是與狀態碼對應的文字解釋.

 

六、RTSP 重要方法

 

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

 

[email protected] (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

 

媒體初始化是任何基於RTSP系統的必要條件，但RTSP規範並沒有規定它必須通過DESCRIBE方法完成。RTSP客戶端可以通過以下方法來接收媒體描述資訊：

 

a)  通過DESCRIBE方法；

 

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

 

c)  通過命令列或標準輸入裝置

 

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

 

伺服器端對SETUP Request產生一個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

 

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

 

七、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"

 

八、簡單的RTSP訊息互動過程

 

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

 

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

 

 1.C->S:OPTIONrequest       //詢問S有哪些方法可用

 

1.S->C:OPTIONresponse    //S迴應資訊的public頭欄位中包括提供的所有可用方法

 

2.   第二步：得到媒體描述資訊

 

2.C->S:DESCRIBE request      //要求得到S提供的媒體描述資訊

 

2.S->C:DESCRIBE response    //S迴應媒體描述資訊，一般是sdp資訊

 

3.   第三步：建立RTSP會話

 

3.C->S:SETUPrequest            //通過Transport頭欄位列出可接受的傳輸選項，請求S建立會話

 

3.S->C:SETUPresponse          //S建立會話，通過Transport頭欄位返回選擇的具體轉輸選項，並返回建立的Session ID;

 

4.   第四步：請求開始傳送資料

 

4.C->S:PLAY request        //C請求S開始傳送資料

 

4.S->C:PLAYresponse            //S迴應該請求的資訊

 

5.   第五步： 資料傳送播放中

 

S->C:傳送流媒體資料    // 通過RTP協議傳送資料

 

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

 

6.C->S:TEARDOWN request      //C請求關閉會話

 

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

 

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

 

其中第三和第四步是必需的！第一步，只要伺服器客戶端約定好，有哪些方法可用，則option請求可以不要。第二步，如果我們有其他途徑得到媒體初始化描述資訊（比如http請求等等），則我們也不需要通過rtsp中的describe請求來完成。

 

第二部分:SDP協議

 

一、SDP協議概述

 

SDP(SessionDescription Protocol )會話描述協議，用於描述多媒體會話，它為會話通知、會話初始和其它形式的多媒體會話初始等操作提供服務。

 

SDP的設計宗旨是通用性協議，所有它可以應用於很大範圍的網路環境和應用程式，但 SDP 不支援會話內容或媒體編碼的協商操作。

 

SDP資訊包括：

  • 會話名稱和目標；
  • 會話活動時間；
  • 構成會話的媒體；
  • 有關接收媒體的資訊、地址等。

二、SDP格式

 

SDP 資訊是文字資訊，UTF-8 編碼採用 ISO 10646 字元設定。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

[email protected] (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= （協議版本）
  • o= （所有者/建立者和會話識別符號）
  • s= （會話名稱）
  • i=* （會話資訊）
  • u=* （URI 描述）
  • e=* （Email 地址）
  • p=* （電話號碼）
  • c=* （連線資訊 ― 如果包含在所有媒體中，則不需要該欄位）
  • b=* （頻寬資訊）

　　一個或更多時間描述（如下所示）：

  • z=* （時間區域調整）
  • k=* （加密金鑰）
  • a=* （0個或多個會話屬性線路）
  • 0個或多個媒體描述（如下所示）

　　時間描述

  • t= （會話活動時間）
  • r=* （0或多次重複次數）

　　媒體描述

  • m= （媒體名稱和傳輸地址）
  • i=* （媒體標題）
  • c=* （連線資訊 — 如果包含在會話層則該欄位可選）
  • b=* （頻寬資訊）
  • k=* （加密金鑰）
  • a=* （0個或多個會話屬性線路）

三、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

 

[email protected] (Mark Handley)

 

c=IN IP4 224.2.17.12/127

 

t=2873397496 2873404696

 

a=recvonly

 

m=audio 49170 RTP/AVP 0

 

m=video 51372 RTP/AVP 31

 

m=application 32416 udp wb

 

a=orient:portrait

 

//欄位解釋

 

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

 

o=

 

； Origin ,給定了會話的發起者資訊

 

s= ;給定了Session Name

 

i= ; Information 關於Session的一些資訊

 

u= ; URI

 

e=    ;Email

 

c=

 

;Connect Data包含連線資料

 

t=

 

a=     ; Attribute

 

a=:

 

m= ; MediaAnnouncements

相關推薦

RTSP協議 sdp

第一部分:RTSP協議   一、RTSP協議概述   RTSP(Real-Time Stream Protocol )是一種基於文字的應用層協議，在語法及一些訊息引數等方面，RTSP協議與HTTP協議類似。   RTSP被用於建立的控制媒體流

rtsp和sdp協議簡介

目前還沒有 RTSP 連線的概念；伺服器維護由識別符標識的會話。RTSP 會話不會繫結到傳輸層連線，如 TCP。在 RTSP 會話期間，RTSP 客戶端可開啟或關閉多個對伺服器的可靠傳輸連線以發出 RTSP 請求。它也可選擇使用無連線傳輸協議，如 UDP。 RTSP 控制的流可能用到 RTP，但 RTSP

RTSP協議詳解

5.1 handler 詳解 finally 運行 綁定 prot mage accepted RTSP簡介 RTSP（Real Time Streaming Protocol）是由Real Network和Netscape共同提出的如何有效地在IP網絡上傳輸流媒

(轉)RTSP協議詳解

定義 attach highlight not xtend prev desc 設備 代理服 轉自：https://www.cnblogs.com/lidabo/p/6553212.html RTSP簡介 RTSP（Real Time Streaming Prot

RTSP協議轉換RTMP協議，直播網路攝像頭

　　RTSP協議也是廣泛使用的直播/點播流媒體協議，以前的專案裡實現了一個RTSP協議轉換RTMP直播協議的程式，為的是可以接收遠端裝置或伺服器的多路RTSP直播資料，實時轉換為RTMP直播協議，推送到NginxRtmp等RTMP伺服器，可以在PC上實現flash觀看RTSP直播源（比如IP

RTSP 協議分析

RTSP 協議分析1.概述：  RTSP（Real Time Streaming Protocol），實時流傳輸協議，是TCP/IP協議體系中的一個應用層協議，由哥倫比亞大學、網景和RealNetworks公司提交的IETF RFC標準。該協議定義了一對多應用程式如何有效地通過IP網路傳

H.264+AAC在會話描述協議SDP中格式

預備知識《SDP 引數說明》，讀者可以先參考連結地址  https://blog.csdn.net/zymill/article/details/79836953 -------------------------------------------------------

會話描述協議-SDP協議介紹

    SDP會話描述協議，是描述流媒體初始化引數的格式，由IETF作為RFC 4566頒佈，為會話通知、會話邀請和其它形式的多媒體會話初始化等目的提供了多媒體會話描述。會話目錄用於協助多媒體會議的通告，併為會話參與者傳送相關設定資訊。 SDP 即用於將這種資訊傳輸到接收端。 S

RTSP協議、RTMP協議、HTTP協議的區別

RTSP、 RTMP、HTTP的共同點、區別 共同點： 1：RTSP RTMP HTTP都是在應用應用層。 2： 理論上RTSP RTMPHTTP都可以做直播和點播，但一般做直播用RTSP RTMP，做點播用HTTP。做視訊會議的時候原來用SIP協議，現在

【視訊開發】EasyIPCamera通過RTSP協議接入海康、大華等攝像機，摒棄私有SDK接入弊端

近期工作中需要開發一套視訊監控系統，實現WEB端、手機APP端預覽區域網內的道路監控攝像機，我負責一些後臺服務的開發工作。       由於之前專案中的程式都是採用私有協議、各攝像機廠商的SDK進行視訊監控系統開發，這種技術方案更適合C/S架構的系統，應用於此次專案存在

RTSP協議與G711 AAC

文章目錄 文件 RTSP/RTP over TCP + G711 OPTIONS DESCRIBE SETUP PLAY TEARDOWN RTP over TCP的封裝格式 RTPS/RTP

在IPCAM上實現RTSP協議直播-live555

為了實現網路播放，找協議找開源找破了頭。終於找到一個能用的 當播出來的時候，震驚了！這也太容易了。列下步驟如下： 2，編譯之，在該網站上有說明，基本命令： ./genMakefile linux make 3，開啟live/testProgs/testOnDemandR

RTSP協議分析與標準RTSP服務端與客戶端互動流程

1.1.   RTSP協議簡介 一種應用層協議，可基於tcp或udp協議。 RTSP（Real Time StreamingProtocol，實時流媒體協議）是由Real Network和Netscape共同提出的一種應用層協議，它定義瞭如何在IP網路上有效地傳輸流媒

RTSP 協議 簡單互動過程

Real Time Streaming Protocol或者RTSP（實時流媒體協議），是由Real network 和 Netscape共同提出的如何有效地在IP網路上傳輸流媒體資料的應用層協議。RTSP提供一 種可擴充套件的框架，使能夠提供可控制的，按需傳輸實時資料，

在IPCAM上實現RTSP協議直播-live555 轉

為了實現網路播放，找協議找開源找破了頭。終於找到一個能用的 當播出來的時候，震驚了！這也太容易了。列下步驟如下： 2，編譯之，在該網站上有說明，基本命令： ./genMakefile linux make 3，開啟live/testProgs/testOnDemandRTSPServer.c

android錄屏直播：VLC通過rtsp協議播放android錄屏實時視訊（Java實現）

首先說下為什麼要做這樣一個東西          在上家公司的時候，作為客戶端開發，一個月要給領導演示異常app的開發成果，當時用的策略是用錄屏類軟體，錄製成mp4，然後通過投影播放mp4檔案，來給領導看。這樣做帶來的問題是，要提前準備mp4需要時間，領導想要看除了mp4外的

RTSP協議之TCP/UDP問題

前言 RTSP（Real-Time StreamingProtocol）實時流式協議在直播、流媒體、視訊會議等平臺用得很多，它是基於TCP/IP開發的上層協議，所以音視訊流資料可以用TCP或者UDP來傳輸。這篇文章目的主要是講述這二者的區別，如果想了解更多RTSP相關的知識

[rtsp]協議UDP、TCP、RTP三種協議的總結分析

　　RTP 全名是 Real-time Transport Protocol（實時傳輸協議）。它是IETF提出的一個標準，對應的RFC文件為RFC3550（RFC1889為其過期版本）。RFC3550 不僅定義了 RTP，而且

RTSP再學習 -- RTSP協議分析（轉載）

最近一直在看 RTSP，但是RTSP協議是個啥？還沒有搞清楚。首先流媒體百度百科上有這樣一段，從基本的名字上或多或少可以理解一下這些傳輸協議的區別。這很重要！！傳輸協議1、RSVP：資源預留協議2、RT

rtsp協議標準流程

RTSP C-REQ Format: MethodName URL RTSPVersion CR LF MessageHead: CR LF CR LF MessageBody: CR LF RTSP S-RES Format: MethodName RTSPVersion