字節(jié)跳動(dòng)《實(shí)時(shí)音視頻通訊技術(shù)》學(xué)習(xí)筆記之RTC概述及技術(shù)簡介

字節(jié)跳動(dòng)《實(shí)時(shí)音視頻通訊技術(shù)》學(xué)習(xí)筆記之RTC概述及技術(shù)簡介

什么是實(shí)時(shí)音視頻

實(shí)時(shí)音視頻（RTC）即基于IP技術(shù)實(shí)現(xiàn)的實(shí)時(shí)交互的音視頻通信技術(shù)。

RTC 與 直播常用協(xié)議的區(qū)別

而這里我們要使用的RTC技術(shù)就厲害了~

它是基于IP技術(shù)的，它的延遲低于400ms，RTC傳輸?shù)膬?nèi)容是音視頻數(shù)據(jù)。

實(shí)時(shí)音視頻應(yīng)用場景

音視頻通話

產(chǎn)品功能

1V1，多人音視頻通話

可以美顏、使用道具等等。

技術(shù)特點(diǎn)

支持設(shè)備差異性大

網(wǎng)路接入經(jīng)常切換

因?yàn)檫@種產(chǎn)品主要是面向用戶的，不同用戶使用的設(shè)備的差別比較大。根據(jù)不同設(shè)備需要做不同的優(yōu)化。這就是為什么我們說支持設(shè)備差異性大。

而在實(shí)際情況中，經(jīng)常遇到移動(dòng)網(wǎng)絡(luò)4G、5G切換WIFI，或者基站之間的切換。這些導(dǎo)致網(wǎng)絡(luò)環(huán)境的變化需要中斷重連。

下面介紹兩種場景：抖音直播和直播連麥。

抖音直播

產(chǎn)品功能Ⅰ

電商直播

游戲直播

秀場直播

技術(shù)特點(diǎn)Ⅰ

主播段推流

觀眾端CDN拉流

直播連麥

產(chǎn)品功能Ⅱ

多個(gè)主播同框互動(dòng)，觀眾圍觀實(shí)況

K歌、游戲互動(dòng)、互動(dòng)交流

技術(shù)特點(diǎn)Ⅱ

服務(wù)端&客戶端合流

合流轉(zhuǎn)推

實(shí)時(shí)審核

直播連麥將多個(gè)主播的視頻流合流然后發(fā)送給觀眾。這種合流一般是在服務(wù)端做的，但是現(xiàn)在由于客戶端的性能不斷提高，現(xiàn)在出現(xiàn)了將合流放在客戶端的情況，這樣節(jié)約了成本。

我們都知道傳統(tǒng)直播技術(shù)的延遲比較高，從觀眾評(píng)論到看到主播反饋一般要5-10秒以上，那么這樣在教育直播、電商直播、體育直播等直播就會(huì)出現(xiàn)一些問題。

前面我們提到RTC能夠?qū)崿F(xiàn)低延遲的實(shí)時(shí)傳輸音視頻流，那么RTC可以應(yīng)用在直播場景嗎？

答案是是，因?yàn)橹灰覀儗⒒赥CP的網(wǎng)絡(luò)傳輸協(xié)議轉(zhuǎn)化為基于UDP的RTC就行了。

那為什么我們不一開始就使用RTC呢？

第一因?yàn)槌杀荆珻DN的成本是RTC的三分之一，RTC的部署是比較消耗資源的。

第二是因?yàn)镽TC是需要做很多網(wǎng)絡(luò)的優(yōu)化的，比較復(fù)雜。

普通直播替換為低延時(shí)直播的方案

拉流端（播放端）替換為RTC：收益大。

因?yàn)橛^眾端的延時(shí)比較大，所以一般是從觀眾端替換為RTC。

推流端（主播端）替換為RTC：收益中。

因?yàn)橹鞑ゾW(wǎng)絡(luò)環(huán)境一般還不錯(cuò)，所以不優(yōu)先考慮主播端。

RTC應(yīng)用場景：在線教育

一對一教育

產(chǎn)品功能

1V1 教學(xué)

白板、課件

云端錄制

監(jiān)課

技術(shù)特點(diǎn)

課件同步

音視頻通話類似

可能需要跨國

要求和音視頻通話一樣，需要及時(shí)反饋，需要低延遲，跨國一對一可能物理距離較遠(yuǎn)，導(dǎo)致延遲可能較高。

大班課

產(chǎn)品功能

萬人課堂

白板、課件

云端錄制

監(jiān)課

技術(shù)特點(diǎn)

1人發(fā)布

課件同步

大班課技術(shù)難度比1V1教育低，因?yàn)橐话闱闆r下只是老師一個(gè)人推流，不存在過多互動(dòng)。總的來看，大班課互動(dòng)性較差，學(xué)習(xí)體驗(yàn)可能不是很好。

于是，小班課就產(chǎn)生了，它有較強(qiáng)的互動(dòng)性，但是其難度最大，比1v1教育難度要高。因?yàn)槊總€(gè)人網(wǎng)絡(luò)環(huán)境不一樣，需要給不同用戶下發(fā)不同碼率的視頻。

小班課

產(chǎn)品功能

多人互動(dòng)

白板、課件

云端錄制

監(jiān)課

技術(shù)特點(diǎn)

多人發(fā)布與訂閱

課件同步

RTC使用場景：視頻會(huì)議

飛書視頻會(huì)議

產(chǎn)品功能

百（千）人視頻互動(dòng)

屏幕共享

文檔分享

PSTN接入

背景虛化，美顏…

技術(shù)特點(diǎn)

多人音視頻互動(dòng)

接入設(shè)備多樣性

音頻降噪

弱網(wǎng)優(yōu)化

AI能力

總體來說，視頻會(huì)議的技術(shù)難度較大，對音頻降噪的要求比較高，同時(shí)存在PSTN接入的情況。

RTC使用場景：游戲

游戲?qū)?zhàn)

產(chǎn)品功能

小隊(duì)語音

范圍語音

技術(shù)特點(diǎn)

低延遲、低耗能、流量小

范圍語音

因?yàn)橛螒虮容^耗計(jì)算機(jī)資源和網(wǎng)絡(luò)資源，又要求低延遲。所以需要達(dá)到低延遲、低耗能、流量小。

云游戲

產(chǎn)品功能

游戲運(yùn)行在服務(wù)端

客戶端渲染、控制

技術(shù)特點(diǎn)

超低延遲

海量控制指令

這樣即使設(shè)備性能不高也能實(shí)現(xiàn)嘗試高性能的游戲。適用于大型游戲和游戲試玩。

因?yàn)樾枰己玫挠螒蝮w驗(yàn)，就需要超低延遲。而且因?yàn)槲覀僐TC可以傳輸海量的控制指令，所以可以用于云游戲。

實(shí)時(shí)音視頻技術(shù)概覽

信令是一些控制指令，信令服務(wù)器可以用于呼叫、協(xié)調(diào)。

合流轉(zhuǎn)推等等這些操作是后處理服務(wù)器來完成的。

客戶端是音視頻通話的終端，我們來看看客戶端整體技術(shù)架構(gòu)。

QoS是保證在弱網(wǎng)的情況下仍然能夠使用。

事件上報(bào)是因?yàn)槿魏蔚娜罩径夹枰蟼鳎梢蕴幚礤e(cuò)誤和進(jìn)行性能優(yōu)化、算法改進(jìn)。

全平臺(tái)支持

設(shè)備適配

性能適配

連接保持

斷網(wǎng)重連

多徑傳輸

數(shù)據(jù)運(yùn)營

事件上報(bào)

日志收集

低性能的設(shè)備使用低性能的算法。

同時(shí)支持WIFI、4G就需要實(shí)現(xiàn)多徑傳輸。

采集到音視頻等數(shù)據(jù)需要進(jìn)行編碼壓縮然后通過網(wǎng)絡(luò)傳輸，然后解碼播放。

信令：為使網(wǎng)絡(luò)中各種設(shè)備協(xié)調(diào)運(yùn)作，在設(shè)備之間傳遞的控制信息。

信令服務(wù)器：就是用來傳輸、中專信令的服務(wù)器。

常見問題

全球化部署

信令到達(dá)率

連接保持

實(shí)現(xiàn)方案

WebSocket

自定義協(xié)議

媒體服務(wù)器：在終端用戶之間中轉(zhuǎn)音視頻流，進(jìn)而讓用戶之間可以進(jìn)行音視頻通信。通常部署在邊緣，距離用戶較近的地方。

Simulcast&SVC是根據(jù)不同用戶的網(wǎng)絡(luò)狀況提供不同碼率、幀率的視頻。

BWE&擁塞控制是用來估計(jì)用戶的可用帶寬，來判斷給用戶發(fā)送多大碼率的碼流。

下面來看看幾種媒體服務(wù)器的典型架構(gòu)：

音視頻錄制

合流轉(zhuǎn)推

截圖、切片

審核

數(shù)據(jù)運(yùn)營

質(zhì)量評(píng)估

QoS

自動(dòng)化測試

應(yīng)用場景探索

需要數(shù)據(jù)才能優(yōu)化，視頻是否清晰，音頻是否悅耳這就需要質(zhì)量評(píng)估。

自動(dòng)化測試和質(zhì)量評(píng)估也是比較重要的。

去探索新的應(yīng)用場景也是非常重要的。

實(shí)時(shí)音視頻 視頻

版權(quán)聲明：本文內(nèi)容由網(wǎng)絡(luò)用戶投稿，版權(quán)歸原作者所有，本站不擁有其著作權(quán)，亦不承擔(dān)相應(yīng)法律責(zé)任。如果您發(fā)現(xiàn)本站中有涉嫌抄襲或描述失實(shí)的內(nèi)容，請聯(lián)系我們jiasou666@gmail.com 處理，核實(shí)后本網(wǎng)站將在24小時(shí)內(nèi)刪除侵權(quán)內(nèi)容。