生活随笔
收集整理的這篇文章主要介紹了
RTCP协议分析
小編覺(jué)得挺不錯(cuò)的,現(xiàn)在分享給大家,幫大家做個(gè)參考.
RTCP協(xié)議分析
目錄
RTCP功能 RTCP報(bào)?格式–報(bào)?類型 RTSP play同步 時(shí)間戳映射關(guān)系 媒體間同步?法（不同設(shè)備的同步） RTCP同步
1. RTCP功能
Real-time Transport Control Protocol或RTP Control Protocol或簡(jiǎn)寫RTCP）是實(shí)時(shí)傳輸協(xié)議（RTP）的?個(gè)姐妹協(xié)議。RTCP由RFC 3550定義（取代作廢的RFC 1889）。 RTP 使??個(gè) 偶數(shù) UDPport ；?RTCP 則使? RTP 的下?個(gè) port，也就是?個(gè)奇數(shù) port。 RTCP與RTP聯(lián)合?作，RTP實(shí)施實(shí)際數(shù)據(jù)的傳輸，RTCP則負(fù)責(zé)將控制包送?參與者。其主要功能是就RTP正在提供的服務(wù)質(zhì)量做出反饋。 RTCP報(bào)?封裝在UDP中進(jìn)?傳輸，作?如下: 質(zhì)量反饋 傳輸層標(biāo)識(shí)（CNAME） 給參與者發(fā)送RTCP控制報(bào)? 最?會(huì)話控制消息（可選） RTCP端?號(hào) = RTP端?號(hào) + 1
2. RTCP報(bào)?格式–報(bào)?類型
在RTP的規(guī)范（RFC 3550）中，?共定義了5種RTCP報(bào)告?來(lái)報(bào)告當(dāng)前控制信息：
Packet Type值分組類型描述 200 SR（Sender report） 發(fā)送?報(bào)告 201 RR（Receiver report） 接收?報(bào)告 202 SDES（Source description） 源描述報(bào)告 203 BYE（Goodbye） 離開(kāi)會(huì)話 204 APP（Application-defined） 應(yīng)?定義 206 REMB（Receiver Estimated Maximum Bitrate） 接收方估計(jì)的最大比特率
RTCP的5種報(bào)告：RR，SR，SDES，BYE，APP和REMB。他們使?共同的結(jié)構(gòu)，但是在某些具體的地?有?些不同。 以下是RTCP報(bào)?基本結(jié)構(gòu)： 其中?較重要的?個(gè)域及其意義如下：
域名?度（bit）含義 Version（V） 2 定義了RTP的版本，此協(xié)議定義的版本是2。 Padding（P） 1 如果填充位被設(shè)置為1，則?個(gè)或多個(gè)附加的字節(jié)會(huì)加在包頭的最后，附加的最后?個(gè)字節(jié)放置附加的字節(jié)數(shù)。填充可能?于某些具有固定?度的加密算法，或者在底層數(shù)據(jù)單元中傳輸多個(gè)RTP包。 Item count（IC） 5 有些RTCP分組類型包含多個(gè)條?（item），IC?來(lái)計(jì)算有多少個(gè)條?。因?yàn)镮C只有5個(gè)?特，所以最多31個(gè)item。如果需要的item超過(guò)31個(gè)，那么應(yīng)?實(shí)現(xiàn)必須包含多個(gè)RTCP分組。如果IC為0表示空的item列表。分組如果不需要item列表，那么可以把IC字段?于其他?的。 Packettype（PT） 8 PT標(biāo)識(shí)了分組中攜帶消息的類型。在RTP標(biāo)準(zhǔn)中定義了5種類型：RR，SR，SDES，BYE和APP Length（M） 16 分組?度，以4 bytes為單位，所以意味著RTCP分組必須是4字節(jié)對(duì)?。該?度不包含32 bites固定頭，也就是說(shuō)length為0也是合理的，說(shuō)明只有4字節(jié)的頭部（這種情況IC也是0）。
header size = 2 + 1 + 5 +8 + 16 = 4個(gè)字節(jié) SR 包，總共28字節(jié) = header 4字節(jié) + 4字節(jié)*6
typedef
struct _rtcp_header_t
{ uint32_t v
: 2 ; uint32_t p
: 1 ; uint32_t rc
: 5 ; uint32_t pt
: 8 ; uint32_t length
: 16 ;
} rtcp_header_t
;
1. RTCP報(bào)?格式-- SR報(bào)?格式
為了補(bǔ)充接收者報(bào)告，RTP協(xié)議還規(guī)定了最近發(fā)送數(shù)據(jù)的參與者發(fā)送SR，該報(bào)告提供了發(fā)送的媒體的?些信息。主要?于接收端同步多媒體流，如語(yǔ)?和視頻流 其中域及其意義如下：
域名?度（bit）含義 NTP timestamp 64 64 bites，?符號(hào)整數(shù)。指出了該報(bào)告發(fā)出時(shí)的時(shí)間 。該時(shí)間戳的?32 bites以NTP格式表示，從1900年1?1?開(kāi)始計(jì)數(shù)，以秒為單位。低32 bites表示秒后?的?數(shù)。如果需要轉(zhuǎn)化Unix時(shí)間到NTP時(shí)間，在Unix時(shí)間加上2,208,988,800即可。 RTP timestamp / RTP時(shí)間戳以RTP媒體流的時(shí)鐘為單位，這個(gè)值通常不等于前?分組數(shù)據(jù)的RTP時(shí)間戳，因?yàn)闀r(shí)間會(huì)流逝。 Sender’s packet count / 表示這個(gè)同步源從這個(gè)會(huì)話開(kāi)始到現(xiàn)在（發(fā)出RTCP報(bào)?時(shí)）發(fā)出的數(shù)據(jù)分組的個(gè)數(shù)。 Sender’s octet count / 表示同步源從這個(gè)會(huì)話開(kāi)始到現(xiàn)在（發(fā)出RTCP報(bào)?時(shí)）發(fā)出的所有數(shù)據(jù)分組的字節(jié)數(shù)。如果發(fā)送者改變了SSRC，那么sender’s packet count和sender’s octet count被會(huì)被重置。
typedef
struct _rtcp_sr_t
{ uint32_t ssrc
; uint32_t ntpmsw
; uint32_t ntplsw
; uint32_t rtpts
; uint32_t spc
; uint32_t soc
;
} rtcp_sr_t
;
如下圖我們可知： video時(shí)間戳是 2794373590，采樣率是90000，相除得到具體時(shí)間：31048.595秒 audio時(shí)間戳是 4216229973，采樣率是48000，相除得到具體時(shí)間：87838.124秒 我們發(fā)現(xiàn)，相隔0.1毫秒（29.790-29.789）發(fā)送出去的視頻、音頻包時(shí)間戳的差值特別大 rtp包打時(shí)間戳?xí)r，是有一個(gè)base_time的，base_time是隨機(jī)，比如視頻第一幀，應(yīng)用層是0.04秒，換算成90khz的時(shí)基，則為3600+base_time(起點(diǎn)時(shí)間) base_time是隨機(jī)生成的 既然接收端，不能直接用收到的rtp的timestamp做音視頻同步，那應(yīng)該怎么辦？ 接收端需要發(fā)送端把NTP時(shí)間發(fā)送過(guò)來(lái) rtcp發(fā)送間隔的問(wèn)題 在發(fā)送第一個(gè)rtp包前要先發(fā)一個(gè)rtcp包（推流SR） rtcp包占用rtp包的 %0.5的字節(jié)比例，rtcp_bytes>=28字節(jié) 上次發(fā)送rtcp包和目前時(shí)間間隔超過(guò)5秒 能否不發(fā)rtcp也能做音視頻同步 每一路rtp通道的ts的起點(diǎn)時(shí)間不能隨機(jī)進(jìn)行初始化，每個(gè)通道base_timestamp進(jìn)行換算成秒單位值要一致。
2. RTCP報(bào)?格式-- RR報(bào)?格式
RTCP通過(guò)RR可以很好地保證傳輸質(zhì)量，每個(gè)接收數(shù)據(jù)的參與者都要發(fā)出RR。
其中PT定義為201。接收者報(bào)告包含發(fā)送者的SSRC，跟隨在由RC指定的（0個(gè)或多個(gè)）報(bào)告塊之后。
其中域及其意義如下：
域名?度（bit）含義 Reportee SSRC（接收者同步源） 32 占?32 bites，表示這個(gè)報(bào)告反饋給誰(shuí)，也就是誰(shuí)適合接收這個(gè)報(bào)告。 Loss fraction（丟包率） 8 占?8 bites，定義為這個(gè)報(bào)告周期丟失的分組除以期待的分組數(shù)量。 Cumulative number of packets lost（丟包數(shù)量） 24 24 bites帶符號(hào)整形，累計(jì)丟失的包的個(gè)數(shù)。計(jì)算?法是：期待接收的分組數(shù)?-實(shí)際接收的分組數(shù)?。所謂期待的分組數(shù)?是這樣定義的：最后?個(gè)分組的序列號(hào)－初始化分組序列號(hào)。 Extended highest sequencenumber（擴(kuò)展?位序列號(hào)） 32 占?32 bites，低16 bites取值為當(dāng)前收到的RTP報(bào)?的序列號(hào)，?16 bites是擴(kuò)展位，?于標(biāo)識(shí)序列號(hào)周期的計(jì)數(shù)。 Interarrival jitter（抖動(dòng)評(píng)估） 32 占?32 bites，數(shù)據(jù)分組傳輸?shù)慕y(tǒng)計(jì)評(píng)估值，?于評(píng)估?絡(luò)的抖動(dòng)情況。表示?式和時(shí)間戳相同 Last sender report (LSR) 32 占?32 bites，等于從reportee最近接收到SR分組的64 bits NTP 格式時(shí)間戳的中間32 bites，如果沒(méi)有接收到SR分組，那么LSR置0。 Delay since last sender report (DLSR) 32 表示接收到最近的SR到發(fā)出這個(gè)報(bào)告的時(shí)延，單位是1/65,536秒。如果沒(méi)有接收到SR，DLSR置0。
typedef
struct _rtcp_rr_t
{ uint32_t ssrc
;
} rtcp_rr_t
;
typedef
struct _rtcp_rb_t
{ uint32_t ssrc
; uint32_t fraction
: 8 ; uint32_t cumulative
: 24 ; uint32_t exthsn
; uint32_t jitter
; uint32_t lsr
; uint32_t dlsr
;
} rtcp_rb_t
;
丟包率計(jì)算：表示?式：分?固定為256，分?是loss fraction表示的整數(shù)。所以如果想要表示1/4的報(bào)?丟失，那么loss fraction＝64。 丟包數(shù)量計(jì)算：cumulative number of packets lost不是以每個(gè)周期為計(jì)算范圍，?是以整個(gè)會(huì)話為計(jì)算范圍。所以0x7fffff是cumulative number of packets lost的最?值，因?yàn)樗菐Х?hào)整數(shù)。 擴(kuò)展?位序列號(hào)：隨著會(huì)話時(shí)間增?，16?特?度的序列號(hào)可能會(huì)不夠?，當(dāng)序列號(hào)?回到初始化序列號(hào)時(shí)，為了表示這個(gè)環(huán)繞，在?16?特記錄環(huán)繞的次數(shù)，也就是把序列號(hào)擴(kuò)展了。
–
3. RTSP play同步
RTP 包中的時(shí)間戳字段是說(shuō)明數(shù)據(jù)包時(shí)間的同步信息，是數(shù)據(jù)能以正確的時(shí)間順序恢復(fù)的關(guān)鍵。時(shí)間戳的值給出了分組中數(shù)據(jù)的第?個(gè)字節(jié)的采樣時(shí)間。為了計(jì)算各個(gè)數(shù)據(jù)流的播放時(shí)間以及同步處理，僅有 RTP包中的時(shí)間戳信息是不夠的。 在整個(gè)播放過(guò)程中，包括這樣?種時(shí)間: RTP 包中的 rtptime PLAY 請(qǐng)求的 Response 中的 rtp time 和 npt
1. 時(shí)間戳映射關(guān)系
?先介紹 PLAY 請(qǐng)求的 Response ?的兩個(gè)域：
1. npt
npt 顧名思義 Normal PLay Time ，正常播放時(shí)間，指出了流相對(duì)與播放開(kāi)始時(shí)的絕對(duì)位置。播放開(kāi)始時(shí)的之間定義為 0.0s 。這個(gè)特殊的常量 now 被定義為現(xiàn)場(chǎng)事件的當(dāng)前時(shí)刻。 " now "常數(shù)允許客戶端請(qǐng)求接收實(shí)時(shí)反饋?不是存儲(chǔ)或者延時(shí)的版本。因?yàn)閷?duì)于這種情況??,既沒(méi)有絕對(duì)時(shí)間,也沒(méi)有 0 時(shí)間,所以需要該參數(shù)。
2. rtptime
rtptime 是發(fā)送 PLAY 請(qǐng)求后將收到的第?個(gè) RTP 包的時(shí)間戳值。 npt 和 rtptime 的區(qū)別在于 npt 是影?開(kāi)始的相對(duì)時(shí)間，? rtptime 是會(huì)話開(kāi)始的相對(duì)時(shí)間。因此在client 端，需要對(duì)這兩者進(jìn)? map 處理。 在 client 端計(jì)算播放時(shí)間戳的公式如下： nptUs = (current_rtpTime - start_rtptime) / scale + srart_npt 其中： start_rtptime 與 start_npt 分別是 PLAY 請(qǐng)求的 Response 中的 rtptime 和 npt 。 current_rtpTime 是當(dāng)前收到的 RTP 包頭中的 rtptime 。 scale 為 PLAY 請(qǐng)求的 Response 中的 scale 值。在正常播放的情況下為 1 ，快速播放時(shí)?于 1 ，當(dāng)處于反向掃描模式時(shí)?于 -1
2. 媒體間同步?法（不同設(shè)備的同步）
上?的處理僅僅實(shí)現(xiàn)了媒體內(nèi)的同步，在實(shí)現(xiàn)媒體間同步時(shí)，還需要進(jìn)?其他的處理?作。這就需要?到RTCP 的 SR ( Sender Report )。在 SR 中包含?個(gè)< rtp ， ntp >時(shí)間戳對(duì)，通過(guò)這個(gè)時(shí)間戳對(duì)可以將?頻和視頻準(zhǔn)確的定位到?個(gè)絕對(duì)時(shí)間軸上。 < rtp ， ntp >時(shí)間戳對(duì)的必要性在于不同流的 RTP 時(shí)間戳有不同的隨機(jī)偏移量，因此?法直接進(jìn)?同步。 < rtp ， ntp >中的 ntp 是?絡(luò)時(shí)間協(xié)議格式表示的絕對(duì)時(shí)間值。 < rtp ， ntp >中的 RTP 與數(shù)據(jù)包中的 RTP 時(shí)間戳具有相同的單位和偏移量，但在?多數(shù)情況下此時(shí)間戳不等于任何臨近的 RTP 包中的時(shí)間戳。 根據(jù)不同 stream 中的< rtp ， ntp >時(shí)間戳對(duì)，可以將?個(gè) stream 中的時(shí)間戳值映射為另?個(gè)stream 的時(shí)間戳值，從?實(shí)現(xiàn)媒體間的同步。
4. RTCP同步
RTP?持傳送不同codec的steaming，不同codec的clock rate的也不?樣，不同的media之間需要依靠RTCP進(jìn)?同步。這?簡(jiǎn)單介紹?下他們的機(jī)制。
在每個(gè)RTCP SR包中對(duì)應(yīng)有?個(gè)RTP時(shí)間和?個(gè)NTP時(shí)間，它表達(dá)的意思很明確，那就是這個(gè)RTP時(shí)間對(duì)應(yīng)的絕對(duì)時(shí)間， 不同media的RTP時(shí)間盡管不同，但可以通過(guò)NTP時(shí)間映射到同?個(gè)時(shí)間軸上，從?實(shí)現(xiàn)同步。
如下圖所示，RTP session 1 send H264 使?90,000HZ，?RTP session 2 send G.711 使?8,000HZ
也就是是說(shuō)有3個(gè)時(shí)間軸，?頻時(shí)間軸，視頻時(shí)間軸，ntp時(shí)間軸。
?視頻的時(shí)間軸的單位都是各?的采樣率，需要除以采樣率才能取得單位為秒的時(shí)間單位。
有兩個(gè)rtcp流，分別為?/視頻的，其中有?個(gè)當(dāng)前的?頻的timestamp和?個(gè)ntp的timestamp。
這兩個(gè)值是在不同軸上的相同時(shí)間點(diǎn)，即?/視頻軸和ntp軸的重合點(diǎn)。使?這個(gè)值可以使?視頻軸同步。當(dāng)拿到?頻NTP時(shí)間 （Tan），?頻RTP時(shí)間（Tar），視頻NTP時(shí)間（Tvn），視頻RTP時(shí)間（Tvr），就可以計(jì)算?視頻時(shí)間軸的差距D:
假設(shè)使??頻為主軸，視頻向?頻對(duì)?。D = (Tar-Tvr) - (Tan - Tvn);新的視頻時(shí)間戳為Tar = Tar + D;
在rtcp的sr單元中有32位的MSW和32位的LSW。MSW的單位為秒，?LSW的單位為232picoseconds。1?秒為1/10^12秒。LSW轉(zhuǎn)為us的公式為(LSW*10^12/2^32)/1000000;
總結(jié)
以上是生活随笔 為你收集整理的RTCP协议分析 的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問(wèn)題。
如果覺(jué)得生活随笔 網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔 推薦給好友。
