關(guān)于線上抓娃娃機(jī)的架構(gòu)設(shè)計(jì)問題，宇眾網(wǎng)絡(luò)高防服務(wù)器租用，183.2.236.1惠州單雙線服務(wù)器首選！??！

從直播在線上抓娃娃，不斷變化的是玩法的創(chuàng)新，始終不變的是對(duì)超低延遲的苛求。實(shí)時(shí)架構(gòu)是超低延遲的基石，如何在信源編碼、信道編碼和實(shí)時(shí)傳輸整個(gè)鏈條來構(gòu)建實(shí)時(shí)架構(gòu)？在實(shí)時(shí)架構(gòu)的基礎(chǔ)之上，如果通過優(yōu)化采集、編碼、傳輸、解碼和渲染中的關(guān)鍵環(huán)節(jié)來降低延遲？本文將會(huì)介紹即構(gòu)在這方面的思考與實(shí)踐。

從直播到線上抓娃娃

圖 1

圖 1 展示了實(shí)時(shí)音視頻兩種不同的應(yīng)用場(chǎng)景——連麥互動(dòng)直播和線上娃娃機(jī)。雖然這兩種都是互動(dòng)，但是對(duì)于實(shí)時(shí)音視頻的要求卻不同。第一個(gè)實(shí)時(shí)連麥?zhǔn)钦Z(yǔ)音視頻流的互動(dòng)，例如其中一個(gè)說了一句話，另外一個(gè)人聽到了，再回復(fù)一句話，這個(gè)實(shí)時(shí)性只是對(duì)語(yǔ)音視頻流的實(shí)時(shí)性要求很高。而第二種線上抓娃娃則對(duì)信令的延遲提出了更高的要求，操縱者無(wú)需說話，看到的是娃娃機(jī)傳回來的視頻流結(jié)果。

如果考量互動(dòng)直播是用實(shí)時(shí)音視頻的延遲，那么線上抓娃娃則是用信令和視頻流的延時(shí)。隨著時(shí)代的發(fā)展，我們對(duì)實(shí)時(shí)語(yǔ)音視頻的定義會(huì)慢慢有一些不同，將來可能還有更多的因素需要考慮。

圖 2

圖 2 是即構(gòu)互動(dòng)直播的實(shí)時(shí)架構(gòu)圖，我們把互動(dòng)直播分為兩部分，一個(gè)是主播側(cè)，需要更低的延遲，另一側(cè)是普通觀眾，對(duì)延時(shí)不太敏感，但對(duì)流暢性敏感，中間通過一些旁路的服務(wù)把這兩個(gè)集群（一個(gè)集群叫超低延遲集群，另外一個(gè)集群叫圍觀集群）連接起來。

在超低延時(shí)部分，我們提供的服務(wù)包括流狀態(tài)更新、房間管理等，以及一些流媒體服務(wù)，主要起到分發(fā)的作用。我們通過超低延遲服務(wù)器集群（和觀眾側(cè)不太一樣），提供實(shí)時(shí)分發(fā)的功能。

此外還提供了動(dòng)態(tài)調(diào)度的服務(wù)，幫助我們?cè)诂F(xiàn)有的資源網(wǎng)絡(luò)上找到更好的鏈路。后面的觀眾集群是另外一個(gè)集群，把它們分開是出于一些業(yè)務(wù)方和我們自己成本上的考慮，另外會(huì)提供存儲(chǔ)、PCB 加速、分發(fā)的功能。

★如有服務(wù)器租用可咨詢宇眾臨風(fēng)，QQ：2850293179   Tel：15999932452  服務(wù)器租用價(jià)格列表

中間的旁路服務(wù)包括混流、轉(zhuǎn)格式（主要是轉(zhuǎn)碼）、轉(zhuǎn)協(xié)議等。為什么要混流？舉一個(gè)比較簡(jiǎn)單的例子。當(dāng)主播一側(cè)有 9 個(gè)人連麥，如果沒有混流服務(wù)，觀眾端就會(huì)同時(shí)拉 9 路音視頻，這樣對(duì)帶寬壓力很大。

普通觀眾是通過圍觀服務(wù)器集群（延遲相對(duì)大的集群）去拉這些流的，這個(gè)集群的延遲可控性相對(duì)比較弱，有可能會(huì)出現(xiàn)這 9 路畫面之間的不同步現(xiàn)象，通過混流服務(wù)，觀眾拉的都是合成好的音視頻流，就不會(huì)出現(xiàn)各路流之間的不同步問題。

還有轉(zhuǎn)格式轉(zhuǎn)碼的服務(wù)，前面集群提供的是很低延遲的服務(wù)，里面一些，比如說編碼碼流，不能夠在傳統(tǒng)的 CDN 網(wǎng)絡(luò)分發(fā)，如果想在傳統(tǒng)的 CDN 網(wǎng)絡(luò)上分發(fā)，就要服務(wù)端的轉(zhuǎn)碼。還有就是轉(zhuǎn)協(xié)議，因?yàn)榍懊嫣峁┮粋€(gè)更低延時(shí)的服務(wù)，后面要在 CDN 網(wǎng)絡(luò)上分發(fā)，所以協(xié)議也需要轉(zhuǎn)。

圖 3

圖 3 是線上娃娃機(jī)的 APP 版本的架構(gòu)圖，這里的是特色是線上娃娃機(jī)可以實(shí)時(shí)推兩路視頻流，上機(jī)玩家可以隨時(shí)任意去切其中一路畫面去看。這兩路視頻流首先通過我們超低延時(shí)服務(wù)器集群，同時(shí)上機(jī)玩家也可以推一路流上去，可以給圍觀觀眾方看到這個(gè)人在抓娃娃時(shí)候的一些表情、反應(yīng)、語(yǔ)言，增加一種互動(dòng)性。此外，玩家需要通過手機(jī)遠(yuǎn)程操控娃娃機(jī)，因此還需要實(shí)時(shí)信令的分發(fā)。

圖 4

接下來是娃娃機(jī)的 H5 架構(gòu)圖。在推流方面和 APP 版本沒有太大的區(qū)別，娃娃機(jī)一側(cè)還是走的私有協(xié)議。不同的地方是因?yàn)樗接袇f(xié)議沒有辦法直接讓 H5 拉到流，所以中間會(huì)加入一個(gè)媒體網(wǎng)關(guān)，作用是把我們的私有協(xié)議翻譯成 H5 可以識(shí)別的碼流格式，然后 H5 端通過 websocket 方式把這路流拉下來，這里需要媒體網(wǎng)關(guān)做到超低延時(shí)的轉(zhuǎn)換。

簡(jiǎn)單來看，這里的網(wǎng)關(guān)服務(wù)器只是做了一個(gè)分發(fā)服務(wù)，好像不會(huì)引入延時(shí)，實(shí)際上不然。

因?yàn)?websocket 拉的是 TCP 的流，但是我們推的是 UDP 的，當(dāng)視頻幀很大的時(shí)候，一個(gè)幀數(shù)據(jù)就要切割成很多 UDP 包上行，服務(wù)器需要將這些 UDP 包攢起來，湊成一個(gè)完整的幀后才下發(fā)給 H5，這樣才能保證不花屏，才能跑得通，所以這個(gè)攢包組幀的過程是會(huì)有延遲的。信令部分和 APP 部分基本是相似的。

實(shí)時(shí)架構(gòu)的若干點(diǎn)思考

剛才介紹了實(shí)時(shí)音視頻的兩種場(chǎng)景，下面提出一點(diǎn)思考：實(shí)時(shí)音視頻有什么樣的特征？怎么樣去架構(gòu)一個(gè)實(shí)時(shí)音視頻系統(tǒng)？

這是仁者見仁，智者見智的問題。你可以通過很多方式把這個(gè)系統(tǒng)架構(gòu)起來，都會(huì)達(dá)到相對(duì)不錯(cuò)的效果。但是我認(rèn)為，無(wú)論怎樣，實(shí)時(shí)音視頻都有繞不過如下幾個(gè)點(diǎn)，只有把它們做好了，才能夠在業(yè)界有更高的知名度、更好的技術(shù)儲(chǔ)備。

第一是實(shí)時(shí)音視頻是不能等的，因?yàn)榈攘司筒皇菍?shí)時(shí)音視頻了。 不能等，這里會(huì)引入一個(gè)矛盾。既然不能等，例如你把實(shí)時(shí)音視頻也看作一個(gè)消費(fèi)模型來看，那是提前生產(chǎn)還是按需生產(chǎn)？字面上理解很簡(jiǎn)單，肯定是按需生產(chǎn)，需要的時(shí)候才生產(chǎn)，如果提前生產(chǎn)就是延時(shí)了。但是并不是每一個(gè)點(diǎn)都做成按需生產(chǎn)是合理的。

舉一個(gè)例子，比如你要去播放一段音頻，最好的做法是系統(tǒng)或者驅(qū)動(dòng)告訴你，它需要數(shù)據(jù)了，然后去解一幀塞給它，這就是按需生產(chǎn)。但是為什么還有提前生產(chǎn)一說呢？就是系統(tǒng)告訴你它要數(shù)據(jù)的時(shí)候，實(shí)際上它有一個(gè)對(duì)響應(yīng)周期的要求。

你現(xiàn)去生產(chǎn)可能就要等去解完一幀，但是這個(gè)時(shí)候來得及嗎？如果你只有一路下行，可能就來得及。但是現(xiàn)在要求很多路下行，在很短的時(shí)間周期內(nèi)解很多幀，對(duì)硬件性能有很高的要求。通常來講，并不可取。這只是實(shí)時(shí)音視頻中一個(gè)簡(jiǎn)單的例子。提前生產(chǎn)會(huì)引入延遲的，那么到底要提前多久生產(chǎn)，怎么樣動(dòng)態(tài)估計(jì)我們什么時(shí)候應(yīng)該生產(chǎn)？這是一個(gè)開放性的問題，也是一個(gè)大家在設(shè)計(jì)系統(tǒng)時(shí)要重點(diǎn)考慮的。

第二是實(shí)時(shí)音視頻不能久等。 實(shí)時(shí)音視頻中有些等待是避免不了的，例如你要做音頻編碼，它本來一定要 20 毫秒一幀或者 40 毫秒一幀去做，給一個(gè)采樣點(diǎn)點(diǎn)是編不了的。這里既然有些延遲和等待避免不了，我們當(dāng)然希望系統(tǒng)處理的粒度越低越好，這樣可能會(huì)帶來更低的延時(shí)。但是處理的粒度越低，整個(gè)系統(tǒng)在頻繁跑的時(shí)候，你可以認(rèn)為它是一套循環(huán)，當(dāng)循環(huán)的東西很少，這個(gè)循環(huán)就會(huì)跑很多次，對(duì)系統(tǒng)來說就是一個(gè)很大的開銷和負(fù)擔(dān)。

所以不能久等的時(shí)候，我們當(dāng)然希望它處理粒度小。另外處理粒度小還有一個(gè)優(yōu)勢(shì)，在整個(gè)系統(tǒng)中并不能保證每一個(gè)環(huán)節(jié)的處理粒度是一致的。例如這個(gè)節(jié)點(diǎn)可能要求是 10 毫秒，下一個(gè)結(jié)點(diǎn)要求 15 毫秒，這是由于算法的限制，可能沒有辦法避免。如果在整個(gè)系統(tǒng)內(nèi)選一個(gè)相對(duì)小的粒度，在粒度拼接的時(shí)候，例如 10-15 毫秒，要兩個(gè) 10 毫秒才能夠 15 毫秒，還剩下 5 毫秒，剩的就比較少。

如果粒度很粗，可能剩下的東西就很多。在粒度拼接的時(shí)候，這個(gè)剩余的量代表了整個(gè)鏈路中的延遲。所以我們希望處理粒度盡量小，但是又不能小到整個(gè)系統(tǒng)沒有辦法接受的粒度。

第三，實(shí)時(shí)音視頻不能死等。 例如你需要接收一個(gè)網(wǎng)絡(luò)包的時(shí)候，這個(gè)包遲遲不到，這個(gè)時(shí)候你不能完全不等，完全不等就會(huì)卡。但是在等的時(shí)候有一個(gè)超時(shí)的機(jī)制，例如這個(gè)音頻包就是很久不到，就把它跳過去做一個(gè)糾幀補(bǔ)償，當(dāng)包最終還是到了的時(shí)候，我也只能把它扔掉，而不應(yīng)該把它利用起來。

圖 5

此外，實(shí)時(shí)音視頻在服務(wù)器端還需要深入考慮這樣幾個(gè)問題：第一是負(fù)載均衡。第二是就近接入，第三是質(zhì)量評(píng)估，第四是動(dòng)態(tài)路由，第五是算法流控。

第一，負(fù)載均衡是說讓整個(gè)服務(wù)器的每一個(gè)節(jié)點(diǎn)都承擔(dān)相對(duì)均勻的服務(wù)，不至于使得某一個(gè)節(jié)點(diǎn)負(fù)載過高造成一些丟包，造成網(wǎng)絡(luò)往返時(shí)的增大，這樣對(duì)任何的網(wǎng)絡(luò)損傷來講，對(duì)實(shí)時(shí)音視頻都會(huì)造成比較大的延遲增加。

第二是就近接入，這里的“近”并不是指地域上的近，而是“網(wǎng)絡(luò)上的近”。很簡(jiǎn)單的例子，我們?cè)谏钲谧鐾屏?，香港離得很近，可以推到香港的服務(wù)器，但實(shí)際上這畢竟是一個(gè)跨域的網(wǎng)絡(luò)，有不穩(wěn)定的因素在里面，所以我們寧愿推遠(yuǎn)一點(diǎn)。這個(gè)近指的應(yīng)該是在網(wǎng)絡(luò)質(zhì)量評(píng)估意義上的近，例如網(wǎng)絡(luò)往返時(shí)很小、往返時(shí)很平穩(wěn)、分布在延遲比較大的時(shí)刻不會(huì)還具有很大的概率，丟包率很低等。

要做到就近接入，這個(gè)近要有一個(gè)很好的質(zhì)量評(píng)估體系。質(zhì)量評(píng)估方法有兩種：

1. 事后質(zhì)量評(píng)估。在復(fù)盤的時(shí)候，例如這個(gè)網(wǎng)絡(luò)平穩(wěn)的運(yùn)行了一個(gè)月，復(fù)盤看一下整個(gè)月中的質(zhì)量怎么樣，這樣的質(zhì)量評(píng)估可以認(rèn)為是一個(gè)相對(duì)離線的評(píng)估，它能夠給我們提供一個(gè)指標(biāo)，最近一個(gè)月的網(wǎng)絡(luò)和上個(gè)月相比是否有所改善。我們可以從中學(xué)習(xí)到一些經(jīng)驗(yàn)，例如這個(gè)月和上個(gè)月的調(diào)度上有些策略上的不同。這是一個(gè)系統(tǒng)化的經(jīng)驗(yàn)總結(jié)和優(yōu)化的方法。

2. 實(shí)時(shí)質(zhì)量評(píng)估。更重要的應(yīng)該是一個(gè)實(shí)時(shí)上的評(píng)估，例如我現(xiàn)在推流，能夠?qū)崟r(shí)監(jiān)控到當(dāng)前的質(zhì)量是怎么樣的，就可以做到實(shí)時(shí)動(dòng)態(tài)路由。實(shí)時(shí)動(dòng)態(tài)路由是說某個(gè)人推流從北京推到迪拜，有很多鏈路可以選，他可能根據(jù)之前的一些經(jīng)驗(yàn)，假如他之前經(jīng)驗(yàn)告訴你，直接推到迪拜，這個(gè)鏈路是很好的，但是畢竟有個(gè)例。有動(dòng)態(tài)實(shí)時(shí)的質(zhì)量評(píng)估，就知道這個(gè)時(shí)候推迪拜是否好，如果不好，可以在用戶無(wú)感知的情況下更換，隨時(shí)增減整個(gè)鏈路中一些路由的節(jié)點(diǎn)。這就是動(dòng)態(tài)路由的思路。

實(shí)時(shí)動(dòng)態(tài)路由是說某個(gè)人推流從北京推到迪拜，有很多鏈路可以選，他可能根據(jù)之前的一些經(jīng)驗(yàn)，假如他之前經(jīng)驗(yàn)告訴你，直接推到迪拜，這個(gè)鏈路是很好的，但是畢竟有個(gè)例。有動(dòng)態(tài)實(shí)時(shí)的質(zhì)量評(píng)估，就知道這個(gè)時(shí)候推迪拜是否好，如果不好，可以在用戶無(wú)感知的情況下更換，隨時(shí)增減整個(gè)鏈路中一些路由的節(jié)點(diǎn)。這就是動(dòng)態(tài)路由的思路。

★如有服務(wù)器租用可咨詢宇眾臨風(fēng)，QQ：2850293179    Tel：15999932452    服務(wù)器租用價(jià)格列表

實(shí)際情況中是結(jié)合前面這 4 個(gè)點(diǎn)，在我們的網(wǎng)絡(luò)和服務(wù)器資源集中，去選出質(zhì)量最優(yōu)或者近似最優(yōu)的鏈路來保證實(shí)時(shí)音視頻的服務(wù)的。但是資源集是有限的，沒有人可以保證你的資源集中一定可以選出的這個(gè)最優(yōu)具有很好的鏈路特征。保證不了就要考慮第五點(diǎn)，我即使選出了一個(gè)認(rèn)為是整個(gè)資源集中最優(yōu)的鏈路，但是它的質(zhì)量還達(dá)不到很好的標(biāo)準(zhǔn)，就要通過一些算法才能彌補(bǔ)。這些算法包括在一個(gè)不可靠的網(wǎng)絡(luò)中怎么樣進(jìn)行可靠的音視頻傳輸?shù)募夹g(shù)，這些技術(shù)在接下來我們會(huì)和大家稍微分享一下，也包括整個(gè)鏈路的一些擁塞控制。

關(guān)于信源編碼的思考

圖 6

信源編碼是為了減少網(wǎng)絡(luò)中的負(fù)擔(dān)，把大量的數(shù)據(jù)壓縮成比較小的網(wǎng)絡(luò)數(shù)據(jù)，來減少網(wǎng)絡(luò)負(fù)擔(dān)的方式。壓縮方式有很多種，我們先以音頻來看，上面畫了一些圖（圖 6），我們重點(diǎn)看 Opus 編碼器，它有幾種模式在里面，一種是線性預(yù)測(cè)模式，還有一種是混合模式，還有一種是頻域編碼模式。混合模式是把兩種編碼模式混合在一起，根據(jù)不同的情況進(jìn)行選擇。

圖 6 是一個(gè)編碼器，橫軸是碼率，縱軸是它的質(zhì)量，中間是各種音頻編解碼器的表現(xiàn)。你會(huì)發(fā)現(xiàn)線性預(yù)測(cè)的方式能夠在低碼率上提供比較好的質(zhì)量，但是在 20K 左右的時(shí)候就沒有曲線了，因?yàn)樗恢С帜敲锤叩拇a率。然后看 MDCT 編碼，它可以在比較高的碼率上達(dá)到近似透明的音質(zhì)。音頻編碼器是有不同的編碼原理在里面的，像這種 LP Mode 是模擬人的發(fā)聲模型，既然有了數(shù)學(xué)建模，它的特征是能夠在一個(gè)比較低的碼率上提供一個(gè)比較可靠的質(zhì)量。

但是它的特點(diǎn)是容易達(dá)到一種質(zhì)量上的飽和，也就是說當(dāng)你碼率給它很高的時(shí)候，實(shí)際上它也就編的效果還是那樣，因?yàn)樗吘故且环N參數(shù)化的編碼。所以根據(jù)業(yè)務(wù)場(chǎng)景，當(dāng)你需要一個(gè)很高的音質(zhì)，又需要音樂場(chǎng)景的時(shí)候，選擇它明顯不合適。MDCT MODE 沒有任何的模型在里面，實(shí)際上就是把信號(hào)轉(zhuǎn)換成頻域，直接去量化。既然沒有模型化，它是比較消耗碼率的，但是它可以在一個(gè)較高的碼率上提供很好的質(zhì)量，可是低碼率的表現(xiàn)遠(yuǎn)遠(yuǎn)不如模型化的方法。

圖 7

整體總結(jié)起來，音頻包括語(yǔ)音和音樂兩種，因此有適合語(yǔ)音的 codec 和適合音樂的 codec。第一種 codec 適合語(yǔ)音，語(yǔ)音可以模型化，適用于語(yǔ)音的 codec 能夠在低碼率上提供很好的質(zhì)量，提供一個(gè)相對(duì)高的壓縮比, 但是它容易達(dá)到飽和，不能夠提供一個(gè)近似于透明的音質(zhì)。另外一種 codec 的編碼原理不一樣，能夠把音樂、語(yǔ)音都編得很好，但是特點(diǎn)是不能夠提供太高的壓縮比，指望它能夠在低碼率下提供很高的編碼質(zhì)量是做不到的。

圖 8

關(guān)于視頻編碼，最簡(jiǎn)單的幾個(gè)點(diǎn)有 I 幀、P 幀、B 幀。I 幀是自參考，P 幀是向前參考，它會(huì)參考?xì)v史幀的特性進(jìn)行編碼。B 幀是雙向參考，它可以參考前面的幀，也可以參考后面的幀。B 幀可以帶來更高的壓縮比，提供更好的質(zhì)量。但是因?yàn)樗鼤?huì)參考將來的幀，所以會(huì)引入延遲，因此我們?cè)趯?shí)時(shí)音視頻系統(tǒng)中是很少用到 B 幀的。

想要做好實(shí)時(shí)的音視頻系統(tǒng)，流控是一定要做的，流控對(duì)視頻的編解碼有什么要求？至少有一點(diǎn)，編解碼器的碼控一定要很穩(wěn)定。為什么？舉例說，我現(xiàn)在有一個(gè)很好的擁塞控制策略，帶寬估計(jì)做得很好，一點(diǎn)差錯(cuò)都沒有，估計(jì)出某一個(gè)時(shí)刻可分配視頻的帶寬就是 500kbps，就可以讓視頻編碼器設(shè)置成 500kbps。但是，如果碼控不是很穩(wěn)定，你設(shè)置 500kbps 的時(shí)候，視頻編碼器可能就跑到 600kbps 了，這樣就會(huì)帶來一些阻塞和延遲。因此，我們希望選擇的 codec 具有很好的碼控策略。

實(shí)際上一些開源代碼都是有做碼控的，但是直接拿來用并不是適合你的場(chǎng)景，因?yàn)檫@些開源代碼做起來，可能或多或少的考慮其他的場(chǎng)景，并不只是實(shí)時(shí)音視頻場(chǎng)景。比如說某個(gè) codec 是用來是壓片的，希望半個(gè)小時(shí)或者一個(gè)小時(shí)之內(nèi)達(dá)到預(yù)定的碼率就可以，不會(huì)管這一秒鐘或者下一秒是什么樣子的，但是實(shí)時(shí)音視頻就是要求要把時(shí)間窗做得很小。

另外我們希望 codec 有分層編碼的能力。什么是分層編碼？為什么要有分層編碼？分層編碼也分兩種，一種是時(shí)域上的分層，一種是空域上的分層。前者是編碼的時(shí)候是當(dāng)前幀不參考上一幀，而是有隔幀參考的策略；后者可以認(rèn)為使用較低的碼率先編碼一個(gè)小的畫面，然后使用剩余的碼率編碼增量的部分，得到更高分辨率的畫面。

為什么要這樣做？實(shí)時(shí)音視頻中并不是很多場(chǎng)景都是一對(duì)一的，當(dāng)不是一對(duì)一，要做流控的時(shí)候，不可能因?yàn)槟骋宦酚^眾的下行不好，就把主播上行推流的碼率降下來，因?yàn)榭赡苓€有一千個(gè)觀眾的網(wǎng)絡(luò)很好，這些網(wǎng)絡(luò)好的觀眾也會(huì)因?yàn)閭€(gè)別觀眾網(wǎng)絡(luò)不好，而只能看到不那么清晰的畫面。所以要分層，可以在服務(wù)器端選擇給用戶到底下發(fā)哪一層的，因?yàn)橛蟹謱硬呗?，如果這個(gè)人線路不好，只要選擇其中一個(gè)比較小的層次發(fā)給他就可以了，例如核心層，這樣可以緊緊利用核心層把整個(gè)視頻還原，可能會(huì)損傷一些細(xì)節(jié)或者幀率偏低，但是至少整體可用。

最后，我想說一下，很多人認(rèn)為，視頻的數(shù)據(jù)量很大，視頻的延時(shí)比音頻應(yīng)該更高才對(duì)，實(shí)際上不是。因?yàn)楹芏嗟难舆t實(shí)際上是編解碼自有的延遲，如果編解碼中沒有 B 幀的話，你可以理解為視頻編碼是沒有任何延遲的。但是音頻編碼或多或少都會(huì)參考一些將來的數(shù)據(jù)，也就是說音頻編碼器的延時(shí)一定是存在的。因此，通常來講，音頻的延時(shí)比視頻的延時(shí)更高才對(duì)。

關(guān)于信道編碼技術(shù)的思考

圖 9

信道編碼分幾個(gè)部分。一種是根據(jù)先驗(yàn)知識(shí)的網(wǎng)絡(luò)冗余編碼技術(shù)——前向糾錯(cuò)技術(shù)。以 RS（4，6）編碼為例，我要發(fā)一個(gè)分組，這個(gè)分組有六個(gè)包，其中有四個(gè)包是實(shí)際媒體數(shù)據(jù)，有兩個(gè)包是冗余包。那么在解碼端收到六個(gè)包中任意的四個(gè)，就可以完全恢復(fù)所有攜帶媒體內(nèi)容的包。

例如這里 2、3 都丟了，收到了 1、4、r1、r2，也能夠完全恢復(fù) 2 和 3。這樣看來很好，任意兩個(gè)丟掉都可以完全恢復(fù)。但是這樣的算法也有它的弱點(diǎn)，不太適合突發(fā)性的丟包。因?yàn)檫@個(gè)分組不宜太大，如果分組很大，分組就有很大的延時(shí)。分組如果很小，很可能整個(gè)分組都丟掉了。

實(shí)際上這種做法就沒有任何意義。所以它不太適合突發(fā)性丟包，而且它畢竟是根據(jù)先驗(yàn)知識(shí)去做的一種冗余，也就是說它永遠(yuǎn)是根據(jù)上一時(shí)刻網(wǎng)絡(luò)的狀態(tài)作出的判斷，下一時(shí)刻網(wǎng)絡(luò)是什么樣的，是預(yù)測(cè)的東西。網(wǎng)絡(luò)是實(shí)時(shí)發(fā)生變化的，這種預(yù)測(cè)的東西并不完全可靠。

所以它恢復(fù)的效率在實(shí)際網(wǎng)絡(luò)中相對(duì)比較低，而且這樣的算法復(fù)雜度相對(duì)比較高。當(dāng)然它也有優(yōu)勢(shì)，例如我們是提前算好的，一次性發(fā)過去，不需要等到你發(fā)現(xiàn)丟包時(shí)我再做怎樣的冗余傳輸，所以不受網(wǎng)絡(luò)往返的影響。而且這種分組可以任意、隨機(jī)調(diào)整大小冗余度，比較適合均勻丟包的場(chǎng)景。

圖 10

另外一項(xiàng)技術(shù)是丟包重傳技術(shù)。相對(duì)來說，丟包重傳相對(duì) RS 來講，更有針對(duì)性，所以恢復(fù)效率比較高。第一個(gè) Go Back N 技術(shù)是類似于 TCP 的傳輸技術(shù)，發(fā)送端在不斷的發(fā)包，接收端要負(fù)責(zé)告訴發(fā)送端我現(xiàn)在收到包的情況是怎么樣，收到的連續(xù)的幀的是序列號(hào)什么樣的。發(fā)送端發(fā)現(xiàn)發(fā)了 10 個(gè)幀，接收端只正確收到 8，不管 9 號(hào)包或者 10 號(hào)包是否收到，都會(huì)丟包重傳。所以 Go Back N 技術(shù)有一定的目的性，維護(hù)的是丟包狀態(tài)，它知道哪些包是沒有收到的，但是并不精準(zhǔn)。

接下來是自動(dòng)選擇重傳技術(shù)（Selective ARQ）。選擇性的重傳，是在接收端發(fā)現(xiàn)了哪個(gè)包丟了，然后才會(huì)讓發(fā)送端重新發(fā)送這個(gè)包。聽起來是非常好的一個(gè)技術(shù)，效率很高，丟了哪個(gè)包就重傳哪個(gè)包。但是它的弱點(diǎn)在于，你必須要假定這個(gè)包是頻密的發(fā)送才可以。例如發(fā)送端發(fā)出 1、2、3、4 這樣的包，但是一秒鐘才發(fā)一個(gè)包，什么時(shí)候發(fā)現(xiàn) 2 丟了呢？收到 3 的時(shí)候。如果 2 作為最后一包，永遠(yuǎn)發(fā)現(xiàn)不了丟掉了。也就是如果發(fā)包不頻密，至少需要 1 秒鐘才發(fā)現(xiàn)它丟。這個(gè)時(shí)候再讓它重傳，就很晚了。

所以在一個(gè)真實(shí)的系統(tǒng)中，選擇性重傳是首選，因?yàn)橐粢曨l的大部分場(chǎng)景是頻密的，但是可能也要結(jié)合一些 Go-Back -N 的做法。發(fā)一些確認(rèn)機(jī)制，這樣才能把重傳做得更加完備。另外所有的重傳都要至少等一個(gè)網(wǎng)絡(luò)往還時(shí)，因?yàn)闊o(wú)論是確認(rèn)丟包還是反饋收包情況，都需要一個(gè)網(wǎng)絡(luò)往返時(shí)，所以它的弱點(diǎn)是，它受網(wǎng)絡(luò)往返時(shí)影響比較大，如果控制不好，有可能造成重傳風(fēng)暴。優(yōu)勢(shì)是算法計(jì)算復(fù)雜比較低，且容易實(shí)現(xiàn)。另外，因?yàn)樗泻艽蟮尼槍?duì)性，無(wú)效的重傳包會(huì)比較少，針對(duì)突發(fā)性的丟包會(huì)有比較好的效果。

剛才講了針對(duì)不可靠網(wǎng)絡(luò)的兩種傳輸技術(shù)，前向糾錯(cuò)和丟包重傳，它們都有各自的優(yōu)點(diǎn)和缺點(diǎn)。實(shí)際上一個(gè)好的網(wǎng)絡(luò)分發(fā)技術(shù)應(yīng)該是將這兩種結(jié)合在一起的，根據(jù)不同的信道情況把這兩種技術(shù)結(jié)合在一起。

圖 11

圖 11 來自于網(wǎng)絡(luò)，首先從左下角藍(lán)色部分看起，當(dāng)網(wǎng)絡(luò)往返時(shí)很小，丟包率不高的時(shí)候就用重傳。但是當(dāng)網(wǎng)絡(luò) RTT 很高的時(shí)候，在這個(gè)圖里面去看，就沒有選用重傳策略。從我個(gè)人的角度來看，我認(rèn)為這并不是一個(gè)非常合理的做法。因?yàn)閯偛盘岬搅?，F(xiàn)EC 是一個(gè)無(wú)目的性的、根據(jù)先驗(yàn)知識(shí)去做的一種冗余技術(shù)，雖然當(dāng) RTT 很高，重傳很耗時(shí)，但如果沒有重傳，要加很多冗余包，才能把丟掉的包完全恢復(fù)，實(shí)際就會(huì)帶來很大的資源浪費(fèi)。而且當(dāng)你丟包率很高的時(shí)候，可能還并不能夠完全恢復(fù)所有包。視頻只要丟幀就會(huì)很卡，視頻丟包率應(yīng)該控制在千分之幾以下，才可以達(dá)到順暢的可以觀看的水平。

圖 12

關(guān)于信道編碼的思考。信道編碼和網(wǎng)絡(luò)吞吐呈反比關(guān)系。無(wú)論是重傳性編碼還是冗余性編碼，都會(huì)占用帶寬，從而減低實(shí)際媒體信息的吞吐量?，F(xiàn)實(shí)的生活中，信道都有限制。當(dāng)你傳輸?shù)臅r(shí)候，就要根據(jù)信道的特征去做一些策略。信道如果有擁塞，我們就需要有一個(gè)擁塞控制的算法，去估計(jì)應(yīng)該把整個(gè)信道怎么樣做合理分配。

另外，在做一個(gè)系統(tǒng)的時(shí)候，想清楚如何去評(píng)價(jià)一個(gè)系統(tǒng)的效果是很重要的一個(gè)點(diǎn)。在信道編碼的時(shí)候，一個(gè)很重要的指標(biāo)是，信道編碼的有效性是什么樣子的。有效性分為兩種，一種是重傳或者冗余能否真的把丟掉的包補(bǔ)回來，這是一個(gè)有效性。即使這個(gè)包補(bǔ)回來了，但是如果經(jīng)過一個(gè)信道編碼策略之后，還有一些丟包。

例如原來的丟包是 20%，補(bǔ)回來變成 1%，那么這個(gè)重傳在我們的評(píng)價(jià)當(dāng)中實(shí)際上是沒有效果的，因?yàn)?1% 的丟包對(duì)音頻來講是無(wú)所謂的，但是對(duì)視頻來講是很卡的。在這樣的評(píng)價(jià)系統(tǒng)中，補(bǔ)回來還有 1% 的丟包，那么所有的編碼都是沒有太大意義的。舉這個(gè)例子，如果在這時(shí)信道也發(fā)生擁塞，再進(jìn)行這樣的信道編碼，就不會(huì)達(dá)到很好的效果。這個(gè)時(shí)候是否應(yīng)該停止所有的信道編碼呢？

還有信道編碼有效性的判斷，衡量它是否好，就是加了多少冗余，冗余中有多少?zèng)]有被利用好，如果這些冗余像剛才那個(gè)例子那樣，6 包帶 2 包的冗余，剛好丟掉 2 包，整個(gè)包都恢復(fù)出來了都使用到了，那就是百分之百的冗余都有效。如果 4 包信息丟了 1 包，卻帶了 2 包榮譽(yù)，其中 1 包就沒有效果。所以想要做一個(gè)好的系統(tǒng)，應(yīng)該先想到如何評(píng)價(jià)這個(gè)系統(tǒng)的好壞。

引入延遲的環(huán)節(jié)和降低延遲的思路

延遲的引入主要分三部分，一個(gè)是采集 / 渲染。這好像是很簡(jiǎn)單一個(gè)部分，但是它引入延遲可能是最大的，可能是整個(gè)分發(fā)過程中最大的環(huán)節(jié)。

有很多人不是特別理解，但實(shí)際上在即構(gòu)現(xiàn)有的網(wǎng)絡(luò)結(jié)構(gòu)中，網(wǎng)絡(luò)往返時(shí)的延遲都控制在 50 毫秒以內(nèi)，但是渲染和采集，尤其是渲染，幾乎沒有任何移動(dòng)端系統(tǒng)可以保證它百分之百的 50 毫秒，這是一些硬件上的限制。如何去降低這些延遲？剛才我已經(jīng)舉了一個(gè)生產(chǎn)消費(fèi)模型的思路，到底是按需生產(chǎn)還是提前生產(chǎn)，這些都是可以仔細(xì)去考慮的。

還有編解碼會(huì)帶來一些延遲，尤其是音頻會(huì)帶來一些延遲。這些延遲中有些是避免不了的，我們就要根據(jù)實(shí)際的使用場(chǎng)景去減少這些延遲，這些都是要在具體形態(tài)上做一些權(quán)衡的東西。還有處理粒度上的考慮，也會(huì)影響整個(gè)系統(tǒng)的延遲。