作者：高澤華，聲網 Agora 音訊工匠，先後在中磊電子、士蘭微電子、虹軟科技主導音訊專案。任職 YY 期間負責語音音訊技術工作。在音樂、語音編解碼方面有超過十年的研發經驗。
音視訊實時通訊的應用場景已經隨處可見，從“吃雞”的語音對講、直播連麥、直播答題組隊開黑，再到銀行視訊開戶等。對於開發者來講，除了關注如何能快速實現不同應用場景重點額音視訊通訊，另一個更需要關注的可能就是“低延時”。但是，到底實時音視訊傳輸延時應該如何“低”，才能滿足你的應用場景呢？
延時的產生與優化
在聊低延時之前，我們先要講清延時是如何產生的。由於音視訊的傳輸路徑一樣，我們可以通過一張圖來說明延時的產生:
在音視訊傳輸過程中，在不同階段都會產生延時。總體可以分為三類：
T1：裝置端上的延時
音視訊資料在裝置端上產生延時還可以細分。裝置端上的延時主要與硬體效能、採用的編解碼演算法、音視訊資料量相關，裝置端上的延時可達到 30~200ms，甚至更高。如上表所示，音訊與視訊分別在採集端或播放端產生延時的過程基本相同，但產生延時的原因不同。
音訊在裝置端上的延時：
-
音訊採集延時：採集後的音訊首先會經過音效卡進行訊號轉換，音效卡本身會產生延時，比如 M-Audio 音效卡裝置延遲 1ms，艾肯音效卡裝置延遲約為 37ms；
-
編解碼延時：隨後音訊進入前處理、編碼的階段，如果採用 OPUS 標準編碼，最低演算法延時大約需要 2.5~60ms；
-
音訊播放延時：這部分延時與播放端硬體效能相關。
-
音訊處理延時：前後處理，包括 AEC，ANS，AGC 等前後處理演算法都會帶來演算法延時，通常這裡的延時就是濾波器階數。在 10ms 以內。
-
端網路延時：這部分延時主要出現在解碼之前的 jitter buffer 內，如果在抗丟包處理中，增加了重傳演算法和前向糾錯演算法，這裡的延時一般在 20ms 到 200ms 左右。但是受到 jitter buffer 影響，可能會更高。
視訊在裝置端上的延時：
-
採集延時：採集時會遇到成像延遲，主要由 CCD 相關硬體產生，市面上較好的 CCD 一秒可達 50 幀，成像延時約為 20ms，如果是一秒 20~25 幀的 CCD，會產生 40~50ms 的延時；
-
編解碼延時：以 H.264 為例，它包含 I、P、B 三種幀（下文會詳細分析），如果是每秒 30 幀相連幀，且不包括 B 幀（由於 B 幀的解碼依賴前後視訊幀會增加延遲），採集的一幀資料可能直接進入編碼器，沒有 B 幀時，編碼的幀延時可以忽略不計，但如果有 B 幀，會帶來演算法延時。
-
視訊渲染延時：一般情況下渲染延時非常小，但是它也會受到系統效能、音畫同步的影響而增大。
-
端網路延時：與音訊一樣，視訊也會遇到端網路延時。
另外，在裝置端，CPU、快取通常會同時處理來自多個應用、外接裝置的請求，如果某個問題裝置的請求佔用了 CPU，會導致音視訊的處理請求出現延時。以音訊為例，當出現該狀況時，CPU 可能無法及時填充音訊緩衝區，音訊會出現卡頓。所以裝置整體的效能，也會影響音視訊採集、編解碼與播放的延時。
T2：端與伺服器間的延時
影響採集端與伺服器、伺服器與播放端的延時的有以下主幾個因素：客戶端同服務間的物理距離、客戶端和伺服器的網路運營商、終端網路的網速、負載和網路型別等。如果伺服器就近部署在服務區域、伺服器與客戶端的網路運營商一致時，影響上下行網路延時的主要因素就是終端網路的負載和網路型別。一般來說，無線網路環境下的傳輸延時波動較大，傳輸延時通常在 10~100ms 不定。而有線寬頻網路下，同城的傳輸延時能較穩定的低至 5ms~10ms。但是在國內有很多中小運營商，以及一些交叉的網路環境、跨國傳輸，那麼延時會更高。
T3：伺服器間的延時
在此我們要要考慮兩種情況，第一種，兩端都連線著同一個邊緣節點，那麼作為最優路徑，資料直接通過邊緣節點進行轉發至播放端；第二種，採集端與播放端並不在同一個邊緣節點覆蓋範圍內，那麼資料會經由“靠近”採集端的邊緣節點傳輸至主幹網路，然後再傳送至“靠近”播放端的邊緣節點，但這時伺服器之間的傳輸、排隊還會產生延時。僅以骨幹網路來講，資料傳輸從黑龍江到廣州大約需要 30ms，從上海到洛杉磯大約需要 110ms~130ms。
在實際情況下，我們為了解決網路不佳、網路抖動，會在採集裝置端、伺服器、播放端增設緩衝策略。一旦觸發緩衝策略就會產生延時。如果卡頓情況多，延時會慢慢積累。要解決卡頓、積累延時，就需要優化整個網路狀況。
綜上所述，由於音視訊在採集與播放端上的延時取決於硬體效能、編解碼核心的優化，不同裝置，表現不同。所以通常市面上常見的“端到端延時”指的是 T2+T3。
延時低≠通話質量可靠
不論是教育、社交、金融，還是其它場景下，大家在開發產品時可能會認為“低延時”一定就是最好的選擇。但有時，這種“追求極致”也是陷入誤區的表現，低延時不一定意味著通訊質量可靠。由於音訊與視訊本質上的差異，我們需要分別來講實時音訊、視訊的通訊質量與延時之間的關係。
音訊質量與延時
影響實時音訊通訊質量的因素包括：音訊取樣率、位元速率、延時。音訊資訊其實就是一段以時間為橫軸的正弦波，它是一段連續的訊號（如上圖）。
取樣率：是每秒從連續訊號中提取並組成離散訊號的取樣個數。取樣率越高，音訊聽起來越接近真實聲音。
位元速率：它描述了單位時間長度的媒體內容需要空間。位元速率越高，意味著每個取樣的資訊量就越大，對這個取樣的描述就越精確，音質越好。
假設網路狀態穩定不變，那麼取樣率越高、位元速率越高，音質就越好，但是相應單個取樣資訊量就越大，那麼傳輸時間可能會相對更長。
對照我們之前的公式，如果想要達到低延時，那麼可以提高網路傳輸效率，比如提高頻寬、網路速度，這在實驗室環境下可以輕易實現。但放到生活環境中，弱網、中小運營商等不可控的問題必定會影響網路傳輸效率，最後結果就是通訊質量沒有保障。還有一種方法，就是降低位元速率，那麼會損失音質。
視訊質量與延時
影響實時視訊質量的因素包括：位元速率、幀率、解析度、延時。其中視訊的位元速率與音訊位元速率相似，是指單位時間傳輸的資料位數。位元速率越大，畫面細節資訊越豐富，視訊檔案體積越大。
**幀：**正如大家所知，視訊由一幀幀影像組成，如上圖所示為 H.264 標準下的視訊幀。它以 I 幀、P 幀、B 幀組成的 GOP 分組來表示影像畫面（如下圖）：I 幀是關鍵幀，帶有影像全部資訊；P 幀是預測編碼幀，表示與當前與前一幀（I 或 P 幀）之間的差別；B 幀是雙向預測編碼幀，記錄本幀與前後幀的差別。
**幀率：**它是指每秒鐘重新整理的影像幀數。它直接影響視訊的流暢度，幀率越大，視訊越流暢。由於人類眼睛與大腦處理影像資訊非常快，當幀率高於 24fps 時，畫面看起來是連貫的，但這只是一個起步值。在遊戲場景下，幀率小於 30fps 就會讓人感到畫面不流暢，當提升到 60fps 時會帶來更實時的互動感，但超過 75fps 後一般很難讓人感到有什麼區別了。
**解析度：**是指單位英寸中所包含的畫素點數，直接影響影像的清晰度。如果將一張 640 x 480 與 1024 x 768 的視訊在同一裝置上全屏播放，你會感到清晰度明顯不同。
在解析度一定的情況下，位元速率與清晰度成正比關係，位元速率越高，影像越清晰；位元速率越低，影像越不清晰。
在實時視訊通話情況下，會出現多種質量問題，比如：與編解碼相關的畫面糊、不清晰、畫面跳躍等現象，因網路傳輸問題帶來的延時、卡頓等。所以解決了低延時，只是解決了實時音訊通訊的一小部分問題而已。
綜上來看，如果在網路傳輸穩定的情況下，想獲得越低的延時，就需要在流暢度、視訊清晰度、音訊質量等方面進行權衡。
不同場景下的延時
我們通過下表看到每個行業對實時音視訊部分特性的大致需求。但是每個行業，不僅對低延時的要求不同，對延時、音質、畫質，甚至功耗之間的平衡也有要求。在有些行業中，低延時並非永遠排在首位。
遊戲場景
在手遊場景下，不同遊戲型別對實時音視訊的要求不同，比如狼人殺這樣的桌遊，語音溝通是否順暢，對遊戲體驗影響很大，所以對延時要求較高。其它型別遊戲具體如下方表格所示。
但滿足低延時，並不意味著能滿足手遊開發的要求。因為手遊開發本身存在很多痛點，比如功耗、安裝包體積、安全性等。從技術層面講，將實時音視訊與手遊結合時，手遊開發關注的問題有兩類：效能類與體驗類。
在將實時音視訊與手遊結合時，除了延時，更注重包的大小、功耗等。安裝包的大小直接影響使用者是否安裝，而功耗則直接影響遊戲體驗。
社交直播場景
目前的社交直播產品按照功能型別分有僅支援純音訊社交的，比如荔枝 FM；還有音視訊社交的，比如陌陌。這兩類場景對實時音視訊的要求包括：
直播答題場景
在直播答題場景中，對實時音視訊的要求主要有如下兩點：
我們以前經常能看到主持人說完一道題，題目卻還沒發到手機上，最後只剩 3 秒的答題時間，甚至沒看到題就已出局。該場景的痛點不是低延時，而是直播音視訊與題目的同步，保證所有人公平，有錢分。
K 歌合唱場景
天天 K 歌、唱吧等 K 歌類應用中，都有合唱功能，主流形式是 A 使用者上傳完整錄音，B 使用者再進行合唱。實現實時合唱的主要需求有如下幾點：
在這個場景中，兩人的歌聲與音樂三者之間的同步給低延時提出了很高的要求。同時，音質也是關鍵，如果為了延時而大幅降低音質，就偏離了 K 歌應用的初衷。
金融場景
對於核保、銀行開戶來講，需要一對一音視訊通話。由於金融業特殊性，該類應用對實時音視訊的需求，按照重要性來排序如下：
在這個場景中，低延時不是關鍵。重要的是，要保證安全性、雙錄功能和系統平臺的相容。
線上教育
線上教育主要分為兩類：非 K12 線上教育，比如技術開發類教學，該場景對實時音視訊的要求主要有：
很多非 K12 教學發生在單向直播場景下，所以延時要求並不高。
另一類是 K12 線上教育，比如英語外教、部分興趣教學，通常會有一對一或一對多的師生連麥功能，它對直播場景的要求包括：
在 K12 的線上教育中，師生的連麥在低延時方面有較高的要求。如果會涉及跨國的英語教學，或需要面向偏遠地區學生，那還要考慮海外節點部署、中小運營商網路的支援等。
線上抓娃娃
線上抓娃娃是近期新興熱點，主要依靠實時音視訊與線下娃娃機來實現。它對實時音視訊的要求包括：
瓶頸與權衡
產品的開發追求極致，需要讓延時低到極限。但理想豐滿，現實骨感。我們曾在上文提到，延時是因多個階段的資料處理、傳輸而產生的。那麼就肯定有它觸及天花板的時候。
我們大膽假設，要從北京機場傳輸一路音視訊留到上海虹橋機場。我們突破一切物理環境、財力、人力限制，在兩地之間搭設了一條筆直的光纖，且保證真空傳輸（實際上根本不可能）。兩地之間距離約為 1061 km。通過計算可知，傳輸需要約 3.5ms。資料在採集裝置與播放裝置端需要的採集、編解碼處理與播放緩衝延時計為較高的值，30ms。那麼端到端的延時大概需要 33.5ms。請注意，我們在這裡還忽略了音視訊檔案本身、系統、光的衰減等因素帶來的影響。
所以，所謂“超低延時”也會遇到瓶頸。在任何實驗環境下都可以達到很低的延時，但是到實際環境中，要考慮邊緣節點的部署、主幹網路擁塞、弱網環境、裝置效能、系統效能等問題，實際延時會更大。在一定的網路條件限制下，針對不同場景選擇低延時方案或技術選型時，就需要圍繞延時、卡頓、音訊質量、視訊清晰度等指標進行權衡與判斷。