日本综合一区二区|亚洲中文天堂综合|日韩欧美自拍一区|男女精品天堂一区|欧美自拍第6页亚洲成人精品一区|亚洲黄色天堂一区二区成人|超碰91偷拍第一页|日韩av夜夜嗨中文字幕|久久蜜综合视频官网|精美人妻一区二区三区

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

創(chuàng)新互聯(lián)公司2013年開創(chuàng)至今，先為桂陽等服務(wù)建站，桂陽等地企業(yè)，進(jìn)行企業(yè)商務(wù)咨詢服務(wù)。為桂陽企業(yè)網(wǎng)站制作PC+手機+微官網(wǎng)三網(wǎng)同步一站式服務(wù)解決您的所有建站問題。

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

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

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

要實現(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 策略就必不可少。沒有任何一種 QoS 技術(shù)能解決所有問題，實時語音視頻傳輸機制必須是多種 QoS 技術(shù)的有機結(jié)合。

協(xié)議的選擇

如果是視頻直播 SDK，一般會選擇 RTMP 協(xié)議，因為要能夠普遍兼容 CDN 分發(fā)網(wǎng)絡(luò)，從而向圍觀的廣大用戶進(jìn)行直播。如果是音頻社交 SDK、視頻社交 SDK 或者游戲語音 SDK，一般會選擇 RTP/RTCP 協(xié)議(或者類 RTP 的私有協(xié)議)，因為不需要通過 CDN 網(wǎng)絡(luò)向圍觀用戶廣播媒體流。是否要考慮兼容 CDN 網(wǎng)絡(luò)，是語音視頻通話 SDK 和視頻直播 SDK 的重大區(qū)別。

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

TCP 協(xié)議的特點

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

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

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

UDP 協(xié)議的特點

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

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

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

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

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

信道保護(hù)

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

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

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

信道 QoS 的三大措施

前向糾錯 FEC

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

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

下面使用 RS 的一個例子來說明 FEC 編解碼算法的使用方法。

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

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

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

使用前向糾錯 FEC 算法，優(yōu)點是數(shù)據(jù)包只需要傳輸一次，傳輸延遲不會受到 RTT(Round Trip Time) 的影響，不會增加額外的延遲時間;缺點是需要增加冗余數(shù)據(jù)包，降低了傳輸信道的利用率?？偟膩碚f是一種“空間換時間”的策略。

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

丟包重傳 ARQ

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

具體地來說，發(fā)送端給每一個數(shù)據(jù)包都植入順序號碼和時間戳，順序號碼代表被發(fā)送數(shù)據(jù)包的順序，允許接收端可以通過監(jiān)測順序號碼來發(fā)現(xiàn)丟包事件;時間戳代表語音視頻數(shù)據(jù)包解碼的時間點。發(fā)送端發(fā)送數(shù)據(jù)包后，如果接收端沒有收到，接收端將會通過 RTCP/TCP 信道發(fā)送一個重傳請求。發(fā)送端維護(hù)一個緩沖隊列，當(dāng)收到重傳請求的時候?qū)貍鲾?shù)據(jù)包。接收端也會維護(hù)一個緩沖隊列，等待尚未收到的數(shù)據(jù)包以及對已經(jīng)收到的數(shù)據(jù)包進(jìn)行排序。在解碼的 deadline 到來之前，接收端把緩沖區(qū)的數(shù)據(jù)包交給解碼器進(jìn)行解碼。在解碼 deadline 的時間點，接收端要么已經(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ù)包，直到收到接收端的重傳請求。發(fā)送端除了重傳被要求重傳的數(shù)據(jù)包以外，還會把該數(shù)據(jù)包時間戳后面已經(jīng)被接收端成功接收到的一批數(shù)據(jù)包全部重傳一遍。
3. Selective Repeat ARQ，也就是選擇性重傳的 ARQ，發(fā)送端不需等待接收端的確認(rèn)，不停地發(fā)送數(shù)據(jù)包;接收端只會有選擇性地對關(guān)鍵的數(shù)據(jù)包要求重傳，而發(fā)送端只重傳被要求重傳的數(shù)據(jù)包。

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

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

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

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

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

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

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

使用選擇性重傳的 ARQ 算法，優(yōu)點是只需要有選擇性地傳輸關(guān)鍵的數(shù)據(jù)包，不會明顯增加額外的帶寬，帶寬利用率十分高;缺點是需要請求和重傳，增加了傳輸延遲時間?？偟膩碚f是一種“時間換空間”的策略。

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

FEC 和 ARQ 的特點對比

碼率自適應(yīng) ABC

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

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

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

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

錯誤隱藏 PLC

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

智能 QoS

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

混合 FEC&ARQ

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

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

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

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

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

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

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

帶寬估算

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

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

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

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

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

帶寬分配

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

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

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

下面是一個例子，展示隨著 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ù)，原始語音視頻數(shù)據(jù)所占的帶寬都要適當(dāng)犧牲。

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

結(jié)語

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

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

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

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

分享標(biāo)題：語音視頻SDK如何實現(xiàn)超低延遲優(yōu)化？
文章鏈接：http://www.dlmjj.cn/article/dhshcip.html