RTC

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

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

前些年網絡帶寬，網絡技術如瀏覽器的快速進步，大大提升了視頻網站的用戶體驗，并使之得到了廣泛認可和應用，甚至使傳統的音視頻下載分發網站的市場大大萎縮。近些年及未來的計算能力提升，5G 網絡高帶寬低延遲傳輸技術提升，及音視頻處理技術的發展等，RTC 應用的用戶體驗極大提升和廣泛應用相信就在眼前了。

一般來說，一個完整的音視頻系統大概是這樣的：

一個完整的音視頻系統一般都會包含 音視頻采集 ， 音視頻數據的處理 ， 音視頻的編碼 ， 音視頻編碼數據的封裝 、 保存 ， 音視頻編碼數據的傳輸和分發 ， 音視頻的解碼 ， 音視頻數據的處理 ，和 音視頻的播放和渲染 。

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

這個時代中，音視頻產業鏈中的不同團隊可以更加專注于其中的一些環節，如音視頻采集、處理、編碼和封裝保存到文件由專門的團隊來做，音視頻文件的分發下載由專門的團隊來做，音視頻文件的分發下載所用到的技術和其它各種文件的分發下載技術基本上沒有本質任何區別，有專門的播放器團隊提供播放器供用戶下載使用。這個時代中，不同部分的工作，獨立性比較強，相互之間的影響較弱。

下載媒體文件通常要耗費比較多的時間，下載到本地之后又需要占用大量的磁盤空間來保存，這些問題都常常造成不好的用戶體驗。隨著網絡帶寬的增加，網絡傳輸技術的發展，以及瀏覽器的發展，解決媒體文件時代的問題的條件逐漸成熟，于是我們進入了視頻網站時代，或者說流媒體時代。

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

人民群眾的創造力才真正是無窮無盡的。隨著音視頻制作技術和工具的發展成熟和普及，特別是我們日常使用的手機等隨身攜帶的設備，都具備了強大的音視頻數據采集、處理和編碼等強大能力，我們進入了音視頻用戶生成內容（UGC）的時代。此時在許多視頻網站上出現了大量用戶自己制作和上傳的內容。相對于流媒體時代，此時的變化主要在于，充滿創造力的廣大人民，完成了大量的音視頻內容制作的事情。用戶欣賞音視頻資源的方式主要還是瀏覽器和 APP。

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

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

同時直播系統對于互動性的要求沒有那么強。技術上，傳輸過程中的問題，網絡狀況如帶寬和延遲的變化，向前面的采集編碼和處理，及后面的解碼和處理的反饋無需那么及時，影響也不會很大。

技術繼續向前發展，音視頻數據的采集、處理、編解碼和傳輸技術的進一步提升，人們隨手持有的終端設備的計算能力大為提升，網絡帶寬提升和延遲降低，RTC 無處不在終于成為了可能。

實時音視頻系統，相對于之前的音視頻系統，最大的區別在于傳輸，以及傳輸和音視頻數據處理、編解碼之間的相互作用相互關系。

網絡中通過 TCP 這種通用的可靠傳輸協議傳輸的數據，會由 TCP 層通過重傳排序等機制，解決互聯網數據傳輸天然具有的丟失、亂序和重復到達等問題。但在實時音視頻中，對數據傳輸的及時性的要求通常要高于可靠性的要求。如發送端采集的一幀編碼數據丟失了，對于接收播放端可能并沒有太大的影響，接收播放端可以利用收到的前面和后面的幀，通過補幀等技術，實現同樣好的用戶體驗，再如一幀音頻數據丟失了，接收端可以用 NetEQ 等技術，根據收到的前面和后面的數據，用算法填上這一幀的數據，而不會降低用戶體驗。這是實時音視頻中與一般的網絡傳輸不同的地方。

另外，在實時音視頻中，網絡狀況變化時，會對音視頻的采集編碼產生巨大的影響。在實時音視頻系統中，探測到網絡狀況變差時，這種信息會被反饋給音視頻的采集編碼模塊中，音視頻的采集編碼模塊則會根據一定的規則，降低分辨率或降低碼率等，以保證音視頻的流暢性。在實時音視頻中，一個終端，通常還需要扮演音視頻內容的制作者和播放渲染者兩種角色。

ffmpeg，x264，openh264，fdkaac，live555 等項目的開源和應用，使一般音視頻系統的實現，相對于幾十年前變得容易了許多，如播放器幾乎變得無處不在。Google 對 WebRTC 的開源，也使得實時音視頻系統的實現變得更加方便。不過，實時音視頻依然有著一個非常復雜的技術知識體系。

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

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

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

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

實時音視頻中，除了音視頻的內容外，網絡傳輸相關的技術也十分重要。實時音視頻目前應用最多的就是基于 UDP 的 RTP/RTCP 了。與 TCP 和 QUIC 這類通用的可靠傳輸協議不同，不同編解碼格式的數據，在通過 RTP/RTCP 傳輸時，通常都有一份專門的 RFC 協議文檔來定義具體的方法。如 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 等（更多相關的 RTC 文檔可以在 RTC 的 index 頁 https://tools.ietf.org/rfc/index 搜 “RTP Payload Format”）。實現了不同音視頻編解碼格式針對 RTP 的打包解包之后，還需要借助于 RTCP 報告的網絡狀況信息，實現各種精細的網絡傳輸控制，即擁塞控制 CC，以實現良好的用戶體驗。RTSP 是基于 RTP/RTCP 設計的一種得到廣泛應用的實時音視頻流傳輸協議。QUIC 是另外一種基于 UDP 的，有可能可以用于實時音視頻傳輸的網絡協議。在實時音視頻的開發中，對于相關的網絡協議的了解幾乎是必不可少的。

如我們前面提到的，實時音視頻技術相對于之前的音視頻技術有一個巨大的不同，即網絡傳輸的部分檢測到的網絡狀況，對于音視頻的采集編碼處理和播放都有巨大的影響。在 WebRTC 中有相當一部分代碼在處理這部分邏輯。

網絡協議也好，編解碼也好，都需要具體實現的庫提供支持，才能真正地應用于項目之中。之前的音視頻系統中會用到的大量相關庫在實時音視頻系統中同樣會被用到，如 ffmpeg，libx264，fdkaac，openh264 等。WebRTC 是實時音視頻領域的一個集大成者，其中繼集成了許多早已存在的音視頻相關的庫，同時也實現了許許多多實時音視頻領域中專有的邏輯。

來源: hanpfei.github.io/2020/03/22/rtc_knowledge_architecture/