WebRTC基于GCC的擁塞控制(下) - 實(shí)現(xiàn)分析

本文在文章[1]的基礎(chǔ)上哮兰,從源代碼實(shí)現(xiàn)角度對WebRTC的GCC算法進(jìn)行分析。主要內(nèi)容包括: RTCP RR的數(shù)據(jù)源、報(bào)文構(gòu)造和接收,接收端基于數(shù)據(jù)包到達(dá)延遲的碼率估計(jì)宋梧,發(fā)送端碼率的計(jì)算以及生效于目標(biāo)模塊卸留。</br>

擁塞控制是實(shí)時流媒體應(yīng)用的重要服務(wù)質(zhì)量保證闷旧。通過本文和文章[1][2],從數(shù)學(xué)基礎(chǔ)、算法步驟到實(shí)現(xiàn)細(xì)節(jié),對WebRTC的擁塞控制GCC算法有一個全面深入的理解窘哈,為進(jìn)一步學(xué)習(xí)WebRTC奠定良好基礎(chǔ)。</br>

1 GCC算法框架再學(xué)習(xí)

</br>
</br>本節(jié)內(nèi)容基本上是文章[1]第1節(jié)的復(fù)習(xí)亭敢,目的是再次復(fù)習(xí)GCC算法的主要框架滚婉,梳理其算法流程中的數(shù)據(jù)流和控制流,以此作為后續(xù)章節(jié)的行文提綱帅刀。GCC算法的數(shù)據(jù)流和控制流如圖1所示让腹。</br>

圖1 GCC算法數(shù)據(jù)流和控制流

對發(fā)送端來講,GCC算法主要負(fù)責(zé)兩件事:1)接收來自接收端的數(shù)據(jù)包信息反饋扣溺,包括來自RTCP RR報(bào)文的丟包率和來自RTCP REMB報(bào)文的接收端估計(jì)碼率骇窍,綜合本地的碼率配置信息,計(jì)算得到目標(biāo)碼率A娇妓。2)把目標(biāo)碼率A生效于目標(biāo)模塊,包括PacedSender模塊活鹰,RTPSender模塊和ViEEncoder模塊等哈恰。</br>

對于接收端來講,GCC算法主要負(fù)責(zé)兩件事:1)統(tǒng)計(jì)RTP數(shù)據(jù)包的接收信息志群,包括丟包數(shù)着绷、接收RTP數(shù)據(jù)包的最高序列號等,構(gòu)造RTCP RR報(bào)文锌云,發(fā)送回發(fā)送端荠医。2)針對每一個到達(dá)的RTP數(shù)據(jù)包,執(zhí)行基于到達(dá)時間延遲的碼率估計(jì)算法桑涎,得到接收端估計(jì)碼率彬向,構(gòu)造RTCP REMB報(bào)文,發(fā)送回發(fā)送端攻冷。</br>

由此可見娃胆,GCC算法由發(fā)送端和接收端配合共同實(shí)現(xiàn),接收端負(fù)責(zé)碼率反饋數(shù)據(jù)的生成等曼,發(fā)送端負(fù)責(zé)根據(jù)碼率反饋數(shù)據(jù)計(jì)算目標(biāo)碼率里烦,并生效于目標(biāo)模塊凿蒜。本文接下來基于本節(jié)所述的GCC算法的四項(xiàng)子任務(wù),分別詳細(xì)分析之胁黑。</br>

2 RTCP RR報(bào)文構(gòu)造及收發(fā)

</br>
</br>關(guān)于WebRTC上的RTP/RTCP協(xié)議的具體實(shí)現(xiàn)細(xì)節(jié)废封,可參考文章[3]。本節(jié)主要從RR報(bào)文的數(shù)據(jù)流角度丧蘸,對其數(shù)據(jù)源漂洋、報(bào)文構(gòu)造和收發(fā)進(jìn)行分析。其數(shù)據(jù)源和報(bào)文構(gòu)造如圖2所示触趴,報(bào)文接收和作用于碼率控制模塊如圖3所示氮发。</br>

在數(shù)據(jù)接收端,RTP數(shù)據(jù)包從Network線程到達(dá)Worker線程冗懦,經(jīng)過Call對象爽冕,VideoReceiveStream對象到達(dá)RtpStreamReceiver對象。在該對象中披蕉,主要執(zhí)行三項(xiàng)任務(wù):1)接收端碼率估計(jì)颈畸;2) 轉(zhuǎn)發(fā)RTP數(shù)據(jù)包到VCM模塊;3)接收端數(shù)據(jù)統(tǒng)計(jì)没讲。其中1)是下一節(jié)的重點(diǎn)眯娱,2)是RTP數(shù)據(jù)包進(jìn)一步組幀和解碼的地方;3)是統(tǒng)計(jì)RTP數(shù)據(jù)包接收信息爬凑,作為RTCP RR報(bào)文和其他數(shù)據(jù)統(tǒng)計(jì)模塊的數(shù)據(jù)來源徙缴,是我們本節(jié)重點(diǎn)分析的部分。</br>

在RtpStreamReceiver對象中嘁信,RTP數(shù)據(jù)包經(jīng)過解析得到頭部信息于样,作為輸入?yún)?shù)調(diào)用ReceiveStatistianImpl::IncomingPacket()。該函數(shù)中分別調(diào)用UpdateCounters()和NotifyRtpCallback()潘靖,前者用來更新對象內(nèi)部的統(tǒng)計(jì)信息穿剖,如接收數(shù)據(jù)包計(jì)數(shù)等,后者用來更新RTP回調(diào)對象的統(tǒng)計(jì)信息卦溢,該信息用來作為getStats調(diào)用的數(shù)據(jù)源糊余。</br>

圖2 RTCP RR報(bào)文數(shù)據(jù)源及報(bào)文構(gòu)造

RTCP發(fā)送模塊在ModuleProcess線程中工作,RTCP報(bào)文周期性發(fā)送单寂。當(dāng)線程判斷需要發(fā)送RTCP報(bào)文時贬芥,調(diào)用SendRTCP()進(jìn)行發(fā)送。接下來調(diào)用PrepareReport()準(zhǔn)備各類型RTCP報(bào)文的數(shù)據(jù)宣决。對于我們關(guān)心的RR報(bào)文誓军,會調(diào)用AddReportBlock()獲取數(shù)據(jù)源并構(gòu)造ReportBlock對象:該函數(shù)首先通過ReceiveStatistianImpl::GetStatistics()拿到類型為RtcpStatistics的數(shù)據(jù)源,然后以此填充ReportBlock對象疲扎。GetStatistics()會調(diào)用CalculateRtcpStatistics()計(jì)算ReportBlock的每一項(xiàng)數(shù)據(jù)昵时,包括丟包數(shù)捷雕、接收數(shù)據(jù)包最高序列號等。ReportBlock對象會在接下來的報(bào)文構(gòu)造環(huán)節(jié)通過BuildRR()進(jìn)行序列化壹甥。RTCP報(bào)文進(jìn)行序列化之后救巷,交給Network線程進(jìn)行網(wǎng)絡(luò)層發(fā)送。</br>

圖3 RTCP RR報(bào)文接收及反饋

在發(fā)送端(即RTCP報(bào)文接收端)句柠,RTCP報(bào)文經(jīng)過Network線程到達(dá)Worker線程浦译,最后到達(dá)ModuleRtpRtcpImpl模塊調(diào)用IncomingRtcpPacket()進(jìn)行報(bào)文解析工作。解析完成以后溯职,調(diào)用TriggerCallbacksFromRTCPPackets()反饋到回調(diào)模塊精盅。在碼率估計(jì)方面,會反饋到BitrateController模塊谜酒。ReportBlock消息最終會到達(dá)BitrateControllerImpl對象叹俏,進(jìn)行下一步的目標(biāo)碼率確定。</br>

至此僻族,關(guān)于RTCP RR報(bào)文在擁塞控制中的執(zhí)行流程分析完畢粘驰。</br>

3 接收端基于延遲的碼率估計(jì)

</br>
</br>接收端基于數(shù)據(jù)包到達(dá)延遲的碼率估計(jì)是整個GCC算法最復(fù)雜的部分,本節(jié)在分析WebRTC代碼的基礎(chǔ)上述么,闡述該部分的實(shí)現(xiàn)細(xì)節(jié)蝌数。</br>

接收端基于延遲碼率估計(jì)的基本思想是:RTP數(shù)據(jù)包的到達(dá)時間延遲m(i)反映網(wǎng)絡(luò)擁塞狀況。當(dāng)延遲很小時度秘,說明網(wǎng)絡(luò)擁塞不嚴(yán)重顶伞,可以適當(dāng)增大目標(biāo)碼率;當(dāng)延遲變大時剑梳,說明網(wǎng)絡(luò)擁塞變嚴(yán)重唆貌,需要減小目標(biāo)碼率;當(dāng)延遲維持在一個低水平時阻荒,目標(biāo)碼率維持不變挠锥。其主要由三個模塊組成:到達(dá)時間濾波器众羡,過載檢查器和速率控制器侨赡。</br>

在實(shí)現(xiàn)上,WebRTC定義該模塊為遠(yuǎn)端碼率估計(jì)模塊RemoteBitrateEstimator粱侣,整個模塊的工作流程如圖4所示羊壹。需要注意的是,該模塊需要RTP報(bào)文擴(kuò)展頭部abs-send-time的支持齐婴,用以記錄RTP數(shù)據(jù)包在發(fā)送端的絕對發(fā)送時間油猫,詳細(xì)請參考文獻(xiàn)[4]。</br>

圖4 GCC算法基于延遲的碼率估計(jì)

接收端收到RTP數(shù)據(jù)包后柠偶,經(jīng)過一系列調(diào)用到RtpStreamReceiver對象情妖,由該對象調(diào)用遠(yuǎn)端碼率估計(jì)模塊的總控對象RemoteBitrateEstimatorAbsSendTime睬关,由該對象的總控函數(shù)IncomingPacketInfo()負(fù)責(zé)整個碼率估計(jì)流程,如圖4所示毡证,算法從左到右依次調(diào)用子對象的功能函數(shù)电爹。</br>

總控函數(shù)首先調(diào)用InterArrival::ComputeDeltas()函數(shù),用以計(jì)算相鄰數(shù)據(jù)包組的到達(dá)時間相對延遲料睛,該部分對應(yīng)文章[1]的3.1節(jié)內(nèi)容丐箩。在計(jì)算到達(dá)時間相對延遲時,用到了RTP報(bào)文頭部擴(kuò)展abs-send-time恤煞。另外屎勘,實(shí)現(xiàn)細(xì)節(jié)上要注意數(shù)據(jù)包組的劃分,以及對亂序和突發(fā)時間的處理居扒。</br>

接下來算法調(diào)用OveruseEstimator::Update()函數(shù)概漱,用以估計(jì)數(shù)據(jù)包的網(wǎng)絡(luò)延遲,該部分對應(yīng)文章[1]的3.2節(jié)內(nèi)容苔货。對網(wǎng)絡(luò)延遲的估計(jì)用到了Kalman濾波犀概,算法的具體細(xì)節(jié)請參考文章[2]。Kalman濾波的結(jié)果為網(wǎng)絡(luò)延遲m(i)夜惭,作為下一階段網(wǎng)絡(luò)狀態(tài)檢測的輸入?yún)?shù)姻灶。</br>

算法接著調(diào)用OveruseDetector::Detect(),用來檢測當(dāng)前網(wǎng)絡(luò)的擁塞狀況诈茧,該部分對應(yīng)文章[1]的3.2節(jié)內(nèi)容产喉。網(wǎng)絡(luò)狀態(tài)檢測用當(dāng)前網(wǎng)絡(luò)延遲m(i)和閾值gamma_1進(jìn)行比較,判斷出overuse敢会,underuse和normal三種網(wǎng)絡(luò)狀態(tài)之一曾沈。在算法細(xì)節(jié)上,要注意overuse的判定相對復(fù)雜一些:當(dāng)m(i) > gamma_1時鸥昏,計(jì)算處于當(dāng)前狀態(tài)的持續(xù)時間t(ou)塞俱,如果t(ou) > gamma_2,并且m(i) > m(i-1)吏垮,則發(fā)出網(wǎng)絡(luò)過載信號Overuse障涯。如果m(i)小于m(i-1),即使高于閥值gamma_1也不需要發(fā)出過載信號膳汪。在判定網(wǎng)絡(luò)擁塞狀態(tài)之后唯蝶,還要調(diào)用UpdateThreshold()更新閾值gamma_1。</br>

算法接著調(diào)用AimdRateControl::Update()和UpdateBandwidthEstimate()函數(shù)遗嗽,用以估計(jì)當(dāng)前網(wǎng)絡(luò)狀態(tài)下的目標(biāo)碼率Ar粘我,該部分對應(yīng)文章[1]的3.3節(jié)。算法基于當(dāng)前網(wǎng)絡(luò)狀態(tài)和碼率變化趨勢有限狀態(tài)機(jī)痹换,采用AIMD(Additive Increase Multiplicative Decrease)方法計(jì)算目標(biāo)碼率征字,具體計(jì)算公式請參考文章[1]都弹。需要注意的是,當(dāng)算法處于開始階段時匙姜,會采用Multiplicative Increase方法快速增加碼率缔杉,以加快碼率估計(jì)速度。</br>

此時搁料,我們已經(jīng)拿到接收端估計(jì)的目標(biāo)碼率Ar或详。接下來以Ar為參數(shù)調(diào)用VieRemb對象的OnReceiveBitrateChange()函數(shù),發(fā)送REMB報(bào)文到發(fā)送端郭计。REMB報(bào)文會推送到RTCP模塊霸琴,并設(shè)置REMB報(bào)文發(fā)送時間為立即發(fā)送。關(guān)于REMB報(bào)文接下來的發(fā)送和接收流程昭伸,和第1節(jié)描述的RTCP報(bào)文一般處理流程是一樣的梧乘,即經(jīng)過序列化發(fā)送到網(wǎng)絡(luò),然后發(fā)送端收到以后庐杨,反序列化出描述結(jié)構(gòu)选调,最后通過回調(diào)函數(shù)到達(dá)發(fā)送端碼率控制模塊BitrateControllerImpl。</br>

至此灵份,接收端基于延遲的碼率估計(jì)過程描述完畢仁堪。</br>

4 發(fā)送端碼率計(jì)算及生效

</br>
</br>在發(fā)送端,目標(biāo)碼率計(jì)算和生效是異步進(jìn)行的填渠,即Worker線程從RTCP接收模塊經(jīng)回調(diào)函數(shù)拿到丟包率和REMB碼率之后弦聂,計(jì)算得到目標(biāo)碼率A;然后ModuleProcess線程異步把目標(biāo)碼率A生效到目標(biāo)模塊如PacedSender和ViEEncoder等氛什。下面分別描述碼率計(jì)算和生效過程莺葫。</br>

圖5 發(fā)送端碼率計(jì)算過程

碼率計(jì)算過程如圖5所示:Worker線程從RTCPReceiver模塊經(jīng)過回調(diào)函數(shù)拿到RTCP RR報(bào)文和REMB報(bào)文的數(shù)據(jù),到達(dá)BitrateController模塊枪眉。RR報(bào)文中的丟包率會進(jìn)入U(xiǎn)pdate()函數(shù)中計(jì)算碼率捺檬,碼率計(jì)算公式如文章[1]第2節(jié)所述。然后算法流程進(jìn)入CapBitrateToThreshold()函數(shù)贸铜,和配置的最大最小碼率和遠(yuǎn)端估計(jì)碼率進(jìn)行比較后堡纬,確定最終目標(biāo)碼率。而REMB報(bào)文的接收端估計(jì)碼率Ar則直接進(jìn)入CapBitrateToThreshold()函數(shù)參與目標(biāo)碼率的確定萨脑。目標(biāo)碼率由文章[1]的3.4節(jié)所示公式進(jìn)行確定隐轩。需要注意的是饺饭,RR報(bào)文和REMB報(bào)文一般不在同一個RTCP報(bào)文里渤早。</br>

圖6 發(fā)送端碼率生效過程

發(fā)送端碼率生效過程如圖6所示:ModuleProcess線程調(diào)用擁塞控制總控對象CongestionController周期性從碼率控制模塊BitrateControllerImpl中獲取當(dāng)前最新目標(biāo)碼率A,然后判斷目標(biāo)碼率是否有變化瘫俊。若是鹊杖,則把最新目標(biāo)碼率設(shè)置到相關(guān)模塊中悴灵,主要包括PacedSender模塊,RTPSender模塊和ViEEncoder模塊骂蓖。</br>

對于PacedSender模塊积瞒,設(shè)置碼率主要是為了平滑RTP數(shù)據(jù)包的發(fā)送速率,盡量避免數(shù)據(jù)包Burst造成碼率波動登下。對于RTPSender模塊茫孔,設(shè)置碼率是為了給NACK模塊預(yù)留碼率,如果預(yù)留碼率過小被芳,則在某些情況下對于NACK報(bào)文請求選擇不響應(yīng)缰贝。對于ViEEncoder模塊,設(shè)置碼率有兩個用途:1)控制發(fā)送端丟幀策略畔濒,根據(jù)設(shè)定碼率和漏桶算法決定是否丟棄當(dāng)前幀剩晴。2)控制編碼器內(nèi)部碼率控制,設(shè)定碼率作為參數(shù)傳輸?shù)骄幋a器內(nèi)部侵状,參與內(nèi)部碼率控制過程赞弥。</br>

至此,發(fā)送端碼率計(jì)算和生效過程分析完畢趣兄。</br>

5 總結(jié)

本文結(jié)合文章[1]绽左,深入WebRTC代碼內(nèi)部,詳細(xì)分析了WebRTC的GCC算法的實(shí)現(xiàn)細(xì)節(jié)艇潭。通過本文妇菱,對WebRTC的代碼結(jié)構(gòu)和擁塞控制實(shí)現(xiàn)細(xì)節(jié)有了更深層次的理解,為進(jìn)一步學(xué)習(xí)WebRTC奠定良好基礎(chǔ)暴区。</br>
</br>
</br>
</br>

參考文獻(xiàn)

[1] WebRTC基于GCC的擁塞控制(上) – 算法分析
http://www.reibang.com/p/0f7ee0e0b3be
[2] WebRTC視頻接收緩沖區(qū)基于KalmanFilter的延遲模型.
http://www.reibang.com/p/bb34995c549a
[3] WebRTC中RTP/RTCP協(xié)議實(shí)現(xiàn)分析
http://www.reibang.com/p/c84be6f3ddf3
[4] abs-send-time. https://webrtc.org/experiments/rtp-hdrext/abs-send-time/

最后編輯于
?著作權(quán)歸作者所有,轉(zhuǎn)載或內(nèi)容合作請聯(lián)系作者
禁止轉(zhuǎn)載闯团,如需轉(zhuǎn)載請通過簡信或評論聯(lián)系作者。
  • 序言:七十年代末仙粱,一起剝皮案震驚了整個濱河市房交,隨后出現(xiàn)的幾起案子,更是在濱河造成了極大的恐慌伐割,老刑警劉巖候味,帶你破解...
    沈念sama閱讀 206,214評論 6 481
  • 序言:濱河連續(xù)發(fā)生了三起死亡事件,死亡現(xiàn)場離奇詭異隔心,居然都是意外死亡白群,警方通過查閱死者的電腦和手機(jī),發(fā)現(xiàn)死者居然都...
    沈念sama閱讀 88,307評論 2 382
  • 文/潘曉璐 我一進(jìn)店門硬霍,熙熙樓的掌柜王于貴愁眉苦臉地迎上來帜慢,“玉大人,你說我怎么就攤上這事×涣幔” “怎么了躬柬?”我有些...
    開封第一講書人閱讀 152,543評論 0 341
  • 文/不壞的土叔 我叫張陵,是天一觀的道長抽减。 經(jīng)常有香客問我允青,道長,這世上最難降的妖魔是什么卵沉? 我笑而不...
    開封第一講書人閱讀 55,221評論 1 279
  • 正文 為了忘掉前任颠锉,我火速辦了婚禮,結(jié)果婚禮上史汗,老公的妹妹穿的比我還像新娘木柬。我一直安慰自己,他們只是感情好淹办,可當(dāng)我...
    茶點(diǎn)故事閱讀 64,224評論 5 371
  • 文/花漫 我一把揭開白布眉枕。 她就那樣靜靜地躺著,像睡著了一般怜森。 火紅的嫁衣襯著肌膚如雪速挑。 梳的紋絲不亂的頭發(fā)上,一...
    開封第一講書人閱讀 49,007評論 1 284
  • 那天副硅,我揣著相機(jī)與錄音姥宝,去河邊找鬼。 笑死恐疲,一個胖子當(dāng)著我的面吹牛腊满,可吹牛的內(nèi)容都是我干的。 我是一名探鬼主播培己,決...
    沈念sama閱讀 38,313評論 3 399
  • 文/蒼蘭香墨 我猛地睜開眼碳蛋,長吁一口氣:“原來是場噩夢啊……” “哼!你這毒婦竟也來了省咨?” 一聲冷哼從身側(cè)響起肃弟,我...
    開封第一講書人閱讀 36,956評論 0 259
  • 序言:老撾萬榮一對情侶失蹤,失蹤者是張志新(化名)和其女友劉穎零蓉,沒想到半個月后笤受,有當(dāng)?shù)厝嗽跇淞掷锇l(fā)現(xiàn)了一具尸體,經(jīng)...
    沈念sama閱讀 43,441評論 1 300
  • 正文 獨(dú)居荒郊野嶺守林人離奇死亡敌蜂,尸身上長有42處帶血的膿包…… 初始之章·張勛 以下內(nèi)容為張勛視角 年9月15日...
    茶點(diǎn)故事閱讀 35,925評論 2 323
  • 正文 我和宋清朗相戀三年箩兽,在試婚紗的時候發(fā)現(xiàn)自己被綠了。 大學(xué)時的朋友給我發(fā)了我未婚夫和他白月光在一起吃飯的照片章喉。...
    茶點(diǎn)故事閱讀 38,018評論 1 333
  • 序言:一個原本活蹦亂跳的男人離奇死亡汗贫,死狀恐怖身坐,靈堂內(nèi)的尸體忽然破棺而出,到底是詐尸還是另有隱情芳绩,我是刑警寧澤,帶...
    沈念sama閱讀 33,685評論 4 322
  • 正文 年R本政府宣布撞反,位于F島的核電站妥色,受9級特大地震影響,放射性物質(zhì)發(fā)生泄漏遏片。R本人自食惡果不足惜嘹害,卻給世界環(huán)境...
    茶點(diǎn)故事閱讀 39,234評論 3 307
  • 文/蒙蒙 一、第九天 我趴在偏房一處隱蔽的房頂上張望吮便。 院中可真熱鬧笔呀,春花似錦、人聲如沸髓需。這莊子的主人今日做“春日...
    開封第一講書人閱讀 30,240評論 0 19
  • 文/蒼蘭香墨 我抬頭看了看天上的太陽僚匆。三九已至微渠,卻和暖如春,著一層夾襖步出監(jiān)牢的瞬間咧擂,已是汗流浹背逞盆。 一陣腳步聲響...
    開封第一講書人閱讀 31,464評論 1 261
  • 我被黑心中介騙來泰國打工, 沒想到剛下飛機(jī)就差點(diǎn)兒被人妖公主榨干…… 1. 我叫王不留松申,地道東北人云芦。 一個月前我還...
    沈念sama閱讀 45,467評論 2 352
  • 正文 我出身青樓,卻偏偏與公主長得像贸桶,于是被迫代替她去往敵國和親舅逸。 傳聞我的和親對象是個殘疾皇子,可洞房花燭夜當(dāng)晚...
    茶點(diǎn)故事閱讀 42,762評論 2 345

推薦閱讀更多精彩內(nèi)容

  • 一 前言 RTP/RTCP協(xié)議是流媒體通信的基石皇筛。RTP協(xié)議定義流媒體數(shù)據(jù)在互聯(lián)網(wǎng)上傳輸?shù)臄?shù)據(jù)包格式堡赔,而RTCP協(xié)...
    weizhenwei閱讀 33,272評論 4 47
  • 實(shí)時流媒體應(yīng)用的最大特點(diǎn)是實(shí)時性设联,而延遲是實(shí)時性的最大敵人善已。從媒體收發(fā)端來講,媒體數(shù)據(jù)的處理速度是造成延遲的重要原...
    weizhenwei閱讀 24,075評論 6 49
  • 1. 前言 在基于IP網(wǎng)絡(luò)的多媒體通信系統(tǒng)(比如WebRTC)中离例,網(wǎng)絡(luò)丟包對多媒體通信質(zhì)量有非常嚴(yán)重的影響:例如造...
    weizhenwei閱讀 19,029評論 8 39
  • 對于實(shí)時音視頻應(yīng)用來講换团,媒體數(shù)據(jù)從采集到渲染,在數(shù)據(jù)流水線上依次完成一系列處理宫蛆。流水線由不同的功能模塊組成艘包,彼此分...
    weizhenwei閱讀 11,010評論 4 29
  • 在WebRTC中的猛,前向糾錯(FEC)和丟包重傳(NACK)是抵抗網(wǎng)絡(luò)錯誤的重要手段。FEC在發(fā)送端將數(shù)據(jù)包添加冗余...
    weizhenwei閱讀 23,048評論 8 25