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

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

從直播到線上抓娃娃

圖 1

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

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

圖 2

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

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

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

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

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

普通觀眾是通過圍觀服務(wù)器集群（延遲相對大的集群）去拉這些流的，這個集群的延遲可控性相對比較弱，有可能會出現(xiàn)這 9 路畫面之間的不同步現(xiàn)象，通過混流服務(wù)，觀眾拉的都是合成好的音視頻流，就不會出現(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é)議，因為前面提供一個更低延時的服務(wù)，后面要在 CDN 網(wǎng)絡(luò)上分發(fā)，所以協(xié)議也需要轉(zhuǎn)。

圖 3

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

圖 4

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

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

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

實時架構(gòu)的若干點思考

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

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

第一是實時音視頻是不能等的，因為等了就不是實時音視頻了。 不能等，這里會引入一個矛盾。既然不能等，例如你把實時音視頻也看作一個消費模型來看，那是提前生產(chǎn)還是按需生產(chǎn)？字面上理解很簡單，肯定是按需生產(chǎn)，需要的時候才生產(chǎn)，如果提前生產(chǎn)就是延時了。但是并不是每一個點都做成按需生產(chǎn)是合理的。

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

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

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

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

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

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

圖 5

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

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

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

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

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

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

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

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

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

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

圖 6

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

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

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

圖 7

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

圖 8

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

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

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

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

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

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

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

圖 9

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

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

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

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

圖 10

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

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

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

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

圖 11

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

圖 12

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

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

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

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

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

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

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

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