科普文：詳解音視頻直播中的低延時

1、音視頻實時通訊的應(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)生延時?？傮w可以分為三類：T1 ：設(shè)備端上的延時 音視頻數(shù)據(jù)在設(shè)備端上產(chǎn)生延時還可以細(xì)分。設(shè)備端上的延時主要與硬件性能、采用的編解碼算法、音視頻數(shù)據(jù)量相

2、關(guān)，設(shè)備端上的延時可達(dá)到30200ms ，甚至更高。如上表所示，音頻與視頻分別在采集端或播放端產(chǎn)生延時的過程基本相同，但產(chǎn)生延時的原因不同。音頻在設(shè)備端上的延時：? 音頻采集延時：采集后的音頻首先會經(jīng)過聲卡進行信號轉(zhuǎn)換，聲卡本身會產(chǎn)生延時，比如 M-Audio聲卡設(shè)備延遲1ms,艾肯聲卡設(shè)備延遲約為 37ms；? 編解碼延時：隨后音頻進入前處理、編碼的階段，如果采用 OPUS標(biāo)準(zhǔn)編碼, 最低算法延時大約需要2.560ms；? 音頻播放延時：這部分延時與播放端硬件性能相關(guān)。? 音頻處理延時：前后處理，包括AEC, ANS, AGC等前后處理算法都會帶來算 法延時，通常這里的延時就是濾波器階數(shù)。在

3、10ms 以內(nèi)。端網(wǎng)絡(luò)延時：這部分延時主要出現(xiàn)在解碼之前的jitter buffer 內(nèi)，如果在抗丟包處理中，增加了重傳算法和前向糾錯算法，這里的延時一般在20ms 到200ms 左右。但是受到j(luò)itter buffer 影響，可能會更高。視頻在設(shè)備端上的延時：? 采集延時：采集時會遇到成像延遲，主要由 CCD相關(guān)硬件產(chǎn)生，市面上較好 的CCr秒可達(dá)50幀，成像延時約為20ms,如果是一秒2025幀的CCD, 會產(chǎn)生 4050ms 的延時；? 編解碼延時：以H.264為例，它包含I、P、B三種幀（下文會詳細(xì)分析），如果是每秒30 幀相連幀，且不包括B 幀（由于B 幀的解碼依賴前后視頻幀會增加延

4、遲），采集的一幀數(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ù)器與播放端的

5、延時的有以下主幾個因素：客戶端同服務(wù)間的物理距離、客戶端和服務(wù)器的網(wǎng)絡(luò)運營商、終端網(wǎng)絡(luò)的網(wǎng)速、負(fù)載和網(wǎng)絡(luò)類型等。如果服務(wù)器就近部署在服務(wù)區(qū)域、服務(wù)器與客戶端的網(wǎng)絡(luò)運營商一致時，影響上下行網(wǎng)絡(luò)延時的主要因素就是終端網(wǎng)絡(luò)的負(fù)載和網(wǎng)絡(luò)類型。一般來說，無線網(wǎng)絡(luò)環(huán)境下的傳輸延時波動較大，傳輸延時通常在10100ms 不定。而有線寬帶網(wǎng)絡(luò)下，同城的傳輸延時能較穩(wěn)定的低至5ms10ms 。但是在國內(nèi)有很多中小運營商，以及一些交叉的網(wǎng)絡(luò)環(huán)境、跨國傳輸，那么延時會更高。T3 ：服務(wù)器間的延時在此我們要要考慮兩種情況，第一種，兩端都連接著同一個邊緣節(jié)點，那么作為最優(yōu)路徑，數(shù)據(jù)直接通過邊緣節(jié)點進行轉(zhuǎn)發(fā)至播放端；第二

6、種，采集端與播放端并不在同一個邊緣節(jié)點覆蓋范圍內(nèi)，那么數(shù)據(jù)會經(jīng)由“靠近 ”采集端的邊緣節(jié)點傳輸至主干網(wǎng)絡(luò)，然后再發(fā)送至“靠近 ”播放端的邊緣節(jié)點，但這時服務(wù)器之間的傳輸、排隊還會產(chǎn)生延時。僅以骨干網(wǎng)絡(luò)來講，數(shù)據(jù)傳輸從黑龍江到廣州大約需要30ms,從上海到洛杉磯大約需要110ms130ms 。在實際情況下，我們?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)不同。所以通常市面上

7、常見的“端到端延時”指的是 T2+T3延時低右！話質(zhì)量可靠不論是教育、社交、金融，還是其它場景下，大家在開發(fā)產(chǎn)品時可能會認(rèn)為“低延時 ”一定就是最好的選擇。但有時，這種 “追求極致 ”也是陷入誤區(qū)的表現(xiàn)，低延時不一定意味著通訊質(zhì)量可靠。由于音頻與視頻本質(zhì)上的差異，我們需要分別來講實時音頻、視頻的通訊質(zhì)量與延時之間的關(guān)系。音頻質(zhì)量與延時 音頻采樣示意圖影響實時音頻通訊質(zhì)量的因素包括：音頻采樣率、碼率、延時。音頻信息其實就是一段以時間為橫軸的正弦波，它是一段連續(xù)的信號（如上圖）。? 采樣率：是每秒從連續(xù)信號中提取并組成離散信號的采樣個數(shù)。采樣率越高，音頻聽起來越接近真實聲音。? 碼率： 它描述了單

8、位時間長度的媒體內(nèi)容需要空間。碼率越高，意味著每個采樣的信息量就越大，對這個采樣的描述就越精確，音質(zhì)越好。假設(shè)網(wǎng)絡(luò)狀態(tài)穩(wěn)定不變，那么采樣率越高、碼率越高，音質(zhì)就越好，但是相應(yīng)單個 采樣信息量就越大，那么傳輸時間可能會相對更長。對照我們之前的公式，如果想要達(dá)到低延時，那么可以提高網(wǎng)絡(luò)傳輸效率，比如提 高帶寬、網(wǎng)絡(luò)速度，這在實驗室環(huán)境下可以輕易實現(xiàn)。但放到生活環(huán)境中，弱網(wǎng)、 中小運營商等不可控的問題必定會影響網(wǎng)絡(luò)傳輸效率，最后結(jié)果就是通訊質(zhì)量沒有 保障。還有一種方法，就是降低碼率，那么會損失音質(zhì)。視頻質(zhì)量與延時影響實時視頻質(zhì)量的因素包括：碼率、幀率、分辨率、延時。其中視頻的碼率與音 頻碼率相似，是

9、指單位時間傳輸?shù)臄?shù)據(jù)位數(shù)。碼率越大，畫面細(xì)節(jié)信息越豐富，視 頻文件體積越大。幀：正如大家所知，視頻由一幀幀圖像組成，如上圖所示為H.264標(biāo)準(zhǔn)下的 視頻幀。它以I幀、P幀、B幀組成的GOP分組來表示圖像畫面（如下圖）： 幀是關(guān)鍵幀，帶有圖像全部信息；P 幀是預(yù)測編碼幀，表示與當(dāng)前與前一幀（ I 或 P 幀）之間的差別；B 幀是雙向預(yù)測編碼幀，記錄本幀與前后幀的差別。幀率：*它是指每秒鐘刷新的圖像幀數(shù)。*它直接影響視頻的流暢度，幀率越大，視頻越流暢。由于人類眼睛與大腦處理圖像信息非?？?，當(dāng)幀率高于24fps 時，畫面看起來是連貫的，但這只是一個起步值。在游戲場景下，幀率小于 30fps 就會讓人

10、感到畫面不流暢，當(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)定的情況

11、下，想獲得越低的延時，就需要在流暢度、視頻清晰度、音頻質(zhì)量等方面進行權(quán)衡。不同場景下的實時音視頻 我們通過下表看到每個行業(yè)對實時音視頻部分特性的大致需求。但是每個行業(yè)，不 僅對低延時的要求不同，對延時、音質(zhì)、畫質(zhì)，甚至功耗之間的平衡也有要求。在 有些行業(yè)中，低延時并非永遠(yuǎn)排在首位。游戲場景在手游場景下，不同游戲類型對實時音視頻的要求不同，比如狼人殺這樣的桌游，語音溝通是否順暢，對游戲體驗影響很大，所以對延時要求較高。其它類型游戲具體如下方表格所示。但滿足低延時，并不意味著能滿足手游開發(fā)的要求。因為手游開發(fā)本身存在很多痛點，比如功耗、安裝包體積、安全性等。從技術(shù)層面講，將實時音視頻與手游結(jié)合時，

12、 手游開發(fā)關(guān)注的問題有兩類：性能類與體驗類。? 性能類：包括SDK包大小、流量使用情況、CPU與內(nèi)存占用率、功耗? 體驗類：包括網(wǎng)絡(luò)延遲、回音消除、抗雜音能力等 在將實時音視頻與手游結(jié)合時，除了延時，更注重包的大小、功耗等。安裝包的大 小直接影響用戶是否安裝，而功耗則直接影響游戲體驗。社交直播場景目前的社交直播產(chǎn)品按照功能類型分有僅支持純音頻社交的，比如荔枝FM;還有音視頻社交的，比如陌陌。這兩類場景對實時音視頻的要求包括：直播答題場景在直播答題場景中，對實時音視頻的要求主要有如下兩點：? 音視頻質(zhì)量：與視頻直播類似，畫面與音質(zhì)決定了用戶的直觀體驗? 直播與題目同步：直播畫面與題目的同步我們以

13、前經(jīng)常能看到主持人說完一道題，題目卻還沒發(fā)到手機上，最后只剩3 秒的答題時間，甚至沒看到題就已出局。該場景的痛點不是低延時，而是直播音視頻與題目的同步，保證所有人公平，有錢分。K 歌合唱場景天天K歌、唱吧等K歌類應(yīng)用中，都有合唱功能，主流形式是 A用戶上傳完整錄 音，B 用戶再進行合唱。實現(xiàn)實時合唱的主要需求有如下幾點：在這個場景中，兩人的歌聲與音樂三者之間的同步給低延時提出了很高的要求。同時，音質(zhì)也是關(guān)鍵，如果為了延時而大幅降低音質(zhì)，就偏離了K歌應(yīng)用的初衷金融場景 對于核保、銀行開戶來講，需要一對一音視頻通話。由于金融業(yè)特殊性，該類應(yīng)用 對實時音視頻的需求，按照重要性來排序如下： 在這個場景

14、中，低延時不是關(guān)鍵。重要的是，要保證安全性、雙錄功能和系統(tǒng)平臺 的兼容。在線教育在線教育主要分為兩類：非K12 在線教育，比如技術(shù)開發(fā)類教學(xué)，該場景對實時音視頻的要求主要有：? 音視頻播放流暢：直播音視頻畫面不會出現(xiàn)卡頓、畫面模糊等情況? 回放功能：一些有價值的演講，或技術(shù)門檻較高的內(nèi)容都需要有回放功能很多非 K12 教學(xué)發(fā)生在單向直播場景下，所以延時要求并不高。另一類是K12 在線教育，比如英語外教、部分興趣教學(xué)，通常會有一對一或一對多的師生連麥功能，它對直播場景的要求包括：在 K12 的在線教育中，師生的連麥在低延時方面有較高的要求。如果會涉及跨國 的英語教學(xué)，或需要面向偏遠(yuǎn)地區(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è)備端需要的采集