即時串流協定

即時串流協定(Real Time Streaming Protocol,RTSP)是一種網路應用協定,專為娛樂和通訊系統的使用,以控制串流媒體伺服器。該協定用於建立和控制終端之間的媒體對談。媒體伺服器的客戶端發布VCR命令,例如播放,錄製和暫停,以便於即時控制從伺服器到客戶端(影片點播)或從客戶端到伺服器(語音錄音)的媒體流。

流資料本身的傳輸不是RTSP的任務。大多數RTSP伺服器使用即時傳輸協定(RTP)和即時傳輸控制協定(RTCP)結合媒體流傳輸。然而,一些供應商實現專有傳輸協定。例如,RealNetworks公司的RTSP伺服器軟體也使用RealNetworks的專有即時資料傳輸(RDT)。

RTSP由RealNetworks公司,Netscape公司 [1]哥倫比亞大學開發,第一稿於1996年提交給IETF[2]。由網際網路工程任務組(IETF)的多方多媒體對談控制工作群組(MMUSIC WG)進行了標準化,並於1998年發布為RFC 2326。[3] RTSP 2.0 於2016年發布為RFC 7826,作為RTSP 1.0的替代品。RTSP 2.0基於RTSP 1.0,但除了基本的版本協商機制之外不向下相容。

協定指令

編輯

雖然在某些方面與HTTP類似,RTSP定義了控制多媒體播放控制順序。雖然HTTP是無狀態的,但RTSP具有狀態; 當需要跟蹤並行對談時使用識別碼。像HTTP一樣,RTSP使用TCP來維護端到端連接,而大多數RTSP控制訊息由客戶端傳送到伺服器,一些命令沿著另一個方向(即從伺服器到客戶端)傳播。

這裡提供了基本的RTSP請求。一些典型的HTTP請求,如OPTIONS請求也可用。預設傳輸埠為554[3] ,該埠同時應用於TCPUDP,但後者很少用於控制請求。

OPTIONS 請求
OPTIONS請求返回伺服器將接受的請求類型。 (C 代表客戶端 S 代表伺服器端)
C->S:  OPTIONS rtsp://example.com/media.mp4 RTSP/1.0
       CSeq: 1
       Require: implicit-play
       Proxy-Require: gzipped-messages

S->C:  RTSP/1.0 200 OK
       CSeq: 1
       Public: DESCRIBE, SETUP, TEARDOWN, PLAY, PAUSE
DESCRIBE 請求
DESCRIBE請求包括RTSP URL(rtsp:// ...)以及可以處理的回覆資料類型。該回覆包括呈現描述,通常以對談描述協定(SDP)格式。其中,演示文稿描述列出了使用匯總網址控制的媒體流。在典型的情況下,每個音訊和影片都有一個媒體流。
C->S: DESCRIBE rtsp://example.com/media.mp4 RTSP/1.0
      CSeq: 2

S->C: RTSP/1.0 200 OK
      CSeq: 2
      Content-Base: rtsp://example.com/media.mp4
      Content-Type: application/sdp
      Content-Length: 460

      m=video 0 RTP/AVP 96
      a=control:streamid=0
      a=range:npt=0-7.741000
      a=length:npt=7.741000
      a=rtpmap:96 MP4V-ES/5544
      a=mimetype:string;"video/MP4V-ES"
      a=AvgBitRate:integer;304018
      a=StreamName:string;"hinted video track"
      m=audio 0 RTP/AVP 97
      a=control:streamid=1
      a=range:npt=0-7.712000
      a=length:npt=7.712000
      a=rtpmap:97 mpeg4-generic/32000/2
      a=mimetype:string;"audio/mpeg4-generic"
      a=AvgBitRate:integer;65790
      a=StreamName:string;"hinted audio track"
SETUP 請求
SETUP請求指定如何傳輸單個媒體流。這必須在傳送PLAY請求之前完成。請求包含媒體流URL和傳輸說明符。該說明符通常包括用於接收RTP資料(音訊或影片)的本地埠,另一個用於RTCP資料(元資訊)。伺服器回覆通常會確認所選參數,並填寫缺少的部分,例如伺服器選擇的埠。必須在傳送聚合播放請求之前,使用SETUP組態每個媒體流。
C->S: SETUP rtsp://example.com/media.mp4/streamid=0 RTSP/1.0
      CSeq: 3
      Transport: RTP/AVP;unicast;client_port=8000-8001

S->C: RTSP/1.0 200 OK
      CSeq: 3
      Transport: RTP/AVP;unicast;client_port=8000-8001;server_port=9000-9001;ssrc=1234ABCD
      Session: 12345678
Play 播放請求
Play 播放請求 將導致播放一個或所有媒體流。可以通過傳送多個播放請求來堆疊播放請求。URL可以是聚合URL(播放所有媒體流)或單個媒體流URL(僅播放該流)。可以指定範圍。如果沒有指定範圍,流將從頭開始播放,並播放到最後,或者如果流暫停,則在暫停點恢復播放。
C->S: PLAY rtsp://example.com/media.mp4 RTSP/1.0
      CSeq: 4
      Range: npt=5-20
      Session: 12345678

S->C: RTSP/1.0 200 OK
      CSeq: 4
      Session: 12345678
      RTP-Info: url=rtsp://example.com/media.mp4/streamid=0;seq=9810092;rtptime=3450012
PAUSE 暫停請求
PAUSE 暫停請求 暫時停止一個或所有媒體流,因此稍後可以通過播放請求恢復。請求包含聚合或媒體流URL。PAUSE請求中的範圍參數指定何時暫停。當省略範圍參數時,暫停會立即無限期地發生。
C->S: PAUSE rtsp://example.com/media.mp4 RTSP/1.0
      CSeq: 5
      Session: 12345678

S->C: RTSP/1.0 200 OK
      CSeq: 5
      Session: 12345678
RECORD 記錄請求
RECORD 該方法根據呈現描述開始記錄一系列媒體資料。時間戳反映開始和結束時間(UTC)。如果沒有給定時間範圍,請使用演示文稿描述中提供的開始或結束時間。如果對談已經開始,請立即開始錄製。伺服器決定是否將記錄的資料儲存在請求URI或其他URI下。如果伺服器不使用請求URI,則回應應為201,並包含描述請求狀態並參照新資源的實體以及Location頭。
C->S: RECORD rtsp://example.com/media.mp4 RTSP/1.0
      CSeq: 6
      Session: 12345678

S->C: RTSP/1.0 200 OK
      CSeq: 6
      Session: 12345678
ANNOUNCE 發布請求
ANNOUNCE 發布方法有兩個目的:

從客戶端傳送到伺服器時,ANNOUNCE將請求URL標識的演示文稿或媒體對象的描述發布到伺服器。當從伺服器傳送到客戶端時,ANNOUNCE會即時更新對談描述。如果新的媒體流被添加到演示文稿中(例如,在即時演示中),則應該再次傳送整個演示文稿描述,而不僅僅是附加的組件,以便可以刪除組件。(下面電子信箱'#'號替換成'@')

C->S: ANNOUNCE rtsp://example.com/media.mp4 RTSP/1.0
      CSeq: 7
      Date: 23 Jan 1997 15:35:06 GMT
      Session: 12345678
      Content-Type: application/sdp
      Content-Length: 332

      v=0
      o=mhandley 2890844526 2890845468 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

S->C: RTSP/1.0 200 OK
      CSeq: 7
TEARDOWN 停止發布流請求
TEARDOWN 請求用於終止對談。它停止所有媒體流,並釋放所有與對談相關的資料在伺服器上。
C->S: TEARDOWN rtsp://example.com/media.mp4 RTSP/1.0
      CSeq: 8
      Session: 12345678

S->C: RTSP/1.0 200 OK
      CSeq: 8
GET_PARAMETER 取得參數請求
GET_PARAMETER 請求檢索在URI中指定的呈現或流的參數的值。答覆和回覆的內容留給實施。沒有實體的GET_PARAMETER可能用於測試客戶端或伺服器活動(「ping」)。
S->C: GET_PARAMETER rtsp://example.com/media.mp4 RTSP/1.0
      CSeq: 9
      Content-Type: text/parameters
      Session: 12345678
      Content-Length: 15

      packets_received
      jitter

C->S: RTSP/1.0 200 OK
      CSeq: 9
      Content-Length: 46
      Content-Type: text/parameters

      packets_received: 10
      jitter: 0.3838
SET_PARAMETER 設定參數請求
SET_PARAMETER 此方法請求設定由URI指定的演示文稿或流的參數值。
C->S: SET_PARAMETER rtsp://example.com/media.mp4 RTSP/1.0
      CSeq: 10
      Content-length: 20
      Content-type: text/parameters

      barparam: barstuff

S->C: RTSP/1.0 451 Invalid Parameter
      CSeq: 10
      Content-length: 10
      Content-type: text/parameters

      barparam
REDIRECT 重新導向請求
REDIRECT 請求通知客戶端它必須連接到另一個伺服器位置。它包含強制性標頭檔位置,表示客戶端應發出該URL的請求。它可能包含參數Range,它指示重新導向何時生效。如果客戶端希望繼續傳送或接收此URI的媒體,則客戶端必須向指定的主機發出針對當前對談的TEARDOWN請求和新對談的SETUP。
S->C: REDIRECT rtsp://example.com/media.mp4 RTSP/1.0
      CSeq: 11
      Location: rtsp://bigserver.com:8001
      Range: clock=19960213T143205Z-
嵌入式(交錯式)二進制資料
某些防火牆設計和其他情況可能會強制伺服器交叉RTSP方法和流資料。通常應避免這種交錯,除非有必要,因為它會使客戶端和伺服器操作複雜化,並增加額外的開銷。交叉二進制資料只能在RTSP通過TCP傳輸時使用。諸如RTP封包之類的流資料由ASCII碼符號(24個十六進制)封裝,後跟一個位元組的信道識別碼,後面是封裝二進制資料的長度,以二進制位元組為單位,以網路位元組順序排列。流資料緊隨其後,沒有CRLF,但包括上層協定頭。每個$塊只包含一個上層協定資料單元,例如一個RTP包。
C->S: SETUP rtsp://example.com/media.mp4 RTSP/1.0
      CSeq: 3
      Transport: RTP/AVP/TCP;interleaved=0-1

S->C: RTSP/1.0 200 OK
      CSeq: 3
      Date: 05 Jun 1997 18:57:18 GMT
      Transport: RTP/AVP/TCP;interleaved=0-1
      Session: 12345678

C->S: PLAY rtsp://example.com/media.mp4 RTSP/1.0
      CSeq: 4
      Session: 12345678

S->C: RTSP/1.0 200 OK
      CSeq: 4
      Session: 12345678
      Date: 05 Jun 1997 18:59:15 GMT
      RTP-Info: url=rtsp://example.com/media.mp4;
      seq=232433;rtptime=972948234

S->C: $\000{2 byte length}{"length" bytes data, w/RTP header}
S->C: $\000{2 byte length}{"length" bytes data, w/RTP header}
S->C: $\001{2 byte length}{"length" bytes  RTCP packet}

速率適配

編輯

使用RTP和RTCP的RTSP允許實現速率適配。[4]

已經成功實現的

編輯

伺服器端

編輯

客戶端

編輯

參考

編輯
  1. ^ InfoWorld Media Group, Inc. InfoWorld. InfoWorld Media Group, Inc. 2 March 1998: 18 [2017-05-10]. ISSN 0199-6649. (原始內容存檔於2019-12-15). 
  2. ^ Rafael Osso. Handbook of Emerging Communications Technologies: The Next Decade. CRC Press. 1999: 42 [2017-05-10]. ISBN 978-1-4200-4962-6. (原始內容存檔於2019-05-02). 
  3. ^ 3.0 3.1 RFC 2326, Real Time Streaming Protocol (RTSP), IETF, 1998
  4. ^ Rate Adaption Techniques for WebTV, [2016-09-20], (原始內容存檔於2019-05-03) 
  5. ^ erlyvideo website. [2017-05-10]. (原始內容存檔於2016-04-09). 
  6. ^ cURL - Changes. [2017-05-10]. (原始內容存檔於2011-08-14). 
  7. ^ FFmpeg Documentation. The FFmpeg project. Section 20.19. September 11, 2012 [2012-09-11]. (原始內容存檔於2018-07-26). 

外部連結

編輯