音視頻通信為什么要選擇WebRTC？

在網(wǎng)上經(jīng)?？吹接腥苏f：“在線教育直播是用WebRTC做的”，“音視頻會議是用WebRTC做的”......；“聲網(wǎng)、騰訊、阿里......都使用的WebRTC”。但你有沒有好奇，這些一線大廠為什么都要使用WebRTC呢？換句話說，WebRTC到底好在哪里呢？

這個問題，對于長期做音視頻實時通信的老手來說是不言而喻的；但對于新手，則是急切想知道，而又很難得到答案的問題。那么本文我將采用對比法，向你詳細闡述一下WebRTC到底好在哪里。

這次我們對比的指標包括：性能、易用性、可維護性、流行性、代碼風格等多個方面。不過，要做這樣的對比并非易事兒，首先要解決的難點是，目前市面上沒有一款與WebRTC接近或有相似功能的開源庫。這真成了無米之炊了！

好在這點困難并難不倒我們，既然沒有與之可比較的開源庫，那我們就自己“造”一個，用自研系統(tǒng)與WebRTC作比較。評估一下自研系統(tǒng)與基于WebRTC開發(fā)的音視頻客戶端，哪個成本更低、質(zhì)量更好。通過這樣的對比，相信能讓你更加了解WebRTC，知道其到底有多優(yōu)秀了。

自研系統(tǒng)直播客戶端架構(gòu)

首先我們先來了解一下自研直播客戶端的架構(gòu)，其如（圖1）所示。這是一個最簡單的音視頻直播客戶端架構(gòu)，通過這張架構(gòu)圖，你大體可以知道自研系統(tǒng)都要實現(xiàn)那些模塊了。

由（圖1）你可以知道，一個最簡單的直播客戶端至少應(yīng)該包括：音視頻采集模塊、音視頻編碼模塊、網(wǎng)絡(luò)傳輸模塊、音視頻解碼模塊和音視頻渲染模塊五大部分。

• 音視頻采集模塊：該模塊調(diào)用系統(tǒng)的API，從麥克風和攝像讀取設(shè)備采集到的音視頻數(shù)據(jù)。音頻采集的是PCM數(shù)據(jù)，視頻采集的是YUV數(shù)據(jù)。
• 音視頻編碼模塊：它負責將音視頻設(shè)備上采集的原始數(shù)據(jù)（PCM、YUV)進行壓縮編碼。網(wǎng)
• 絡(luò)傳輸模塊：該模塊負責將編碼后的數(shù)據(jù)生成RTP包，并通過網(wǎng)絡(luò)傳輸給對端；同時，接收對端的RTP數(shù)據(jù)。
• 音視頻解碼模塊：它將網(wǎng)絡(luò)模塊接收到的壓縮數(shù)據(jù)進行解碼，還原回原始數(shù)據(jù)（PCM、YUV）。
• 音視頻渲染渲染：拿到解碼后的數(shù)據(jù)后，該模塊將音頻輸出到揚聲器，將視頻渲染到顯示器。

通過前面的介紹，相信你一定覺得，自研一個直播客戶端好像也不是特別難的事兒。但實際上，上面介紹的音視頻直播客戶端架構(gòu)是極簡化的，甚至都不能稱之為直播客戶端架構(gòu)，而只能稱它為示意圖。因為要將它變?yōu)檎鎸嵉摹⒖缮逃玫募軜?gòu)還需要做不少的細化工作。

拆分音視頻模塊

接下來，咱們就對上面的直播客戶端架構(gòu)圖進行逐步細化，細化的第一步就是拆分音視頻模塊。因為在實際開發(fā)中，音頻與視頻的處理是完全獨立的，它們有各自的處理方式。如音頻有獨立的采集設(shè)備（聲卡），獨立的播放設(shè)備（揚聲器）、訪問音頻設(shè)備的系統(tǒng)API等，另外，音頻還有多種音頻編解碼器，如Opus、AAC、iLBC等；同樣，視頻也有自己獨立的采集設(shè)備（攝像頭）、渲染設(shè)備（顯示器）、各種視頻編碼器，如H264、VP8等。細化后的直播客戶端架構(gòu)如（圖2）所示。

從（圖2）中你可以看到，細化后的架構(gòu)中，音頻的采集模塊與視頻的采集模塊是分開的，而音頻編解碼模塊與視頻的編解碼模塊也都是分開的。也就是說，音頻是一條處理流程，視頻是另外一條處理流程，它們之間并不相交。在音視頻處理中，我們一般稱每一路音頻或每一路視頻為一條軌。

除此之外，你還可以知道，自研音視頻直播客戶端要實現(xiàn)的模塊遠不止5個，至少應(yīng)該包括：音頻采集模塊、視頻采集模塊、音頻編碼/音頻解碼模塊、視頻編碼/視頻解碼模塊、網(wǎng)絡(luò)傳輸模塊、音頻播放模塊以及視頻渲染７個模塊。

跨平臺

實現(xiàn)音視頻直播客戶端除了要實現(xiàn)上面介紹的7個模塊外，還要考慮跨平臺的問題，只有在各個平臺上都能實現(xiàn)音視頻的互聯(lián)互通，才能稱得上是一個合格的音視頻直播客戶端。所以它至少應(yīng)該實現(xiàn)Windows端、Mac端、Android端以及iOS四個終端，當然如果還能夠支持Linux端和瀏覽器則是再好不過的了。

你要知道的是，如果不借助WebRTC，想在瀏覽器上實現(xiàn)音視頻實時互通，難度是非常大的，這是自研系統(tǒng)的一大缺陷。除了與瀏覽器互通外，其它幾個終端實現(xiàn)互通倒是相對較容易的事兒。

增加跨平臺后，音視頻直播客戶端的架構(gòu)要較之前復(fù)雜得多了，其如（圖3）所示。從這張圖中你可以看到，要實現(xiàn)跨平臺，難度最大、首當其沖的，是訪問硬件設(shè)備的模塊，如音頻采集模塊、音頻播放模塊、視頻采集模塊以及視頻播放模塊等，它們在架構(gòu)中的變化是最大的。

以音頻采集為例，在不同的平臺上，采集音頻數(shù)據(jù)時使用的API是完全不一樣的。PC端使用的是CoreAudio系列的API；巧合的是，Mac端用于采集音頻的系統(tǒng)API也稱為CoreAudio，不過具體的函數(shù)名肯定是不同的；在Android端，它為采集音視頻提供的API稱之為AudioRecord；iOS端，使用AudioUnit來采集音頻數(shù)據(jù)；而Linux端，則使用PulseAudio采集音頻數(shù)據(jù)。

總之，每個終端都有各自采集音視頻數(shù)據(jù)的API。由于不同的系統(tǒng)，其API設(shè)計的架構(gòu)也不同，所以在使用這些API時，調(diào)用的方式和使用的邏輯也千差萬別。因此，在開發(fā)這部分模塊時，其工作量是巨大的。

插件化管理

對于音視頻直播客戶端來說，我們不但希望它可以處理音頻數(shù)據(jù)、視頻數(shù)據(jù)，而且還希望它可以分享屏幕、播放多媒體文件、共享白板......此外，既使是處理音視頻，我們也希望它可以支持多種編解碼格式，如音頻除了可以支持Opus、AAC外，還可以支持G.711/G.722、iLBC、speex等；視頻除了可能支持H264外，還可以支持H265、VP8、VP9、AV1等，這樣它才能應(yīng)用的更廣泛。

實際上，這些音視頻編解碼器都有各自的優(yōu)缺點，也有各自適用的范圍。比如G.711/G.722主要用于電話系統(tǒng)，音視頻直播客戶端要想與電話系統(tǒng)對接，就要支持這種編解碼格式；Opus主要用于實時通話；AAC主要應(yīng)用于音樂類的應(yīng)用，如鋼琴教學(xué)等。所以，我們希望直播客戶端能夠支持盡可能多的編解碼器，這樣的直播客戶端才足夠強大。

如何才能做到這一點呢?最好的設(shè)計方案就是實現(xiàn)插件化管理。當你需要支持某個功能時，直接編寫一個插件放上去即可；當不需要的時候，可以隨時將插件拿下來，這樣的設(shè)計方案靈活、安全、可靠。

為了讓直播客戶端支持插件化管理，我對之前的架構(gòu)圖又做了調(diào)整。如（圖4）所示。從中你可以看到，為了支持插件化管理，我將原來架構(gòu)圖中的音視頻編解碼器換成音視頻編解碼插件管理器，而各種音視頻編解碼器（Opus、AAC、iLBC......）都可以作為一個插件注冊到其中。當你想使用某種類型的編碼器時，可以通過參數(shù)進行控制，這樣從音視頻采集模塊采集到的數(shù)據(jù)就會被送往對應(yīng)的編碼器進行編碼；當接收接收到RTP格式的音視頻數(shù)據(jù)時，又可以根據(jù)RTP頭中的Payload Type來區(qū)分，將數(shù)據(jù)交由對應(yīng)的解碼器進行解碼。經(jīng)這樣處理后，咱們的音視頻直播客戶端的功能就更強大了，應(yīng)用范圍也更廣了。

這里我以音頻編解碼器為例，簡要的向你介紹一下直播客戶端增加插件管理前后的區(qū)別?？蛻舳嗽谠黾硬寮芾碇?，它只能使用一種音頻編解碼器，如Opus。因此，在一場直播活動中，所有參與直播的終端都只能使用同一種音頻的編解碼器（Opus）。這樣看起來貌似也不會產(chǎn)生什么問題，是吧？不過，假如此時，我們想將一路電話語音接入到這場直播中（電話語音使用的編解碼器為G.711/G.722），它就無能為力了；而有了插件管理情況就不同了，各終端可以根據(jù)接收到的音頻數(shù)據(jù)類型調(diào)用不同的音頻解碼器進行解碼，從而實現(xiàn)不同編解碼器在同一場直播中互通的場景，這就是插件化管理給我們帶來的好處。

服務(wù)質(zhì)量

除了上面我介紹的幾點外，要實現(xiàn)一個功能強大的、性能優(yōu)越的、應(yīng)用廣泛的音視頻直播客戶端還有很多的工作要做，尤其將服務(wù)質(zhì)量是大家特別關(guān)心的。如果直播客戶端不能提供好的服務(wù)質(zhì)量，那它就失去了商業(yè)價值。

實時通信中的服務(wù)質(zhì)量指的是什么呢？它主要包括三個方面，一是通信時延?。欢峭染W(wǎng)路條件下視頻更清晰、流暢；三是同等網(wǎng)絡(luò)條件下語音失真小。如何才能保障通信時延小、視頻清晰、語音不失真呢？

這里的關(guān)鍵是網(wǎng)絡(luò)。如果直播客戶端可以保障用戶有一條非常好的網(wǎng)絡(luò)線路，在這條線路上傳輸?shù)臅r延最小、不丟包、不亂序，那我們的音視頻服務(wù)質(zhì)量自然就上去了，對吧！

但我們都知道，網(wǎng)絡(luò)的問題是最難解決的。出現(xiàn)丟包、抖動、亂序更是家常便飯。有的同學(xué)可以會說 TCP 不是已經(jīng)解決了丟包、亂序這些問題嗎？確實是，但它是以犧牲時延為代價的。當我們的網(wǎng)絡(luò)比較優(yōu)質(zhì)時，TCP/UDP都可以用于實時傳輸，但大多數(shù)情況下，我們首選UDP，原因是在弱網(wǎng)環(huán)境下使用TCP會產(chǎn)生極大的延時。

要想弄清楚TCP為什么在弱網(wǎng)環(huán)境下會產(chǎn)生極大的延時，就要介紹一點TCP的機制的了。TCP為了保證不丟包，不亂序，采用了發(fā)送、確認、丟包、重傳的機制。正常情況下，數(shù)據(jù)從一端傳輸?shù)搅硪欢耸菦]有任何問題的，但當出現(xiàn)丟包時就會有較大的麻煩。如圖所示。

圖中顯示了多次丟包時的延遲情況：從客戶端向服務(wù)端發(fā)送數(shù)據(jù)包，服務(wù)端需要返回ACK消息進行確認; 客戶端收到確認消息后, 才能繼續(xù)發(fā)送后面的數(shù)據(jù)（有滑窗時也是類似的）。每次客戶端發(fā)完數(shù)據(jù)后，都會啟動一個定時器，定時器的最短超時時間是200ms。如果因某種原因，在200毫秒客戶端沒有收到返回的ACK包，客戶端會重發(fā)上一個包。由于TCP有退避機制，以防止頻繁發(fā)送丟失的包，因此會將重發(fā)包的超時時間延長到400ms。如果重發(fā)包依然沒有收到確認消息，則下一次重發(fā)的超時時間會延長到800ms。我們可以看到，連續(xù)幾次丟包后，就會產(chǎn)生非常大的延遲，這就是TCP在弱網(wǎng)環(huán)境下不能使用的根本原因。

根據(jù)實時通信指標，超過 500ms 就不能稱為實時通信了，因此在弱網(wǎng)情況下，絕對不能使用TCP協(xié)議。實時通信的指標如（圖6）所示。

通過（圖6）中的表格可以看到，如果端到端延遲在200ms以內(nèi)，說明整個通話是優(yōu)質(zhì)的，通話效果就像大家在同一個房間里聊天一樣；300ms以內(nèi)，大多數(shù)人很滿意，400ms以內(nèi)，有小部分人可以感覺到延遲，但互動基本不受影響；500ms以上時，延遲會明顯影響互動，大部分人都不滿意。所以最關(guān)鍵的一點是500ms，只有延遲低于500ms，才可以說是合格的實時互動系統(tǒng)。

通過上面的描述我們可以知道，如果我們想在自己的直播客戶端中實現(xiàn)好的服務(wù)質(zhì)量，任務(wù)還是非常艱巨的。當然，除了上面要實現(xiàn)的功能外，還有其它很多需要處理的細節(jié)。

其它

音視頻不同步問題。音視頻數(shù)據(jù)經(jīng)網(wǎng)絡(luò)傳輸后，由于網(wǎng)絡(luò)抖動和延遲等問題，很可能造成音視頻不同步。因此，你在實現(xiàn)音視頻直播客戶端時，需要增加音視頻同步模塊以保障音視頻的同步。

回音問題?；匾魡栴}指的是，自己與其它人進行實時互動時，可以聽到自己的回聲。在實時音視頻通信中，不光有回音問題，還有噪音、聲音過小等問題，我們將它們統(tǒng)稱為3A問題。這些問題都是非常棘手的。目前開源的項目中，只有WebRTC和Speex有開源的回音消除算法，而且WebRTC的回音消除算法還是目前世界上最頂級的。

音視頻的實時性問題。要進行實時通信，網(wǎng)絡(luò)質(zhì)量尤為關(guān)鍵。但你應(yīng)該也清楚，網(wǎng)絡(luò)的物理層是很難保障網(wǎng)絡(luò)服務(wù)質(zhì)量的，必須在軟件層加以控制才行。雖然大家常用的TCP協(xié)議有一套完整的保障網(wǎng)絡(luò)質(zhì)量的方案，但它在實時性方面表現(xiàn)不佳。換句話說，TCP是以犧牲實時性來保障網(wǎng)絡(luò)服務(wù)質(zhì)量的，而實時性又是音視頻實時通信的命脈，這就導(dǎo)致TCP協(xié)議不能作為音視頻實時傳輸?shù)淖罴堰x擇了。因此，為了保證實時性，一般情況下實時直播應(yīng)該首選UDP協(xié)議。但這樣一來，我們就必須自己編寫網(wǎng)絡(luò)控制算法以保證網(wǎng)絡(luò)質(zhì)量了。

此外，還有網(wǎng)絡(luò)擁塞、丟包、延時、抖動、混音......不勝枚舉。可以說，要實現(xiàn)一個實時的音視頻直播客戶端有許許多多的問題要解決，這里我就不一一列舉了。總之，通過上面的描述，我想你已經(jīng)清楚要自己研發(fā)一套音視頻直播客戶端到底有多難了。

WebRTC客戶端架構(gòu)

實際上，在直播客戶端架構(gòu)一節(jié)我講的所有功能，WebRTC都已經(jīng)實現(xiàn)了。下面讓我們看一下WebRTC架構(gòu)圖吧，如（圖）所示。

從WebRTC架構(gòu)圖中你可以了解到，它大體上可以分成四層：即接口層、Session層、核心引擎層和設(shè)備層。下面我就向你簡要的介紹一下每一層的作用。

接口層包括兩部分，一是Web層接口；二是Native層接口。也就是說，你既可以使用瀏覽器開發(fā)音視頻直播客戶端，也可以使用Native(C++、Android、OC等)開發(fā)音視頻直播客戶端。

Session層的主要作用是控制業(yè)務(wù)邏輯，如媒體協(xié)商、收集Candidate等，這些操作都是在Session層處理的；

核心引擎層包括的內(nèi)容就比較多了。從大的方面說，它包括音頻引擎、視頻引擎和網(wǎng)絡(luò)傳輸層。音頻引擎層包括NetEQ、音頻編解碼器（如OPUS、iLBC)、3A等。視頻引擎包括JitterBuffer、視頻編解碼器（VP8/VP9/H264)等。網(wǎng)絡(luò)傳輸層包括SRTP、網(wǎng)絡(luò)I/O多路復(fù)用、P2P等。以上這些內(nèi)容中，本書重點介紹了網(wǎng)絡(luò)相關(guān)的內(nèi)容，它們分布在第三章音視頻實時通信的本質(zhì)、第六章WebRTC中的ICE實現(xiàn)、第九章RTP/RTCP協(xié)議詳解、第十章WebRTC擁塞控制等幾個章節(jié)中，由于篇幅的原因，其它內(nèi)容我會陸續(xù)發(fā)布在我的個人主站https://avdancedu.com上。

設(shè)備層主要與硬件打交道，它涉及的內(nèi)容包括：在各終端設(shè)備上進行音頻的采集與播放、視頻的采集以及網(wǎng)絡(luò)層等。這部分內(nèi)容會在本書的最后一章 \textbf{WebRTC源碼分析}中做詳細介紹。

從上面的描述中你可以看到，在WebRTC架構(gòu)的四層中，最復(fù)雜、最核心的是第三層，即引擎層，因此，這里我再對引擎層內(nèi)部的關(guān)系做下簡要介紹。引擎層包括三部分內(nèi)容，分別是：音頻引擎、視頻引擎以及網(wǎng)絡(luò)傳輸。其中音視引擎和視頻引擎是相對比較獨立的。不過，它們都需要與網(wǎng)絡(luò)傳輸層（transport）打交道。也就是說，它們都需要將自己產(chǎn)生的數(shù)據(jù)通過網(wǎng)絡(luò)傳輸層發(fā)送出去；同時，也需要通過網(wǎng)絡(luò)傳輸層接收其它端發(fā)過來的數(shù)據(jù)。此外，音頻引擎與視頻引擎由于要進行音視頻同步的原因，所以它們之間也存在著關(guān)聯(lián)關(guān)系。

最后，我們再次以音頻為例（如圖8所示），來看一下WebRTC中的數(shù)據(jù)流是如何流轉(zhuǎn)的吧。當WebRTC作為發(fā)送端時，它通過音頻設(shè)備采集到音頻數(shù)據(jù)后，先要進行3A處理，處理后的數(shù)據(jù)交由音頻編碼器編碼，編碼后由網(wǎng)絡(luò)傳輸層將數(shù)據(jù)發(fā)送出去；另一方面，當網(wǎng)絡(luò)傳輸層收到數(shù)據(jù)后，它要判斷數(shù)據(jù)的類型是什么，如果是音頻，它會將數(shù)據(jù)交給音頻引擎模塊處理，數(shù)據(jù)首先被放入到NetEQ模塊做平滑處理及音頻補償處理，之后進行音頻解碼，最終將解碼后的數(shù)據(jù)通過揚聲器播放出來。視頻的處理流程與音頻的處理流程是類似的，這里我就不再贅述了。

小結(jié)

通過上面對自研音視頻客戶端架構(gòu)的描述以及WebRTC客戶端架構(gòu)的描述，相信在你心中，對WebRTC的優(yōu)勢已經(jīng)非常清楚了。下面我再從性能、跨平臺、音視頻服務(wù)質(zhì)量、穩(wěn)定性等幾個方面對兩者做一下總結(jié)。如（圖9）所示：

（圖9）告訴我們，WebRTC在實時音視頻直播方面的優(yōu)勢是不言而喻的，又有Google的強大支持，這就是為什么大家都選擇WebRTC的真正原因了。

我的視頻課

WebRTC實時互動直播技術(shù)入門與實戰(zhàn) 5G時代必備技能 （戳鏈接直達課程）

百萬級高并發(fā)WebRTC流媒體服務(wù)器設(shè)計與開發(fā) （戳鏈接直達課程）

編程必備基礎(chǔ)-音視頻小白系統(tǒng)入門課 （戳鏈接直達課程）

OpenCV入門到進階：實戰(zhàn)三大典型項目 （戳鏈接直達課程）

經(jīng)典再升級-FFmpeg音視頻核心技術(shù)全面精講+實戰(zhàn) （戳鏈接直達課程）

我的新書

★本書深入淺出地對WebRTC技術(shù)進行了系統(tǒng)講解，既有原理又有實戰(zhàn)，從WebRTC是如何實現(xiàn)實時音視頻通信的，到如何應(yīng)用WebRTC庫實現(xiàn)音視頻通信，再到WebRTC源碼的剖析，逐步展開講解。此外，對WebRTC的傳輸系統(tǒng)進行了重點分析，相信讀者通過本書可以一窺WebRTC傳輸?shù)膴W秘。