1.1 兩條技術(shù)路線

1.1.1 以音視頻會(huì)議為代表的實(shí)時(shí)互動(dòng)直播

互動(dòng)直播主要解決音視頻遠(yuǎn)程交流問(wèn)題，實(shí)時(shí)性較強(qiáng)，時(shí)延一般低于500ms。

1.1.2?以?shī)蕵?lè)直播為代表的流媒體分發(fā)

娛樂(lè)直播主要解決音視頻大規(guī)模分發(fā)問(wèn)題，實(shí)時(shí)性較差，時(shí)延一般在3s以上。

1.2 直播技術(shù)

WebRTC用于實(shí)時(shí)互動(dòng)直播，RTMP、HTTP-FLV、HLS、DASH用于娛樂(lè)直播。

1.3?現(xiàn)狀與未來(lái)

1.3.1 現(xiàn)狀

實(shí)時(shí)互動(dòng)直播與娛樂(lè)直播技術(shù)相結(jié)合成為現(xiàn)在直播服務(wù)器的主流技術(shù)方案。

WebRTC不僅可以用在瀏覽器之間進(jìn)行音視頻互動(dòng)，還可以用在P2P傳輸、文本聊天、文本傳輸、游戲、多人實(shí)時(shí)互動(dòng)、音頻處理（回音消除、降噪）等應(yīng)用中，甚至是人工智能軟件上。

在一些實(shí)驗(yàn)產(chǎn)品中，可以使用RTMP推流，然后在瀏覽器上使用WebRTC技術(shù)拉流觀看，這種技術(shù)對(duì)于視頻監(jiān)控行業(yè)是個(gè)不錯(cuò)的解決方案。

1.3.2 未來(lái)

可以利用AI、深度學(xué)習(xí)技術(shù)對(duì)音視頻數(shù)據(jù)做二次處理，將這些非結(jié)構(gòu)化數(shù)據(jù)轉(zhuǎn)變成結(jié)構(gòu)化數(shù)據(jù)（存入數(shù)據(jù)庫(kù)或保存成格式化文件），再利用大數(shù)據(jù)技術(shù)分析生成各種報(bào)表，為業(yè)務(wù)提供支持和服務(wù)。

將AI和大數(shù)據(jù)分析速度提升到實(shí)時(shí)處理級(jí)別，讓產(chǎn)品可以根據(jù)視頻中用戶的面部表情、行為舉止實(shí)時(shí)改變服務(wù)內(nèi)容。

1.4?自研直播架構(gòu)

1.4.1 客戶端架構(gòu)

音頻采集PCM數(shù)據(jù)，視頻采集YUV數(shù)據(jù)。

音頻有獨(dú)立的采集設(shè)備（麥克風(fēng)/話筒）、獨(dú)立的播放設(shè)備（揚(yáng)聲器）、訪問(wèn)音頻設(shè)備的系統(tǒng)API、多種音頻編解碼器（如Opus、AAC、iLBC、G.711/G.722、Speex）等。

視頻也有自己的采集設(shè)備（攝像頭）、渲染設(shè)備（顯示器）、各種視頻編解碼器（如H264、VP8、H265、VP9、AVI）等。

在音視頻處理中，一般稱每一路的音頻/視頻為一條軌。

1.4.2 跨平臺(tái)架構(gòu)

1.4.3 插件化管理

1.4.4 其他問(wèn)題

1）音視頻不同步：增加音視頻同步模塊。

2）3A：AEC（Acoustic Echo Cancelling，回音消除）、AGC（Automatic Gain Control，自動(dòng)增益控制）、ANC（Active Noise Control，降噪）。

3）音視頻的實(shí)時(shí)性：網(wǎng)絡(luò)質(zhì)量很關(guān)鍵，物理層很難保障，需要在軟件層加以控制。

4）網(wǎng)絡(luò)擁塞、丟包、延時(shí)、抖動(dòng)、混音等。

1.4.5?自研系統(tǒng)與WebRTC比較

1.5?音視頻實(shí)時(shí)通信目標(biāo)

目標(biāo)：盡可能逼近或達(dá)到面對(duì)面交流的效果。

兩種指標(biāo)：實(shí)時(shí)通信延遲指標(biāo)和音視頻服務(wù)質(zhì)量指標(biāo)。

1.5.1?實(shí)時(shí)通信延遲指標(biāo)

端到端之間，引起延遲的因素有：音視頻采集時(shí)間、編解碼時(shí)間、網(wǎng)絡(luò)傳輸時(shí)間、音視頻的渲染時(shí)間、各種緩沖區(qū)所用的時(shí)間等。

1.5.2?視頻相關(guān)概念

1）分辨率：指圖像占用屏幕上像素的多少。對(duì)實(shí)時(shí)通信而言，圖像默認(rèn)分辨率一般設(shè)置為640*480或640*360。

2）幀率：指視頻每秒放幀（圖像）的數(shù)量。對(duì)實(shí)時(shí)通信而言，當(dāng)幀率小于15幀/秒時(shí)，會(huì)感覺(jué)視頻質(zhì)量不佳，卡頓嚴(yán)重。

3）碼率：指視頻壓縮后，每秒數(shù)據(jù)流的大小。相同分辨率下，碼率越大（MOS <= 5）還原度越好，圖像越清晰。

1.5.3?影響網(wǎng)絡(luò)質(zhì)量因素

1）丟包：網(wǎng)絡(luò)質(zhì)量最重要的指標(biāo)，對(duì)網(wǎng)絡(luò)影響最大。對(duì)WebRTC而言，大于2%且小于10%的丟包率是正常的網(wǎng)絡(luò)。

2）延遲：也是網(wǎng)絡(luò)質(zhì)量的重要指標(biāo)。如果兩端之間延遲持續(xù)增加，說(shuō)明網(wǎng)絡(luò)線路很可能發(fā)生了擁塞。

3）抖動(dòng)：對(duì)網(wǎng)絡(luò)質(zhì)量影響最小。如果抖動(dòng)很小，通過(guò)循環(huán)隊(duì)列將其消除；如果抖動(dòng)過(guò)大，將亂序包當(dāng)作丟包處理。在WebRTC中，抖動(dòng)時(shí)長(zhǎng)不能超過(guò)10秒，超過(guò)10秒就認(rèn)為該包丟了。

1.5.4?提高音視頻服務(wù)質(zhì)量

1）增加帶寬

① 5G落地：全面覆蓋。

② 客戶端WebRTC支持選路方案：按優(yōu)先級(jí)選擇最優(yōu)質(zhì)的的網(wǎng)絡(luò)連接線路。

③ 服務(wù)端方案：提供更優(yōu)質(zhì)的接入服務(wù)（讓用戶連接同一地區(qū)、同一運(yùn)營(yíng)商的接入服務(wù)器），保證云端網(wǎng)絡(luò)的帶寬和質(zhì)量（可以購(gòu)買優(yōu)質(zhì)的BGP網(wǎng)絡(luò)作為云內(nèi)部使用），更合理的路由調(diào)度策略（選擇距離最近、網(wǎng)絡(luò)質(zhì)量最好、服務(wù)器負(fù)載最小的線路）。

2）減少數(shù)據(jù)量

減少音視頻數(shù)據(jù)量是以犧牲音視頻服務(wù)質(zhì)量為代價(jià)。

① 更好的壓縮算法：H265壓縮率比H264提高了25%左右，AVI在veryslow模式下壓縮率比H264提高了40%左右。

② SVC技術(shù)：將視頻按時(shí)間、空間及質(zhì)量分成多層編碼，將它們裝在一路流中發(fā)給服務(wù)端。服務(wù)端再根據(jù)用戶帶寬情況選擇不同的層下發(fā)。

③ Simulcast技術(shù)：與SVC技術(shù)類似，實(shí)現(xiàn)比SVC簡(jiǎn)單。將視頻編碼出多種不同分辨率的多路碼流發(fā)給服務(wù)器，服務(wù)器根據(jù)用戶帶寬情況選擇其中一路最合適的碼流下發(fā)。

④ 動(dòng)態(tài)碼率：當(dāng)評(píng)估出用戶帶寬不夠時(shí)通過(guò)編譯器讓其減小輸出碼率；當(dāng)評(píng)估出帶寬增大時(shí)增大輸出碼率。

⑤ 甩幀或減少業(yè)務(wù)：甩幀或關(guān)閉某些不重要的業(yè)務(wù)。

3）適當(dāng)增加時(shí)延

增加時(shí)延，即先將數(shù)據(jù)放到隊(duì)列中緩沖一下，然后再?gòu)年?duì)列中獲取數(shù)據(jù)進(jìn)行處理，使數(shù)據(jù)變得"平滑"。

實(shí)時(shí)音視頻直播須將時(shí)延控制在一定范圍內(nèi)（單向延遲小于500ms）。

音視頻的采集、編解碼、渲染等時(shí)間是固定的，可以將網(wǎng)絡(luò)時(shí)延計(jì)算出來(lái)，就可以確定緩沖區(qū)的時(shí)延。

4）提高網(wǎng)絡(luò)質(zhì)量

① NACK/RTX ：NACK是RTCP中的一種消息類型，由接收端向發(fā)送端報(bào)告一段時(shí)間內(nèi)有哪些包丟失了；RTX是指發(fā)送端重傳丟失包，并使用新的SSRC將傳輸?shù)囊粢曨l包與重傳包進(jìn)行區(qū)分。

② FEC前向糾錯(cuò)：使用異或操作傳輸數(shù)據(jù)，以便在丟包時(shí)通過(guò)這種機(jī)制恢復(fù)丟失的包。FEC特別適合隨機(jī)少量丟包的場(chǎng)景。

③ JitterBuffer防抖動(dòng)：可以將抖動(dòng)較小的亂序包恢復(fù)成有序包。

④ NetEQ：專用于音頻控制，里面包括了JitterBuffer，另外還利用音頻的變速不變調(diào)機(jī)制將積攢的音頻數(shù)據(jù)快速播放或?qū)⒉蛔愕囊纛l拉長(zhǎng)播放，以實(shí)現(xiàn)音頻的防抖動(dòng)。

⑤ 擁塞控制：

WebRTC中擁塞控制算法：GCC（Google Congestion Control，Google擁塞控制）、BBR（Bottleneck Bandwidth and Round-trip propagation time，瓶頸帶寬和往返傳播時(shí)間）、PCC（Performance-oriented Congestion Control，基于性能的擁塞控制）

GCC根據(jù)實(shí)現(xiàn)分為：基于發(fā)送端的擁塞控制算法Transport-CC（Transport-wide Congestion Control，傳輸帶寬擁塞控制），基于接收端的擁塞控制算法Goog-REMB（Google Receiver Estimated Maximum Bitrate）。

5）快速準(zhǔn)確評(píng)估帶寬

實(shí)時(shí)通信領(lǐng)域有四種常見的帶寬評(píng)估方法：Goog-REMB、Goog-TCC、NADA、SCReAM。

NADA在準(zhǔn)確性和及時(shí)性方面好于GCC，GCC在網(wǎng)絡(luò)使用的公平性方面比NADA更具優(yōu)勢(shì)。在有丟包情況的網(wǎng)絡(luò)下，NADA表現(xiàn)極差，無(wú)法與GCC相比。SCReAM在各方面的表現(xiàn)都有失水準(zhǔn)。文章來(lái)源地址http://www.zghlxwxcb.cn/news/detail-834593.html

到了這里，關(guān)于WebRTC技術(shù)文檔 -- 1.音視頻直播（筆記）的文章就介紹完了。如果您還想了解更多內(nèi)容，請(qǐng)?jiān)谟疑辖撬阉鱐OY模板網(wǎng)以前的文章或繼續(xù)瀏覽下面的相關(guān)文章，希望大家以后多多支持TOY模板網(wǎng)！