RTC

RTC （ Real-time Communications ），直譯或者廣義指 實(shí)時(shí)通信 ，狹義一般稱為 實(shí)時(shí)音視頻 ，在這次全球大爆發(fā)的新冠肺炎疫情中，作為視頻會(huì)議、視頻通話、遠(yuǎn)程辦公、遠(yuǎn)程醫(yī)療和互動(dòng)直播等應(yīng)用的底層技術(shù)，為全社會(huì)的盡力運(yùn)轉(zhuǎn)提供了巨大的支持。

實(shí)時(shí)音視頻本身并不是最近才出現(xiàn)的新技術(shù)，很早以前的網(wǎng)絡(luò)教科書就已經(jīng)在介紹 RTP 和 RTCP 了，如道格拉斯·科默 (Douglas E.Comer) 的 《用TCP/IP進(jìn)行網(wǎng)際互聯(lián)》。互聯(lián)網(wǎng)語(yǔ)音通話、視頻通話和視頻會(huì)議等應(yīng)用，也不是剛剛出現(xiàn)的新東西，幾十年前這些應(yīng)用就已經(jīng)出現(xiàn)在許多地方了。只是受限于硬件的運(yùn)算能力、網(wǎng)絡(luò)傳輸帶寬、網(wǎng)絡(luò)傳輸技術(shù)和網(wǎng)絡(luò)應(yīng)用技術(shù)的發(fā)展，相關(guān)應(yīng)用的部署、成本和體驗(yàn)，一直不太盡如人意，因而應(yīng)用范圍也就比較受限。

前些年網(wǎng)絡(luò)帶寬，網(wǎng)絡(luò)技術(shù)如瀏覽器的快速進(jìn)步，大大提升了視頻網(wǎng)站的用戶體驗(yàn)，并使之得到了廣泛認(rèn)可和應(yīng)用，甚至使傳統(tǒng)的音視頻下載分發(fā)網(wǎng)站的市場(chǎng)大大萎縮。近些年及未來(lái)的計(jì)算能力提升，5G 網(wǎng)絡(luò)高帶寬低延遲傳輸技術(shù)提升，及音視頻處理技術(shù)的發(fā)展等，RTC 應(yīng)用的用戶體驗(yàn)極大提升和廣泛應(yīng)用相信就在眼前了。

一般來(lái)說(shuō)，一個(gè)完整的音視頻系統(tǒng)大概是這樣的：

一個(gè)完整的音視頻系統(tǒng)一般都會(huì)包含 音視頻采集 ， 音視頻數(shù)據(jù)的處理 ， 音視頻的編碼 ， 音視頻編碼數(shù)據(jù)的封裝 、 保存 ， 音視頻編碼數(shù)據(jù)的傳輸和分發(fā) ， 音視頻的解碼 ， 音視頻數(shù)據(jù)的處理 ，和 音視頻的播放和渲染 。

很多年以前，大家依賴于音視頻下載網(wǎng)站來(lái)欣賞音視頻的時(shí)代中，完整的音視頻系統(tǒng)中各個(gè)部分的角色和分工大概是這樣的：專業(yè)的音視頻制作團(tuán)隊(duì)完成音視頻的數(shù)據(jù)采集、處理、編碼和封裝保存，產(chǎn)生最終的如 mp3 文件，mp4 文件，flv 文件，mkv 文件等媒體文件；音視頻網(wǎng)站拿到這些音視頻文件放在他們的網(wǎng)站上，我們大家從音視頻網(wǎng)站上下載這些文件，如曾經(jīng)我們常常以百度為入口下載各種音視頻文件的網(wǎng)站；在我們本地的 PC 機(jī)，Mac，Android 或 iOS 設(shè)備中安裝有專門的播放器來(lái)播放這些文件，如很多年以前的千千靜聽(tīng)，Winamp，超級(jí)解霸，RealPlayer 等，后來(lái)出現(xiàn)的暴風(fēng)影音，VLC，QQ 影音等，從而欣賞到音視頻資源。這個(gè)時(shí)代的音視頻系統(tǒng)大概是這樣的：

這個(gè)時(shí)代中，音視頻產(chǎn)業(yè)鏈中的不同團(tuán)隊(duì)可以更加專注于其中的一些環(huán)節(jié)，如音視頻采集、處理、編碼和封裝保存到文件由專門的團(tuán)隊(duì)來(lái)做，音視頻文件的分發(fā)下載由專門的團(tuán)隊(duì)來(lái)做，音視頻文件的分發(fā)下載所用到的技術(shù)和其它各種文件的分發(fā)下載技術(shù)基本上沒(méi)有本質(zhì)任何區(qū)別，有專門的播放器團(tuán)隊(duì)提供播放器供用戶下載使用。這個(gè)時(shí)代中，不同部分的工作，獨(dú)立性比較強(qiáng)，相互之間的影響較弱。

下載媒體文件通常要耗費(fèi)比較多的時(shí)間，下載到本地之后又需要占用大量的磁盤空間來(lái)保存，這些問(wèn)題都常常造成不好的用戶體驗(yàn)。隨著網(wǎng)絡(luò)帶寬的增加，網(wǎng)絡(luò)傳輸技術(shù)的發(fā)展，以及瀏覽器的發(fā)展，解決媒體文件時(shí)代的問(wèn)題的條件逐漸成熟，于是我們進(jìn)入了視頻網(wǎng)站時(shí)代，或者說(shuō)流媒體時(shí)代。

在流媒體時(shí)代，用戶欣賞音視頻資源所需經(jīng)歷的鏈路大為縮短，成本降低，用戶體驗(yàn)大為提升。流媒體時(shí)代的音視頻資源主要還是由專門的制作團(tuán)隊(duì)在做。流媒體網(wǎng)站拿到音視頻文件，通常需要轉(zhuǎn)碼為更適宜分片傳輸下載的格式，流媒體網(wǎng)站整合瀏覽器的一些技術(shù)或流媒體播放技術(shù)，及傳輸技術(shù)，如 HLS，ffmpeg，HTML 5 等，使得用戶打開(kāi)瀏覽器或者 APP 就能直接欣賞音視頻資源。本質(zhì)上，此時(shí)在網(wǎng)絡(luò)中傳輸?shù)倪€是靜態(tài)的音視頻文件。網(wǎng)絡(luò)如果偶爾卡頓一下，播放端通常通過(guò)數(shù)據(jù)的預(yù)取或緩沖等方式來(lái)解決。

人民群眾的創(chuàng)造力才真正是無(wú)窮無(wú)盡的。隨著音視頻制作技術(shù)和工具的發(fā)展成熟和普及，特別是我們?nèi)粘Ｊ褂玫?a target="_blank">手機(jī)等隨身攜帶的設(shè)備，都具備了強(qiáng)大的音視頻數(shù)據(jù)采集、處理和編碼等強(qiáng)大能力，我們進(jìn)入了音視頻用戶生成內(nèi)容（UGC）的時(shí)代。此時(shí)在許多視頻網(wǎng)站上出現(xiàn)了大量用戶自己制作和上傳的內(nèi)容。相對(duì)于流媒體時(shí)代，此時(shí)的變化主要在于，充滿創(chuàng)造力的廣大人民，完成了大量的音視頻內(nèi)容制作的事情。用戶欣賞音視頻資源的方式主要還是瀏覽器和 APP。

音視頻用戶生成內(nèi)容（UGC）還催生了短視頻等極大豐富人們生活的工具。

此后，網(wǎng)絡(luò)傳輸技術(shù)進(jìn)一步發(fā)展，以降低延遲，并提升用戶體驗(yàn)，于是出現(xiàn)了火爆的網(wǎng)絡(luò)視頻直播，我們進(jìn)入視頻直播時(shí)代。立足于之前音視頻數(shù)據(jù)采集、處理、編碼和播放技術(shù)的發(fā)展，網(wǎng)絡(luò)帶寬的增加，網(wǎng)絡(luò)傳輸技術(shù)，如 RTMP，CDN 等的發(fā)展，各種形式的視頻直播，如娛樂(lè)，電商等大量出現(xiàn)。此時(shí)從內(nèi)容的制作，到這些內(nèi)容觸達(dá)用戶的時(shí)間和鏈路都大為縮短。從用戶側(cè)來(lái)看，這和視頻網(wǎng)站似乎沒(méi)有太大的區(qū)別，然而底層支撐技術(shù)則已是有了巨大的改變。音視頻內(nèi)容，在直播中，保存為各種格式封裝的文件不再那么必要。無(wú)封裝的裸的各種媒體流，由各種媒體數(shù)據(jù)傳輸協(xié)議運(yùn)載，穿行于我們的網(wǎng)絡(luò)中。盡管此時(shí)從內(nèi)容的制作到這些內(nèi)容觸達(dá)用戶的時(shí)間和鏈路大為縮短，但這其中的延遲，幾百 ms 一般還是有的。直播中的實(shí)時(shí)互動(dòng)性也沒(méi)有那么強(qiáng)。

同時(shí)直播系統(tǒng)對(duì)于互動(dòng)性的要求沒(méi)有那么強(qiáng)。技術(shù)上，傳輸過(guò)程中的問(wèn)題，網(wǎng)絡(luò)狀況如帶寬和延遲的變化，向前面的采集編碼和處理，及后面的解碼和處理的反饋無(wú)需那么及時(shí)，影響也不會(huì)很大。

技術(shù)繼續(xù)向前發(fā)展，音視頻數(shù)據(jù)的采集、處理、編解碼和傳輸技術(shù)的進(jìn)一步提升，人們隨手持有的終端設(shè)備的計(jì)算能力大為提升，網(wǎng)絡(luò)帶寬提升和延遲降低，RTC 無(wú)處不在終于成為了可能。

實(shí)時(shí)音視頻系統(tǒng)，相對(duì)于之前的音視頻系統(tǒng)，最大的區(qū)別在于傳輸，以及傳輸和音視頻數(shù)據(jù)處理、編解碼之間的相互作用相互關(guān)系。

網(wǎng)絡(luò)中通過(guò) TCP 這種通用的可靠傳輸協(xié)議傳輸?shù)臄?shù)據(jù)，會(huì)由 TCP 層通過(guò)重傳排序等機(jī)制，解決互聯(lián)網(wǎng)數(shù)據(jù)傳輸天然具有的丟失、亂序和重復(fù)到達(dá)等問(wèn)題。但在實(shí)時(shí)音視頻中，對(duì)數(shù)據(jù)傳輸?shù)募皶r(shí)性的要求通常要高于可靠性的要求。如發(fā)送端采集的一幀編碼數(shù)據(jù)丟失了，對(duì)于接收播放端可能并沒(méi)有太大的影響，接收播放端可以利用收到的前面和后面的幀，通過(guò)補(bǔ)幀等技術(shù)，實(shí)現(xiàn)同樣好的用戶體驗(yàn)，再如一幀音頻數(shù)據(jù)丟失了，接收端可以用 NetEQ 等技術(shù)，根據(jù)收到的前面和后面的數(shù)據(jù)，用算法填上這一幀的數(shù)據(jù)，而不會(huì)降低用戶體驗(yàn)。這是實(shí)時(shí)音視頻中與一般的網(wǎng)絡(luò)傳輸不同的地方。

另外，在實(shí)時(shí)音視頻中，網(wǎng)絡(luò)狀況變化時(shí)，會(huì)對(duì)音視頻的采集編碼產(chǎn)生巨大的影響。在實(shí)時(shí)音視頻系統(tǒng)中，探測(cè)到網(wǎng)絡(luò)狀況變差時(shí)，這種信息會(huì)被反饋給音視頻的采集編碼模塊中，音視頻的采集編碼模塊則會(huì)根據(jù)一定的規(guī)則，降低分辨率或降低碼率等，以保證音視頻的流暢性。在實(shí)時(shí)音視頻中，一個(gè)終端，通常還需要扮演音視頻內(nèi)容的制作者和播放渲染者兩種角色。

ffmpeg，x264，openh264，fdkaac，live555 等項(xiàng)目的開(kāi)源和應(yīng)用，使一般音視頻系統(tǒng)的實(shí)現(xiàn)，相對(duì)于幾十年前變得容易了許多，如播放器幾乎變得無(wú)處不在。Google 對(duì) WebRTC 的開(kāi)源，也使得實(shí)時(shí)音視頻系統(tǒng)的實(shí)現(xiàn)變得更加方便。不過(guò)，實(shí)時(shí)音視頻依然有著一個(gè)非常復(fù)雜的技術(shù)知識(shí)體系。

音視頻的采集和播放渲染，通常是與終端系統(tǒng)平臺(tái)緊密相關(guān)的。實(shí)時(shí)音視頻系統(tǒng)通常借助于終端系統(tǒng)平臺(tái)提供的 API 和能力來(lái)完成這一功能。如對(duì)于音頻的采集和播放，Android 有 AudioTrack、OpenSLES 和 AAudio，Linux 有 ALSA 和 Pulse 等，iOS、Mac 和 Windows 系統(tǒng)也都各有自己的音頻采集和播放 API。對(duì)于視頻的采集，通常不同的系統(tǒng)平臺(tái)也都有各自訪問(wèn)攝像頭的 API，和完成屏幕錄制的 API。對(duì)于視頻的播放和渲染，則需要借助于不同系統(tǒng)平臺(tái)提供的圖形和渲染接口來(lái)實(shí)現(xiàn)，如 OpenGL ES。

音頻數(shù)據(jù)的處理，需要完成回聲消除，降噪，自動(dòng)增益控制，和變聲之類的各種不同的音效。WebRTC 的代碼中包含了大量用于完成音頻數(shù)據(jù)處理的內(nèi)容。

音頻數(shù)據(jù)的編碼和解碼，主要分為硬編硬解和軟便軟解。硬編硬解主要借助于終端設(shè)備上專門的硬件，通過(guò)特定終端系統(tǒng)提供的專門 API 來(lái)完成。軟編軟解則通過(guò)跨平臺(tái)的一些專門的編解碼庫(kù)來(lái)完成，如 WebRTC 中包含有 OPUS 等格式的音頻軟件編解碼器，fdkaac 庫(kù)可以用于 AAC 的編碼解碼等。

視頻數(shù)據(jù)的編碼解碼，同樣分為硬編硬解和軟編軟解。硬編硬解同樣主要借助于終端設(shè)備上專門的硬件，通過(guò)特定終端系統(tǒng)提供的專門 API 來(lái)完成。軟編軟解同樣通過(guò)跨平臺(tái)的一些專門的編解碼庫(kù)來(lái)完成，如 WebRTC 中包含有 VP8、VP9 等格式的視頻軟件編解碼器，x264 和 openh264 庫(kù)可以用于 H264 的編碼解碼，x265 可以用于 H265 的編碼解碼等。相對(duì)于音頻，視頻的硬編硬解通常要更加重要一點(diǎn)。軟編軟解對(duì)于許多終端的系統(tǒng)平臺(tái)而言，實(shí)現(xiàn)高分辨率高幀率的流暢的編碼解碼和播放幾乎是不可能實(shí)現(xiàn)的。

實(shí)時(shí)音視頻中，除了音視頻的內(nèi)容外，網(wǎng)絡(luò)傳輸相關(guān)的技術(shù)也十分重要。實(shí)時(shí)音視頻目前應(yīng)用最多的就是基于 UDP 的 RTP/RTCP 了。與 TCP 和 QUIC 這類通用的可靠傳輸協(xié)議不同，不同編解碼格式的數(shù)據(jù)，在通過(guò) RTP/RTCP 傳輸時(shí)，通常都有一份專門的 RFC 協(xié)議文檔來(lái)定義具體的方法。如 RFC6184 （RTP Payload Format for H.264 Video），RFC7741 （RTP Payload Format for VP8 Video），RFC7587 （RTP Payload Format for the Opus Speech and Audio Codec），RFC7587 （RTP Payload Format for High Efficiency Video Coding (HEVC)），及 How to Write an RTP Payload Format 的 RFC8088 等（更多相關(guān)的 RTC 文檔可以在 RTC 的 index 頁(yè) https://tools.ietf.org/rfc/index 搜 “RTP Payload Format”）。實(shí)現(xiàn)了不同音視頻編解碼格式針對(duì) RTP 的打包解包之后，還需要借助于 RTCP 報(bào)告的網(wǎng)絡(luò)狀況信息，實(shí)現(xiàn)各種精細(xì)的網(wǎng)絡(luò)傳輸控制，即擁塞控制 CC，以實(shí)現(xiàn)良好的用戶體驗(yàn)。RTSP 是基于 RTP/RTCP 設(shè)計(jì)的一種得到廣泛應(yīng)用的實(shí)時(shí)音視頻流傳輸協(xié)議。QUIC 是另外一種基于 UDP 的，有可能可以用于實(shí)時(shí)音視頻傳輸?shù)木W(wǎng)絡(luò)協(xié)議。在實(shí)時(shí)音視頻的開(kāi)發(fā)中，對(duì)于相關(guān)的網(wǎng)絡(luò)協(xié)議的了解幾乎是必不可少的。

如我們前面提到的，實(shí)時(shí)音視頻技術(shù)相對(duì)于之前的音視頻技術(shù)有一個(gè)巨大的不同，即網(wǎng)絡(luò)傳輸?shù)牟糠謾z測(cè)到的網(wǎng)絡(luò)狀況，對(duì)于音視頻的采集編碼處理和播放都有巨大的影響。在 WebRTC 中有相當(dāng)一部分代碼在處理這部分邏輯。

網(wǎng)絡(luò)協(xié)議也好，編解碼也好，都需要具體實(shí)現(xiàn)的庫(kù)提供支持，才能真正地應(yīng)用于項(xiàng)目之中。之前的音視頻系統(tǒng)中會(huì)用到的大量相關(guān)庫(kù)在實(shí)時(shí)音視頻系統(tǒng)中同樣會(huì)被用到，如 ffmpeg，libx264，fdkaac，openh264 等。WebRTC 是實(shí)時(shí)音視頻領(lǐng)域的一個(gè)集大成者，其中繼集成了許多早已存在的音視頻相關(guān)的庫(kù)，同時(shí)也實(shí)現(xiàn)了許許多多實(shí)時(shí)音視頻領(lǐng)域中專有的邏輯。

來(lái)源: hanpfei.github.io/2020/03/22/rtc_knowledge_architecture/