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