當前位置：首頁 > 编程资源 > 编程问答 >内容正文

编程问答

RTCP协议分析

發布時間：2024/4/11 编程问答 42 豆豆

生活随笔收集整理的這篇文章主要介紹了 RTCP协议分析小編覺得挺不錯的,現在分享給大家,幫大家做個參考.

RTCP協議分析

Version（V）	2	定義了RTP的版本，此協議定義的版本是2。
Padding（P）	1	如果填充位被設置為1，則?個或多個附加的字節會加在包頭的最后，附加的最后?個字節放置附加的字節數。填充可能?于某些具有固定?度的加密算法，或者在底層數據單元中傳輸多個RTP包。
Item count（IC）	5	有些RTCP分組類型包含多個條?（item），IC?來計算有多少個條?。因為IC只有5個?特，所以最多31個item。如果需要的item超過31個，那么應?實現必須包含多個RTCP分組。如果IC為0表示空的item列表。分組如果不需要item列表，那么可以把IC字段?于其他?的。
Packettype（PT）	8	PT標識了分組中攜帶消息的類型。在RTP標準中定義了5種類型：RR，SR，SDES，BYE和APP
Length（M）	16	分組?度，以4 bytes為單位，所以意味著RTCP分組必須是4字節對?。該?度不包含32 bites固定頭，也就是說length為0也是合理的，說明只有4字節的頭部（這種情況IC也是0）。

header size = 2 + 1 + 5 +8 + 16 = 4個字節

SR 包，總共28字節 = header 4字節 + 4字節*6

typedef struct _rtcp_header_t {uint32_t v:2; // versionuint32_t p:1; // paddinguint32_t rc:5; // reception report countuint32_t pt:8; // packet typeuint32_t length:16; /* pkt len in words, w/o this word */ } rtcp_header_t;

1. RTCP報?格式-- SR報?格式

為了補充接收者報告，RTP協議還規定了最近發送數據的參與者發送SR，該報告提供了發送的媒體的?些信息。主要?于接收端同步多媒體流，如語?和視頻流

其中域及其意義如下：

域名?度（bit）含義

NTP timestamp	64	64 bites，?符號整數。指出了該報告發出時的時間。該時間戳的?32 bites以NTP格式表示，從1900年1?1?開始計數，以秒為單位。低32 bites表示秒后?的?數。如果需要轉化Unix時間到NTP時間，在Unix時間加上2,208,988,800即可。
RTP timestamp	/	RTP時間戳以RTP媒體流的時鐘為單位，這個值通常不等于前?分組數據的RTP時間戳，因為時間會流逝。
Sender’s packet count	/	表示這個同步源從這個會話開始到現在（發出RTCP報?時）發出的數據分組的個數。
Sender’s octet count	/	表示同步源從這個會話開始到現在（發出RTCP報?時）發出的所有數據分組的字節數。如果發送者改變了SSRC，那么sender’s packet count和sender’s octet count被會被重置。

typedef struct _rtcp_sr_t // sender report {uint32_t ssrc;uint32_t ntpmsw; // ntp timestamp MSW(in second)uint32_t ntplsw; // ntp timestamp LSW(in picosecond)uint32_t rtpts; // rtp timestampuint32_t spc; // sender packet countuint32_t soc; // sender octet count } rtcp_sr_t;

如下圖我們可知：

video時間戳是 2794373590，采樣率是90000，相除得到具體時間：31048.595秒

audio時間戳是 4216229973，采樣率是48000，相除得到具體時間：87838.124秒

我們發現，相隔0.1毫秒（29.790-29.789）發送出去的視頻、音頻包時間戳的差值特別大

rtp包打時間戳時，是有一個base_time的，base_time是隨機，比如視頻第一幀，應用層是0.04秒，換算成90khz的時基，則為3600+base_time(起點時間)

base_time是隨機生成的

既然接收端，不能直接用收到的rtp的timestamp做音視頻同步，那應該怎么辦？

接收端需要發送端把NTP時間發送過來

rtcp發送間隔的問題

在發送第一個rtp包前要先發一個rtcp包（推流SR）

rtcp包占用rtp包的 %0.5的字節比例，rtcp_bytes>=28字節

上次發送rtcp包和目前時間間隔超過5秒

能否不發rtcp也能做音視頻同步

每一路rtp通道的ts的起點時間不能隨機進行初始化，每個通道base_timestamp進行換算成秒單位值要一致。

2. RTCP報?格式-- RR報?格式

RTCP通過RR可以很好地保證傳輸質量，每個接收數據的參與者都要發出RR。

其中PT定義為201。接收者報告包含發送者的SSRC，跟隨在由RC指定的（0個或多個）報告塊之后。

其中域及其意義如下：

域名?度（bit）含義

Reportee SSRC（接收者同步源）	32	占?32 bites，表示這個報告反饋給誰，也就是誰適合接收這個報告。
Loss fraction（丟包率）	8	占?8 bites，定義為這個報告周期丟失的分組除以期待的分組數量。
Cumulative number of packets lost（丟包數量）	24	24 bites帶符號整形，累計丟失的包的個數。計算?法是：期待接收的分組數?-實際接收的分組數?。所謂期待的分組數?是這樣定義的：最后?個分組的序列號－初始化分組序列號。
Extended highest sequencenumber（擴展?位序列號）	32	占?32 bites，低16 bites取值為當前收到的RTP報?的序列號，?16 bites是擴展位，?于標識序列號周期的計數。
Interarrival jitter（抖動評估）	32	占?32 bites，數據分組傳輸的統計評估值，?于評估?絡的抖動情況。表示?式和時間戳相同
Last sender report (LSR)	32	占?32 bites，等于從reportee最近接收到SR分組的64 bits NTP 格式時間戳的中間32 bites，如果沒有接收到SR分組，那么LSR置0。
Delay since last sender report (DLSR)	32	表示接收到最近的SR到發出這個報告的時延，單位是1/65,536秒。如果沒有接收到SR，DLSR置0。

typedef struct _rtcp_rr_t // receiver report {uint32_t ssrc; } rtcp_rr_t; typedef struct _rtcp_rb_t // report block {uint32_t ssrc;uint32_t fraction:8; // fraction lostuint32_t cumulative:24; // cumulative number of packets lostuint32_t exthsn; // extended highest sequence number receiveduint32_t jitter; // interarrival jitteruint32_t lsr; // last SRuint32_t dlsr; // delay since last SR } rtcp_rb_t;

丟包率計算：表示?式：分?固定為256，分?是loss fraction表示的整數。所以如果想要表示1/4的報?丟失，那么loss fraction＝64。

丟包數量計算：cumulative number of packets lost不是以每個周期為計算范圍，?是以整個會話為計算范圍。所以0x7fffff是cumulative number of packets lost的最?值，因為它是帶符號整數。

擴展?位序列號：隨著會話時間增?，16?特?度的序列號可能會不夠?，當序列號?回到初始化序列號時，為了表示這個環繞，在?16?特記錄環繞的次數，也就是把序列號擴展了。

–

3. RTSP play同步

RTP 包中的時間戳字段是說明數據包時間的同步信息，是數據能以正確的時間順序恢復的關鍵。時間戳的值給出了分組中數據的第?個字節的采樣時間。為了計算各個數據流的播放時間以及同步處理，僅有 RTP包中的時間戳信息是不夠的。

在整個播放過程中，包括這樣?種時間:

RTP 包中的 rtptime

PLAY 請求的 Response 中的 rtp time 和 npt

1. 時間戳映射關系

?先介紹 PLAY 請求的 Response ?的兩個域：

1. npt

npt 顧名思義 Normal PLay Time ，正常播放時間，指出了流相對與播放開始時的絕對位置。播放開始時的之間定義為 0.0s 。這個特殊的常量 now 被定義為現場事件的當前時刻。

" now "常數允許客戶端請求接收實時反饋?不是存儲或者延時的版本。因為對于這種情況??,既沒有絕對時間,也沒有 0 時間,所以需要該參數。

2. rtptime

rtptime 是發送 PLAY 請求后將收到的第?個 RTP 包的時間戳值。

npt 和 rtptime 的區別在于 npt 是影?開始的相對時間，? rtptime 是會話開始的相對時間。因此在client 端，需要對這兩者進? map 處理。

在 client 端計算播放時間戳的公式如下：

nptUs = (current_rtpTime - start_rtptime) / scale + srart_npt

其中：

start_rtptime 與 start_npt 分別是 PLAY 請求的 Response 中的 rtptime 和 npt 。

current_rtpTime 是當前收到的 RTP 包頭中的 rtptime 。

scale 為 PLAY 請求的 Response 中的 scale 值。在正常播放的情況下為 1 ，快速播放時?于 1 ，當處于反向掃描模式時?于 -1

2. 媒體間同步?法（不同設備的同步）

上?的處理僅僅實現了媒體內的同步，在實現媒體間同步時，還需要進?其他的處理?作。這就需要?到RTCP 的 SR ( Sender Report )。在 SR 中包含?個< rtp ， ntp >時間戳對，通過這個時間戳對可以將?頻和視頻準確的定位到?個絕對時間軸上。

< rtp ， ntp >時間戳對的必要性在于不同流的 RTP 時間戳有不同的隨機偏移量，因此?法直接進?同步。

< rtp ， ntp >中的 ntp 是?絡時間協議格式表示的絕對時間值。

< rtp ， ntp >中的 RTP 與數據包中的 RTP 時間戳具有相同的單位和偏移量，但在?多數情況下此時間戳不等于任何臨近的 RTP 包中的時間戳。

根據不同 stream 中的< rtp ， ntp >時間戳對，可以將?個 stream 中的時間戳值映射為另?個stream 的時間戳值，從?實現媒體間的同步。

4. RTCP同步

RTP?持傳送不同codec的steaming，不同codec的clock rate的也不?樣，不同的media之間需要依靠RTCP進?同步。這?簡單介紹?下他們的機制。

在每個RTCP SR包中對應有?個RTP時間和?個NTP時間，它表達的意思很明確，那就是這個RTP時間對應的絕對時間，不同media的RTP時間盡管不同，但可以通過NTP時間映射到同?個時間軸上，從?實現同步。

如下圖所示，RTP session 1 send H264 使?90,000HZ，?RTP session 2 send G.711 使?8,000HZ

也就是是說有3個時間軸，?頻時間軸，視頻時間軸，ntp時間軸。

?視頻的時間軸的單位都是各?的采樣率，需要除以采樣率才能取得單位為秒的時間單位。

有兩個rtcp流，分別為?/視頻的，其中有?個當前的?頻的timestamp和?個ntp的timestamp。

這兩個值是在不同軸上的相同時間點，即?/視頻軸和ntp軸的重合點。使?這個值可以使?視頻軸同步。當拿到?頻NTP時間（Tan），?頻RTP時間（Tar），視頻NTP時間（Tvn），視頻RTP時間（Tvr），就可以計算?視頻時間軸的差距D:

假設使??頻為主軸，視頻向?頻對?。D = (Tar-Tvr) - (Tan - Tvn);新的視頻時間戳為Tar = Tar + D;

在rtcp的sr單元中有32位的MSW和32位的LSW。MSW的單位為秒，?LSW的單位為232picoseconds。1?秒為1/10^12秒。LSW轉為us的公式為(LSW*10^12/2^32)/1000000;

總結

以上是生活随笔為你收集整理的RTCP协议分析的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。

协议
RTCP

200	SR（Sender report）	發送?報告
201	RR（Receiver report）	接收?報告
202	SDES（Source description）	源描述報告
203	BYE（Goodbye）	離開會話
204	APP（Application-defined）	應?定義
206	REMB（Receiver Estimated Maximum Bitrate）	接收方估計的最大比特率

生活随笔