RTSP協議詳解 一

2021-07-24 10:54:28 字數 3533 閱讀 7870

1.   

overview

rtsp

(real time streaming protocol

),rfc2326

,實時流

傳輸協議

,是tcp/ip

協議體系中的乙個

應用層協議,該協議定義了一對多應用程式如何有效地通過

ip網路

傳送多**資料。

圖1 rtsp的主要結構

圖1中第一層是rtsp協議的主要構成部分,包括rtp, rtcp,以及rtsp本身。第二層則是上一層協議將會通過哪些協議傳送出去,包括udp和tcp,圖中rtp和rtcp對應的是udp,其實rtp和rtcp也是可以通過tcp進行傳送的。

所以想要學習rtsp則必須先學習rtp和rtcp(rtcp可以忽略),因為rtsp僅僅是乙個互動協議,並不負責資料的傳輸任務,而rtp協議則承擔著資料傳輸的任務。

2.   rtp(real-timetransport protocol

,實時傳輸協議)

網上關於rtp協議的文章很多,但是真正能全部講通透的並不多,而且他們多數是利用開源**編寫個demo,但是開源**對於剛開始學的朋友顯得略微有些難以理解。好啦,不廢話,進入正題。

一般不管什麼協議都是由head和body兩部分構成,rtp也不例外。rtp的head如圖2所示。

圖2rtp

的head

每行是32bits

,由此可以直**到每個表示部分所佔的位數。簡單介紹一下:

v(version)

:2 bits

,rtp

的版本,這裡統一為2

p(padding)

:1 bit

,如果置1,在

packet

的末尾被填充,填充有時是方便一些針對固定長度的

演算法的封裝,一般直接置為0。

x(extension)

:1 bit

,如果置1,在

rtpheader

會跟著乙個

headerextension

,一般直接置為0。

cc(csrc count): 4 bits

,表示頭部後

contributingsources

的個數,一般直接置為0。

m(marker): 1 bit

,標誌著是否為一幀的結束

pt(playload type): 7 bits

,表示所傳輸的多**的型別,本文中的

h.264

的型別為96

sequence number: 16 bits

,每個rtppacket

的sequencenumber

會自動加

1,以便接收端檢測丟包情況

timestamp: 32 bits

,時間戳

ssrc: 32 bits

,同步源的

id,沒兩個同步源的

id不能相同

csrc:

上文說到,個數由

cc指定,範圍是

0-15

,直接忽略,不寫入碼流

static void send_rtp_data(rtpmux *rtpmux, const uint8_t *buf1, int len, int m)

上述**就是rtp協議的12bytes頭,相信這個對大家都不難理解吧,因為樓主電腦寫檔案的時候採用的是小端模式,所以需要將小端模式轉換為大端模式,則上述**中smalltobig_2和smalltobig_4就是分別代表著將2byte和4byte的資料由小端模式轉換到大端模式的巨集。

rtp協議的head部分已經解釋完畢,那麼現在該rtp的body部分了。

rtp協議的body部分可以分為三種模式:單包模式,聚合包模式以及分片模式

圖3 rtp單包模式的body部分

f(forbidden): 1bit,禁止位,一般為0

nri: 2bit,表示此包的重要性

type:5bit,表示此包所包含的nal單元是什麼型別的,例如:idr, sei, sps, pps等

第乙個位元組之後則存放的是nal的第乙個位元組之後的資料。

對於單包模式來說,直接把h.264的nal單元寫入就ok了,因為h.264的第乙個byte與rtp包的第乙個byte是一樣的,然後在其前面加上rtp head,就是乙個完整的rtp包了。

(2)fu-a分片模式

由於在網路傳輸過程中,每個包能包含的最大位元組數是有限制的,一般為1400位元組,那麼當我們使用單包模式的時候,單個包的位元組數大於1400,在網路傳輸中這種包會被丟棄的,所以,對於h.264中比較大的nal單元,我們採用fu-a分片模式來進行封裝,其封包規則如下:

圖4 rtp fu-a分片模式

圖5. fu indicator和fu header

跟單包模式有所區別,主要是其頭包括fu indicator和fu header兩部分,共兩位元組,含義如下:

f(forbidden): 1bit,禁止位,一般為0

nri: 2bit,表示此包的重要性

type:5bit,表示此fu-a包為什麼型別,一般此處為28

s:1bit,是否為分片nal的開始,也就是說這個fu-a包是不是當前nal的第乙個fu-a包

e:1bit,是否為分片nal的結尾,也就是說這個fu-a包是不是當前nal的最後乙個fu-a包

r:1bit保留為,必須設定為0

type:5bit,表示此nal型別,例如:idr, sei, sps, pps等

由於fu-a分片包的特殊規則,那麼fu-a分片包必須滿足下列一些條件:

(1)rtp head + fu-a indicator + fu-a header + fu-a payload < 1400位元組,即此rtp包的大小要小於網路傳輸的限制

(2)fu-a payload(1) + fu-a payload(2) +........+ fu-a payload(n) = nal - 1,即連續的n個fu-a包的payload構成乙個nal包(不包括nal的head部分(1位元組))

rtp協議好像也就這麼多了吧,下面是原始碼位址,此原始碼採用了ffmpeg庫作為編碼庫,然後將實時編好的每一幀傳送到本機127.0.0.1上,客戶端採用的是vlc,記得要用sdp開啟,sdp我就不多說了,我會在原始碼中給出,還在審核~~~。我會在接下來的部落格裡詳細述說一下rtsp,以及給出乙份自己寫的並不是很完善的**。

RTSP協議詳解

1.rtsp協議簡介 2 rtsp特點 rtsp是有狀態的,rtsp的命令總是按照順序來傳送,某個命令總在另外乙個命令之前要傳送。rtsp不管處於什麼狀態都不會去斷掉連線。rtsp協議使用554埠。rtsp負責建立和控制會話,rtp負責多 的傳輸,rtcp配合rtp做控制和流量統計,他們是合作的關係...

RTSP 協議分析 (一)

rtsp 協議分析 1.概述 rtsp real time streaming protocol 實時流傳輸協議,是tcp ip協議體系中的乙個應用層協議,由哥倫比亞大學 網景和realnetworks公司提交的ietf rfc標準。該協議定義了一對多應用程式如何有效地通過ip網路傳送多 資料。類似...

RTSP 協議分析 (一)

rtsp 協議分析 1.概述 rtsp real time streaming protocol 實時流傳輸協議,是tcp ip協議體系中的乙個應用層協議,由哥倫比亞大學 網景和realnetworks公司提交的ietf rfc標準。該協議定義了一對多應用程式如何有效地通過ip網路傳送多 資料。類似...