流媒體傳輸控制協議詳解之RTSP
流媒體傳輸協議介紹
一、RTSP協議介紹
什麼是rtsp?
RTSP協議以客戶伺服器方式工作,,如:暫停/繼續、後退、前進等。它是一個多媒體播放控制協議,用來使使用者在播放從因特網下載的實時資料時能夠進行控制,
因此 RTSP 又稱為“因特網錄影機遙控協議”。
RTSP(Real-Time Stream Protocol)是一種基於文字的應用層協議,在語法及一些訊息引數等方面,RTSP協議與HTTP協議類似。 是TCP/IP協議體系中的一個應用層協議, 由哥倫比亞大學, 網景和RealNetworks公司提交的IETF RFC標準. 對應的RFC編號是2326,可以在這裡搜尋
該協議定義了一對多應用程式如何有效地通過IP網路傳送多媒體資料. RTSP在體系結構上位於RTP和RTCP之上, 它使用TCP或RTP完成資料傳輸.
RTSP被用於建立的控制媒體流的傳輸,它為多媒體服務扮演“網路遠端控制”的角色。儘管有時可以把RTSP控制資訊和媒體資料流交織在一起傳送,但一般情況RTSP本身並不用於轉送媒體流資料。媒體資料的傳送可通過RTP/RTCP等協議來完成。
該協議用於C/S模型, 是一個基於文字的協議, 用於在客戶端和伺服器端建立和協商實時流會話.
網路體系
RTSP是類似http的應用層協議,一個典型的流媒體框架網路體系可參考下圖
一次基本的RTSP操作過程:
- 首先,客戶端連線到流伺服器併發送一個RTSP描述命令(DESCRIBE)。
- 流伺服器通過一個SDP描述來進行反饋,反饋資訊包括流數量、媒體型別等資訊。
- 客戶端再分析該SDP描述,併為會話中的每一個流傳送一個RTSP建立命令(SETUP),RTSP建立命令告訴伺服器客戶端用於接收媒體資料的埠。流媒體連線建立完成後,
- 客戶端傳送一個播放命令(PLAY),伺服器就開始在UDP上傳送媒體流(RTP包)到客戶端。 在播放過程中客戶端還可以向伺服器傳送命令來控制快進、快退和暫停等。
- 最後,客戶端可傳送一個終止命令(TERADOWN)來結束流媒體會話
sequenceDiagram
客戶端->>伺服器:DESCRIBE
伺服器->>客戶端: 200 OK (SDP)
客戶端->>伺服器:SETUP
伺服器->>客戶端: 200 OK
客戶端->>伺服器:PLAY
伺服器->>客戶端: (RTP包)
- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 1
- 2
- 3
- 4
- 5
- 6
- 7
協議特點
- 可擴充套件性: 新方法和引數很容易加入RTSP.
- 易解析: RTSP可由標準HTTP或MIME解析器解析.
- 安全: RTSP使用網頁安全機制.
- 獨立於傳輸: RTSP可使用不可靠資料報協議(EDP), 可靠資料報協議(RDP); 如要實現應用級可靠, 可使用可靠流協議.
- 多伺服器支援: 每個流可放在不同伺服器上, 使用者端自動與不同伺服器建立幾個併發控制連線, 媒體同步在傳輸層執行.
- 記錄裝置控制: 協議可控制記錄和回放裝置.
- 流控與會議開始分離: 僅要求會議初始化協議提供, 或可用來建立惟一會議標識號. 特殊情況下, 可用SIP或H.323來邀請伺服器入會.
- 適合專業應用: 通過SMPTE時標, RTSP支援幀級精度, 允許遠端數字編輯.
- 演示描述中立: 協議沒強加特殊演示或元檔案, 可傳送所用格式型別; 然而, 演示描述至少必須包括一個RTSP URL.
- 代理與防火牆友好: 協議可由應用和傳輸層防火牆處理. 防火牆需要理解SETUP方法, 為UDP媒體流開啟一個“缺口”.
- HTTP友好: 此處, RTSP明智地採用HTTP觀念, 使現在結構都可重用. 結構包括Internet內容選擇平臺(PICS). 由於在大多數情況下控制連續媒體需要伺服器狀態, RTSP不僅僅向HTFP新增方法.
- 適當的伺服器控制: 如使用者啟動一個流, 必須也可以停止一個流.
- 傳輸協調: 實際處理連續媒體流前, 使用者可協調傳輸方法.
- 效能協調: 如基本特徵無效, 必須有一些清理機制讓使用者決定哪種方法沒生效. 這允許使用者提出適合的使用者介面.
RTSP協議與HTTP協議區別
- RTSP引入了幾種新的方法,比如DESCRIBE、PLAY、SETUP 等,並且有不同的協議識別符號,RTSP為rtsp 1.0,HTTP為http 1.1;
- HTTP是無狀態的協議,而RTSP為每個會話保持狀態;
- RTSP協議的客戶端和伺服器端都可以傳送Request請求,而在HTTPF 協議中,只有客戶端能傳送Request請求。
- 在RTSP協議中,載荷資料一般是通過帶外方式來傳送的(除了交織的情況),及通過RTP協議在不同的通道中來傳送載荷資料。而HTTP協議的載荷資料都是通過帶內方式傳送的,比如請求的網頁資料是在迴應的訊息體中攜帶的。
- 使用ISO 10646(UTF-8) 而不是ISO 8859-1,以配合當前HTML的國際化;
- RTSP使用URI請求時包含絕對URI。而由於歷史原因造成的向後相容性問題,HTTP/1.1只在請求中包含絕對路徑,把主機名放入單獨的標題域中;
二、RTSP 的報文結構
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的媒體流資源,可以標識單一的媒體流資源,也可以標
識多個媒體流資源的集合。
RTSP的報文結構
RTSP是一種基於文字的協議,用CRLF作為一行的結束符。使用基於文字協議的好處在於我們可以隨時在使用過程中的增加自定義的引數,也可以隨便將協議包抓住很直觀的進行分析。
RTSP有兩類報文:請求報文和響應報文。請求報文是指從客戶向伺服器傳送請求報文,響應報文是指從伺服器到客戶的回答。
由於 RTSP 是面向正文的(text-oriented),因此在報文中的每一個欄位都是一些 ASCII 碼串,因而每個欄位的長度都是不確定的。
RTSP報文由三部分組成,即開始行、首部行和實體主體。在請求報文中,開始行就是請求行.
RTSP請求報文的結構如下圖所示
圖2 RTSP請求報文的結構
RTSP請求報文的方法包括:OPTIONS、DESCRIBE、SETUP、TEARDOWN、PLAY、PAUSE、GET_PARAMETER和SET_PARAMETER。
一個請求訊息(a request message)即可以由客戶端向服務端發起也可以由服務端向客戶端發起。請求訊息的語法結構如下:
>
Request = Request-Line
*( general-header | request-header | entity-header) CRLF [message-body]
1. Request Line
請求訊息的第一行的語法結構如下:
Request-Line = Method 空格 Request-URI 空格 RTSP-Version CRLF
其中在訊息行中出現的第一個單詞即是所使用的信令標誌。目前已經有的資訊標誌如下:
Method = “DESCRIBE” | “ANNOUNCE” | “GET_PARAMETER” | “OPTIONS” | “PAUSE” | “PLAY” | “RECORD” | “REDIRECT” | “SETUP” | “SET_PARAMETER” | “TEARDOWN”
例子:
DESCRIBE rtsp://211.94.164.227/3.3gp RTSP/1.0
2. Request Header Fields
在訊息頭中除了第一行的內容外,還有一些需求提供附加資訊。其中有些是一定要的,後續我們會詳細介紹經常用到的幾個域的含義。
Request-header = Accept | Accept-Encoding | Accept-Language | Authorization | From | If-Modified-Since | Range | Referer | User-Agent
響應訊息
響應報文的開始行是狀態行,RTSP響應報文的結構如下圖所示
圖3 RTSP響應報文的結構
響應訊息的語法結構如下:
Response = Status-Line
*( general-header
| response-header
| entity-header)
CRLF
[message-body]
1. Status-Line
響應訊息的第一行是狀態行(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 | = |
. | | |
. | | |
. | | |
2. Response Header Fields
在響應訊息的域中存放的是無法放在Status-Line中,而又需要傳送給請求者的一些附加資訊。
Response-header = Location | Proxy-Authenticate | Public | Retry-After | Server | Vary | WWW-Authenticate
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)大小寫敏感,不能以字元”$”開始,並且一定要是一個標記符。
RTSP重要頭欄位引數
-
Accept:
用於指定客戶端可以接受的媒體描述資訊型別。比如:
Accept: application/rtsl, application/sdp;level=2 -
Bandwidth:
用於描述客戶端可用的頻寬值。 - CSeq:
指定了RTSP請求迴應對的序列號,在每個請求或迴應中都必須包括這個頭欄位。對每個包含一個給定序列號的請求訊息,都會有一個相同序列號的迴應訊息。 - Rang:
用於指定一個時間範圍,可以使用SMPTE、NTP或clock時間單元。 - Session:
Session頭欄位標識了一個RTSP會話。Session ID 是由伺服器在SETUP的迴應中選擇的,客戶端一當得到Session ID後,在以後的對Session 的操作請求訊息中都要包含Session ID. - 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服務端
第一步:查詢伺服器端可用方法
C->S OPTION request //詢問S有哪些方法可用
S->C OPTION response //S迴應資訊的public頭欄位中包括提供的所有可用方法
第二步:得到媒體描述資訊
C->S DESCRIBE request //要求得到S提供的媒體描述資訊
S->C DESCRIBE response //S迴應媒體描述資訊,一般是sdp資訊
第三步:建立RTSP會話
C->S SETUP request //通過Transport頭欄位列出可接受的傳輸選項,請求S建立會話
S->C SETUP response //S建立會話,通過Transport頭欄位返回選擇的具體轉輸選項,並返回建立的Session ID;
第四步:請求開始傳送資料
C->S PLAY request //C請求S開始傳送資料
S->C PLAY response //S迴應該請求的資訊
第五步: 資料傳送播放中
S->C 傳送流媒體資料 // 通過RTP協議傳送資料
第六步:關閉會話,退出
C->S EARDOWN request //C請求關閉會話
S->C TEARDOWN response //S迴應該請求
上述的過程只是標準的、友好的rtsp流程,但實際的需求中並不一定按此過程。
其中第三和第四步是必需的!第一步,只要伺服器和客戶端約定好有哪些方法可用,則option請求可以不要。第二步,如果我們有其他途徑得到媒體初始化描述資訊(比如http請求等等),則我們也不需要通過rtsp中的describe請求來完成。
RTSP的請求響應示例
其中C是客戶端,S是服務端。
OPTIONS
C->S: OPTION request //詢問S有哪些方法可用 S->C: OPTION response //S迴應資訊中包括提供的所有可用方法
* 客戶端到服務端 *
OPTIONS rtsp://218.207.101.236:554/mobile/3/67A451E937422331 RTSP/1.0
Cseq: 1
服務端對OPTIONS的迴應:(伺服器的迴應資訊會在Public欄位列出提供的方法。)
RTSP/1.0 200 OK
Server: PVSS/1.4.8 (Build/20090111; Platform/Win32; Release/StarValley; )
Cseq: 1
Public: DESCRIBE, SETUP, TEARDOWN, PLAY, PAUSE, OPTIONS, ANNOUNCE, RECORD
DESCRIBE
C->S: DESCRIBE request //要求得到S提供的媒體初始化描述資訊
S->C: DESCRIBE response //S迴應媒體初始化描述資訊,主要是sdp
客戶端到服務端的請求舉例:(客戶端向伺服器端傳送DESCRIBE,用於得到URI所指定的媒體描述資訊,一般是SDP資訊。客戶端通過Accept頭指定客戶端可以接受的媒體述資訊型別。)
DESCRIBE rtsp://218.207.101.236:554/mobile/3/67A451E937422331/8jH5QPU5GWS07Ugn.sdp RTSP/1.0
Cseq: 2
服務端對DESCRIBE的迴應:(伺服器迴應URI指定媒體的描述資訊)
RTSP/1.0 200 OK
Server: PVSS/1.4.8 (Build/20090111; Platform/Win32; Release/StarValley; )
Cseq: 2
Content-length: 421
Date: Mon, 03 Aug 2009 08:21:33 GMT
Expires: Mon, 03 Aug 2009 08:21:33 GMT
Content-Type: application/sdp
x-Accept-Retransmit: our-retransmit
x-Accept-Dynamic-Rate: 1
Content-Base: rtsp://218.207.101.236:554/mobile/3/67A451E937422331/8jH5QPU5GWS07Ugn.sdp/
v=0
o=MediaBox 127992 137813 IN IP4 0.0.0.0
s=RTSP Session
i=Starv Box Live Cast
c=IN IP4 218.207.101.236
t=0 0
a=range:npt=now-
a=control:*
m=video 0 RTP/AVP 96
b=AS:20
a=rtpmap:96 MP4V-ES/1000
a=fmtp:96 profile-level-id=8; config=000001b008000001b5090000010000000120008440fa282c2090a31f; decode_buf=12586
a=range:npt=now-
a=framerate:5
a=framesize:96 176-144
a=cliprect:0,0,144,176
a=control:trackID=1
相關推薦
流媒體傳輸控制協議詳解之RTSP
流媒體傳輸協議介紹 一、RTSP協議介紹 什麼是rtsp? RTSP協議以客戶伺服器方式工作,,如:暫停/繼續、後退、前進等。它是一個多媒體播放控制協議,用來使使用者在播放從因特網下載的實時資料時能夠進行控制, 因此 RTSP 又稱為“因特網錄影機遙控協議”。
1553B 協議詳解之二字的組成
產生 差分 4.2 所有 管理 錯誤處理 遠程終端 同時 通道 1553B簡介本設計文檔將在SylixOS下設計一個1553B設備驅動的抽象層,從而進一步解除用戶層與驅動層的耦合。MIL-STD-1553B總線是美國空軍電子子系統聯網的標準總線,是一種中央集權式的串行總線,
TCP協議詳解之TCP Flag標誌位來判斷TCP會話的開始和結束
首先回顧一下TCP標誌位的具體含義。 TCP Flag標誌位(控制位) 一個TCP包的詳細內容: TCP FLAG 標記佔1.5個byte,12bit(4bit+8bit,前半個byte與Header Length公用)。 12bit中前三個bit是保留,預設為全0
PyQt5基本控制元件詳解之QPixmap(十九)
QPixmap 前言 QPixmap類用於繪圖裝置的影象顯示,它可以作為一個QPainterDevice物件,也可以載入到一個控制元件中,通常是標籤或者按鈕,用於在標籤或按鈕上顯示影象
HTTP協議詳解之報頭篇
最近看《PHP核心技術與最佳實踐》一書,HTTP協議部分講解的清晰易懂,特此整理。 HTTP協議如何工作? 1. 建立連線 客戶機與伺服器需要建立連線。單機某個超連結,HTTP協議工作開始 2. 傳送請求 建立連線後,客戶機發送一個請求給伺服器。格
PyQt5基本控制元件詳解之QDialog(十二)
QDialog 前言 為了更好的實現人機互動,比如window和linux等系統均會提供一系列的標準對話方塊來完成特定場景下的功能,比如選擇字號大小。字型顏色等,在PyQt5中定義了一系列的標準對話方塊類,讓使用者能夠方便快捷地通過各個類完成字號大
http協議詳解之請求篇
http請求由三部分組成:請求行,訊息報頭,請求正文 1)get:請求獲取request-uri所標識的資源 2)post:在request-uri所標識的資源後附加新的資料 3)head:請求獲取由request-uri所標識的資源的響應訊息報頭 4)put:請求伺服器儲
HTTP協議詳解之響應篇
HTTP響應也是由三個部分組成,分別是:狀態行、訊息報頭、響應正文 1、狀態行格式如下: HTTP-Version Status-Code Reason-Phrase CRLF 其中,HTTP-Version表示伺服器HTTP協議的版本;Status-Code表示伺服器發回的響應狀態程式碼;Reason-Ph
PyQt5基本控制元件詳解之QCheckBox(八)
QCheckBox QCheckBox類中常用方法如表 方法 描述 setChecked() 設定複選框的狀態,設定為True表示選中,False表示取消選中的複選框 setText() 設定複選框的顯示文字
PyQt5基本控制元件詳解之QLineEdit(四)
QLineEdit QLineEdit類中常用的方法如下表 方法 描述 setAlignment() 按固定值方式對齊文字 Qt.AlignLeft:水平方向靠左對齊 Qt.AlignRight:水平方
[轉]javaCV開發詳解之5:錄製音訊(錄製麥克風)到本地檔案/流媒體伺服器(基於javax.sound、javaCV-FFMPEG)
本文轉載自部落格:https://blog.csdn.net/eguid_1/article/details/52702385 ------------------------------------------------------------------------------------
TCP-IP詳解筆記8: TCP傳輸控制協議
TCP提供一種面向連線的、可靠的位元組流服務。 TCP將使用者資料打包構成報文段;它傳送資料後啟動一個定時器;另一端對收到的資料進行確認,對失序的資料重新排序,丟棄重複資料;TCP提供端到端的流量控制,並計算和驗證一個強制性的端到端檢驗和 TCP首部 TCP
視訊直播技術詳解之推流和傳輸
宣告:本文為CSDN原創投稿文章,未經許可,禁止任何形式的轉載。 作者:七牛雲 責編:錢曙光,關注架構和演算法領域,尋求報道或者投稿請發郵件[email protected],另有「CSDN 高階架構師群」,內有諸多知名網際網路公司的大牛架構師,
javaCV開發詳解之4:轉流器實現(也可作為本地收流器、推流器,新增新增圖片及文字水印,視訊影象幀儲存),實現rtsp/rtmp/本地檔案轉發到rtmp流媒體伺服器(基於javaCV-FFMPEG)
javaCV系列文章: 補充篇: 歡迎大家積極開心的加入討論群 javacpp-ffmpeg: 前言: 本章基於javaCV實現轉流器和收流器功能,測試採用監控rtsp地址轉發至rtmp伺服器地址 新增openCV儲存圖片功能。 補充:
javaCV開發詳解之2:推流器實現,推本地攝像頭視訊到流媒體伺服器以及攝像頭錄製視訊功能實現(基於javaCV-FFMPEG、javaCV-openCV)
javaCV系列文章: 補充篇: 歡迎大家積極開心的加入討論群 javacpp-ffmpeg: 前言: 本章將在上一章的基礎上,增加視訊推流到流媒體伺服器和視訊錄製的功能; 功能:實現邊播放邊錄製/推流,停止預覽即停止錄製/推流 提示:
流媒體傳輸協議系列之----RTP/RTCP協議解析
RTP協議 實時傳輸協議RTP(Real-time Transport Protocol)是一個網路傳輸協議,它是由IETF的多媒體傳輸工作小組1996年在RFC 1889中公佈的,後在RFC3550中進行更新。 國際電信聯盟ITU-
面試之路(29)-TCP流量控制和擁塞控制-滑動視窗協議詳解
擁塞: 擁塞發生的主要原因在於網路能夠提供的資源不足以滿足使用者的需求,這些資源包括快取空間、鏈路頻寬容量和中間節點的處理能力。由於網際網路的設計機制導致其缺乏“接納控制”能力,因此在網路資源不足時不能限制使用者數量,而只能靠降低服務質量來繼續為使用者服務,也
流媒體傳輸協議之 RTP(下篇)
本系列文章將整理各個流媒體傳輸協議,包括 RTP/RTCP,RTMP,希望通過深入梳理協議的設計細節,能夠給流媒體領域的開發者帶來一定的啟發。 作者:逸殊 稽核:泰一 接上篇:《 流媒體傳輸協議之 RTP(上篇)》 # RTP 控制協議 ## Sender & Receiver 報告 RTP 使
OSI七層詳解之四 傳輸層(Transport)
http 計算機 地址 包括 分組 tcp aik 全部 滿足 一、簡介 第四層的數據單元也稱作數據包(packets)。但是,當你談論TCP等具體的協議時又有特殊的叫法,TCP的數據單元稱為段(segments)而UDP協議的數據單元稱為“數據報(datagrams)
流媒體傳輸協議介紹
level mic ntp 正常 mes 結果 傳輸層 再次 http請求 一、RTSP協議介紹 什麽是rtsp? RTSP協議以客戶服務器方式工作,,如:暫停/繼續、後退、前進等。它是一個多媒體播放控制協議,用來使用戶在播放從因特網下載的實時數據時能夠進行控制, 因此