????????端到端通信互動技術(shù)可分解為以下幾個(gè)技術(shù)難點(diǎn)：客戶端技術(shù)、服務(wù)器技術(shù)、全球設(shè)備網(wǎng)絡(luò)適配技術(shù)和通信互動質(zhì)量監(jiān)控與展示技術(shù)。

一、音視頻直播

????????音視頻直播可分成兩條技術(shù)路線：一條是以音視頻會議為代表的實(shí)時(shí)互動直播；另一條是以娛樂直播為代表的流媒體分發(fā)。

????????互動直播主要解決人們遠(yuǎn)程音視頻交流的問題，所以其優(yōu)點(diǎn)是實(shí)時(shí)性強(qiáng)，時(shí)延一般低于500ms；而娛樂直播則主要解決音視頻的大規(guī)模分發(fā)問題，因此其在大規(guī)模分發(fā)上更具優(yōu)勢，但實(shí)時(shí)性比較差，通常時(shí)延在3s以上。

1.常見的直播技術(shù)

? ? ? ? 上表中，只有WebRTC技術(shù)用于實(shí)時(shí)互動直播，而其他幾種技術(shù)都用于娛樂直播。

????????HLS是基于HTTP的，它首先對媒體流（文件）進(jìn)行切片，然后通過HTTP傳輸，接收端則需要將接收到的切片進(jìn)行緩沖，之后才能將媒體流平穩(wěn)地播放出來。（實(shí)際上，最初娛樂直播也只有RTMP這一種方案可選，但后來由于蘋果宣布不再支持RTMP，并推出了自己的解決方案HLS，最終導(dǎo)致RTMP走向了消亡。）

????????將RTMP換成HLS需要付出高昂的成本，于是有人提出了HTTP-FLV方案，即傳輸?shù)膬?nèi)容仍然使用RTMP格式，但底層傳輸協(xié)議換成HTTP，這種方案既可以保障其實(shí)時(shí)性比HLS好，又可以節(jié)約升級的成本，因此也受到各方的歡迎。不過HTTP-FLV的擴(kuò)展性比較差，因此它只是一種臨時(shí)方案。

????????HLS方案雖然不錯(cuò)（有大量的用戶使用），但其他公司也有類似的方案，這使得各直播廠商不得不寫多套代碼，費(fèi)時(shí)費(fèi)力。于是，F(xiàn)FMPEG推出了DASH方案，該方案與HLS類似，也是以切片的方式傳輸數(shù)據(jù)，最終該方案成為國際標(biāo)準(zhǔn)，從而使直播廠商只要寫一套代碼就可以實(shí)現(xiàn)切片傳輸了。

2.音視頻直播的現(xiàn)狀

????????WebRTC的愿景是讓瀏覽器間可以快速、方便地實(shí)現(xiàn)端到端的實(shí)時(shí)音視頻互動。實(shí)時(shí)互動直播與娛樂直播技術(shù)相結(jié)合成為現(xiàn)在直播服務(wù)器的主流技術(shù)方案。

????????音視頻直播技術(shù)有兩個(gè)重要趨勢：一是實(shí)時(shí)互動直播技術(shù)與娛樂直播技術(shù)合二為一；二是WebRTC已經(jīng)是直播技術(shù)的標(biāo)準(zhǔn)，大家都在積極地?fù)肀ebRTC。

二、自研直播客戶端架構(gòu)

1.基本的五大模塊

????????一個(gè)最簡單的直播客戶端至少應(yīng)該包括：音視頻采集模塊、音視頻編碼模塊、網(wǎng)絡(luò)傳輸模塊、音視頻解碼模塊和音視頻渲染模塊五大部分。

? ? ? ? 細(xì)化一下，音頻的采集模塊與視頻的采集模塊是分開的，而音頻編解碼模塊與視頻的編解碼模塊也是分開的。也就是說，音頻采用了一條處理流程，視頻則采用了另外一條處理流程，它們之間并不相交。在音視頻處理中，我們一般稱每一路音頻或每一路視頻為一條軌。

2.支持跨平臺

????????除上述籠統(tǒng)的五大模塊之外，還需考慮跨平臺問題。只有在各個(gè)平臺上都能實(shí)現(xiàn)音視頻的互聯(lián)互通，才能稱得上是一個(gè)合格的音視頻直播客戶端。以音頻采集為例，在不同的平臺上，采集音頻數(shù)據(jù)時(shí)使用的系統(tǒng)API是不一樣的。PC端使用的是CoreAudio；Mac端使用的系統(tǒng)API也稱為CoreAudio，不過具體的函數(shù)名是不同的；Android端使用的是AudioRecord；iOS端使用的是AudioUnit；Linux端使用的是PulseAudio。

3.編解碼的插件化管理

????????對于音視頻直播客戶端來說，我們不但希望它可以處理音頻數(shù)據(jù)、視頻數(shù)據(jù)，而且還希望它可以分享屏幕、播放多媒體文件、共享白板……即使是處理音視頻，我們也希望它可以支持多種編解碼格式：

• 音頻除了可以支持Opus、AAC外，還可以支持G.711/G.722、iLBC、Speex等；
• 視頻除了可以支持H264外，還可以支持H265、VP8、VP9、AVI等。

????????G.711/G.722主要用于電話系統(tǒng)，音視頻直播客戶端要想與電話系統(tǒng)對接，就要支持這種編解碼格式；Opus主要用于實(shí)時(shí)通話；AAC主要用于音樂類的應(yīng)用，如鋼琴教學(xué)等。實(shí)現(xiàn)插件化管理可以很方便的使直播客戶端能夠支持盡可能多的編解碼器。

4.關(guān)注其他問題

• 音視頻不同步問題

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

• 3A問題

????????3A是指：Acoustic Echo Cancelling（AEC），即回音消除；Automatic Gain Control（AGC），即自動增益；Active Noise Control（ANC，也稱為Noise Cancellation、Noise Suppression），即降噪。

• 音視頻實(shí)時(shí)問題

????????TCP是以犧牲實(shí)時(shí)性來保障網(wǎng)絡(luò)服務(wù)質(zhì)量的。所以，為了保證實(shí)時(shí)性，一般情況下實(shí)時(shí)直播應(yīng)該首選UDP。

三、WebRTC客戶端架構(gòu)

?????????從WebRTC架構(gòu)圖中可以了解到，它大體上可以分成四層：接口層、Session層、核心引擎層和設(shè)備層。

• 接口層包括兩部分：一是Web層接口；二是Native層接口。也就是說，既可以使用瀏覽器開發(fā)音視頻直播客戶端，也可以使用Native（C++、Android、OC等）開發(fā)音視頻直播客戶端。
• Session層的主要作用是控制業(yè)務(wù)邏輯，如媒體協(xié)商、收集Candidate等。
• 核心引擎層包括的內(nèi)容比較多。從大的方面說，它包括音頻引擎、視頻引擎和網(wǎng)絡(luò)傳輸層。音頻引擎層包括NetEQ、音頻編解碼器（如Opus、iLBC）、3A等；視頻引擎包括JitterBufer、視頻編解碼器（VP8、VP9、H264）等；網(wǎng)絡(luò)傳輸層包括SRTP、網(wǎng)絡(luò)I/O多路復(fù)用、P2P等。
• 設(shè)備層主要與硬件打交道，它涉及的內(nèi)容包括：在各終端設(shè)備上進(jìn)行音頻的采集與播放，視頻的采集，以及網(wǎng)絡(luò)層等。

四、自研系統(tǒng)與WebRTC比較

?文章來源地址http://www.zghlxwxcb.cn/news/detail-633777.html

到了這里，關(guān)于WebRTC | 音視頻直播客戶端框架的文章就介紹完了。如果您還想了解更多內(nèi)容，請?jiān)谟疑辖撬阉鱐OY模板網(wǎng)以前的文章或繼續(xù)瀏覽下面的相關(guān)文章，希望大家以后多多支持TOY模板網(wǎng)！