音視頻流媒體開發(fā)-目錄
iOS知識點-目錄
Android-目錄
Flutter-目錄
數(shù)據(jù)結(jié)構(gòu)與算法-目錄
uni-pp-目錄
RTCP功能
Real-time Transport Control Protocol或RTP Control Protocol或簡寫RTCP）是實時傳輸協(xié)議（RTP）的?個姐妹協(xié)議蚁滋。RTCP由RFC 3550定義（取代作廢的RFC 1889）蜡娶。RTP 使??個 偶數(shù) UDPport 坡疼；?RTCP 則使? RTP 的下?個 port羡藐，也就是?個奇數(shù) port果复。RTCP與RTP聯(lián)合?作憾朴，RTP實施實際數(shù)據(jù)的傳輸倒槐，RTCP則負責(zé)將控制包送?電話中的每個?惕艳。其主要功能是就RTP正在提供的服務(wù)質(zhì)量做出反饋。
RTCP報?封裝在UDP中進?傳輸晨缴，作?如下:
- 質(zhì)量反饋
- 傳輸層標識（CNAME）
- 給參與者發(fā)送RTCP控制報?
- 最?會話控制消息（可選）
RTCP端?號 = RTP端?號 + 1
RTCP報?格式--報?類型
在RTP的規(guī)范（RFC 3550）中译秦，?共定義了5種RTCP報告?來報告當(dāng)前控制信息：
RTCP的5種報告：RR，SR击碗，SDES筑悴，BYE和APP。他們使?共同的結(jié)構(gòu)稍途，但是在某些具體的地?有?些不同阁吝。
以下是RTCP報?基本結(jié)構(gòu)：
其中?較重要的?個域及其意義如下：
header size = 2 + 1 + 5 +8 + 16 = 4個字節(jié)
SR 包，總共28字節(jié) = header 4字節(jié) + 4字節(jié)*6
typedef struct _rtcp_header_t{
uint32_t v:2; // version
uint32_t p:1; // padding
uint32_t rc:5; // reception report count
uint32_t pt:8; // packet type
uint32_t length:16; /* pkt len in words, w/o this word */
} rtcp_header_t;
RTCP報?格式-- SR報?格式
為了補充接收者報告晰房，RTP協(xié)議還規(guī)定了最近發(fā)送數(shù)據(jù)的參與者發(fā)送SR求摇，該報告提供了發(fā)送的媒體的?些信息。主要?于接收端同步多媒體流殊者，如語?和視頻流与境。
其中域及其意義如下：
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 timestamp
uint32_t spc; // sender packet count
uint32_t soc; // sender octet count
} rtcp_sr_t;
以下是SR報?的實例:
RTCP報?格式-- RR報?格式
RTCP通過RR可以很好地保證傳輸質(zhì)量，每個接收數(shù)據(jù)的參與者都要發(fā)出RR猖吴。
其中PT定義為201摔刁。接收者報告包含發(fā)送者的SSRC，跟隨在由RC指定的（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 lost
uint32_t cumulative:24; // cumulative number of packets lost
uint32_t exthsn; // extended highest sequence number received
uint32_t jitter; // interarrival jitter
uint32_t lsr; // last SR
uint32_t dlsr; // delay since last SR
} rtcp_rb_t;
- 丟包率計算：表示?式：分?固定為256共屈，分?是loss fraction表示的整數(shù)。所以如果想要表示1/4的報?丟失党窜，那么loss fraction＝64拗引。
- 丟包數(shù)量計算：cumulative number of packets lost不是以每個周期為計算范圍，?是以整個會話為計算范圍幌衣。所以0x7fffff是cumulative number of packets lost的最?值矾削，因為它是帶符號整數(shù)。
- 擴展?位序列號：隨著會話時間增?豁护，16?特?度的序列號可能會不夠?哼凯，當(dāng)序列號?回到初始化序列號時，為了表示這個環(huán)繞楚里，在?16?特記錄環(huán)繞的次數(shù)断部，也就是把序列號擴展了。
RTCP報?格式-- RR報?實例
RTCP報?格式-- SDES報?格式
lRTCP還可以通過傳輸SDES來詳細描述源班缎，如標識和?些輔助信息（地理位置蝴光，電話號碼以及Email地址等信息）她渴。?般來說SDES數(shù)據(jù)由?戶輸?，顯示在應(yīng)?的圖形界?上虱疏。
-
?般來說SDES列表（list of SDES items）以被描述的源的SSRC開始惹骂。跟隨?個或者多個描述項苏携，描述項格式如下圖：
- 如果描述項的type＝1做瞪，那么該描述稱為CNAME item，為每個參與者提供了規(guī)范名（canonical name）右冻。
- 這個規(guī)范名是穩(wěn)固的永久的標識装蓬，獨?于同步源標識。CNAME能同時?于?個參與者的多個會話纱扭。
- CNAME是唯??個強制實現(xiàn)的SDES item牍帚，所有實現(xiàn)必須實現(xiàn)該描述。
RTCP報?格式-- SDES報?實例
SR的SDES報?案例
RR的SDES報?案例
RTCP報?格式-- BYE報?格式
RTCP協(xié)議可以通過BYE分組進??由的成員控制乳蛾，RTCP BYE標識離開會話的成員暗赶，或者成員改變SSRC。BYE分組可能在傳輸中丟失肃叶，?且應(yīng)?實現(xiàn)不會再次產(chǎn)?BYE分組蹂随。所以接收者應(yīng)該準備好對某些?戶超時，?且沒有接收到BYE分組因惭。
以下是BYE的報?實例
RTCP報?格式-- APP報?格式
APP數(shù)據(jù)報?允許應(yīng)?定義擴展岳锁。APP分組?來進??些?標準RTCP擴展，或者進??些新特性的試驗蹦魔，等到試驗成熟激率，就可以注冊成?種新的類型。應(yīng)?實現(xiàn)對不認識的APP應(yīng)該予以忽略勿决。
RTCP報?格式-- APP報告實例
Application-defined packet name使?4個字符的標識符乒躺，唯?標識這個擴展。每個字符使?ASCII編碼格式低缩，區(qū)分??寫嘉冒。
RTSP play同步
RTP 包中的時間戳字段是說明數(shù)據(jù)包時間的同步信息，是數(shù)據(jù)能以正確的時間順序恢復(fù)的關(guān)鍵表制。時間戳的值給出了分組中數(shù)據(jù)的第?個字節(jié)的采樣時間健爬。為了計算各個數(shù)據(jù)流的播放時間以及同步處理，僅有 RTP包中的時間戳信息是不夠的么介。
在整個播放過程中娜遵，包括這樣?種時間:
- RTP 包中的 rtptime
- PLAY 請求的 Response 中的 rtp time 和 npt
- RTCP 的 SR ( Sender Report )中的 rtp 和 ntp 時間戳對
?、時間戳映射關(guān)系
?先介紹 PLAY 請求的 Response ?的兩個域：
（1） npt
npt 顧名思義 Normal PLay Time 壤短，正常播放時間设拟，指出了流相對與播放開始時的絕對位置慨仿。播放開始時的之間定義為 0.0s 。這個特殊的常量 now 被定義為現(xiàn)場事件的當(dāng)前時刻纳胧。" now "常數(shù)允許客戶端請求接收實時反饋?不是存儲或者延時的版本镰吆。因為對于這種情況??,既沒有絕對時間,也沒有 0 時間,所以需要該參數(shù)。
（2） rtptime
rtptime 是發(fā)送 PLAY 請求后將收到的第?個 RTP 包的時間戳值跑慕。
npt 和 rtptime 的區(qū)別在于 npt 是影?開始的相對時間万皿，? rtptime 是會話開始的相對時間。因此在client 端核行，需要對這兩者進? map 處理牢硅。
在 client 端計算播放時間戳的公式如下：
nptUs = (current_rtpTime - start_rtptime) / scale + srart_npt
其中：
start_rtptime 與 start_npt 分別是 PLAY 請求的 Response 中的 rtptime 和 npt 。current_rtpTime 是當(dāng)前收到的 RTP 包頭中的 rtptime 芝雪。
scale 為 PLAY 請求的 Response 中的 scale 值减余。在正常播放的情況下為 1 ，快速播放時?于 1 惩系，當(dāng)處于反向掃描模式時?于 -1 .
?位岔、媒體間同步?法（不同設(shè)備的同步）
上?的處理僅僅實現(xiàn)了媒體內(nèi)的同步，在實現(xiàn)媒體間同步時堡牡，還需要進?其他的處理?作抒抬。這就需要?到RTCP 的 SR ( Sender Report )。在 SR 中包含?個< rtp 悴侵， ntp >時間戳對瞧剖，通過這個時間戳對可以將?頻和視頻準確的定位到?個絕對時間軸上。
< rtp 可免， ntp >時間戳對的必要性在于不同流的 RTP 時間戳有不同的隨機偏移量抓于，因此?法直接進?同步。
< rtp 浇借， ntp >中的 ntp 是?絡(luò)時間協(xié)議格式表示的絕對時間值捉撮。
< rtp ， ntp >中的 RTP 與數(shù)據(jù)包中的 RTP 時間戳具有相同的單位和偏移量妇垢，但在?多數(shù)情況下此時間戳不等于任何臨近的 RTP 包中的時間戳巾遭。
根據(jù)不同 stream 中的< rtp ， ntp >時間戳對闯估，可以將?個 stream 中的時間戳值映射為另?個stream 的時間戳值灼舍，從?實現(xiàn)媒體間的同步。
RTCP同步
RTP?持傳送不同codec的steaming涨薪，不同codec的clock rate的也不?樣骑素，不同的media之間需要依靠RTCP進?同步。這?簡單介紹?下他們的機制刚夺。
在每個RTCP SR包中對應(yīng)有?個RTP時間和?個NTP時間献丑，它表達的意思很明確末捣，那就是這個RTP時間對應(yīng)的絕對時間， 不同media的RTP時間盡管不同创橄，但可以通過NTP時間映射到同?個時間軸上箩做，從?實現(xiàn)同步。
如下圖所示妥畏，RTP session 1 send H264 使?90,000HZ邦邦，?RTP session 2 send G.711 使?8,000HZ:
也就是是說有3個時間軸，?頻時間軸咖熟，視頻時間軸圃酵，ntp時間軸柳畔。
?視頻的時間軸的單位都是各?的采樣率馍管，需要除以采樣率才能取得單位為秒的時間單位。
有兩個rtcp流薪韩，分別為?/視頻的确沸，其中有?個當(dāng)前的?頻的timestamp和?個ntp的timestamp。這兩個值是在不同軸上的相同時間點俘陷，即?/視頻軸和ntp軸的重合點罗捎。使?這個值可以使?視頻軸同步。
當(dāng)拿到?頻NTP時間 （Tan）拉盾，?頻RTP時間（Tar）桨菜，視頻NTP時間（Tvn），視頻RTP時間（Tvr）捉偏，就可以計算?視頻時間軸的差距D:
假設(shè)使??頻為主軸倒得，視頻向?頻對?。D = (Tar-Tvr) - (Tan - Tvn);
新的視頻時間戳為Tar = Tar + D;
在rtcp的sr單元中有32位的MSW和32位的LSW夭禽。MSW的單位為秒霞掺，?LSW的單位為232
picoseconds。1?秒為1/1012秒讹躯。LSW轉(zhuǎn)為us的公式為(LSW*1012/2^32)/1000000;
