詳解音視頻直播中的低延時

高澤華，聲網 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。經過計算可知，傳輸須要約 35ms。數據在採集設備與播放設備端須要的採集、編解碼處理與播放緩衝延時計爲較高的值，30ms。那麼端到端的延時大概須要 65ms。請注意，咱們在這裏還忽略了音視頻文件自己、系統、光的衰減等因素帶來的影響。

因此，所謂「超低延時」也會遇到瓶頸。在任何實驗環境下均可以達到很低的延時，可是到實際環境中，要考慮邊緣節點的部署、主幹網絡擁塞、弱網環境、設備性能、系統性能等問題，實際延時會更大。在必定的網絡條件限制下，針對不一樣場景選擇低延時方案或技術選型時，就須要圍繞延時、卡頓、音頻質量、視頻清晰度等指標進行權衡與判斷。

---

聲網Agora 有獎徵文活動 正在進行中，只要你分享與聲網SDK相關的開發經驗博文，即有機會得到Cherry 機械鍵盤、T恤等聲網定製獎品。詳情請戳這裏