要在語(yǔ)音視頻 SDK 中實(shí)現(xiàn)超低延遲，實(shí)時(shí)的語(yǔ)音視頻傳輸機(jī)制是必不可少的，而 FEC 和 ARQ 的智能結(jié)合是實(shí)時(shí)語(yǔ)音視頻傳輸機(jī)制的基石。

在語(yǔ)音社交、視頻社交、游戲語(yǔ)音和互動(dòng)直播等領(lǐng)域，關(guān)于在語(yǔ)音視頻實(shí)時(shí)傳輸中實(shí)現(xiàn)低延遲這個(gè)議題，已經(jīng)有不少的文章提出各種方案。絕大部分方案的思路都是“優(yōu)化”，比如說(shuō)，優(yōu)化編碼、推流、傳輸和播放等各個(gè)環(huán)節(jié)。

愚以為，要在實(shí)時(shí)語(yǔ)音視頻傳輸中獲得超低延遲，是不能單靠挖空心思去“優(yōu)化”的，而是要依靠實(shí)時(shí)的傳輸機(jī)制。就像高鐵和火車(chē)有著本質(zhì)的區(qū)別一樣，火車(chē)不管如何優(yōu)化，也只是跑得更快的火車(chē)，永遠(yuǎn)達(dá)不到高鐵的速度。沒(méi)有一套實(shí)時(shí)的傳輸機(jī)制，再怎么在各個(gè)環(huán)節(jié)“優(yōu)化”，也無(wú)法獲得真正超低的延遲。

即構(gòu)的實(shí)時(shí)語(yǔ)音視頻通訊架構(gòu)圖

要實(shí)現(xiàn)超低延遲，信道 QoS 十分關(guān)鍵。首先要選擇合適的網(wǎng)絡(luò)傳輸協(xié)議，采用基于 UDP 的私有協(xié)議還是標(biāo)準(zhǔn) RTMP 協(xié)議?然后根據(jù)網(wǎng)絡(luò)環(huán)境采用合適的 QoS 技術(shù)，采用 FEC，ARQ，還是雙管齊下? 如果采用 FEC 和 ARQ 雙管齊下，那么一套智能的 QoS 策略就必不可少。沒(méi)有任何一種 QoS 技術(shù)能解決所有問(wèn)題，實(shí)時(shí)語(yǔ)音視頻傳輸機(jī)制必須是多種 QoS 技術(shù)的有機(jī)結(jié)合。

協(xié)議的選擇

如果是視頻直播 SDK，一般會(huì)選擇 RTMP 協(xié)議，因?yàn)橐軌蚱毡榧嫒?CDN 分發(fā)網(wǎng)絡(luò)，從而向圍觀的廣大用戶(hù)進(jìn)行直播。如果是音頻社交 SDK、視頻社交 SDK 或者游戲語(yǔ)音 SDK，一般會(huì)選擇 RTP/RTCP 協(xié)議(或者類(lèi) RTP 的私有協(xié)議)，因?yàn)椴恍枰ㄟ^(guò) CDN 網(wǎng)絡(luò)向圍觀用戶(hù)廣播媒體流。是否要考慮兼容 CDN 網(wǎng)絡(luò)，是語(yǔ)音視頻通話(huà) SDK 和視頻直播 SDK 的重大區(qū)別。

RTMP 協(xié)議是基于 TCP 協(xié)議的，RTP 協(xié)議或者私有協(xié)議是基于 UDP 協(xié)議的，因此 RTMP 協(xié)議和 RTP 協(xié)議之爭(zhēng)，本質(zhì)就是 TCP 協(xié)議和 UDP 協(xié)議之爭(zhēng)。

TCP 協(xié)議的特點(diǎn)

1) 是通用的 IP 網(wǎng)絡(luò)協(xié)議，不是為實(shí)時(shí)媒體傳輸而設(shè)計(jì)的，在弱網(wǎng)網(wǎng)絡(luò)環(huán)境下延遲會(huì)增大。

2) 有內(nèi)嵌的 ARQ，但沒(méi)有 FEC，不允許開(kāi)發(fā)者對(duì) ARQ 策略進(jìn)行控制，不能實(shí)現(xiàn) FEC。

3) 不是從實(shí)時(shí)語(yǔ)音視頻的角度進(jìn)行設(shè)計(jì)的，更多考慮網(wǎng)絡(luò)傳輸?shù)墓叫裕瑑?nèi)嵌的傳輸控制策略比較溫和。

UDP 協(xié)議的特點(diǎn)

1) 適合實(shí)時(shí)語(yǔ)音視頻通訊，允許端到端全鏈條進(jìn)行信道策略控制，在弱網(wǎng)環(huán)境下可控性更強(qiáng)。

2) 延遲時(shí)間的大小取決于丟包時(shí)候的 ARQ 和 FEC 策略，允許開(kāi)發(fā)者深度控制 ARQ 和 FEC 策略。

3) 適合設(shè)計(jì)實(shí)時(shí)語(yǔ)音視頻的通訊機(jī)制，根據(jù)網(wǎng)絡(luò)狀況自適應(yīng)地選取 ARQ 和 FEC 策略，以及調(diào)整傳輸碼率和報(bào)文的數(shù)量。

在網(wǎng)絡(luò)環(huán)境好的情況下，只要語(yǔ)音視頻編解碼器相同，RTMP 協(xié)議和基于 UDP 的私有協(xié)議的傳輸效率是相當(dāng)?shù)模伎梢詫?shí)現(xiàn)低延遲、不卡頓和高品質(zhì)的實(shí)時(shí)通訊效果。

在網(wǎng)絡(luò)環(huán)境較差的情況下，特別是在跨網(wǎng)甚至跨國(guó)的情況下，基于 UDP 的私有協(xié)議對(duì)端到端全鏈條可控，包括流控碼控、ARQ、FEC 和抖動(dòng)緩沖等，對(duì)抗惡劣網(wǎng)絡(luò)環(huán)境會(huì)更有保障。

信道保護(hù)

IP 網(wǎng)絡(luò)是“盡力而為”地提供數(shù)據(jù)傳輸服務(wù)的，盡最大的可能性來(lái)發(fā)送報(bào)文，但對(duì)時(shí)延、可靠性等性能概不負(fù)責(zé)效果，傳輸?shù)臄?shù)據(jù)出錯(cuò)是避免不了的，因此對(duì)信道進(jìn)行保護(hù)是必須的。

信道 QoS 技術(shù)主要包括前向糾錯(cuò) FEC，丟包重傳 ARQ 和混合型 ARQ。這幾種算法都是成熟的技術(shù)，在最基礎(chǔ)的算法上又衍生出多個(gè)變種，而且在實(shí)現(xiàn)的過(guò)程中也可以進(jìn)行定制化。

在 FEC 和 ARQ 的基礎(chǔ)上，為了更好地適應(yīng)弱網(wǎng)環(huán)境，需要讓碼率自動(dòng)適應(yīng)網(wǎng)絡(luò)環(huán)境的波動(dòng)，這樣能夠更好地保障實(shí)時(shí)語(yǔ)音視頻通話(huà)的可用性和流暢性。

信道 QoS 的三大措施

前向糾錯(cuò) FEC

FEC 全稱(chēng)是 Forward Error Correction，中文翻譯為前向糾錯(cuò)，是一種通過(guò)增加冗余數(shù)據(jù)對(duì)丟失的數(shù)據(jù)包進(jìn)行恢復(fù)的信道編碼算法。具體地說(shuō)，由發(fā)送端對(duì)原始數(shù)據(jù)進(jìn)行 FEC 編碼，生成冗余奇偶校驗(yàn)數(shù)據(jù)包，原始數(shù)據(jù)和冗余數(shù)據(jù)包合并稱(chēng)作 FEC 數(shù)據(jù)塊，原始數(shù)據(jù)包和冗余數(shù)據(jù)包的數(shù)量比例是固定的。發(fā)送端發(fā)送 FEC 數(shù)據(jù)塊。接收端接收到 FEC 數(shù)據(jù)塊后，通過(guò)冗余數(shù)據(jù)包和原始數(shù)據(jù)包來(lái)恢復(fù)出丟失或者出錯(cuò)的數(shù)據(jù)包。

FEC 編解碼算法推薦使用比較成熟的 RS(Reeds-Solomon) 算法、Raptor 算法和 Tornado 算法。使用 FEC 編碼算法的時(shí)候要根據(jù)丟包率(PLR, Packet Lost Rate)來(lái)設(shè)置冗余度。

下面使用 RS 的一個(gè)例子來(lái)說(shuō)明 FEC 編解碼算法的使用方法。

因?yàn)樵谝粋€(gè) FEC 數(shù)據(jù)塊中，原始數(shù)據(jù)包的個(gè)數(shù)和冗余數(shù)據(jù)包的個(gè)數(shù)的比例是固定的，所以很容易根據(jù)丟包的個(gè)數(shù)和冗余包的個(gè)數(shù)來(lái)判斷是否能夠全部恢復(fù)丟失的數(shù)據(jù)包。RS (n, k) 表示通過(guò) RS 算法把 k 個(gè)原始數(shù)據(jù)包進(jìn)行編碼，生成(n-k)個(gè)冗余數(shù)據(jù)包，總共是一個(gè)包含有 n 個(gè)數(shù)據(jù)包的 FEC 數(shù)據(jù)塊。假設(shè)丟失了 m 個(gè)數(shù)據(jù)包，如果 m<=(n-k)，那么 RS 算法可以完全恢復(fù)丟失的數(shù)據(jù)包;如果 m>(n-k)，那么 RS 算法就無(wú)法恢復(fù)丟失的數(shù)據(jù)包，這時(shí)候就要進(jìn)行發(fā)送請(qǐng)求要求重傳丟失的數(shù)據(jù)包。

下圖展示了通過(guò) RS(6，4) 進(jìn)行丟包恢復(fù)的過(guò)程。發(fā)送端有 4 個(gè)原始數(shù)據(jù)包，通過(guò) RS 算法編碼生成 2 個(gè)冗余包，形成了一個(gè)擁有 6 個(gè)數(shù)據(jù)包的 FEC 數(shù)據(jù)塊。RS 算法最多能夠恢復(fù) 2 個(gè)丟失的數(shù)據(jù)包。發(fā)送端把 FEC 數(shù)據(jù)塊發(fā)出去，在傳輸過(guò)程中第 2 號(hào)原始數(shù)據(jù)包丟失了。接收端接收到 FEC 數(shù)據(jù)塊以后，通過(guò) r1 冗余包把已經(jīng)丟失的第 2 號(hào)原始數(shù)據(jù)包恢復(fù)出來(lái)。

RS(6，4) 算法恢復(fù)出丟失的數(shù)據(jù)包

使用前向糾錯(cuò) FEC 算法，優(yōu)點(diǎn)是數(shù)據(jù)包只需要傳輸一次，傳輸延遲不會(huì)受到 RTT(Round Trip Time) 的影響，不會(huì)增加額外的延遲時(shí)間;缺點(diǎn)是需要增加冗余數(shù)據(jù)包，降低了傳輸信道的利用率。總的來(lái)說(shuō)是一種“空間換時(shí)間”的策略。

下文將會(huì)綜合對(duì) FEC 和 ARQ 的特點(diǎn)進(jìn)行全面對(duì)比。

丟包重傳 ARQ

ARQ 全稱(chēng) Automatic Repeat reQuest，中文意譯為丟包重傳，是一種通過(guò)重傳關(guān)鍵數(shù)據(jù)包來(lái)糾錯(cuò)的信道保護(hù)算法。

具體地來(lái)說(shuō)，發(fā)送端給每一個(gè)數(shù)據(jù)包都植入順序號(hào)碼和時(shí)間戳，順序號(hào)碼代表被發(fā)送數(shù)據(jù)包的順序，允許接收端可以通過(guò)監(jiān)測(cè)順序號(hào)碼來(lái)發(fā)現(xiàn)丟包事件;時(shí)間戳代表語(yǔ)音視頻數(shù)據(jù)包解碼的時(shí)間點(diǎn)。發(fā)送端發(fā)送數(shù)據(jù)包后，如果接收端沒(méi)有收到，接收端將會(huì)通過(guò) RTCP/TCP 信道發(fā)送一個(gè)重傳請(qǐng)求。發(fā)送端維護(hù)一個(gè)緩沖隊(duì)列，當(dāng)收到重傳請(qǐng)求的時(shí)候?qū)?huì)重傳數(shù)據(jù)包。接收端也會(huì)維護(hù)一個(gè)緩沖隊(duì)列，等待尚未收到的數(shù)據(jù)包以及對(duì)已經(jīng)收到的數(shù)據(jù)包進(jìn)行排序。在解碼的 deadline 到來(lái)之前，接收端把緩沖區(qū)的數(shù)據(jù)包交給解碼器進(jìn)行解碼。在解碼 deadline 的時(shí)間點(diǎn)，接收端要么已經(jīng)收齊了預(yù)期的數(shù)據(jù)包，要么已經(jīng)決定放棄繼續(xù)等待。

傳統(tǒng)的丟包重傳 ARQ 包括以下三種：

1. Stop-and-wait ARQ，也就是停止等待的 ARQ，發(fā)送端發(fā)送數(shù)據(jù)包后就停止并等待接收端的確認(rèn)消息，在收到確認(rèn)消息之前，信道處于空閑狀態(tài)。
2. Go-Back-N ARQ, 也就是退回 N 步的 ARQ，發(fā)送端不需等待接收端的確認(rèn)，不停地發(fā)送數(shù)據(jù)包，直到收到接收端的重傳請(qǐng)求。發(fā)送端除了重傳被要求重傳的數(shù)據(jù)包以外，還會(huì)把該數(shù)據(jù)包時(shí)間戳后面已經(jīng)被接收端成功接收到的一批數(shù)據(jù)包全部重傳一遍。
3. Selective Repeat ARQ，也就是選擇性重傳的 ARQ，發(fā)送端不需等待接收端的確認(rèn)，不停地發(fā)送數(shù)據(jù)包;接收端只會(huì)有選擇性地對(duì)關(guān)鍵的數(shù)據(jù)包要求重傳，而發(fā)送端只重傳被要求重傳的數(shù)據(jù)包。

第一種和第二種 ARQ 效率比較低下，第三種 ARQ 相對(duì)來(lái)說(shuō)效率比較高。目前主流的丟包重傳算法大部分是第三種 ARQ 的變種或者定制化版本。

選擇性重傳 ARQ 的優(yōu)越性在于它能確定哪些關(guān)鍵的數(shù)據(jù)包需要重傳，從而大大地提高重傳的效率，降低造成重傳風(fēng)暴的風(fēng)險(xiǎn)。比如說(shuō)，在出現(xiàn)花屏的時(shí)候，請(qǐng)求發(fā)送端立即編碼視頻關(guān)鍵幀發(fā)送過(guò)來(lái)，避免長(zhǎng)時(shí)間花屏無(wú)法刷新的現(xiàn)象。選擇要重傳的數(shù)據(jù)包的算法十分關(guān)鍵，這里必須要有比較謹(jǐn)慎的策略，不能任何丟失的數(shù)據(jù)包都要求重傳，那樣就相當(dāng)于又走了 TCP 協(xié)議內(nèi)嵌 ARQ 模塊的老路，必然引入不可控的延時(shí)。

選擇性重傳的 ARQ 要考慮實(shí)時(shí)性，要估算計(jì)劃要重傳數(shù)據(jù)包到達(dá)的時(shí)間(以 RTT 的倍數(shù)來(lái)估算)，如果數(shù)據(jù)包預(yù)期的到達(dá)時(shí)間在解碼的 deadline 之前，就要求重傳，如果在 deadline 之后，就放棄重傳。下面通過(guò)一個(gè)例子來(lái)說(shuō)明選擇性重傳的 ARQ 這個(gè)實(shí)時(shí)策略。

下圖展示了選擇性重傳的 ARQ 的實(shí)時(shí)策略：

1. 發(fā)送端發(fā)送 #1、#2 和 #3 三個(gè)數(shù)據(jù)包，數(shù)據(jù)包 #2 丟失了;
2. N 倍 RTT<數(shù)據(jù)包 #2 解碼 deadline, N=2，判斷可以接受重傳 2 次;
3. 接收端通過(guò) RTCP/TCP 信道請(qǐng)求重傳;
4. 發(fā)送端重傳，數(shù)據(jù)包 #2 再次丟失;
5. 接收端通過(guò) RTCP/TCP 信道請(qǐng)求重傳;
6. 發(fā)送端重傳，數(shù)據(jù)包 #2 成功到達(dá);
7. 接收端把 #1、#2 和 #3 三個(gè)數(shù)據(jù)包排序，交給解碼器解碼。

選擇性重傳 ARQ 考慮 RTT 和編碼 deadline 等實(shí)時(shí)因素

如果在 2 次以?xún)?nèi)能重傳成功，那么就可以縮短接收端的緩沖時(shí)間，在解碼 deadline 之前把數(shù)據(jù)包排序并交給解碼器解碼。如果在 2 次內(nèi)不能重傳成功，那么就放棄繼續(xù)重傳。因此，接收端總能維持解碼的時(shí)間 t<= 解碼 deadline，維持了傳輸?shù)膶?shí)時(shí)性。

使用選擇性重傳的 ARQ 算法，優(yōu)點(diǎn)是只需要有選擇性地傳輸關(guān)鍵的數(shù)據(jù)包，不會(huì)明顯增加額外的帶寬，帶寬利用率十分高;缺點(diǎn)是需要請(qǐng)求和重傳，增加了傳輸延遲時(shí)間。總的來(lái)說(shuō)是一種“時(shí)間換空間”的策略。

下表對(duì) FEC 和 ARQ 的特點(diǎn)進(jìn)行綜合對(duì)比。

FEC 和 ARQ 的特點(diǎn)對(duì)比

碼率自適應(yīng) ABC

ABC 全稱(chēng) Adaptive Bit-rate Control，中文意譯為碼率自適應(yīng)，是服務(wù)端和推流端協(xié)作控制碼率來(lái)自動(dòng)適應(yīng)網(wǎng)絡(luò)環(huán)境變化的技術(shù)。碼率自適應(yīng)的目的是為了對(duì)抗弱網(wǎng)環(huán)境。在網(wǎng)絡(luò)好的情況下，適當(dāng)提高碼率，提高語(yǔ)音視頻的質(zhì)量和降低延遲;在網(wǎng)絡(luò)差的情況下，適當(dāng)降低碼率，保障語(yǔ)音視頻通話(huà)的可用性和流暢性，適當(dāng)犧牲音畫(huà)質(zhì)量。

碼率自適應(yīng)包含了帶寬估算和碼率控制：

1. 帶寬估算，服務(wù)端和推流端協(xié)作完成，推流端把網(wǎng)絡(luò)環(huán)境統(tǒng)計(jì)信息上報(bào)給服務(wù)端，服務(wù)端通過(guò)帶寬估算算法估計(jì)出當(dāng)前帶寬。
2. 推流端按照估算出來(lái)的帶寬進(jìn)行推流，如果網(wǎng)絡(luò)情況良好(沒(méi)有檢測(cè)到網(wǎng)絡(luò)擁塞)則持續(xù)的地提高碼率，試探網(wǎng)絡(luò)帶寬的上限，直到出現(xiàn)網(wǎng)絡(luò)擁塞為止。
3. 當(dāng)網(wǎng)絡(luò)擁塞出現(xiàn)的時(shí)候，推流端降低碼率來(lái)保障可用性和流暢性，直到網(wǎng)絡(luò)擁塞緩解為止。
4. 當(dāng)網(wǎng)絡(luò)擁塞緩解的時(shí)候，轉(zhuǎn)到 #2。

整個(gè)過(guò)程可以類(lèi)比成駕駛汽車(chē)過(guò)程中控制方向盤(pán)的方法，偏左了就往右邊調(diào)整一點(diǎn)，偏右了就往左邊調(diào)整一點(diǎn)，來(lái)來(lái)回回的微調(diào)讓駕駛處于安全和順暢的狀態(tài)。碼率自適應(yīng)也是一樣的道理。

錯(cuò)誤隱藏 PLC

PLC 全稱(chēng) Packet Lost Concealment, 意譯為錯(cuò)誤隱藏，應(yīng)用于實(shí)時(shí)語(yǔ)音通話(huà)的場(chǎng)景。語(yǔ)音數(shù)據(jù)包的丟失會(huì)造成語(yǔ)音的歪曲。為了減少語(yǔ)音數(shù)據(jù)包丟失造成對(duì)語(yǔ)音通話(huà)質(zhì)量的傷害，錯(cuò)誤隱藏 PLC 算法通過(guò)前一個(gè)語(yǔ)音數(shù)據(jù)包和后一個(gè)語(yǔ)音數(shù)據(jù)包的相關(guān)性來(lái)“推測(cè)出”當(dāng)前丟失的語(yǔ)音數(shù)據(jù)包，從而“隱藏”了信道傳輸所造成的錯(cuò)誤。錯(cuò)誤隱藏 PLC 算法在接收端進(jìn)行，不需要發(fā)送端參與。

智能 QoS

上面介紹了信道保護(hù)的各種 QoS 算法。沒(méi)有哪一種算法能夠解決所有問(wèn)題，也不是把所有算法一起混著用就能實(shí)現(xiàn)通訊機(jī)制。如何綜合使用這些算法對(duì)信道進(jìn)行保護(hù)從而達(dá)到實(shí)時(shí)的效果?這里需要一套智能的 QoS 策略，既要能對(duì)抗網(wǎng)絡(luò)損傷，又要能保持媒體數(shù)據(jù)傳輸?shù)膶?shí)時(shí)性。

混合 FEC&ARQ

FEC 和 ARQ 各有各的優(yōu)點(diǎn)和缺點(diǎn)。FEC 雖然不會(huì)增加額外的延遲，但是會(huì)增加額外的帶寬成本。ARQ 雖然算法相對(duì)簡(jiǎn)單而且?guī)缀醪辉黾訋挸杀?，但是?huì)增加額外的延遲。因此，一般的做法是把 FEC 和 ARQ 混著通過(guò)智能的策略來(lái)使用，也就是混合型 HARQ(Hybrid ARQ)。

混合型 HARQ 的智能策略要充分考慮網(wǎng)絡(luò)情況，也就是要根據(jù) RTT 和 PLR 的數(shù)值來(lái)智能地決定使用 FEC 還是 ARQ，還是兩者一起使用，哪個(gè)用多一點(diǎn)哪個(gè)用少一點(diǎn)?

下圖是筆者和團(tuán)隊(duì)在工作經(jīng)驗(yàn)中總結(jié)，僅供參考。

即構(gòu)的智能 HARQ 策略

上圖中有三塊區(qū)域，代表兩個(gè)極端情形和一個(gè)中間情形：

1. 較弱網(wǎng)絡(luò)的極端情形：在 RTT>250ms 或者 PLR>10%， 網(wǎng)絡(luò)延遲特別大或者丟包率特別高的情況下(藍(lán)白色區(qū)域)，不使用 ARQ 而使用 FEC，因?yàn)樵谘舆t大或者丟包多的弱網(wǎng)情況下，ARQ 可能會(huì)進(jìn)一步加大延遲。
2. 較好網(wǎng)絡(luò)的極端情形：在 RTT<70ms 或者 PLR<3%，網(wǎng)絡(luò)延遲很小并且丟包率比較低的情況下(深藍(lán)色區(qū)域)，適合使用 ARQ，如果對(duì)成本不敏感，可以適當(dāng)使用 FEC。
3. 中間的情形：在 (RTT<=250ms 而且 PLR<=10%) 的前提下，RTT>=70ms 或者 PLR>=3% 的情況，可以根據(jù)成本和體驗(yàn)的考慮，智能地選擇使用 FEC 和 ARQ 的權(quán)重。

語(yǔ)音數(shù)據(jù)可以適當(dāng)?shù)赝ㄟ^(guò) PLC 來(lái)恢復(fù)，可以減低延遲時(shí)間和帶寬成本。另外，由于語(yǔ)音數(shù)據(jù)比起視頻數(shù)據(jù)小好多，與其通過(guò) FEC 和 ARQ 復(fù)雜的算法處理，還不如在適當(dāng)?shù)木W(wǎng)絡(luò)情況下，在一定的時(shí)間間隔內(nèi)發(fā)送兩次同樣的語(yǔ)音數(shù)據(jù)包，從而達(dá)到用冗余數(shù)據(jù)糾錯(cuò)的效果。

帶寬估算

無(wú)論是碼率自適應(yīng)、FEC 還是 ARQ，都要依賴(lài)帶寬估算算法來(lái)工作。碼率自適應(yīng)根據(jù)帶寬估算的結(jié)果來(lái)自動(dòng)調(diào)節(jié)碼率;FEC 和 ARQ 根據(jù)帶寬估算的結(jié)果來(lái)分配冗余數(shù)據(jù)所占的帶寬。

發(fā)送端和服務(wù)端協(xié)同對(duì)網(wǎng)絡(luò)帶寬進(jìn)行檢測(cè)和估算，發(fā)送端把網(wǎng)絡(luò)帶寬的統(tǒng)計(jì)信息上報(bào)給服務(wù)端，服務(wù)端把網(wǎng)絡(luò)帶寬的估算結(jié)果反饋給發(fā)送端。當(dāng)然，也可以完全在推送端進(jìn)行帶寬估算。

除了帶寬估算以外，網(wǎng)絡(luò)擁塞探測(cè)對(duì)碼率自適應(yīng)也十分關(guān)鍵。比較傳統(tǒng)的網(wǎng)絡(luò)擁塞探測(cè)算法是根據(jù)網(wǎng)絡(luò)丟包率來(lái)探測(cè)網(wǎng)絡(luò)擁塞的。然而，當(dāng)發(fā)生較大規(guī)模丟包的時(shí)候才提示網(wǎng)絡(luò)擁塞，網(wǎng)絡(luò)擁塞已經(jīng)發(fā)生了，這時(shí)候才來(lái)調(diào)整碼率已經(jīng)太晚了。

拿地震預(yù)報(bào)舉例子。如果等到發(fā)現(xiàn)桌子電燈搖晃的時(shí)候才“預(yù)報(bào)”說(shuō)有地震，“預(yù)報(bào)”的時(shí)機(jī)太晚了。如果發(fā)現(xiàn)老鼠或者飛禽逃走等異常情況，或者探測(cè)到地震波，就真正做到預(yù)報(bào)地震。

現(xiàn)代的網(wǎng)絡(luò)擁塞算法也是力求做到預(yù)報(bào)擁塞的效果。一般的做法是，發(fā)送端發(fā)送一些探測(cè)數(shù)據(jù)包，接收端監(jiān)控?cái)?shù)據(jù)包的延遲時(shí)間和緩沖隊(duì)列長(zhǎng)度。當(dāng)探測(cè)數(shù)據(jù)包經(jīng)過(guò)網(wǎng)絡(luò)擁塞節(jié)點(diǎn)的時(shí)候，延遲時(shí)間會(huì)變長(zhǎng)而且不穩(wěn)定。如果發(fā)現(xiàn)探測(cè)數(shù)據(jù)包的延遲時(shí)間變大或者出現(xiàn)異常波動(dòng)，或者緩沖隊(duì)列變長(zhǎng)了，那么網(wǎng)絡(luò)擁塞很可能將要出現(xiàn)，相應(yīng)地可以降低碼率來(lái)適應(yīng)網(wǎng)絡(luò)情況的變化。另外，也有通過(guò)濾波器來(lái)進(jìn)行網(wǎng)絡(luò)擁塞預(yù)測(cè)，當(dāng)濾波器的某些特征超過(guò)一定的閾值，就預(yù)示網(wǎng)絡(luò)擁塞將要發(fā)生。

帶寬分配

碼率自適應(yīng) ABC 模塊估算出帶寬以后，發(fā)送端把帶寬分配給原始數(shù)據(jù)包、FEC 校驗(yàn)包和 ARQ 重傳包，這里需要一個(gè)智能的帶寬分配策略。帶寬分配策略是根據(jù)網(wǎng)絡(luò)情況，包括 RTT 和 PLR 等因素，來(lái)給原始數(shù)據(jù)包和冗余數(shù)據(jù)包分配帶寬。冗余數(shù)據(jù)包的帶寬分配得越多，QoS 信道保護(hù)算法的糾錯(cuò)能力就越強(qiáng)，然而原始數(shù)據(jù)包就相應(yīng)分配得越少，語(yǔ)音視頻的質(zhì)量也就相對(duì)降低。相對(duì)而言，冗余數(shù)據(jù)包的帶寬分配得越少，QoS 信道保護(hù)算法的糾錯(cuò)能力就越弱，然而原始數(shù)據(jù)包的帶寬分配越多，語(yǔ)音視頻的質(zhì)量也就相對(duì)得到保障。因此，智能的帶寬分配策略是要在語(yǔ)音視頻的質(zhì)量和 QoS 信道保護(hù)算法的糾錯(cuò)能力之間尋找平衡點(diǎn)。

一般來(lái)說(shuō)，帶寬分配的策略可以按照下面的方法進(jìn)行：

1. 總共的帶寬由碼率自適應(yīng) ABC 模塊估算得出;
2. 丟包重傳 ARQ 的重傳數(shù)據(jù)包所占帶寬根據(jù) RTT 和 PLR 估算得出;
3. 前向糾錯(cuò) FEC 的校驗(yàn)數(shù)據(jù)包所占帶寬根據(jù) RTT，ARQ 恢復(fù)后的 PLR，和總共的帶寬估算得出;
4. 原始數(shù)據(jù)包所占的帶寬根據(jù) ARQ、FEC 和總共的帶寬計(jì)算得出。

下面是一個(gè)例子，展示隨著 RTT 和 PLR 的增加，如何在原始數(shù)據(jù)包、ARQ 和 FEC 之間分配帶寬。

智能的帶寬分配策略示例

上圖中左邊的坐標(biāo)系中，縱坐標(biāo)是帶寬，橫坐標(biāo)是 RTT。在 RTT 比較小的網(wǎng)絡(luò)情況下，ARQ 分配的帶寬比較多，不采用 FEC;在 RTT 比較大的情況下，F(xiàn)EC 分配的帶寬比較多，不采用 ARQ。不管使用 ARQ 還是 FEC 冗余數(shù)據(jù)包進(jìn)行信道保護(hù)，原始語(yǔ)音視頻數(shù)據(jù)所占的帶寬都要適當(dāng)犧牲。

上圖中右邊的坐標(biāo)系中，縱坐標(biāo)是帶寬，橫坐標(biāo)是 PLR。在 PLR 比較小的網(wǎng)絡(luò)情況下，ARQ 和 FEC 冗余包分配的帶寬都比較小，甚至沒(méi)有;在 PLR 比較大的網(wǎng)絡(luò)情況下，逐漸給 ARQ 和 FEC 增加帶寬來(lái)增強(qiáng)數(shù)據(jù)糾錯(cuò)能力，原始語(yǔ)音視頻數(shù)據(jù)所占的帶寬也相應(yīng)降低。

結(jié)語(yǔ)

實(shí)時(shí)語(yǔ)音視頻通話(huà)要獲得超低延遲，不能僅僅依靠在各個(gè)環(huán)節(jié)不斷地優(yōu)化，而是要通過(guò) FEC、ARQ 和碼率自適應(yīng)構(gòu)建實(shí)時(shí)通訊機(jī)制。在這個(gè)基礎(chǔ)上，還要充分考慮網(wǎng)絡(luò)情況、實(shí)時(shí)要求和成本因素，以及需要大量經(jīng)驗(yàn)數(shù)據(jù)的支撐(比如說(shuō)，PLR 和 RTT 的關(guān)鍵閾值等)。要比較妥善的做到上面的要求，對(duì)語(yǔ)音視頻技術(shù)團(tuán)隊(duì)絕對(duì)是一個(gè)嚴(yán)峻的考驗(yàn)。如果要選擇第三方的語(yǔ)音視頻 SDK, 上述的技術(shù)要求也可以成為語(yǔ)音視頻 SDK 的選型標(biāo)準(zhǔn)。

作者簡(jiǎn)介：冼牛，即構(gòu)科技資深語(yǔ)音視頻專(zhuān)家，北京郵電大學(xué)計(jì)算機(jī)碩士，香港大學(xué)工商管理碩士，多年從事語(yǔ)音視頻云服務(wù)技術(shù)研究，專(zhuān)注互動(dòng)直播技術(shù)、語(yǔ)音視頻社交和實(shí)時(shí)游戲語(yǔ)音。

【本文為51CTO專(zhuān)欄作者“冼牛”原創(chuàng)稿件，轉(zhuǎn)載請(qǐng)聯(lián)系原作者(微信號(hào)：xianniu1216)】

戳這里，看該作者更多好文