在上一期《超能課堂(287)：消失的第三方之圖形顯示芯片篇》里，回顧了圖形顯示芯片的“戰(zhàn)國(guó)時(shí)代”，那些現(xiàn)在已經(jīng)消失的圖形顯示芯片設(shè)計(jì)廠商。當(dāng)時(shí)在主板的芯片組（Chipset）領(lǐng)域也有類(lèi)似的情況，除了英特爾和AMD各自推出自己平臺(tái)的芯片組外，還有多個(gè)第三方廠商。特別是AMD，很長(zhǎng)時(shí)間里都是依賴(lài)于第三方芯片組設(shè)計(jì)公司。事實(shí)上，這些第三方芯片組設(shè)計(jì)公司的產(chǎn)品在技術(shù)規(guī)格上并不弱，甚至?xí)谐接⑻貭栆I(lǐng)發(fā)展潮流的情況。
隨著英特爾和AMD在CPU設(shè)計(jì)上進(jìn)一步提高集成度，將原本主板芯片組里“北橋”的功能集成到CPU上，現(xiàn)在的主板芯片組已與傳統(tǒng)意義上的芯片組不一樣，更多地只是原本“南橋”的功能，作用明顯弱化了。當(dāng)然，這些第三方芯片組設(shè)計(jì)公司的消失除了技術(shù)的發(fā)展，還有市場(chǎng)因素，以及英特爾和AMD都將自己的平臺(tái)控制權(quán)牢牢把控。現(xiàn)今主板的功能和可玩性也遠(yuǎn)不如從前，不同型號(hào)的定位劃分非常明確，每次更新?lián)Q代里，主板芯片組也只是小配角，很少玩家會(huì)對(duì)其產(chǎn)生興趣。
在過(guò)去《超能課堂(191)：AMD/ATI芯片組變遷史》里，已經(jīng)陳述了相當(dāng)一部分內(nèi)容。在AMD收購(gòu)ATI之前，ATI的芯片組業(yè)務(wù)方面也就開(kāi)展了幾年的時(shí)間，剛剛走上正軌，產(chǎn)品并不多，影響力也有限。
ATI最早是在2002年推出了首款芯片組，面向AMD平臺(tái)的IGP 320，以及面向英特爾平臺(tái)的IGP 330。一開(kāi)始僅提供了北橋芯片，南橋還要依賴(lài)ALi/ULi或威盛的產(chǎn)品，即便后來(lái)的幾款芯片組，采用ALi/ULi南橋的情況也不少。直到2004年至2005年間，RS/RD 400系列（CrossFire Xpress 1000系列）的推出，才讓ATI站穩(wěn)腳跟。
隨著2006年的7月24日，AMD正式宣布以54億美元收購(gòu)ATI，其芯片組進(jìn)入了另一個(gè)階段。被AMD收購(gòu)后，ATI原有的芯片組業(yè)務(wù)曾經(jīng)一度達(dá)到頂峰，不過(guò)現(xiàn)在已變得比較平庸，有點(diǎn)被浪費(fèi)了。
揚(yáng)智電子科技最早于1987年，由Acer董事長(zhǎng)施振榮延攬三位旅美博士莊人川、吳欽智和李曉均共同創(chuàng)設(shè)，主要為Acer集團(tuán)從事IC設(shè)計(jì)等工作，所以英文全名為“Acer Laboratory Inc.”，簡(jiǎn)稱(chēng)“ALi”，并于1993年正式成立。在2002年英文名改為“ALi Corporation”，并更改了企業(yè)識(shí)別標(biāo)志。同年，芯片組設(shè)計(jì)部分從ALi分立，成立宇力電子，英文名“ULi Electronics Inc.”。在2005年12月14日，英偉達(dá)收購(gòu)了宇力電子。
ALi早在1991年就推出了適用于386處理器的芯片組，在1995年左右，將其芯片組命名為“ALADDiN”，也就是阿拉丁。由于背靠Acer，隨著母公司的發(fā)展壯大，ALi的芯片組用在了許多OEM產(chǎn)品上，Socket 7插座時(shí)期已并不少見(jiàn)，不過(guò)定位相對(duì)低端。當(dāng)時(shí)芯片組仍劃分為南北橋，ALi的芯片組命名也比較復(fù)雜，相比其他芯片組廠商，ALi的產(chǎn)品讓人很難記得住。比如Socket 7插座的ALADDiN V芯片組，北橋?yàn)镸1541/M1542，南橋?yàn)镸1543/M1543C，就是里面其中一款北橋搭配其中一款南橋，不同的搭配可能在個(gè)別功能上有差異，類(lèi)似的情況很多。
到了Pentium II和Pentium III時(shí)期，ALi開(kāi)始嘗試在芯片組上加入圖形單元。由于Ali并沒(méi)有高性能的圖形技術(shù)（以前曾有簡(jiǎn)單的圖形處理芯片），所以選擇了與其他廠商展開(kāi)合作，而且不止一間。ALi曾與英偉達(dá)合作推出了名為ALADDiN TNT的芯片組，加入了TNT2 M64圖形單元，這也是英偉達(dá)第一次涉足主板芯片組領(lǐng)域。ALi還與Trident合作，加入了Trident CyberBlade 3D/CyberBlade XP圖形單元，這系列支持英特爾平臺(tái)的芯片組為CyberALADDiN系列。除了英特爾和AMD，ALi還推出了支持全美達(dá)（Transmeta）處理器的芯片組。
2000年7月，ALi率先推出支持DDR內(nèi)存的芯片組，英特爾平臺(tái)的Aladdin Pro 5，AMD桌面平臺(tái)的MAGiK 1以及移動(dòng)平臺(tái)的MobileMAGiK 1，以及搭載Trident圖形單元的CyberMAGiK 1。MAGiK也是ALi為AMD平臺(tái)芯片組取的新名字。顯然ALi的命名體系太復(fù)雜，一般消費(fèi)者很難搞清楚。在后來(lái)的產(chǎn)品上，ALi開(kāi)始仿效英特爾，主要以北橋稱(chēng)呼其芯片組。經(jīng)過(guò)了重整，以及ULi的分立，其產(chǎn)品一度在市場(chǎng)上有非常驚艷的表現(xiàn)。
當(dāng)年華擎發(fā)布了許多讓人津津樂(lè)道的“妖板”，其中采用ULi芯片組的也有不少。比如主板上同時(shí)有754和939兩種插座的K8 Combo-Z，采用的是ULI M1689芯片組。還有可以支持AM2和939兩種插座的939SLI-eSATA2，采用的是ULi M1697芯片組，用戶(hù)可通過(guò)AM2 CPU Board升級(jí)卡實(shí)現(xiàn)不同插座的CPU升級(jí)。
ULi芯片組在技術(shù)上還是挺大膽創(chuàng)新的，例如2005年ULi針對(duì)AMD K8處理器推出的M1695+M1567組合，是全球第一款支持TGi技術(shù)的芯片組，能夠同時(shí)提供PCI-E x16及AGP 8X顯卡插槽，而且PCI-E x16還能分離成兩個(gè)PCI-E x8。用戶(hù)可以在主板上實(shí)現(xiàn)AGP+PCI-E+PCI三種不同接口顯卡同時(shí)輸出，還能通過(guò)PCI-E通道分拆轉(zhuǎn)接卡（類(lèi)似服務(wù)器），將一個(gè)PCI-E x16插槽分成兩個(gè)PCI-E x8破解組成SLI或CrossFire。廠商還可以選擇M1695搭配另一款帶北橋功能的M1697（集成南北橋的單芯片），實(shí)現(xiàn)更多的PCI-E通道，或者在南北橋中間加入其他控制芯片（比如AMD 8132 PCI-X通道控制器），提供原本不支持的接口。
事實(shí)上，ULi是主動(dòng)聯(lián)系英偉達(dá)，尋求被收購(gòu)。據(jù)宇力電子總經(jīng)理郭聰鈴?fù)嘎叮?005年美國(guó)國(guó)慶節(jié)（7月4日）主動(dòng)致電與黃仁勛接觸，雙方很快就決定合并。英偉達(dá)當(dāng)時(shí)在主板芯片組方面已非常強(qiáng)勢(shì)，特別是AMD平臺(tái)，但是南橋技術(shù)方面有所欠缺，但這恰恰是ULi所擅長(zhǎng)的，像ATI早期進(jìn)入芯片組市場(chǎng)也采用了ALi/ULi的南橋技術(shù)。此外，缺乏圖形技術(shù)一直是ULi發(fā)展的瓶頸，后來(lái)幾年的市場(chǎng)發(fā)展也證明了ULi在形勢(shì)判斷上非常正確。
在2005年12月14日，英偉達(dá)以5200萬(wàn)美元收購(gòu)了宇力電子，并在2007年初徹底放棄了ULi品牌及停止其產(chǎn)品供應(yīng)。
威盛（VIA）最早是在1987年成立于美國(guó)硅谷，1992年回到中國(guó)臺(tái)灣后，王雪紅與陳文琦共同創(chuàng)建了我們熟知的威盛。其早期芯片組一般以“Apollo”來(lái)命名，南北橋也有各自VT開(kāi)頭的型號(hào)。威盛至今被許多玩家銘記，是其在世紀(jì)之交的時(shí)候，向英特爾挑戰(zhàn)的勇氣。
進(jìn)入586時(shí)代后，威盛推出了Apollo VP-1，相比英特爾的同類(lèi)產(chǎn)品，價(jià)格低而且功能齊全，因此打響了名堂。隨后的Apollo VPX進(jìn)一步鞏固了威盛的市場(chǎng)位置，也讓英特爾開(kāi)始警覺(jué)。接著Apollo VP2、Apollo VP3和Apollo VP4的推出，使得威盛的市場(chǎng)份額逐漸擴(kuò)大。Apollo MVP4的發(fā)布，使得威盛站上了新的高峰，這款芯片組集成了Trident圖形單元，還有Moden和聲卡，具備最早的DVD硬件加速功能，非常受消費(fèi)者歡迎。這時(shí)期威盛已經(jīng)有很好的市場(chǎng)口碑，但是與英特爾相比，仍然有一段距離。
1999年，如日中天的英特爾非常自信地認(rèn)定RDRAM在技術(shù)上遙遙領(lǐng)先，欽定RDRAM成為其平臺(tái)下一代內(nèi)存的標(biāo)準(zhǔn)，并在1999年9月開(kāi)始在Pentium III平臺(tái)推出相關(guān)的芯片組，希望主流市場(chǎng)從PC-100 SDRAM直接跳到RDRAM。問(wèn)題是RDRAM實(shí)在太貴了，廠商們苦不堪言。于是威盛聯(lián)合三星、現(xiàn)代、日立、西門(mén)子、Micron、LG和NEC等公司提出PC-133規(guī)范，這一場(chǎng)利益之爭(zhēng)的世紀(jì)大戰(zhàn)堪稱(chēng)十八路諸侯討董卓，并取得了成功。
隨后，威盛分別在英特爾和AMD平臺(tái)推出了Apollo Pro 133(693A)/Apollo Pro 133(694X)和Apollo KX133/KT133(A)芯片組，憑借先后對(duì)PC-133 SDRAM、133 MHz前端總線、UDMA 100和AGP 4x的支持，一度占據(jù)了整個(gè)芯片組市場(chǎng)的半壁江山，甚至可以說(shuō)如日中天，是市場(chǎng)上一股不可忽視的力量。2000年是威盛最為輝煌的一年，使其成為了英特爾的噩夢(mèng)。威盛在英特爾平臺(tái)的市場(chǎng)份額比英特爾自己要高，AMD平臺(tái)方面更厲害，在英偉達(dá)推出nForce之前，威盛的芯片組幾乎就是標(biāo)配。
在英特爾看來(lái)，威盛嚴(yán)重侵害了自己的利益，威脅到自己的位置。在之后的很多年里，不斷針對(duì)威盛進(jìn)行訴訟打擊，同時(shí)各種手段威逼利誘主板廠商不能使用威盛的芯片組，拖延威盛在芯片組規(guī)格上的領(lǐng)先時(shí)間。后來(lái)又在發(fā)放Pentium 4平臺(tái)芯片組的授權(quán)生產(chǎn)許可時(shí)，只給了ALi/ULi和SiS，沒(méi)有給威盛。當(dāng)然威盛也并不是坐以待斃，在1999年以1.67億美元收購(gòu)了Cyrix，在2000年以3.22億美元收購(gòu)了S3 Graphics，加上IDT Centaur，不但使其擁有自己的圖形技術(shù)，還獲得了x86授權(quán)，得到了設(shè)計(jì)CPU和GPU的準(zhǔn)入證，是英特爾、AMD之外全球第三家獲得x86架構(gòu)授權(quán)的企業(yè)，這也是目前國(guó)內(nèi)兆芯繼承的技術(shù)基礎(chǔ)。
當(dāng)內(nèi)存進(jìn)入DDR時(shí)代后，雖然威盛仍然穩(wěn)扎穩(wěn)打，不過(guò)一系列產(chǎn)品總體上比較中規(guī)中矩。相比英特爾平臺(tái)遭受的打壓，威盛在AMD平臺(tái)比較平穩(wěn)，從Apollo KT133到KT600，一直穩(wěn)穩(wěn)把守AMD平臺(tái)第一芯片組廠商的位置。隨著英特爾轉(zhuǎn)向LGA 775插座，以及英偉達(dá)從nForce 2開(kāi)始的出色發(fā)揮，勢(shì)單力薄的威盛漸漸失去了位置。威盛后來(lái)的芯片組不再以Apollo命名，英特爾平臺(tái)以PT開(kāi)頭，AMD平臺(tái)則以K8T開(kāi)頭。
經(jīng)過(guò)了多年的爭(zhēng)斗，最終威盛和英特爾在表面上達(dá)成和解協(xié)議，但英特爾根本不會(huì)給威盛一絲一毫翻盤(pán)的機(jī)會(huì)。這場(chǎng)被稱(chēng)為“螞蟻與大象的戰(zhàn)爭(zhēng)”的結(jié)果是數(shù)年后，在英特爾的高壓之下，威盛逐漸被逼出了主板芯片組及x86處理器的消費(fèi)市場(chǎng)（CDMA基帶業(yè)務(wù)也賣(mài)給了英特爾），縮在嵌入式設(shè)備市場(chǎng)，最后英特爾平臺(tái)不再有第三方芯片組的身影。
威盛早已消失在普通消費(fèi)者的視野中，只是偶爾在USB芯片等地方能看到。不過(guò)兆芯基本繼承了威盛多年來(lái)的成果，仍在穩(wěn)步前進(jìn)，或許在未來(lái)會(huì)離我們更為接近一些。
在《超能課堂(287)：消失的第三方之圖形顯示芯片篇》里，已簡(jiǎn)單介紹過(guò)SiS（矽統(tǒng)科技）的一些基本情況。這間老牌廠商曾在英特爾與威盛的交鋒中分得一杯羹，不聲不響一度變成世界第三大主板芯片組廠商。搭載SiS芯片組的主板在DIY市場(chǎng)上并不是玩家的首選，但是因其低廉的價(jià)格，OEM廠商情有獨(dú)鐘。
SiS早期386時(shí)期就開(kāi)始推出相關(guān)的芯片組，一直不溫不火，在市場(chǎng)上也是不聲不響。主要原因在于，SiS芯片組雖然便宜，但性能和功能上都比較一般，技術(shù)上一直都只是追隨者的角色。到了90年代末期，隨著英特爾Socket 370插座的Pentium III處理器以及AMD K7處理器的推出，SiS有了一些野心，無(wú)論主板芯片組還是圖形處理芯片，技術(shù)規(guī)格上都比以往進(jìn)取。同時(shí)在命名上也非常規(guī)范，AMD平臺(tái)對(duì)應(yīng)芯片組是SiS 7xx系列，而英特爾平臺(tái)則是SiS 6xx系列，通過(guò)第一位數(shù)字就知道是對(duì)應(yīng)哪個(gè)CPU廠商的產(chǎn)品。
相比ALi/ULi甚至威盛，SiS一直都有自己的圖形技術(shù)，使得在快速的市場(chǎng)變化中，仍能設(shè)計(jì)出適合市場(chǎng)需要的產(chǎn)品。從技術(shù)來(lái)看，SiS的芯片組沒(méi)有太多可以提的地方，不過(guò)其產(chǎn)品基本穩(wěn)定地貫穿了近20年的時(shí)間，至今在二手市場(chǎng)上仍能找到大量SiS芯片組的舊款OEM主板。英特爾曾經(jīng)在2006年左右，自家芯片組產(chǎn)能不足的時(shí)候，推薦合作伙伴采用SiS芯片組，這種低調(diào)的作風(fēng)也是有好處的。
圖：華擎也曾推出采用SiS 760GX芯片組的K8Upgrade-760GX妖板
SiS有一件比較有趣的事情。在1998年曾有一間很小的x86處理器廠商，很低調(diào)地推出了低功耗、低價(jià)位的mP6處理器，但在1999年底就退出市場(chǎng)了。這間名為Rise Technology的公司，是在1993年由投資銀行與中國(guó)臺(tái)灣的眾多IT企業(yè)（包括Acer和威盛等）籌資成立的，其低功耗的mP6處理器面向移動(dòng)平臺(tái)，由臺(tái)積電負(fù)責(zé)代工。這間公司隨后被SiS收購(gòu)，SiS在2001年推出的SiS 550單芯片系列，里面就整合了mP6處理器的核心，不過(guò)就沒(méi)有然后了。
就這樣，SiS錯(cuò)失成為一間真正意義上橫跨CPU、GPU和芯片組廠商的機(jī)會(huì)。大概這種務(wù)實(shí)作風(fēng)，使得SiS在大風(fēng)大浪中存活至今。
英偉達(dá)是一間非常有實(shí)力，而且有野心的公司。在推出TNT2系列后，逐漸成為圖形處理芯片霸主的時(shí)候，就意識(shí)到主板芯片組上集成高性能圖形單元會(huì)非常有市場(chǎng)，隨即與ALi合作推出了ALADDiN TNT芯片組，加入了TNT2 M64圖形單元。顯然英偉達(dá)并不滿(mǎn)足于此，這種操作僅僅是試水。
隨后在2001年6月，英偉達(dá)發(fā)布了第一代nForce主板芯片組，面向AMD平臺(tái)。雖然規(guī)格上領(lǐng)先，但硬件設(shè)計(jì)上的諸多缺陷，使得這款產(chǎn)品未能撼動(dòng)威盛在AMD平臺(tái)上的霸主地位。不過(guò)英偉達(dá)并未氣餒，在2002年7月推出了nForce 2，雖然仍存在USB兼容性等問(wèn)題，但這款芯片組在規(guī)格上非常前衛(wèi)，支持雙通道DDR內(nèi)存、AGP 8X、400MHz FSB、ATA 133、IEEE1394、整合GeForce 4 MX級(jí)別圖形單元、甚至支持雙網(wǎng)卡等，讓用戶(hù)眼前一亮。憑借nForce 2，英偉達(dá)逐漸取代了威盛在AMD平臺(tái)的首席位置。
英偉達(dá)接下來(lái)又推出了nForce 3和nForce 4，特別是后者，完全確立了英偉達(dá)的市場(chǎng)位置。nForce 4時(shí)期，英偉達(dá)終于得到了英特爾的授權(quán)，其芯片組也進(jìn)入了英特爾平臺(tái)，逐漸走向巔峰。nForce 4還可以支持SLI，加上英偉達(dá)在GPU市場(chǎng)的霸主位置，nForce 4也成為了高端芯片組的代表之一。同時(shí)英偉達(dá)的芯片組不但面向消費(fèi)市場(chǎng)，還進(jìn)入了AMD的工作站和服務(wù)器市場(chǎng)，成為了AMD Opteron（皓龍）處理器的搭檔。
在2006年，英偉達(dá)先后發(fā)布了nForce 500系列和nForce 600系列，先后也就相隔大半年時(shí)間。這一系列芯片組覆蓋了高、中、低端市場(chǎng)，在AMD平臺(tái)英偉達(dá)已經(jīng)完全沒(méi)有對(duì)手了，在英特爾平臺(tái)也引來(lái)了不少高端玩家的關(guān)注。隨后英偉達(dá)在2007年12月發(fā)布了nForce 700系列，以a和i結(jié)尾區(qū)分AMD和英特爾平臺(tái)。與nForce 600系列一樣全面覆蓋，其高技術(shù)規(guī)格和完善的功能引領(lǐng)市場(chǎng)，被發(fā)燒友追捧。
在此期間，MCP61、MCP68和MCP73系列芯片組也在集成顯卡芯片組市場(chǎng)大展拳腳。這時(shí)期英偉達(dá)在芯片組上有著非常大的野心，任何機(jī)會(huì)都不會(huì)錯(cuò)過(guò)，比如推出了支持英特爾Atom處理器的芯片組，組成ION平臺(tái)。與英特爾配套的945GSE芯片組相比，英偉達(dá)MCP79芯片組在性能上全面壓制。當(dāng)時(shí)不少人熱衷迷你的HTPC，ION平臺(tái)是一個(gè)不錯(cuò)的解決方案。除了CPU，英偉達(dá)幾乎做了一切。
英偉達(dá)在主板芯片組市場(chǎng)也達(dá)到了最巔峰。
可惜的是，隨著AMD收購(gòu)ATI建設(shè)3A平臺(tái)，以及英特爾政策的改變，第三方主板芯片組廠商的生存空間越來(lái)越小。英偉達(dá)取消了nForce 800系列的發(fā)布，nForce 900系列也只推出了nForce 980a SLI一款產(chǎn)品，而且這是nForce 780a SLI的更名版罷了。最終在2009年10月，英偉達(dá)決定放棄經(jīng)營(yíng)已久的nForce產(chǎn)品線。
RTCP 協(xié)議規(guī)范中定義了五種類(lèi)型的 RTCP 包：接收?報(bào)告（ RR ）、發(fā)送?報(bào)告（ SR ）、源
描述（ SDES ）、成員管理（ BYE ）和應(yīng)?程序定義（ APP ）。
SR: payload type=200
RR:payload type=201
SDES: payload type=202
BYE:payload type=203
APP：payload type=204
RTPFB：payload type=205
PSFB：payload type=206
RTCP_RTP_FB_NACK_FMT(1): NACK重傳, type-205
RTCP_RTP_FB_RTX_FMT(1):RTX重傳，type-205
RTCP_RTP_FB_CC_FMT(15):Transport-cc 帶寬估計(jì)，type-205
RTCP_PLI_FMT(1): picture重傳, type-206
RTCP_SLI_FMT(2): Slice重傳, type-206
RTCP_FIR_FMT(4): 關(guān)鍵幀重傳, type-206
RTCP_REMB_FMT(15): 帶寬估計(jì), type-206
版本號(hào)（V）：對(duì)于當(dāng)前版本的RTP協(xié)議，版本號(hào)為2（截止到本書(shū)編纂為止），目前還 沒(méi)有推出新版本的計(jì)劃，并且之前的版本并沒(méi)有廣泛的被使用.
填充（P）：填充位表示，所要填充的數(shù)據(jù)已經(jīng)超出了目前所能容納的位數(shù)。如果此位 被設(shè)置為1，那么意味著包尾已經(jīng)被一個(gè)或多個(gè)八位字節(jié)填充，最后一位八位所填充的 內(nèi)容表示此包的總數(shù)大小。
條目計(jì)數(shù)（IC）：某些包類(lèi)型中包含了一個(gè)list的條目，可能作為固定的、用于特定類(lèi) 型的信息的補(bǔ)充。這些條目字段需要標(biāo)示出包中包含的條目的總數(shù)（這個(gè)字段在不同的 包中有不同的命名方法，這取決于具體如何使用此字段）。每個(gè)RTCP包最多包含31個(gè) 條目，同時(shí)也受到MTU（maximum transmission unit）的限制。如果需要傳輸超過(guò)31 個(gè)條目的場(chǎng)景，那么應(yīng)用程序必須生成多個(gè)RTCP包。Item Count字段為0的時(shí)候表示此包中的條目為空（但是并不意味著包中內(nèi)容為空）。如果不需要Item count字段那么此字段可以用于其他的目的。
包類(lèi)型（PT）：此字段標(biāo)識(shí)了傳輸?shù)陌兴鶖y帶的信息的類(lèi)型。在RTP的規(guī)范中定義了 五種標(biāo)準(zhǔn)數(shù)據(jù)包類(lèi)型，將來(lái)可能還會(huì)定義其他的類(lèi)型（例如，報(bào)告額外統(tǒng)計(jì)信息或者傳 遞其他特定源的信息）。
長(zhǎng)度：此字段標(biāo)識(shí)包頭之后的內(nèi)容總長(zhǎng)度。因?yàn)樗械腞TCP的數(shù)據(jù)包的長(zhǎng)度必須為32 位的整數(shù)倍，所以這個(gè)字段放的是32位字的個(gè)數(shù)，因?yàn)槿绻凑瞻宋蛔止?jié)計(jì)算會(huì)出現(xiàn) 此字段和總長(zhǎng)度不一致的情況。0是一個(gè)有效長(zhǎng)度，表示這個(gè)包只包含4個(gè)8位字節(jié)的包 頭（包頭字段IC在這種情況下也是0）。
RTCP包中復(fù)合包的結(jié)構(gòu)
每一個(gè)報(bào)告塊（report block）都是描述單個(gè)同步源的接收質(zhì)量，而報(bào)告者（reporter）從當(dāng)前報(bào)告的間隔期間，接收從該同步源發(fā)過(guò)來(lái)的RTP包。每一個(gè)RTCP的RR包總共有31個(gè)報(bào)告 塊。如果有超過(guò)31個(gè)激活的發(fā)送者，那么接收者應(yīng)該在一個(gè)復(fù)合數(shù)據(jù)包中發(fā)送多個(gè)RR數(shù)據(jù)包，每個(gè)報(bào)告塊有7個(gè)字段，總共24個(gè)字節(jié)。
Reportee（被報(bào)告者）SSRC標(biāo)識(shí)此報(bào)告塊相關(guān)的參與者。報(bào)告塊中的統(tǒng)計(jì)數(shù)據(jù)，表示的是在生成RR數(shù)據(jù)包的參與者處，被報(bào)告方接收到的同步源的數(shù)據(jù)包的接收質(zhì)量。
丟包率（loss fraction）的定義是在這個(gè)報(bào)告間隔中所丟失包的數(shù)量，除以預(yù)期到達(dá)的數(shù)量。丟包率表示為一個(gè)定點(diǎn)數(shù)，該定點(diǎn)數(shù)的二進(jìn)制小數(shù)點(diǎn)位于字段的左邊緣。即丟包率乘 以256后的整數(shù)部分（即如果傳輸中有1/4的包丟掉，那么丟包率應(yīng)該是1/4 * 256 = 64）. 如果接收到的包的數(shù)量大于預(yù)期（由于存在重復(fù)包的情況），使得丟包數(shù)為負(fù)值，那么丟 包的部分設(shè)置為0.
累計(jì)丟包數(shù)是一個(gè)24位帶符號(hào)的整數(shù)，它表示預(yù)期應(yīng)該到達(dá)的包的數(shù)量，減去實(shí)際接收到 的包的數(shù)量。預(yù)期的包數(shù)的定義是，最后接收到的擴(kuò)展序列號(hào)，減去接收到的初始序列號(hào)。接收到的包的總數(shù)包括任何延遲到達(dá)或者重傳過(guò)來(lái)的包，因此可能會(huì)大于預(yù)期的數(shù)量，因此累計(jì)丟包數(shù)有可能是負(fù)值。累計(jì)丟包數(shù)的計(jì)算區(qū)間是統(tǒng)計(jì)的整個(gè)會(huì)話期間的，而不是在每個(gè)間隔期間。如果在會(huì)話期間丟包的總數(shù)大于0x7FFFFF，那么此字段會(huì)在0x7FFFFF處于最大飽和值。
理論計(jì)算方式, packet lost = 期待得到報(bào)文數(shù)量 - 實(shí)際收到報(bào)文的數(shù)量。
實(shí)際計(jì)算方式, packet lost = 期待收到最新sequence - 第一次收到報(bào)文的sequence。
在同步源的RTP數(shù)據(jù)包中接收到的擴(kuò)展最高序列號(hào)（extended highest sequence number） 的計(jì)算，由于可能存在包重新排序的情況，所以并不一定是接收到的最后一個(gè)RTP包的擴(kuò)展序列號(hào)。擴(kuò)張序列號(hào)是 基于會(huì)話計(jì)算的，而不是基于包間隔計(jì)算的。
extended_seq_num = seq_num + (65536 * wrap_around_count)
其中wrap_around_count為sequence翻轉(zhuǎn)的次數(shù)
到達(dá)間隔抖動(dòng)（Interarrival jitter）是對(duì)被報(bào)告者（Reportee）同步源發(fā)送的數(shù)據(jù)包的網(wǎng)絡(luò)傳輸時(shí)間統(tǒng)計(jì)方差的估計(jì)。它是以時(shí)間戳單位衡量的，因此它像RTP時(shí)間戳一樣用32位無(wú) 符號(hào)整數(shù)表示.
J(i) = J(i-1) + (|D(i-1,i)| - J(i-1))/16
D(i,j) = (Rj - Ri) - (Sj - Si) = (Rj - Sj) - (Ri - Si)
最后一個(gè)發(fā)送者報(bào)告（last sender report，LSR）時(shí)間戳是64位NTP（網(wǎng)絡(luò)時(shí)間協(xié)議（Network Time Protocol））格式的時(shí)間戳中間的32位，包含在最近從被報(bào)告者的SSRC接收到的RTCP的SR包中。如果SR沒(méi)有收到，那么此字段可以設(shè)置為0.
自上次發(fā)送者報(bào)告起的延遲（delay since last sender report，DSLR）是從被報(bào)告者SSRC接收到最后一個(gè)SR數(shù)據(jù)包到發(fā)送此接收?qǐng)?bào)告塊之間的延時(shí)，以1/65,536秒為單位。如果沒(méi)從 該被報(bào)告者收到SR，則DLSR字段設(shè)置為0.
發(fā)送方可以使用LSR和DLSR字段來(lái)計(jì)算它與每個(gè)接收方之間的往返時(shí)間（rtt）。當(dāng)接收到 一個(gè)與之相關(guān)的RR包時(shí)，發(fā)送方用當(dāng)前的時(shí)間減去LSR字段，以得到發(fā)送SR到接收此RR之 間的延遲。發(fā)送方然后再減去DLSR字段以消除接收方延遲帶來(lái)的偏移，從而獲得網(wǎng)絡(luò)往返時(shí)間。
RTT=NTP-LSR-DLSR.
領(lǐng)取音視頻開(kāi)發(fā)學(xué)習(xí)資料：音視頻開(kāi)發(fā)（資料文檔+視頻教程+面試題）（FFmpeg+WebRTC+RTMP+RTSP+HLS+RTP）
發(fā)送者報(bào)告的包類(lèi)型為200，有效負(fù)載包含一個(gè)24字節(jié)的發(fā)送者信息 塊，后面跟著0個(gè)或多個(gè)接收方報(bào)告塊，由RC字段標(biāo)識(shí)，類(lèi)似于接收方報(bào)告報(bào)。當(dāng)發(fā)送者 也是接受方的時(shí)候，接收方報(bào)告塊就出現(xiàn)了.
NTP時(shí)間戳是一個(gè)64位的無(wú)符號(hào)值，表示發(fā)送這個(gè)RTCP SR包的時(shí)間。它的格式是NTP時(shí)間戳，時(shí)間從1900年1月1日開(kāi)始計(jì)算秒，低32位代表秒的小數(shù)部分（fractions of second）
（也就是64位定點(diǎn)值，二進(jìn)制小數(shù)點(diǎn)位于32位之后）。如果要將UNIX的時(shí)間戳（從1970 年1月1日開(kāi)始的秒數(shù)）轉(zhuǎn)化為NTP時(shí)間，那么需要添加2,208,988,800秒。
RTP時(shí)間戳與NTP時(shí)間戳的對(duì)應(yīng)的時(shí)間是相同的，但是，它是以RTP媒體時(shí)鐘的基準(zhǔn)單位表 示的。這個(gè)值，通常與前一個(gè)數(shù)據(jù)包的RTP時(shí)間戳不同，因?yàn)樽栽摂?shù)據(jù)包中的數(shù)據(jù)被采樣 已經(jīng)經(jīng)過(guò)了一段時(shí)間了。
發(fā)送方的包計(jì)數(shù)，是這個(gè)同步源自會(huì)話開(kāi)始以來(lái)，生成的數(shù)據(jù)包的總數(shù)。發(fā)送方的字節(jié)計(jì) 數(shù)是這些數(shù)據(jù)包的有效負(fù)載（playload）中包含的字節(jié)數(shù)（不包括包頭或者填充）。如果發(fā)送方改變其SSRC（例如，由于產(chǎn)生沖突），則會(huì)重置發(fā)送方的包計(jì)數(shù)以及字節(jié)計(jì)數(shù) 字段。
RTCP也可以用來(lái)傳遞源描述（SDES）數(shù)據(jù)包，提供參與者認(rèn)證和補(bǔ)充性細(xì)節(jié)，如位置、 電子郵件地址和電話號(hào)碼。
應(yīng)用程序有可能生成SDES項(xiàng)為空列表的包，在這種場(chǎng)景下，RTCP公共包頭中的SC和length 字段都為0.在正常情況下，SC應(yīng)該為1（混流?（mixers）和轉(zhuǎn)換?（translators）所聚集 的轉(zhuǎn)發(fā)信息產(chǎn)生的包會(huì)有較大的SDES項(xiàng)的列表）。
每個(gè)SDES項(xiàng)中的條目都是以連續(xù)的方式打包到包中，沒(méi)有分隔或者填充。條目列表（list of item）以一個(gè)或者多個(gè)空的字節(jié)結(jié)束，當(dāng)解析到第一個(gè)字節(jié)為0類(lèi)型的時(shí)候，意味著這個(gè)列 表結(jié)束。0類(lèi)型字節(jié)后面不會(huì)跟長(zhǎng)度字節(jié)，但是如果需要填充，則包括其他的空字節(jié)，直到 達(dá)到32-bit邊界為止。這個(gè)填充（padding）與RTCP包頭中的P位表示的填充是分開(kāi)的。帶 有零項(xiàng)的列表（四個(gè)空字節(jié)）是有效的，但是沒(méi)有意義。
CNAME項(xiàng)（type = 1）為每個(gè)參與者提供了一個(gè)規(guī)范名稱(chēng)（CNAME）。它提供了一個(gè)獨(dú)立于同步源的穩(wěn)定且持久的標(biāo)識(shí)符（因?yàn)槿绻麘?yīng)用程序重啟或發(fā)生SSRC沖突，SSRC將改 變）。CNAME可以用于關(guān)聯(lián)來(lái)自不同RTP會(huì)話的參與者的多個(gè)媒體流（例如，關(guān)聯(lián)需要同 步的語(yǔ)音和視頻），以及在媒體工具重啟時(shí)命名參與者。這是唯一的強(qiáng)制性的SDES條目， 所有實(shí)現(xiàn)都需要發(fā)送SDES CNAME項(xiàng)。
RTCP通過(guò)RTCP的Bye包為成員提供松散的控制，如果收到Bye表明某些參與者已經(jīng)離開(kāi)了 會(huì)話。Bye包是在參與者離開(kāi)會(huì)話的時(shí)候，或者當(dāng)其他參與者因?yàn)闆_突而改變SSRC的時(shí)候 生成的。Bye包有可能會(huì)在傳輸過(guò)程中丟失，并且有些應(yīng)用程序也不能生成此包。所以，即便沒(méi)有收到Bye包，針對(duì)一段時(shí)間沒(méi)有活躍的參與者，接收方應(yīng)該有超時(shí)機(jī)制。
RTCP BYE包不會(huì)終止參與者之間的任何其他關(guān)聯(lián)關(guān)系。Bye包的標(biāo)識(shí)類(lèi)型為203，公共的RTCP包頭中的RC字段表示SSRC標(biāo) 識(shí)符的數(shù)量。其存在為0的可能性，標(biāo)識(shí)為0時(shí)無(wú)用。在接收到Bye包時(shí)，實(shí)現(xiàn)時(shí)應(yīng)該假設(shè) 此源已經(jīng)離開(kāi)了會(huì)話，并忽略來(lái)自該源的任何后續(xù)的RTP和RTCP包。最重要的是，當(dāng)收到Bye包之后，需要為此參與者保留一段時(shí)間的連接狀態(tài)，因?yàn)橐试S延遲到達(dá)的數(shù)據(jù)包被接收到。
Bye包還可能包含了表示離開(kāi)會(huì)話原因的文本，適合在用戶(hù)界面中顯示。但是，這個(gè)文本是可以選填的，在實(shí)現(xiàn)過(guò)程中我們需要去接收它（即使文本可能會(huì)被忽略）。
RTCP APP：應(yīng)用程序定義的RTCP包
最后一類(lèi)RTCP包（APP）允許應(yīng)用程序來(lái)自己定義擴(kuò)展。它的包類(lèi)型為204，由4個(gè)字符組成唯一的標(biāo)識(shí)，每個(gè)字符都得從ASCII字符集中選擇，并區(qū)分大小寫(xiě)。建議選擇包名稱(chēng)來(lái)匹配它所代表的應(yīng)用程序，并由應(yīng)用程序來(lái)協(xié)調(diào)子類(lèi)型值的選 擇。包其余部分被用于應(yīng)用程序的特定需求。
應(yīng)用程序自定義的包用于RTCP的非標(biāo)準(zhǔn)擴(kuò)展和驗(yàn)證新特性。目的是，驗(yàn)證者首先使用APP 來(lái)驗(yàn)證新特性，然后如果新特性有廣泛的用途，那么就注冊(cè)為新的包類(lèi)型。一些應(yīng)用程序 生成的包或?qū)崿F(xiàn)方案，應(yīng)該忽略識(shí)別不出來(lái)的應(yīng)用程序包。
RTCP包不會(huì)單獨(dú)發(fā)送，而是組包成一個(gè)復(fù)合數(shù)據(jù)包進(jìn)行傳輸。生成復(fù)合RTCP包的參與者是活躍的數(shù)據(jù)發(fā)送方，那么該復(fù)合包必須以RTCP SR包開(kāi)始。否則必須從RTCP RR包開(kāi)始。即使還沒(méi)有發(fā)送或接收數(shù)據(jù)，這也是正確的，在這種情況下，SR/RR包不會(huì)包含接收方的報(bào)告塊（包頭字段RC為0）。另一方面，如果從多個(gè)源接收數(shù)據(jù)，并且報(bào)告太多，導(dǎo)致無(wú)法放入一個(gè)SR/RR包，則復(fù)合后的數(shù)據(jù)應(yīng)以一個(gè)SR/RR包開(kāi)始，后面在跟著多個(gè)RR包。跟在SR/RR包后面的是一個(gè)SDES包。這個(gè)包必須包含一個(gè)CNAME條目。它可能包含其他的 條目。包含其他（非CNAME）SDES條目的頻度由使用中的RTP配置文件決定。
Bye包必須做為最后一個(gè)數(shù)據(jù)包發(fā)送。要發(fā)送的其他RTCP包可以按 任何順序。這些嚴(yán)格的排序規(guī)則，旨在使數(shù)據(jù)包的校驗(yàn)更容易，因?yàn)殄e(cuò)誤定向的數(shù)據(jù)包， 大概率不會(huì)滿(mǎn)足這些約束。
在生成復(fù)合RTCP包時(shí)，一個(gè)潛在的問(wèn)題就是如何處理大量活躍發(fā)送者的會(huì)話。如果存在超 過(guò)31個(gè)活躍的發(fā)送者，那么有必要在復(fù)合包中增加額外的RR包。這可以根據(jù)需要重復(fù)此過(guò) 程，直到達(dá)到MTU的上限。如果發(fā)送方太多，以致于接收方報(bào)告不能被MTU容納，則必須 忽略某些發(fā)送方的接收?qǐng)?bào)告。如果出現(xiàn)這種情況，那么被忽略的報(bào)告，應(yīng)該在生成的下一 個(gè)復(fù)合包中被包含（要求接收方跟蹤每個(gè)間隔中報(bào)告的源）。
有時(shí)候需要將一個(gè)復(fù)合RTCP包填充并超出其原始大小。在這種場(chǎng)景下，填充只是添加到復(fù) 合包中的最后一個(gè)RTCP包中，P位（P bit）在最后一個(gè)包中被設(shè)置。
重傳請(qǐng)求需要兩個(gè)步驟：需要為重傳請(qǐng)求定義數(shù)據(jù)包格式，并且必須修改時(shí)序規(guī)則以允許?立即反饋。
否定應(yīng)答(NACK)的格式如圖9.11所示。NACK包含?一個(gè)表示丟包的包標(biāo)識(shí)符和?一個(gè)位圖，該位圖顯示以下16個(gè)包中的哪?一個(gè)丟失了了，值為1表示丟失。
反饋包作為?一個(gè)復(fù)合RTCP包的?一部分發(fā)送，其?方式與所有其他RTCP包相同。它們放在復(fù)合包的最后，在SR/RR和SDES項(xiàng)之后。
PT=205,FMT=1 和 NACK 一樣
1、rtx 在sdp中的體現(xiàn)：
a=rtpmap:97 rtx/90000
a=fmtp:97 apt=96
a=ssrc-group:FID ssrc rtxssrc
97 為rtx負(fù)載類(lèi)型，90000為時(shí)鐘頻率，一般和要重傳的包的時(shí)鐘頻率相同。
a=fmtp:97 apt=96 表示 負(fù)載類(lèi)型為97的rtx包重傳的是負(fù)載類(lèi)型為96包。
a=ssrc-group:FID ssrc rtxssrc 將rtx包的ssrc與重傳包的ssrc關(guān)聯(lián)起來(lái)。
另外，97 rtx負(fù)載類(lèi)型必須出現(xiàn)在sdp的對(duì)應(yīng)m行里。
Original Rtp Packet Payload為要重傳包的負(fù)載數(shù)據(jù)，OSN為原始包的sequence number，Rtp Header除了Ssrc、負(fù)載類(lèi)型和rtx的sequence number外，其余部分與原始包相同。
Rtx原理：重發(fā)的包封裝到RTX包里發(fā)送，RTX包與原RTP有不同的SSRC，不同的rtpseq，但是timestamp與丟失包的時(shí)間戳相同。
Rtx優(yōu)勢(shì)：rtp重傳包在帶寬估計(jì)時(shí)不計(jì)入運(yùn)算，使用rtx比較方便，不使用rtx統(tǒng)計(jì)丟包率有時(shí)會(huì)出現(xiàn)負(fù)值
Rtxpayload：前兩個(gè)字節(jié)代表丟失包的rtp seq，因此rtx包比丟失的rtp包多2個(gè)字節(jié)
webRTC中被廢棄
對(duì)TMMBR的相應(yīng)
webRTC 中被廢棄
FCI為空
PLI消息用于解碼端通知編碼端我要解碼的圖像的編碼數(shù)據(jù)丟失了。對(duì)于基于幀間預(yù)測(cè)的視頻編碼類(lèi)型，編碼端收到PLI消息就要知道視頻數(shù)據(jù)丟失了，由于幀間預(yù)測(cè)需要基于前后完整的視頻幀才能解碼（例如H264中，存在B幀，需要參考前后幀才能解碼），前面的數(shù)據(jù)丟失了，后面的視頻幀不能正常解碼出圖像，此時(shí)編碼端可以直接生成一個(gè)關(guān)鍵幀，然后發(fā)送給解碼端。
SLI(PSFB-FMT(2))
。。。
FIR(PSFB-FMT(4))
當(dāng)解碼端需要刷新時(shí)，可以發(fā)送FIR消息給編碼端，編碼端此時(shí)發(fā)送關(guān)鍵幀，刷新解碼端。這有點(diǎn)類(lèi)似PLI消息，但是PLI消息是用于丟包情況下的通知，而FIR卻不是，在有些非丟包情況下，F(xiàn)IR就要用到。舉兩個(gè)例子：
1）解碼端需要切換到另一路不同視頻時(shí)，由于需要新的解碼參數(shù)，所以可通過(guò)發(fā)送FIR消息，通知編碼端生成關(guān)鍵幀，獲取新的解碼參數(shù)，刷新視頻解碼器；
2）在視頻會(huì)議中，新用戶(hù)隨機(jī)時(shí)刻加入，各個(gè)編碼端發(fā)送的視頻不一定都是關(guān)鍵幀，所以新用戶(hù)不一定能正常解碼。此時(shí)該新加入用戶(hù)發(fā)送FIR消息，通知各個(gè)編碼端給它發(fā)關(guān)鍵幀，獲取關(guān)鍵幀后即可正常解碼。
REMB(PSFB-FMT(15))
它描述了一個(gè)絕對(duì)值時(shí)間戳選項(xiàng)，用于帶寬估計(jì)。該反饋消息用于通知一個(gè)在同一RTP會(huì)話上有多個(gè)媒體流的發(fā)送方, 通知它在該RTP會(huì)話的接收方路徑上的總的估計(jì)可用比特率。
在用于反饋消息的公共數(shù)據(jù)包頭中（如[RFC4585]的6.1節(jié)所定義），“數(shù)據(jù)包發(fā)送者的SSRC” 字段指示通知的來(lái)源。 不使用“媒體源的SSRC”，并且應(yīng)將其設(shè)置為0。在其他RFC中也使用零值.
媒體發(fā)送方對(duì)符合此規(guī)范的REMB消息的接收將導(dǎo)致該消息在RTP會(huì)話上發(fā)送的總比特率等于或低于此消息中的比特率。 新的比特率限制應(yīng)盡快應(yīng)用。 發(fā)送者可以根據(jù)自己的限制和估計(jì)自由應(yīng)用其他帶寬限制。
a=rtcp-fb:<payload type> goog-remb
a=extmap:3 http://www.webrtc.org/experiments/rtp-hdrext/abs-send-timeV=2 P=0 FMT=15 PT=206 SSRC of media source=0
unique identifier ='R' 'E' 'M' 'B'
同步源的個(gè)數(shù)NUM SSRC:
帶寬的指數(shù)BR EXP:
帶寬的底數(shù)BR Mantissa:
所反饋的SSRC 一個(gè)或多個(gè)值 SSRC feedback (32 bits) Consists of one or more SSRC entries which this feedback message applies to.
receiver-bit-rate = mantissa * 2^exp例子：
Transport-CC(RTPFB-FMT(15))
Transport-cc指的是Transport-wide Congestion Control。WebRTC最新的擁塞控制算法（Sendside BWE）基于Transport-cc，接收端記錄數(shù)據(jù)包到達(dá)時(shí)間，構(gòu)造相關(guān)RTCP包，然后反饋給發(fā)送端，在發(fā)送端做帶寬估計(jì)，從而進(jìn)行擁塞控制.WebRTC中為了使用Transport-cc，需要用到RTP報(bào)頭擴(kuò)展以及增加新的RTCP類(lèi)型。這里我們介紹下Transport-cc中的RTP以及RTCP。
報(bào)文格式
Transport-cc中，收流客戶(hù)端通過(guò)TransportFeedback RTCP向發(fā)送端反饋收到的各個(gè)RTP包的到達(dá)時(shí)間信息。首先我們看下TransportFeedback包格式定義
base sequence number:2字節(jié)，TransportFeedback包中記錄的第一個(gè)RTP包的transport sequence number，在反饋的各個(gè)TransportFeedback RTCP包中，這個(gè)字段不一定是遞增的，也有可能比之前的RTCP包小
packet status count:2字節(jié)，表示這個(gè)TransportFeedback包記錄了多少個(gè)RTP包信息，這些RTP的transport sequence number以base sequence number為基準(zhǔn)，比如記錄的第一個(gè)RTP包的transport sequence number為base sequence number，那么記錄的第二個(gè)RTP包transport sequence number為base sequence number+1
reference time:3字節(jié)，表示參考時(shí)間，以64ms為單位，RTCP包記錄的RTP包到達(dá)時(shí)間信息以這個(gè)reference time為基準(zhǔn)進(jìn)行計(jì)算
feedback packet count:1字節(jié)，用于計(jì)數(shù)發(fā)送的每個(gè)TransportFeedback包，相當(dāng)于RTCP包的序列號(hào)。可用于檢測(cè)TransportFeedback包的丟包情況
packet chunk:2字節(jié)，記錄RTP包的到達(dá)狀態(tài)，記錄的這些RTP包transport sequence number通過(guò)base sequence number計(jì)算得到
recv delta: 8bits，對(duì)于"packet received"狀態(tài)的包，也就是收到的RTP包，在recv delta列表中添加對(duì)應(yīng)的的到達(dá)時(shí)間間隔信息，用于記錄RTP包到達(dá)時(shí)間信息。通過(guò)前面的reference time以及recv delta信息，我們就可以得到RTP包到達(dá)時(shí)間
packet chunk
首先先了解下RTP包狀態(tài)，目前定義了如下四種狀態(tài)，每個(gè)狀態(tài)值2bits，用來(lái)標(biāo)識(shí)RTP包的到達(dá)狀態(tài)，以及與前面RTP包的時(shí)間間隔大小信息：
00-Packet not received
01-Packet received, small delta
10-Packet received, large or negative delta
11-[Reserved]
packet chunk有兩種類(lèi)型，Run length chunk（行程長(zhǎng)度編碼數(shù)據(jù)塊）與Status vector chunk（狀態(tài)矢量編碼數(shù)據(jù)塊），對(duì)應(yīng)packet chunk結(jié)構(gòu)的兩種編碼方式。packet chunk的第一bit標(biāo)識(shí)chunk類(lèi)型。
這里先來(lái)了解下Run length（行程長(zhǎng)度）編碼。Run length編碼是一種簡(jiǎn)單的數(shù)據(jù)壓縮算法，其基本思想是將重復(fù)且連續(xù)出現(xiàn)多次的字符使用“連續(xù)出現(xiàn)次數(shù)+字符”來(lái)描述，例如：aaabbbcdddd通過(guò)Run length編碼就可以壓縮為3a3bc4d。Run length chunk中就使用了Run length編碼標(biāo)識(shí)連續(xù)多個(gè)相同狀態(tài)的包。
Run length chunk第一bit為0，后面跟著packet status以及run length。格式如下：
hunk type (T):1 bit，值為0
packet status symbol (S):2 bits，標(biāo)識(shí)包狀態(tài)
run length (L):13 bits，行程長(zhǎng)度，標(biāo)識(shí)有多少個(gè)連續(xù)包為相同狀態(tài)
下面舉例子說(shuō)明下。
packet status為00，由前面包狀態(tài)可知為"Packet not received"狀態(tài)，run lengh為221（11011101），說(shuō)明連續(xù)有221個(gè)包為"Packet not received"狀態(tài)。
Status Vector Chunk
第一bit為1，后面跟著symbol size以及symbol list。格式如下：
chunk type (T):1 bit，值為1
symbol size(S):1 bit，為0表示只包含"packet not received" (0)以及"packet received"（1）狀態(tài)，每個(gè)狀態(tài)使用1bit表示，這樣后面14bits的symbol list能標(biāo)識(shí)14個(gè)包的狀態(tài)。為1表示使用2bits來(lái)標(biāo)識(shí)包狀態(tài)，這樣symbol list中我們只能標(biāo)識(shí)7個(gè)包的狀態(tài)
symbol list:14 bits，標(biāo)識(shí)一系列包的狀態(tài), 總共能標(biāo)識(shí)7或14個(gè)包的狀態(tài)
symbol size為0，這樣能標(biāo)識(shí)14個(gè)包的狀態(tài)。第一個(gè)包狀態(tài)為"packet not received"（0），接著后面5個(gè)包狀態(tài)為"packet received"（1），再接著三個(gè)包狀態(tài)為"packet not received"，再接著三個(gè)包狀態(tài)為"packet received"，最后兩個(gè)包狀態(tài)為"packet not received"。
symbol size為1，這樣只能標(biāo)識(shí)7個(gè)包的狀態(tài)。第一個(gè)包為"packet not received"（00）狀態(tài)，第二個(gè)包為 "packet received, w/o timestamp"（11）狀態(tài)，再接著三個(gè)包為"packet received"（01）狀態(tài)，最后兩個(gè)包為"packet not received"（00）狀態(tài)。
Receive Delta
以250us(0.25ms)為單位，表示RTP包到達(dá)時(shí)間與前面一個(gè)RTP包到達(dá)時(shí)間的間隔，對(duì)于記錄的第一個(gè)RTP包，該包的時(shí)間間隔是相對(duì)reference time的。
如果在packet chunk記錄了一個(gè)"Packet received, small delta"狀態(tài)的包，那么就會(huì)在receive delta列表中添加一個(gè)無(wú)符號(hào)1字節(jié)長(zhǎng)度receive delta，無(wú)符號(hào)1字節(jié)取值范圍[0,255]，由于Receive Delta以0.25ms為單位，故此時(shí)Receive Delta取值范圍[0, 63.75]ms
如果在packet chunk記錄了一個(gè)"Packet received, large or negative delta"狀態(tài)的包，那么就會(huì)在receive delta列表中添加一個(gè)有符號(hào)2字節(jié)長(zhǎng)度的receive delta，范圍[-8192.0, 8191.75] ms
如果時(shí)間間隔超過(guò)了最大限制，那么就會(huì)構(gòu)建一個(gè)新的TransportFeedback RTCP包，由于reference time長(zhǎng)度為3字節(jié)，所以目前的包中3字節(jié)長(zhǎng)度能夠覆蓋很大范圍了
以上說(shuō)明總結(jié)起來(lái)就是：對(duì)于收到的RTP包在TransportFeedback RTCP receive delta列表中通過(guò)時(shí)間間隔記錄到達(dá)時(shí)間，如果與前面包時(shí)間間隔小，那么使用1字節(jié)表示，否則2字節(jié)，超過(guò)最大取值范圍，就另起新RTCP包了。
對(duì)于"Packet received, small delta"狀態(tài)的包來(lái)說(shuō)，receive delta最大值63.75ms，那么一秒時(shí)間跨度最少能標(biāo)識(shí)1000/63.75~=16個(gè)包。由于receive delta為250us的倍數(shù)，所以一秒時(shí)間跨度最多能標(biāo)識(shí)4000個(gè)包。
packet chunk以及receive delta的使用是為了盡可能減小RTCP包大小。packet chunk用到了不同編碼方式，對(duì)于收到的RTP包才添加到達(dá)時(shí)間信息，而且是通過(guò)時(shí)間間隔的方式記錄到達(dá)時(shí)間。