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。
音頻數據的處理，需要完成回聲消除 AEC、降噪 ANS 和自動增益控制 AGC，AEC 和 ANS 在做什麼可能比較容易理解，AGC 在字面上含義可能不那麼直觀。AGC 用於對錄製的聲音做一些自動的放大或縮小，以使得聲音的接收者聽到的聲音大小不會有劇烈的變動，比如說話者說話的聲音比較小，AGC 會做一些放大，是聲音的接收者也能聽得清。此外，抗丟包也是音頻數據處理的重要內容。數據包在網絡中傳輸時丟失是再正常不過的事了，不像通用的可靠傳輸協議如 TCP 和 QUIC 那樣，對時效性要求不是那麼高，且需要對數據的傳輸可靠性做很強的保證，在 RTC 這種對時效性要求極高的場景中，一般通過音頻數據處理來解決，比如傳輸 3 個包，第1個和第3個收到了，但第二個丟失了，音頻數據處理會通過一些軟件算法，補上第二幀數據的內容，儘管聲音可能會有一定的失真，但用戶體驗還是會好很多。WebRTC 的代碼中包含了大量用於完成音頻數據處理的內容，其中 3A 主要由 AudioProcessing 完成，抗丟包則由 NetEQ 完成。 還可以對聲音應用一些音效，如混響，變聲等等等。音頻數據處理，特別是抗丟包和 3A 是 RTC 中一個非常精巧的部分，也是 RTC 相對於其它音視頻系統的一個比較大的不同點。
音頻數據的編碼和解碼，主要分爲硬編硬解和軟便軟解。硬編硬解主要藉助於終端設備上專門的硬件，通過特定終端系統提供的專門 API 來完成。軟編軟解則通過跨平臺的一些專門的編解碼庫來完成，如 WebRTC 中包含有 OPUS 等格式的音頻軟件編解碼器，fdkaac 庫可以用於 AAC 的編碼解碼等。RTC 的編解碼立足於其它音視頻系統編解碼的長久發展，但也有一些它自己特別的地方：一是碼率的動態變化，即網絡傳輸狀態的信息反饋到編解碼模塊中，編碼碼率會動態的變化，以實現更好的延遲和音質的平衡；二是專門爲 RTC 而生的編解碼方式，如 OPUS 等。
視頻數據的編碼解碼，同樣分爲硬編硬解和軟編軟解。硬編硬解同樣主要藉助於終端設備上專門的硬件，通過特定終端系統提供的專門 API 來完成。軟編軟解同樣通過跨平臺的一些專門的編解碼庫來完成，如 WebRTC 中包含有 VP8、VP9 等格式的視頻軟件編解碼器，x264 和 openh264 庫可以用於 H264 的編碼解碼，x265 可以用於 H265 的編碼解碼等。相對於音頻，視頻的硬編硬解通常要更加重要一點。軟編軟解對於許多終端的系統平臺而言，實現高分辨率高幀率的流暢的編碼解碼和播放幾乎是不可能實現的。與音頻類似，RTC 中的視頻編碼碼率也可能會根據網絡傳輸狀況的變化而變化。
不僅要高分辨率的流暢低延遲播放，對視頻數據的處理，做出各種酷炫的效果，是吸引到衆多用戶的良好手段。
實時音視頻中，除了音視頻的內容外，網絡傳輸相關的技術也十分重要。實時音視頻傳輸目前應用最多的就是基於 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，以實現良好的用戶體驗。對於擁塞控制，除了丟包重傳，FEC 前向冗餘糾錯也是比較常見的一個手段。RTSP 是基於 RTP/RTCP 設計的一種得到廣泛應用的實時音視頻流傳輸協議。QUIC 是另外一種基於 UDP 的，有可能可以用於實時音視頻傳輸的網絡協議。在實時音視頻的開發中，對於相關的網絡協議的瞭解幾乎是必不可少的。
如我們前面提到的，實時音視頻技術相對於之前的音視頻技術有一個巨大的不同，即網絡傳輸的部分檢測到的網絡狀況，對於音視頻的採集編碼處理和播放都有巨大的影響。在 WebRTC 中有相當一部分代碼在處理這部分邏輯。
網絡協議也好，編解碼也好，都需要具體實現的庫提供支持，才能真正地應用於項目之中。之前的音視頻系統中會用到的大量相關庫在實時音視頻系統中同樣會被用到，如 ffmpeg，libx264，fdkaac，openh264 等。WebRTC 是實時音視頻領域的一個集大成者，其中繼集成了許多早已存在的音視頻相關的庫，同時也實現了許許多多實時音視頻領域中專有的邏輯。
RTC 技術還要完成的一個重要的部分，就是提供良好的抽象，把前述各個子部分組合爲一個靈活強大完整的 PIPELINE，並呈現給用戶。
Done.