RTSP協(xié)議棧

rtsp流媒體協(xié)議其實(shí)主要涉及到4種協(xié)議：RTP、RTCP、RTSP、SDP。典型流媒體框架體系參考如下圖：

image.png

RTSP協(xié)議定義了一對(duì)多應(yīng)用程序如何有效地通過IP網(wǎng)絡(luò)傳送多媒體數(shù)據(jù)。RTSP在體系結(jié)構(gòu)上位于RTP和RTCP之上，它使用TCP或UDP完成數(shù)據(jù)傳輸。HTTP與RTSP相比，HTTP請(qǐng)求由客戶機(jī)發(fā)出，服務(wù)器作出響應(yīng)；使用RTSP時(shí)，客戶機(jī)和服務(wù)器都可以發(fā)出請(qǐng)求，即RTSP可以是雙向的。

RTP

RTP(Real Time Transport Protocol)是針對(duì)Internet上多媒體數(shù)據(jù)流的一個(gè)傳輸協(xié)議。, 由IETF(Internet工程任務(wù)組)作為RFC1889發(fā)布。RTP被定義為在一對(duì)一或一對(duì)多的傳輸情況下工作，其目的是提供時(shí)間信息和實(shí)現(xiàn)流同步。RTP的典型應(yīng)用建立在UDP上，但也可以在TCP或ATM等其他協(xié)議之上工作。RTP本身只保證實(shí)時(shí)數(shù)據(jù)的傳輸，并不能為按順序傳送數(shù)據(jù)包提供可靠的傳送機(jī)制，也不提供流量控制或擁塞控制，它依靠RTCP提供這些服務(wù)。

RTCP

RTCP(Real Time Contorl Protocol)負(fù)責(zé)管理傳輸質(zhì)量在當(dāng)前應(yīng)用進(jìn)程之間交換控制信息。在RTP會(huì)話期間，各參與者周期性地傳送RTCP包，包中含有已發(fā)送的數(shù)據(jù)包的數(shù)量、丟失的數(shù)據(jù)包的數(shù)量等統(tǒng)計(jì)資料。因此，服務(wù)器可以利用這些信息動(dòng)態(tài)地改變傳輸速率，甚至改變有效載荷類型。RTP和RTCP配合使用，能以有效的反饋和最小的開銷使傳輸效率最佳化，故特別適合傳送網(wǎng)上的實(shí)時(shí)數(shù)據(jù)。

RTSP

RTSP( Real Time Streaming Protocol，RFC2326)，實(shí)時(shí)流傳輸協(xié)議，是TCP/IP協(xié)議體系中的一個(gè)應(yīng)用層協(xié)議。協(xié)議主要規(guī)定定了一對(duì)多應(yīng)用程序如何有效地通過IP網(wǎng)絡(luò)傳送多媒體數(shù)據(jù)，并允許同時(shí)多個(gè)串流需求控制。RTSP體系結(jié)位于RTP和RTCP之上（RTCP用于控制傳輸，RTP用于數(shù)據(jù)傳輸），使用TCP或UDP完成數(shù)據(jù)傳輸。承載RTSP的傳輸層協(xié)議為TCP，默認(rèn)端口554。
交互流程圖如下：

image.png

wireshark抓包圖如下：

image.png

服務(wù)器端收到客戶端請(qǐng)求后，根據(jù)客戶端請(qǐng)求的端口號(hào)確定發(fā)送控制數(shù)據(jù)的端口以及音視頻數(shù)據(jù)的端口。一個(gè)setup只能給一種媒體源建立流傳輸通道。
PLAY：客戶端向服務(wù)端請(qǐng)求播放媒體。服務(wù)器回復(fù)客戶端200 OK! 之后開始通過SETUP中指定的端口開始發(fā)送數(shù)據(jù)。PLAY消息會(huì)在range中指定媒體的播放時(shí)間，服務(wù)器在接到PLAY消息后會(huì)由range中指定的開始點(diǎn)開始發(fā)送媒體數(shù)據(jù)直到range中指定的結(jié)束點(diǎn)。

Wireshark抓包詳解

抓包過濾方式：rtsp or rtp or rtcp
右鍵-->Follow -->TCP Stream，可以看到整個(gè)協(xié)議交互的流程。

image.png

image.png

OPTIONS

OPTIONS rtsp://192.168.8.169:554/Streaming/Channels/201 RTSP/1.0
CSeq: 1
User-Agent: Lavf59.16.100

RTSP/1.0 401 Unauthorized
CSeq: 1
WWW-Authenticate: Digest realm="ed7d7cc54ddef26fc9b44484", nonce="13a518147", algorithm="MD5"
WWW-Authenticate: Basic realm="/"

OPTIONS rtsp://192.168.8.169:554/Streaming/Channels/201 RTSP/1.0
CSeq: 2
User-Agent: Lavf59.16.100
Authorization: Digest username="admin", realm="ed7d7cc54ddef26fc9b44484", nonce="13a518147", uri="rtsp://192.168.8.169:554/Streaming/Channels/201", response="805c395830e56d283f4797d5eb03c5a5", algorithm="MD5"

RTSP/1.0 200 OK
CSeq: 2
Public: OPTIONS, DESCRIBE, SETUP, PLAY, TEARDOWN, PAUSE, SET_PARAMETER, GET_PARAMETER
Date: Mon, 17 Jul 2023 13:22:31 GMT

可以看到第一次發(fā)送OPTIONS請(qǐng)求，服務(wù)端返回了401。
RTSP 可以未經(jīng)身份驗(yàn)證來訪問。rtsp url直接攜帶明文的用戶名和密碼不安全，一般不使用。現(xiàn)在一半使用HTTP認(rèn)證。
RTSP的HTTP認(rèn)證有2種方式：
● 基本認(rèn)證（basic authentication）是http1.0提出的認(rèn)證方案，其消息傳輸不經(jīng)過加密轉(zhuǎn)換，存在嚴(yán)重的安全隱患
● 摘要認(rèn)證（digest authentication）是http1.1提出的基本認(rèn)證的替代方案，其消息經(jīng)過MD5加密轉(zhuǎn)換，具有更高的安全性

DESCRIBE

image.png

RTSP/1.0 200 OK
CSeq: 3
Content-Type: application/sdp
Content-Length: 630
Date: Mon, 17 Jul 2023 13:22:31 GMT

v=0
o=- 1109162014219182 0 IN IP4 0.0.0.0
s=HIK Media Server V4.51.026
i=HIK Media Server Session Description : standard
e=NONE
c=IN IP4 0.0.0.0
t=0 0
a=control:*
b=AS:1034
a=range:npt=now-
m=video 0 RTP/AVP 96
i=Video Media
a=rtpmap:96 H264/90000
a=fmtp:96 profile-level-id=4D0014;packetization-mode=0;sprop-parameter-sets=Z00AH42NQCgC3QgAAEZQAAr8gCA=,aO44gA==
a=control:trackID=video
b=AS:1024
m=audio 0 RTP/AVP 0
i=Audio Media
a=rtpmap:0 PCMU/8000
a=control:trackID=audio
b=AS:10
a=Media_header:MEDIAINFO=494D4B48020100000400000110710110401F000000FA000000000000000000000000000000000000;
a=appversion:1.0

服務(wù)端對(duì)DESCRIBE的請(qǐng)求回復(fù)中包含了媒體信息，媒體信息包含在了SDP描述信息中。如上圖所示：視頻編碼格式為H264，音頻編碼格式為PCMU。
SDP描述中可以包含多個(gè)流媒體描述，每個(gè)流媒體都是以m開頭，到遇到下個(gè)m為止，媒體流選擇是通過媒體描述的附加屬性a=control:

SDP媒體描述信息說明

SDP（Session Description Protocol）是一種會(huì)話描述協(xié)議，用于描述多媒體會(huì)話的參數(shù)。它是一種文本協(xié)議，通常用于VoIP（Voice over Internet Protocol）和視頻會(huì)議等應(yīng)用中。SDP協(xié)議定義了一種標(biāo)準(zhǔn)的格式，用于描述會(huì)話的各種參數(shù)，包括媒體類型、媒體格式、媒體地址等。
SDP媒體描述極其擴(kuò)展屬性，在不同的協(xié)議中有定義有所不同，需要參照不同協(xié)議的協(xié)議規(guī)范來看，這里介紹的是比較通用的定義，以RTSP協(xié)議中SDP的媒體描述定義。媒體描述擴(kuò)展屬性中有關(guān)c、b等屬性不在做介紹，主要介紹m極其擴(kuò)展屬性a=control\a=rtpmap\a=fmtp進(jìn)行詳細(xì)介紹。

m屬性介紹

m屬性的格式如下：

m=<media> <port> <proto> <fmt> ...

實(shí)例如下：

m=video 0 RTP/AVP 96

每個(gè)字段代表的含義如下：
media：媒體類型，目前應(yīng)用到的有video/audio/application等表示視頻/音頻/元數(shù)據(jù)等類型，根據(jù)不通協(xié)議規(guī)范，可擴(kuò)展其他類型。
port：流媒體服務(wù)器發(fā)送數(shù)據(jù)的傳輸端口號(hào)，表示服務(wù)器從本端口發(fā)送流，0表示隨機(jī)端口發(fā)送，如果是RTSP協(xié)議，一般為0，后繼協(xié)議SETUP時(shí)確定傳輸端口。
proto：傳輸?shù)膮f(xié)議類型， RTP/AVP表示支持UDP傳輸，RTP/AVP/TCP支持TCP傳輸，主流交互協(xié)議中，也用RTP/AVP表示既支持UDP又支持TCP。
<fmt>：媒體格式描述，RTP中用payloadtype來賦值，表示流的類型，這里會(huì)和后面"a=rtpmap:"、“a=fmtp:”相關(guān)聯(lián)，具體對(duì)媒體進(jìn)行描述。

a=control附加屬性介紹

SDP描述中可以包含多個(gè)流媒體描述，每個(gè)流媒體都是以m開頭，到遇到下個(gè)m為止，媒體流選擇是通過媒體描述的附加屬性a=control:來區(qū)分。如前面的

a=control:trackID=video
...
a=control:trackID=audio

a=rtpmap附加屬性介紹

附加屬性的格式如下：

a=rtpmap:<payload type><encoding name>/<clock rate>[/<encodingparameters>]

實(shí)例如下：

a=rtpmap:96 H264/90000

詳解如下：
payloadtype:負(fù)載類型在多路復(fù)用技術(shù)中表示一個(gè)流通道，這里與媒體信息中的fmt對(duì)應(yīng)
擴(kuò)展描述媒體打包信息
encodingname：編碼方式，表示流的編碼方式，比如H264、H265等
clock rate：采樣的時(shí)鐘頻率，這里視頻流一般為90000，如果為RTP流，時(shí)鐘頻率將作為RTP幀間隔的衡量，例如幀間隔為40ms，則RTP包的時(shí)間戳間隔為（40/1000）*90000=3600

a=fmtp附加屬性介紹

附件屬性的格式，H264和H265有一定的區(qū)別，這里分開來說明，首先看下H264格式

a=fmtp:<payload type> profile-level-id=<xxx>; packetization-mode=1;sprop-parameter-sets=xxx,xxx

profile-level-id：為三個(gè)十六進(jìn)制表示的字節(jié)，第一個(gè)字節(jié)表示profile_idc（編碼規(guī)格），第二個(gè)字節(jié)表示profile-iop，第三個(gè)字節(jié)表示level_idc編碼等級(jí)，profile_idc一般有三個(gè)取值0x42(66)-baseline profile,0x4D(77)-main profile,0x58(88)-extened profile;profile-iop, 0x64(100)-high profile;
packetization-mode：表示封裝方式，0或不存在時(shí), 必須使用單一NALU 單元模式；1-必須使用非交錯(cuò)(non-interleaved)封包模式；2-必須使用交錯(cuò)(interleaved)封包模式，一般采用非交錯(cuò)模式。

SETUP

SETUP rtsp://192.168.8.169:554/Streaming/Channels/201/trackID=audio RTSP/1.0
Transport: RTP/AVP/UDP;unicast;client_port=19848-19849
CSeq: 5
User-Agent: Lavf59.16.100
Session: 1634076345
Authorization: Digest username="admin", realm="ed7d7cc54ddef26fc9b44484", nonce="13a518147", uri="rtsp://192.168.8.169:554/Streaming/Channels/201/trackID=audio", response="d0386129e2de040df32acb7893bdf0ee", algorithm="MD5"

RTSP/1.0 200 OK
Session: 1634076345;timeout=60
Transport: RTP/AVP/UDP;unicast;client_port=19848-19849;server_port=62360-62361;ssrc=616606ba
CSeq: 5
Accept-Ranges: NPT
Media-Properties: No-Seeking, Time-Progressing, Time-Duration=0
Date: Mon, 17 Jul 2023 13:22:31 GMT

SETUP指令指定某個(gè)媒體流要如何傳輸，每一個(gè)流需要一個(gè)SETUP命令，視頻流一個(gè)SETUP，音頻流一個(gè)SETUP。
重點(diǎn)看一下Transport：
RTP/AVP：表示RTP通過UDP發(fā)送；RTP/AVP/TCP則表示RTP通過TCP發(fā)送
unicast：表示單播，如果是multicast則表示多播
client_port=54492-54493：由于這里希望采用的是RTP OVER UDP，所以客戶端發(fā)送了兩個(gè)用于傳輸數(shù)據(jù)的端口，客戶端已經(jīng)將這兩個(gè)端口綁定到兩個(gè)udp套接字上，9848表示是RTP端口，19849表示RTCP端口(RTP、RTCP端口成對(duì)出現(xiàn)，RTP端口為某個(gè)偶數(shù)，RTCP端口為RTP端口+1)。
服務(wù)端回復(fù)setup時(shí)，將會(huì)生成一個(gè)session ID.后續(xù)消息必須帶有此Session字段。可以通過查看視頻、音頻的sesseionID，確定兩個(gè)媒體流是否共享同一個(gè)會(huì)話。

PLAY方法

PLAY rtsp://192.168.8.169:554/Streaming/Channels/201 RTSP/1.0
Range: npt=0.000-
CSeq: 6
User-Agent: Lavf59.16.100
Session: 1634076345
Authorization: Digest username="admin", realm="ed7d7cc54ddef26fc9b44484", nonce="13a518147", uri="rtsp://192.168.8.169:554/Streaming/Channels/201", response="d422b155bd6516dad0d5b2faa3632b20", algorithm="MD5"

RTSP/1.0 200 OK
Session: 1634076345
CSeq: 6
Date: Mon, 17 Jul 2023 13:22:31 GMT

GET_PARAMETER rtsp://192.168.8.169:554/Streaming/Channels/201 RTSP/1.0
CSeq: 7
User-Agent: Lavf59.16.100
Session: 1634076345
Authorization: Digest username="admin", realm="ed7d7cc54ddef26fc9b44484", nonce="13a518147", uri="rtsp://192.168.8.169:554/Streaming/Channels/201", response="9b5ff41796895b08b6d87296b2857a64", algorithm="MD5"

RTSP/1.0 200 OK
CSeq: 7
Date: Mon, 17 Jul 2023 13:23:01 GMT

PLAY方法會(huì)再range中指定媒體的播放時(shí)間。PLAY可帶有scale和speed字段用于點(diǎn)播速度控制。對(duì)于實(shí)時(shí)流range一般為Range: npt=0.000。

TEARDOWN

結(jié)束流傳輸，同時(shí)釋放與之相關(guān)的資源，TEARDWON之后，整個(gè)RTSP連接也就結(jié)束了。TEARDOWN中發(fā)送的字段Session為之前SETUP請(qǐng)求后服務(wù)端返回的session字段的值，用于表示此次會(huì)話連接。

RTP包格式分析

服務(wù)端回復(fù)PLAY消息之后，客戶端就開始向服務(wù)端推流。通過RTP協(xié)議傳輸音視頻流。
RTP包由RTP header和RTP payload2部分組成。

image.png

每個(gè)字段的含義如下：
V：RTP協(xié)議的版本號(hào)，占2位，當(dāng)前協(xié)議版本號(hào)為2。
P：填充標(biāo)志，占1位，如果P=1，則在該報(bào)文的尾部將填充一個(gè)或多個(gè)額外的八位組，它們不是有效載荷的一部分。
X：擴(kuò)展標(biāo)志，占1位，如果X=1，則在RTP報(bào)頭后跟有一個(gè)擴(kuò)展報(bào)頭。
CC：CSRC計(jì)數(shù)器，占 4位，指示CSRC 標(biāo)識(shí)符的個(gè)數(shù)，因此CSRC數(shù)量最多為15。主要用于多流組合傳播。
M: 標(biāo)記，占1位，不同的有效載荷有不同的含義。當(dāng)多個(gè)RTP包攜帶1幀數(shù)據(jù)時(shí)，前面的RTP包的marker標(biāo)志設(shè)置為0，最后一個(gè)RTP包marker標(biāo)志設(shè)置為1。
PT: 有效載荷類型，占7位，用于說明RTP報(bào)文中有效載荷的類型，如GSM音頻、JPEM圖像等。
序列號(hào)：占16位，用于標(biāo)識(shí)發(fā)送者所發(fā)送的RTP報(bào)文的序列號(hào)，每發(fā)送一個(gè)報(bào)文，序列號(hào)增1。接收者通過序列號(hào)來檢測(cè)報(bào)文丟失情況，重新排序報(bào)文，恢復(fù)數(shù)據(jù)。
時(shí)戳 (Timestamp)：占32位，時(shí)戳反映了該RTP報(bào)文的第一個(gè)八位組的采樣時(shí)刻。接收者使用時(shí)戳來計(jì)算延遲和延遲抖動(dòng)，并進(jìn)行同步控制。
同步信源(SSRC)標(biāo)識(shí)符：占32位，用于標(biāo)識(shí)同步信源。該標(biāo)識(shí)符是隨機(jī)選擇的，參加同一視頻會(huì)議的兩個(gè)同步信源不能有相同的SSRC。
特約信源(CSRC)標(biāo)識(shí)符：每個(gè)CSRC標(biāo)識(shí)符占32位，可以有0～15個(gè)。每個(gè)CSRC標(biāo)識(shí)了包含在該RTP報(bào)文有效載荷中的所有特約信源，當(dāng)數(shù)量超過15時(shí)，僅識(shí)別15個(gè)。
擴(kuò)展頭(Extension Header)：可選。
載荷(PayLoad)：真正要傳輸?shù)臄?shù)據(jù)，比如音頻或者視頻數(shù)據(jù)。
視頻抓包結(jié)構(gòu)如下圖所示：

image.png

RTP payload type取值及含義解釋

image.png

上表中列出了一些常用的音視頻負(fù)載類型，還有些負(fù)載類型由于誕生的較晚，沒有具體的PT值，只能使用動(dòng)態(tài)（dynamic）PT值，即96到127，這就是為什么普遍指定H264的PT值為96。

視頻/音頻RTP區(qū)別及解析

Wireshark操作：

1. 右鍵，選中一個(gè)RTP包，選擇【Decode As】。

   
   
   image.png

2. 在彈出框中，添加如下：

   
   
   image.png

3. 前后區(qū)別
   未設(shè)置前，Payload還是

   
   
   image.png
   
   

   設(shè)置后，可以看到前2個(gè)包是SPS和PPS。

   
   
   image.png
   
   SPS即Sequence Paramater Set，又稱作序列參數(shù)集。SPS中保存了一組編碼視頻序列(Coded video sequence)的全局參數(shù)。所謂的編碼視頻序列即原始視頻的一幀一幀的像素?cái)?shù)據(jù)經(jīng)過編碼之后的結(jié)構(gòu)組成的序列。而每一幀的編碼后數(shù)據(jù)所依賴的參數(shù)保存于圖像參數(shù)集中。一般情況SPS和PPS的NAL Unit通常位于整個(gè)碼流的起始位置。
   但在某些特殊情況下，在碼流中間也可能出現(xiàn)這兩種結(jié)構(gòu)，主要原因可能為：
   1、解碼器需要在碼流中間開始解碼；
   

   2、編碼器在編碼的過程中改變了碼流的參數(shù)（如圖像分辨率等）；
   SPS包含如下信息Sequence Paramater Set，又稱作序列參數(shù)集profile_idc：標(biāo)志是baseline profile(基準(zhǔn)檔次)、main profile、extended profilelevel_idc：編碼的Level定義了某種條件下的最大視頻分辨率、最大視頻幀率等參數(shù)max_num_ref_frames：用于表示參考幀的最大數(shù)目。pic_width_in_mbs_minus1：用于計(jì)算圖像的寬度。單位為宏塊個(gè)數(shù)，因此圖像的實(shí)際寬度為:frame_width = 16 × (pic_width_in_mbs_minus1 + 1);pic_height_in_map_units_minus1：用于計(jì)算圖像的高度。
   PPS包含的信息圖像參數(shù)集Picture Paramater Set(PPS)entropy_coding_mode_flag：熵編碼模式標(biāo)識(shí)num_slice_groups_minus1：表示某一幀中slice group的個(gè)數(shù)weighted_bipred_idc：表示在B Slice中加權(quán)預(yù)測(cè)的方法constrained_intra_pred_flag：若該標(biāo)識(shí)為1，表示I宏塊在進(jìn)行幀內(nèi)預(yù)測(cè)時(shí)只能使用來自I和SI類型宏塊的信息；若該標(biāo)識(shí)位0，表示I宏塊可以使用來自Inter類型宏塊的信息。

I幀數(shù)據(jù)開始、結(jié)束

開始和結(jié)束，RTP頭中的Marker分別為false和true。

image.png

image.png

同一幀的timestamp時(shí)間戳是相同的。

H.264的RTP負(fù)載格式

RTP Payload有很多形式，可以傳輸編碼的數(shù)據(jù)如視頻H264、H265、音頻G711、OPUS等數(shù)據(jù)，也可以傳輸封裝好的數(shù)據(jù)，如GB28181中常用的PS流等。
由于H264幀大小差別較大，較小的幀小于MTU，則可單包直接發(fā)送，或者多幀組合發(fā)送，當(dāng) NALU 的長(zhǎng)度超過 MTU 時(shí), 就必須對(duì) NALU 單元進(jìn)行分片封包了，比如H264的I幀。
H264 Payload定義了三種不同的基本的負(fù)載結(jié)構(gòu)。
○ Single NAL Unit Packet(單個(gè)NAL單元數(shù)據(jù)包)
○ Aggregation Packet(聚合數(shù)據(jù)包)
○ Fragmenttation Unit(分片單元FU)
單一NAL單元：對(duì)于H264 NALU的長(zhǎng)度小于MTU的包, 一般采用單一NAL單元模式。
打包時(shí)去除"00 00 01" 或 "00 00 00 01"的H264 NALU開始碼, 把其他數(shù)據(jù)封裝到RTP負(fù)載即可。
接收端可以通過RTP Payload的第一個(gè)字節(jié)來識(shí)別它們。

image.png

● F：在規(guī)范中規(guī)定了這一位必須為0.
● NRI：取00~11，表示這個(gè)NALU的重要性，如00的NALU解碼器可以丟棄它而不影響圖像的回放.
● Type：這個(gè)NALU單元的類型，具體如下：
1-23 NAL unit 單一NAL單元
24 STAP-A 單一時(shí)間的組合包模式A
25 STAP-B 單一時(shí)間的組合包模式B
26 MTAP16 多個(gè)時(shí)間的組合包模式A
27 MTAP24 多個(gè)時(shí)間的組合包模式B
28 FU-A 分片的單元模式A
29 FU-B 分片的單元模式B
RTP包中接收的264包是不含有0x00,0x00,0x00,0x01頭的，這部分是rtp接收以后，另外再加上去的，解碼的時(shí)候再做判斷的。
對(duì)于FU的分片模式：
RTP頭部之后的第一個(gè)字節(jié)為 FU indicator，第二個(gè)字節(jié)為 FU header。

image.png

NAL Header(8位----二進(jìn)制位) 的組成為：
forbidden_zero_bit(1bit) + nal_ref_idc(2bit) + nal_unit_type(5bit)
nal_ref_idc: 值越大，代表越重要。

Wireshark保存音視頻裸流

視頻裸流保存

導(dǎo)出H264、H265需要2個(gè)lua的wireshark插件。

image.png

image.png

選擇export all，然后待裸流文件生成后，點(diǎn)擊Browser查看生成的文件?？梢允褂孟鄳?yīng)播放器進(jìn)行播放。

image.png

參考

https://blog.csdn.net/feeltouch/article/details/82957377/
https://zhuanlan.zhihu.com/p/478736595?utm_id=0
https://blog.csdn.net/SimpleForest/article/details/129894415
https://www.pianshen.com/article/78351144335/
https://blog.51cto.com/tsingsee/2733044
https://blog.csdn.net/water1209/article/details/128982677?spm=1001.2014.3001.5502
https://blog.csdn.net/water1209/article/details/126019065
https://blog.51cto.com/u_13267193/5986939