2. 程式人生 > >RTMP協議與RTSP協議比較

RTMP協議與RTSP協議比較

阿新 • • 發佈：2019-01-29

考慮做一個手機直播系統，首先需要指定一個合理的技術方案。由於自己以前不是搞多媒體這塊，對流媒體開發不熟悉，自己的理解思維總習慣用java web開發的慣性走，先指定一個大體的框架。不管對還是錯，先考慮其技術可行性。

框架的指定，首先取決於自己採用的流媒體協議，我們熟知的流媒體協議有RTMP,RTSP,HLS。網上有很多這方面的介紹，我懶得複製了，在這裡只談談自己的看法。

先談一下HLS，這個協議接觸得最早，自己的個人理解，如果要開發一套準實時的手機音視訊直播系統，需要支援iphone，android，windows phone等多款手機，這個協議真心不錯。為什麼是準實時呢，因為客戶端播放的是最新切割的ts檔案，它的延遲取決於切片的大小

。

參考文章http://www.cnblogs.com/haibindev/archive/2013/01/30/2880764.html ，其思路步驟：

1、採集視訊源和音訊源的資料

2、對原始資料進行H264編碼和AAC編碼

3、視訊和音訊資料封裝為MPEG-TS包

4、HLS分段生成策略及m3u8索引檔案

5、HTTP傳輸協議

這裡面的很多步驟需要用到ffmpeg編解碼庫，比如編碼， 切片等。方便之處是可以使用普通的http伺服器就ok了，推薦使用nginx，這是一款功能無比強大的web伺服器，其反向代理，效能好的不可言喻。

由於我大學非計算機專業出身，或者說與計算機專業一點都不靠邊，我的計算機語言功底弱爆了。資料結構演算法真心是我的軟肋，C++語言就會簡單的用MFC編寫hello world ，HLS當初就這樣被我放棄了。

RTSP協議，這應該是實時性最好的了，如果要想實時性要求很高，比如0.5s以內，這個是不錯的選擇。前陣子模仿spydroid寫了個建議的rtsp伺服器，其實就是options，describe，setup，play，pause，teardown這幾步了，這個協議用的最廣泛，網上介紹也比較多。要想真正深入瞭解rtsp協議，c++語言功底好的可以檢視live555 。Real Time Streaming Protocol或者RTSP（實時流媒體協議），是由Real network 和 Netscape共同提出的如何有效地在IP網路上傳輸流媒體資料的應用層協議。RTSP提供一 種可擴充套件的框架，使能夠提供可控制的，按需傳輸實時資料，比如音訊和視訊檔案。源資料可以包括現場資料的反饋和存貯的檔案。rtsp對流媒體提供了諸如暫停，快進等控制，而它本身並不傳輸資料，rtsp作用相當於流媒體伺服器的遠端控制。傳輸資料可以通過傳輸層的tcp，udp協議，rtsp也提供了基於rtp傳輸機制的一些有效的方法。

RTSP訊息格式


RTSP的訊息有兩大類,一是請求訊息(request),一是迴應訊息(response),兩種訊息的格式不同.
請求訊息:

方法 URI RTSP版本 CR LF 
訊息頭 CR LF CR LF 
訊息體 CR LF

其中方法包括OPTION迴應中所有的命令,URI是接受方的地址,例如
rtsp://192.168.20.136

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

RTSP版本 狀態碼 解釋 CR LF 
訊息頭 CR LF CR LF 
訊息體 CR LF

其中RTSP版本一般都是RTSP/1.0,狀態碼是一個數值,200表示成功,解釋是與狀態碼對應 的文字解釋。

簡單的rtsp互動過程

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

1.C->S:OPTION request //詢問S有哪些方法可用 
1.S->C:OPTION response //S迴應資訊中包括提供的所有可用方法 

2.C->S:DESCRIBE request //要求得到S提供的媒體初始化描述資訊 
2.S->C:DESCRIBE response //S迴應媒體初始化描述資訊，主要是sdp 

3.C->S:SETUP request //設定會話的屬性，以及傳輸模式，提醒S建立會話 
3.S->C:SETUP response //S建立會話，返回會話識別符號，以及會話相關資訊 

4.C->S:PLAY request //C請求播放 
4.S->C:PLAY response //S迴應該請求的資訊 

5.S->C:傳送流媒體資料 

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

上述的過程是標準的、友好的rtsp流程，但實際的需求中並不一定按部就班來。
其中第3和4步是必需的！
第一步，只要伺服器客戶端約定好，有哪些方法可用，則option請求可以不要。第二步，如果我們有其他途徑得到媒體初始化描述資訊（比如http請求等等），則我們也不需要通過rtsp中的describe請求來完成。第五步，可以根據系統需求的設計來決定是否需要。

rtsp中常用方法

OPTION

目的是得到伺服器提供的可用方法:

OPTIONS rtsp://192.168.20.136:5000/xxx666 RTSP/1.0 
CSeq: 1 //每個訊息都有序號來標記，第一個包通常是option請求訊息 
User-Agent: VLC media player (LIVE555 Streaming Media v2005.11.10)

伺服器的迴應資訊包括提供的一些方法,例如:

 
RTSP/1.0 200 OK 
Server: UServer 0.9.7_rc1 
Cseq: 1 //每個迴應訊息的cseq數值和請求訊息的cseq相對應 
Public: OPTIONS, DESCRIBE, SETUP, TEARDOWN, PLAY, PAUSE, SCALE, 
GET_PARAMETER //伺服器提供的可用的方法

DESCRIBE

C向S發起DESCRIBE請求,為了得到會話描述資訊(SDP):

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

CSeq: 2 
token: 
Accept: application/sdp 
User-Agent: VLC media player (LIVE555 Streaming Media v2005.11.10)

伺服器迴應一些對此會話的描述資訊(sdp):

RTSP/1.0 200 OK 
Server: UServer 0.9.7_rc1 
Cseq: 2 
x-prev-url: rtsp://192.168.20.136:5000 
x-next-url: rtsp://192.168.20.136:5000 
x-Accept-Retransmit: our-retransmit 
x-Accept-Dynamic-Rate: 1 
Cache-Control: must-revalidate 
Last-Modified: Fri, 10 Nov 2006 12:34:38 GMT 
Date: Fri, 10 Nov 2006 12:34:38 GMT 
Expires: Fri, 10 Nov 2006 12:34:38 GMT 
Content-Base: rtsp://192.168.20.136:5000/xxx666/ 
Content-Length: 344 
Content-Type: application/sdp 

v=0 //以下都是sdp資訊 
o=OnewaveUServerNG 1451516402 1025358037 IN IP4 192.168.20.136 
s=/xxx666 
u=http:/// 
[email protected] 
c=IN IP4 0.0.0.0 
t=0 0 
a=isma-compliance:1,1.0,1 

a=range:npt=0- 
m=video 0 RTP/AVP 96 //m表示媒體描述，下面是對會話中視訊通道的媒體描述 
a=rtpmap:96 MP4V-ES/90000 
a=fmtp:96 
profile-level-id=245;config=000001B0F5000001B509000001000000012000C888B0E0E0FA62D089028307 

a=control:trackID=0//trackID＝0表示視訊流用的是通道0

SETUP

客戶端提醒伺服器建立會話,並確定傳輸模式:

SETUP rtsp://192.168.20.136:5000/xxx666/trackID=0 RTSP/1.0 
CSeq: 3 
Transport: RTP/AVP/TCP;unicast;interleaved=0-1 
User-Agent: VLC media player (LIVE555 Streaming Media v2005.11.10)

uri中帶有trackID＝0，表示對該通道進行設定。Transport引數設定了傳輸模式，包
的結構。接下來的資料包頭部第二個位元組位置就是interleaved，它的值是每個通道都
不同的，trackID＝0的interleaved值有兩個0或1，0表示rtp包，1表示rtcp包，接受端
根據interleaved的值來區別是哪種資料包。

伺服器迴應資訊:

RTSP/1.0 200 OK 
Server: UServer 0.9.7_rc1 
Cseq: 3 
Session: 6310936469860791894 //伺服器迴應的會話識別符號 
Cache-Control: no-cache 
Transport: RTP/AVP/TCP;unicast;interleaved=0-1;ssrc=6B8B4567

PLAY

客戶端傳送播放請求:

PLAY rtsp://192.168.20.136:5000/xxx666 RTSP/1.0 
CSeq: 4 
Session: 6310936469860791894 
Range: npt=0.000- //設定播放時間的範圍 
User-Agent: VLC media player (LIVE555 Streaming Media v2005.11.10)

伺服器迴應資訊:

 
RTSP/1.0 200 OK 
Server: UServer 0.9.7_rc1 
Cseq: 4 
Session: 6310936469860791894 
Range: npt=0.000000- 
RTP-Info: url=trackID=0;seq=17040;rtptime=1467265309 
//seq和rtptime都是rtp包中的資訊

PAUSE

客戶端發起暫停請求:

PAUSE rtsp://192.168.20.136:5000/xxx666 RTSP/1.0 
Cseq: 5
Session: 6310936469860791894

伺服器迴應:

RTSP/1.0 200 OK 
Server: UServer 0.9.7_rc1 
Cseq: 5 
Session: 6310936469860791894

TEARDOWN

客戶端發起關閉請求:

TEARDOWN rtsp://192.168.20.136:5000/xxx666 RTSP/1.0 
CSeq: 6
Session: 6310936469860791894 
User-Agent: VLC media player (LIVE555 Streaming Media v2005.11.10)

伺服器迴應:

 
RTSP/1.0 200 OK 
Server: UServer 0.9.7_rc1 
Cseq: 6
Session: 6310936469860791894 
Connection: Close

其他方法

以上方法都是互動過程中最為常用的,其它還有一些重要的方法如:
get/set_parameter,pause,redirect等等

sdp的格式

v=<version> 
o=<username> <session id> <version> <network type> <address type> <address> 
s=<session name> 
i=<session description> 
u=<URI> 
e=<email address> 
p=<phone number> 
c=<network type> <address type> <connection address> 
b=<modifier>:<bandwidth-value> 
t=<start time> <stop time> 
r=<repeat interval> <active duration> <list of offsets from start-time> 
z=<adjustment time> <offset> <adjustment time> <offset> .... 
k=<method> 
k=<method>:<encryption key> 
a=<attribute> 
a=<attribute>:<value> 
m=<media> <port> <transport> <fmt list> 
v = （協議版本） 
o = （所有者/建立者和會話識別符號） 
s = （會話名稱） 
i = * （會話資訊） 
u = * （URI 描述） 
e = * （Email 地址） 
p = * （電話號碼） 
c = * （連線資訊） 
b = * （頻寬資訊） 
z = * （時間區域調整） 
k = * （加密金鑰） 
a = * （0 個或多個會話屬性行） 
時間描述： 
t = （會話活動時間） 
r = * （0或多次重複次數） 
媒體描述： 
m = （媒體名稱和傳輸地址） 
i = * （媒體標題） 
c = * （連線資訊 — 如果包含在會話層則該欄位可選） 
b = * （頻寬資訊） 
k = * （加密金鑰） 
a = * （0 個或多個媒體屬性行）

RTSP點播訊息流程例項

客戶端：VLC
RTSP伺服器：LIVE555 Media Server

1)C(Client)-> M(Media Server) 
OPTIONS rtsp://192.168.1.109/1.mpg RTSP/1.0 
CSeq: 1 
user-Agent: VLC media player(LIVE555 Streaming Media v2007.02.20) 

1)M -> C 
RTSP/1.0 200 OK 
CSeq: 1 
Date: wed, Feb 20 2008 07:13:24 GMT 
Public: OPTIONS, DESCRIBE, SETUP, TEARDOWN, PLAY, PAUSE 

2)C -> M 
DESCRIBE rtsp://192.168.1.109/1.mpg RTSP/1.0 
CSeq: 2 
Accept: application/sdp 
User-Agent: VLC media player(LIVE555 Streaming Media v2007.02.20) 

2)M -> C 
RTSP/1.0 200 OK 
CSeq: 2 
Date: wed, Feb 20 2008 07:13:25 GMT 
Content-Base: rtsp://192.168.1.109/1.mpg/ 
Content-type: application/sdp 
Content-length: 447 
v=0 
o =- 2284269756 1 IN IP4 192.168.1.109 
s=MPEG-1 or 2 program Stream, streamed by the LIVE555 Media Server 
i=1.mpg 
t=0 0 
a=tool:LIVE555 Streaming Media v2008.02.08 
a=type:broadcast 
a=control:* 
a=range:npt=0-66.181 
a=x-qt-text-nam:MPEG-1 or Program Stream, streamed by the LIVE555 Media Server 
a=x-qt-text-inf:1.mpg 
m=video 0 RTP/AVP 32 
c=IN IP4 0.0.0.0 
a=control:track1 
m=audio 0 RTP/AVP 14 
c=IN IP4 0.0.0.0 
a=control:track2 

3)C -> M 
SETUP rtsp://192.168.1.109/1.mpg/track1 RTSP/1.0 
CSeq: 3 
Transport: RTP/AVP; unicast;client_port=1112-1113 
User-Agent: VLC media player(LIVE555 Streaming Media v2007.02.20) 

3)M -> C 
RTSP/1.0 200 OK 
CSeq: 3 
Date: wed, Feb 20 2008 07:13:25 GMT 
Transport: RTP/AVP;unicast;destination=192.168.1.222;source=192.168.1.109;client_port=1112-1113;server_port=6970-6971 
Session: 3 

4)C -> M 
SETUP rtsp://192.168.1.109/1.mpg/track2 RTSP/1.0 
CSeq: 4 
Transport: RTP/AVP; unicast;client_port=1114-1115 
Session: 3 
User-Agent: VLC media player(LIVE555 Streaming Media v2007.02.20) 

4)M -> C 
RTSP/1.0 200 OK 
CSeq: 4 
Date: wed, Feb 20 2008 07:13:25 GMT 
Transport: RTP/AVP;unicast;destination=192.168.1.222;source=192.168.1.109;client_port=1114-1115;server_port=6972-6973 
Session: 3 

5)C -> M 
PLAY rtsp://192.168.1.109/1.mpg/ RTSP/1.0 
CSeq: 5 
Session: 3 
Range: npt=0.000- 
User-Agent: VLC media player(LIVE555 Streaming Media v2007.02.20) 

5)M -> C 
RTSP/1.0 200 OK 
CSeq: 5 
Range: npt=0.000- 
Session: 3 
RTP-Info: url=rtsp://192.168.1.109/1.mpg/track1;seq=9200;rtptime=214793785,url=rtsp://192.168.1.109/1.mpg/track2;seq=12770;rtptime=31721

(開始傳輸流媒體…)


相關推薦

RTMP協議與RTSP協議比較

考慮做一個手機直播系統，首先需要指定一個合理的技術方案。由於自己以前不是搞多媒體這塊，對流媒體開發不熟悉，自己的理解思維總習慣用java web開發的慣性走，先指定一個大體的框架。不管對還是錯，先考慮其技術可行性。 框架的指定，首先取決於自己採用的流媒體協議，我們熟知的流媒體協議有RTMP,RTSP,HLS

OSPF協議與RIP協議比較

一 從網路結構看：      RIP的拓撲簡單，適用於中小型網路。沒有系統內外、系統分割槽、邊界等概念，用的不是分類的路由。每一個節點只能處理以自己為頭的至多16個節點的鏈，路由是依靠下一跳的個數來描述的，無法體現頻寬與網路延遲。      OSPF適用於較大規模網路。它

HTTP協議/RTP/RTSP協議/RTMP協議的區別

寫在前面：RTP的解析，網上找了很多資料，但是都不全，所以我力圖整理出一個比較全面的解析， 其中借鑑了很多文章，我都列在了文章最後，在此表示感謝。 網際網路的發展離不開大家的無私奉獻，我決定從我做起，希望大家支援。 1、RTP Header解析                       

計算機網路中TCP協議與UDP協議的比較

在計算機網路層次結構的運輸層中，TCP協議、UDP協議解決了端到端的通訊問題。 在這裡的協議即為軟體，用以解決計算機網路的通訊互聯問題。 計算機網路層次結構概述 現代計算機網路基本層次結構由5個層次組成，自頂向下為：應用層、運輸層、網路層、資料

淺析TCP協議與UDP協議

linux運維TCP（Transmission Control Protocol），全稱傳輸控制協議。工作在TCP/IP協議棧中的傳輸層，為主機層對主機層的連接提供了可靠的鏈接服務。此協議通過三個步驟使客戶機與服務器建立一個連接，並通過四個步驟關閉此連接，這個過程我們分別稱之為三次握手和四次揮手。UDP（（U

Http協議與TCP協議簡單理解( 轉 )

art 這也 這一 傳輸協議 方便 編寫 庫服務器 為我 之間 在C#編寫代碼，很多時候會遇到Http協議或者TCP協議，這裏做一個簡單的理解。TCP協議對應於傳輸層，而HTTP協議對應於應用層，從本質上來說，二者沒有可比性。Http協議是建立在TCP協議基礎之上的，當瀏覽

TCP/IP協議與Http協議的區別

內容 發送請求 nfs bstr quest alibaba 數據包 緩存 med 　TPC/IP協議是傳輸層協議，主要解決數據如何在網絡中傳輸，而HTTP是應用層協議，主要解決如何包裝數據。關於TCP/IP和HTTP協議的關系，網絡有一段比較容易理解的介紹：“我們在傳輸數

tomcat http協議與ajp協議

分配 情況 bsp 直接 OS 狀態 默認 redirect 文本 AJP13是定向包協議。因為性能原因，使用二進制格式來傳輸可讀性文本。WEB服務器通過 TCP連接和SERVLET容器連接。為了減少進程生成 socket的花費，WEB服務器和SERVLET容器之間嘗

CAN協議與CANOpen協議

cnblogs 數據 再看 詳細介紹 .net TP 詳細 html open 　　這裏詳細介紹了CAN協議中數據通信幀每位的含義，有圖片，值得一看：https://www.cnblogs.com/pejoicen/p/3986587.html 　　這裏介紹了CanOpen

03 http請求協議與響應協議

pos conn nec TP cti AS .com form type 編輯本博客 yuan先生blogs 請求協議 請求格式 請求首行： 請求方式：get，post 請求路徑：/form/entry 協議版本：HTTP/1.1 請求頭： Host Connect

淺談幸運28源碼下載FIle協議與Http協議及區別

文件file oct 信息 響應 ont view 升級 文件傳輸 協議 先看三段代碼： index.html: 復制代碼<!DOCTYPE html><html lang="en"><head><meta ch

TCP/IP協議與HTTP協議（一）

tar idt 通過 inter bubuko 通信 單位 網絡設備 proto 1、什麽是TCP/IP 如果要了解一個人，可以從他歸屬的集體聊起來。我們的HTTP協議就屬於TCP/IP協議家族中的一員，了解HTTP協議再整個網絡流程中的地位，也能更加充分的理

TCP/IP協議與HTTP協議（二）

動向 沒有 代理 serve 相互 基本 而且 網絡連接 正式 TCP/IP協議是傳輸層協議，主要解決數據如何在網絡中傳輸，而HTTP是應用層協議，主要解決如何包裝數據。 1、TCP連接 手機能夠使用聯網功能是因為手機底層實現了TCP/IP協議，可以使手機終端通過無線網絡

詳知：http協議與soap協議之間的區別

http是標準超文字傳輸協議。使用對引數進行編碼並將引數作為鍵值對傳遞，還使用關聯的請求語義。每個協議都包含一系列HTTP請求標頭及其他一些資訊，定義客戶端向伺服器請求哪些內容，伺服器用一系列HTTP響應標頭和所請求的資料進行響應。HTTP-GET 使用 MIME 型別application

Http協議與TCP協議

背景 在日常工作中，經常會遇到某某框架是基於Http協議或者TCP協議，今天，就針對於該協議，整理下 從本質上來說，Http協議與TCP協議是應用在不同網路層，Http協議處於應用層，TCP處於傳輸層，從上往下的網路層來劃分的話，Http是基於TCP Http協議是一種無狀態的短連線； 何為無狀態？是

TCP協議與UDP協議

用戶 png 理解 等於 序列 收發消息 tag 數據報 size 一.TCP協議： 1.初識TCP：TCP---傳輸控制協議,提供的是面向連接、可靠的字節流服務。當客戶和服務器彼此交換數據前，必須先在雙方之間建立一個TCP連接，之後才能傳輸數據。TCP提供超時重發，丟棄重

TCP協議與HTTP協議

TCP協議與HTTP協議簡介 HTTP，超文字傳輸協議。它是網際網路上應用最為廣泛的一種網路協議。  SOAP, 簡單物件訪問協議。是交換資料的一種協議規範。基於xml, web TCP/IP, 傳輸控制協議/因特網互聯協議，又名網路通訊協議，是Internet最基本的協議， Inte

URL協議與HTTP協議簡介

HTTP：（Hypertext transfer protocol）超文字傳輸協議，是用於從全球資訊網（WWW:World Wide Web）伺服器傳輸超文字到本地瀏覽器的傳送協議。 URL：（Uniform Resource Locator）統一資源定位符，對可以從網際網路上得到的資源的位置和訪問

物聯網常見通訊協議與通訊協議梳理【上】- 通訊協議

  先說明, 這是在微信公眾號看到的,不是自己所寫, 覺得別人總結的很好, 就拿過來了.對於學習, 做一個搬運工也不可恥了,將好的知識自己吸收.  在微信公眾號裡, 沒有找到連線.     1  “通訊”與“通訊”傻傻分得清 傳統意義上的“

TCP/IP協議，HTTP協議與webSocket協議區別

http協議（識別資料內容）與webSocket協議 同：建立在TCP之上，同http一樣通過TCP來傳輸資料 不同： HTTP協議為單向協議，即瀏覽器只能向伺服器請求資源，伺服器才能將資料傳送給瀏覽器，而伺服器不能主動向瀏覽器傳遞資料。分為長連線和短連線，短連線是