2017年12月23日，由即構(gòu)科技主辦的 ZEGO Meetup 第一期 實(shí)時(shí)音視頻開(kāi)發(fā)者沙龍?jiān)谏钲趫A滿(mǎn)結(jié)束。另外，2018年3月17日(本周六)，ZEGO Meetup 第二期 視頻直播+的技術(shù)實(shí)踐之道在北京舉行。此刻，讓我們把深圳 ZEGO Meetup 會(huì)上的精彩技術(shù)演講總結(jié)起來(lái)分享給業(yè)界，3月17日在北京中關(guān)村舉行的ZEGO Meetup技術(shù)沙龍總的精彩技術(shù)演講，也將會(huì)總結(jié)成技術(shù)文章來(lái)和讀者分享。

以下是即構(gòu)科技音視頻核心工程師關(guān)旭就如何打造實(shí)時(shí)視頻通話(huà)超低延遲架構(gòu)的精彩分享。

嘉賓簡(jiǎn)介：

[[223752]]

關(guān)旭，即構(gòu)科技音視頻引擎核心專(zhuān)家，碩士畢業(yè)于南開(kāi)大學(xué)數(shù)學(xué)系，先后就職于中興通訊、騰訊等公司負(fù)責(zé)音視頻相關(guān)的研發(fā)工作，在實(shí)時(shí)音視頻技術(shù)上有多年積累，當(dāng)前在即構(gòu)科技主要負(fù)責(zé)音視頻引擎核心開(kāi)發(fā)。

正文：

大家好，今天我分享的內(nèi)容主要分如下幾部分：

• 實(shí)時(shí)音視頻場(chǎng)景——從直播到線(xiàn)上抓娃娃
• 實(shí)時(shí)架構(gòu)的若干點(diǎn)思考
• 關(guān)于信源編碼的思考
• 關(guān)于信道編碼的思考
• 引入延遲的環(huán)節(jié)和降低延遲的思路

1. 實(shí)時(shí)音視頻場(chǎng)景——從直播到線(xiàn)上抓娃娃

圖 1

圖1展示了實(shí)時(shí)音視頻兩種不同的應(yīng)用場(chǎng)景——連麥互動(dòng)直播和線(xiàn)上娃娃機(jī)。雖然這兩種都是互動(dòng)，但是對(duì)于實(shí)時(shí)音視頻的要求卻不同。第一個(gè)實(shí)時(shí)連麥?zhǔn)钦Z(yǔ)音視頻流的互動(dòng)，例如其中一個(gè)說(shuō)了一句話(huà)，另外一個(gè)人聽(tīng)到了，再回復(fù)一句話(huà)，這個(gè)實(shí)時(shí)性只是對(duì)語(yǔ)音視頻流的實(shí)時(shí)性要求很高。而第二種線(xiàn)上抓娃娃則對(duì)信令的延遲提出了更高的要求，操縱者無(wú)需說(shuō)話(huà)，看到的是娃娃機(jī)傳回來(lái)的視頻流結(jié)果。如果考量互動(dòng)直播是用實(shí)時(shí)音視頻的延遲，那么線(xiàn)上抓娃娃則是用信令和視頻流的延時(shí)。隨著時(shí)代的發(fā)展，我們對(duì)實(shí)時(shí)語(yǔ)音視頻的定義會(huì)慢慢有一些不同，將來(lái)可能還有更多的因素需要考慮。

圖 2

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

在超低延時(shí)部分，我們提供的服務(wù)包括流狀態(tài)更新、房間管理等，以及一些流媒體服務(wù)，主要起到分發(fā)的作用。我們通過(guò)超低延遲服務(wù)器集群(和觀(guān)眾側(cè)不太一樣)，提供實(shí)時(shí)分發(fā)的功能。此外還提供了動(dòng)態(tài)調(diào)度的服務(wù)，幫助我們?cè)诂F(xiàn)有的資源網(wǎng)絡(luò)上找到更好的鏈路。后面的觀(guān)眾集群是另外一個(gè)集群，把它們分開(kāi)是出于一些業(yè)務(wù)方和我們自己成本上的考慮，另外會(huì)提供存儲(chǔ)、PCB加速、分發(fā)的功能。

中間的旁路服務(wù)包括混流、轉(zhuǎn)格式(主要是轉(zhuǎn)碼)、轉(zhuǎn)協(xié)議等。為什么要混流?舉一個(gè)比較簡(jiǎn)單的例子。當(dāng)主播一側(cè)有9個(gè)人連麥，如果沒(méi)有混流服務(wù)，觀(guān)眾端就會(huì)同時(shí)拉9路音視頻，這樣對(duì)帶寬壓力很大。普通觀(guān)眾是通過(guò)圍觀(guān)服務(wù)器集群(延遲相對(duì)大的集群)去拉這些流的，這個(gè)集群的延遲可控性相對(duì)比較弱，有可能會(huì)出現(xiàn)這9路畫(huà)面之間的不同步現(xiàn)象，通過(guò)混流服務(wù)，觀(guān)眾拉的都是合成好的音視頻流，就不會(huì)出現(xiàn)各路流之間的不同步問(wèn)題。還有轉(zhuǎn)格式轉(zhuǎn)碼的服務(wù)，前面集群提供的是很低延遲的服務(wù)，里面一些，比如說(shuō)編碼碼流，不能夠在傳統(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是線(xiàn)上娃娃機(jī)的APP版本的架構(gòu)圖，這里的是特色是線(xiàn)上娃娃機(jī)可以實(shí)時(shí)推兩路視頻流，上機(jī)玩家可以隨時(shí)任意去切其中一路畫(huà)面去看。這兩路視頻流首先通過(guò)我們超低延時(shí)服務(wù)器集群，同時(shí)上機(jī)玩家也可以推一路流上去，可以給圍觀(guān)觀(guān)眾方看到這個(gè)人在抓娃娃時(shí)候的一些表情、反應(yīng)、語(yǔ)言，增加一種互動(dòng)性。此外，玩家需要通過(guò)手機(jī)遠(yuǎn)程操控娃娃機(jī)，因此還需要實(shí)時(shí)信令的分發(fā)。

圖 4

接下來(lái)是娃娃機(jī)的H5架構(gòu)圖。在推流方面和APP版本沒(méi)有太大的區(qū)別，娃娃機(jī)一側(cè)還是走的私有協(xié)議。不同的地方是因?yàn)樗接袇f(xié)議沒(méi)有辦法直接讓H5拉到流，所以中間會(huì)加入一個(gè)媒體網(wǎng)關(guān)，作用是把我們的私有協(xié)議翻譯成H5可以識(shí)別的碼流格式，然后H5端通過(guò)websocket方式把這路流拉下來(lái)，這里需要媒體網(wǎng)關(guān)做到超低延時(shí)的轉(zhuǎn)換。簡(jiǎn)單來(lái)看，這里的網(wǎng)關(guān)服務(wù)器只是做了一個(gè)分發(fā)服務(wù)，好像不會(huì)引入延時(shí)，實(shí)際上不然。因?yàn)閣ebsocket拉的是TCP的流，但是我們推的是UDP的，當(dāng)視頻幀很大的時(shí)候，一個(gè)幀數(shù)據(jù)就要切割成很多UDP包上行，服務(wù)器需要將這些UDP包攢起來(lái)，湊成一個(gè)完整的幀后才下發(fā)給H5,這樣才能保證不花屏，才能跑得通，所以這個(gè)攢包組幀的過(guò)程是會(huì)有延遲的。信令部分和APP部分基本是相似的。

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

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

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

第一是實(shí)時(shí)音視頻是不能等的，因?yàn)榈攘司筒皇菍?shí)時(shí)音視頻了。不能等，這里會(huì)引入一個(gè)矛盾。既然不能等，例如你把實(shí)時(shí)音視頻也看作一個(gè)消費(fèi)模型來(lá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)一說(shuō)呢?就是系統(tǒng)告訴你它要數(shù)據(jù)的時(shí)候，實(shí)際上它有一個(gè)對(duì)響應(yīng)周期的要求。你現(xiàn)去生產(chǎn)可能就要等去解完一幀，但是這個(gè)時(shí)候來(lái)得及嗎?如果你只有一路下行，可能就來(lái)得及。但是現(xiàn)在要求很多路下行，在很短的時(shí)間周期內(nèi)解很多幀，對(duì)硬件性能有很高的要求。通常來(lái)講，并不可取。這只是實(shí)時(shí)音視頻中一個(gè)簡(jiǎn)單的例子。提前生產(chǎn)會(huì)引入延遲的，那么到底要提前多久生產(chǎn)，怎么樣動(dòng)態(tài)估計(jì)我們什么時(shí)候應(yīng)該生產(chǎn)?這是一個(gè)開(kāi)放性的問(wèn)題，也是一個(gè)大家在設(shè)計(jì)系統(tǒng)時(shí)要重點(diǎn)考慮的。

第二是實(shí)時(shí)音視頻不能久等。實(shí)時(shí)音視頻中有些等待是避免不了的，例如你要做音頻編碼，它本來(lái)一定要20毫秒一幀或者40毫秒一幀去做，給一個(gè)采樣點(diǎn)點(diǎn)是編不了的。這里既然有些延遲和等待避免不了，我們當(dāng)然希望系統(tǒng)處理的粒度越低越好，這樣可能會(huì)帶來(lái)更低的延時(shí)。但是處理的粒度越低，整個(gè)系統(tǒng)在頻繁跑的時(shí)候，你可以認(rèn)為它是一套循環(huán)，當(dāng)循環(huán)的東西很少，這個(gè)循環(huán)就會(huì)跑很多次，對(duì)系統(tǒng)來(lái)說(shuō)就是一個(gè)很大的開(kāi)銷(xiāo)和負(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毫秒，這是由于算法的限制，可能沒(méi)有辦法避免。如果在整個(gè)系統(tǒng)內(nèi)選一個(gè)相對(duì)小的粒度，在粒度拼接的時(shí)候，例如10-15毫秒，要兩個(gè)10毫秒才能夠15毫秒，還剩下5毫秒，剩的就比較少。如果粒度很粗，可能剩下的東西就很多。在粒度拼接的時(shí)候，這個(gè)剩余的量代表了整個(gè)鏈路中的延遲。所以我們希望處理粒度盡量小，但是又不能小到整個(gè)系統(tǒng)沒(méi)有辦法接受的粒度。

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

圖 5

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

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

第二是就近接入，這里的“近”并不是指地域上的近，而是“網(wǎng)絡(luò)上的近”。很簡(jiǎn)單的例子，我們?cè)谏钲谧鐾屏鳎愀垭x得很近，可以推到香港的服務(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)估方法有兩種：

• 事后質(zhì)量評(píng)估。在復(fù)盤(pán)的時(shí)候，例如這個(gè)網(wǎng)絡(luò)平穩(wěn)的運(yùn)行了一個(gè)月，復(fù)盤(pán)看一下整個(gè)月中的質(zhì)量怎么樣，這樣的質(zhì)量評(píng)估可以認(rèn)為是一個(gè)相對(duì)離線(xiàn)的評(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)化的方法。
• 實(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)路由是說(shuō)某個(gè)人推流從北京推到迪拜，有很多鏈路可以選，他可能根據(jù)之前的一些經(jīng)驗(yàn)，假如他之前經(jīng)驗(yàn)告訴你，直接推到迪拜，這個(gè)鏈路是很好的，但是畢竟有個(gè)例。有動(dòng)態(tài)實(shí)時(shí)的質(zhì)量評(píng)估，就知道這個(gè)時(shí)候推迪拜是否好，如果不好，可以在用戶(hù)無(wú)感知的情況下更換，隨時(shí)增減整個(gè)鏈路中一些路由的節(jié)點(diǎn)。這就是動(dòng)態(tài)路由的思路。

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

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

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

圖 6

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

圖6是一個(gè)編碼器，橫軸是碼率，縱軸是它的質(zhì)量，中間是各種音頻編解碼器的表現(xiàn)。你會(huì)發(fā)現(xiàn)線(xiàn)性預(yù)測(cè)的方式能夠在低碼率上提供比較好的質(zhì)量，但是在20K左右的時(shí)候就沒(méi)有曲線(xiàn)了，因?yàn)樗恢С帜敲锤叩拇a率。然后看MDCT編碼，它可以在比較高的碼率上達(dá)到近似透明的音質(zhì)。音頻編碼器是有不同的編碼原理在里面的，像這種LP Mode是模擬人的發(fā)聲模型，既然有了數(shù)學(xué)建模，它的特征是能夠在一個(gè)比較低的碼率上提供一個(gè)比較可靠的質(zhì)量。但是它的特點(diǎn)是容易達(dá)到一種質(zhì)量上的飽和，也就是說(shuō)當(dāng)你碼率給它很高的時(shí)候，實(shí)際上它也就編的效果還是那樣，因?yàn)樗吘故且环N參數(shù)化的編碼。所以根據(jù)業(yè)務(wù)場(chǎng)景，當(dāng)你需要一個(gè)很高的音質(zhì)，又需要音樂(lè)場(chǎng)景的時(shí)候，選擇它明顯不合適。MDCT MODE沒(méi)有任何的模型在里面，實(shí)際上就是把信號(hào)轉(zhuǎn)換成頻域，直接去量化。既然沒(méi)有模型化，它是比較消耗碼率的，但是它可以在一個(gè)較高的碼率上提供很好的質(zhì)量，可是低碼率的表現(xiàn)遠(yuǎn)遠(yuǎn)不如模型化的方法。

圖 7

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

圖 8

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

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

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

另外我們希望codec有分層編碼的能力。什么是分層編碼?為什么要有分層編碼?分層編碼也分兩種，一種是時(shí)域上的分層，一種是空域上的分層。前者是編碼的時(shí)候是當(dāng)前幀不參考上一幀，而是有隔幀參考的策略;后者可以認(rèn)為使用較低的碼率先編碼一個(gè)小的畫(huà)面，然后使用剩余的碼率編碼增量的部分，得到更高分辨率的畫(huà)面。 為什么要這樣做?實(shí)時(shí)音視頻中并不是很多場(chǎng)景都是一對(duì)一的，當(dāng)不是一對(duì)一，要做流控的時(shí)候，不可能因?yàn)槟骋宦酚^(guān)眾的下行不好，就把主播上行推流的碼率降下來(lái)，因?yàn)榭赡苓€有一千個(gè)觀(guān)眾的網(wǎng)絡(luò)很好，這些網(wǎng)絡(luò)好的觀(guān)眾也會(huì)因?yàn)閭€(gè)別觀(guān)眾網(wǎng)絡(luò)不好，而只能看到不那么清晰的畫(huà)面。所以要分層，可以在服務(wù)器端選擇給用戶(hù)到底下發(fā)哪一層的，因?yàn)橛蟹謱硬呗裕绻@個(gè)人線(xiàn)路不好，只要選擇其中一個(gè)比較小的層次發(fā)給他就可以了，例如核心層，這樣可以緊緊利用核心層把整個(gè)視頻還原，可能會(huì)損傷一些細(xì)節(jié)或者幀率偏低，但是至少整體可用。

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

4. 關(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。這樣看來(lái)很好，任意兩個(gè)丟掉都可以完全恢復(fù)。但是這樣的算法也有它的弱點(diǎn)，不太適合突發(fā)性的丟包。因?yàn)檫@個(gè)分組不宜太大，如果分組很大，分組就有很大的延時(shí)。分組如果很小，很可能整個(gè)分組都丟掉了。實(shí)際上這種做法就沒(méi)有任何意義。所以它不太適合突發(fā)性丟包，而且它畢竟是根據(jù)先驗(yàn)知識(shí)去做的一種冗余，也就是說(shuō)它永遠(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ā)過(guò)去，不需要等到你發(fā)現(xiàn)丟包時(shí)我再做怎樣的冗余傳輸，所以不受網(wǎng)絡(luò)往返的影響。而且這種分組可以任意、隨機(jī)調(diào)整大小冗余度，比較適合均勻丟包的場(chǎng)景。

圖 10

另外一項(xiàng)技術(shù)是丟包重傳技術(shù)。相對(duì)來(lái)說(shuō)，丟包重傳相對(duì)RS來(lái)講，更有針對(duì)性，所以恢復(fù)效率比較高。第一個(gè)Go Back N技術(shù)是類(lèi)似于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)，它知道哪些包是沒(méi)有收到的，但是并不精準(zhǔn)。

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

圖 12

關(guān)于信道編碼的思考。信道編碼和網(wǎng)絡(luò)吞吐呈反比關(guān)系。無(wú)論是重傳性編碼還是冗余性編碼，都會(huì)占用帶寬，從而減低實(shí)際媒體信息的吞吐量。現(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ǔ)回來(lái)，這是一個(gè)有效性。即使這個(gè)包補(bǔ)回來(lái)了，但是如果經(jīng)過(guò)一個(gè)信道編碼策略之后，還有一些丟包。例如原來(lái)的丟包是20%，補(bǔ)回來(lái)變成1%，那么這個(gè)重傳在我們的評(píng)價(jià)當(dāng)中實(shí)際上是沒(méi)有效果的，因?yàn)?%的丟包對(duì)音頻來(lái)講是無(wú)所謂的，但是對(duì)視頻來(lái)講是很卡的。在這樣的評(píng)價(jià)系統(tǒng)中，補(bǔ)回來(lái)還有1%的丟包，那么所有的編碼都是沒(méi)有太大意義的。舉這個(gè)例子，如果在這時(shí)信道也發(fā)生擁塞，再進(jìn)行這樣的信道編碼，就不會(huì)達(dá)到很好的效果。這個(gè)時(shí)候是否應(yīng)該停止所有的信道編碼呢?

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

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

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

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

還有一個(gè)延遲，大家都能看到的，就是網(wǎng)絡(luò)分發(fā)延遲。如何去減小?除了在資源集中找到一個(gè)最優(yōu)子集之外，還有信道編碼的東西，要做一個(gè)很好的信道編碼系統(tǒng)，我們?nèi)绾卧u(píng)價(jià)信道編碼系統(tǒng)的好壞。有了這些思路之后，可以指導(dǎo)我們?nèi)プ龈玫南乱徊降拈_(kāi)發(fā)工作。

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

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