音視頻低延遲應用的四個技術實踐

低延時是音視頻領域最常遇到的關鍵訴求，如何設計解決方案以知足低延時的應用場景相當重要，本文將基於低延時的解決方案和實例進行講解，分享一些應用的實踐，幫助開發者更快地將解決方案應用到產品中。內容來自即構科技互聯網業務部技術總監邱國欽在LiveVideoStackCon2019北京站上的精彩分享。

文 / 邱國欽
整理 / LiveVideoStack

你們好，我是即構科技互聯網業務開發技術總監邱國欽，衆所周知，在音視頻技術方面有高清無碼和低延遲這兩個很是吸引人的應用，今天我演講的主題就是關於音視頻低延遲應用的技術實踐。

首先作一個自我介紹，我到目前爲止從事互聯網音視頻軟件開發已經有9年的時間，前後就任於騰訊和即構科技，曾參與及主導QQ、即構音視頻SDK等軟件開發，目前在即構科技負責方案設計、評估與交付。

1. 目錄

本次的演講分爲三個部分，首先會從總體來分析影響音視頻通訊延遲的關鍵構成，基於延遲構成的認識，能夠探討一些音視頻低延遲應用的技術實踐，最後會對音視頻低延遲技術作一些總結以及對將來的展望。

1. 影響音視頻通訊延遲的關鍵構成

2.1 現有主流媒體系統的延遲對比

以現有主流流媒體系統爲例，HLS (HTTP Live Streaming)是Apple的動態碼率自適應技術，主要依託於現有的HTTP框架，加上Apple強有力的推進以後，造成了目前在包括IOS和各大瀏覽器上的普遍支持。可是HLS的傳輸單位是切片，默認狀態下切片的長度是6s，此外，瀏覽器爲了保證流暢，會在緩存3個切片後纔開始播放，理論上系統延遲就達到了18s。

LHLS是一種基於HTTP分塊傳輸編碼以下降HLS協議延遲爲目標的方案，它能夠作到3-7s的延遲，但它尚未被正式寫入標準協議中。Apple在今年的全球開發者大會上提出了一個新的草案，號稱能夠將延遲下降到2s，因爲沒有demo，真實性有待考證。

RTMP和HTTP-FLV都是由Adobe提出的，這兩種協議在優化比較好的狀況下能夠作到低延遲的效果，即構科技也支持RTMP，而且能夠將延遲控制在400ms之內，可是硬傷是在TCP發生丟包的狀況下沒法作流控，現實中的延遲可能會達到若干秒。由Google提出的WebRTC在實驗室條件下能夠將延遲控制在100ms之內，實測過程當中的延遲能夠控制在300-500ms之間。

最後是即構自研的實時音視頻通訊系統方案，這個方案在實驗室條件下能夠達到和WebRTC同樣的延遲，但在有網絡抖動和丟包的狀況下，即構的方案要優於WebRTC。

2.2 延遲的構成

延遲能夠理解爲聲音靠聲帶振動發聲，傳到別人耳朵裏的過程，在端到端的延遲中能夠分爲信號採集、前處理、編碼和傳輸這幾個步驟，流程中的每個環節都會引入延遲，若是想作到很細緻的優化，就要在每個環節下功夫。

2.2.1 數據採集過程當中的延遲

接下來一塊兒關注信號傳輸過程當中每個環節中須要關注的延時。數據的採集不少狀況下與設備和採集的參數配置相關，例如音頻一般須要考慮採樣頻率及採樣點數。若是以44.1K Hz採樣，1024採樣點緩衝區，採集延遲就會大於23.2ms；若是以48K Hz採樣，192採樣點緩衝區，這時的延遲只有4ms。對於採集延遲而言並非時間越短效果越好，而是須要在各項指標之間進行權衡，好比採樣點越少，CALLBACK的次數越多，交互增長使得CPU相應增長，幀越短可能須要拼幀來完成編碼等一系列的操做都會致使成本增長。

2.2.2 音頻前處理

關於音頻前處理大概可分爲音頻3A處理、變聲、視頻濾鏡和美顏、掛件，形成音頻前處理延遲的兩大因素分別是算法延遲和計算延遲。算法延遲是濾波器固有延遲，而計算延遲對音頻來講還能夠接受，但在對於視頻的計算延遲存在不少挑戰，首先計算量須要多少CPU週期與CPU相關，其次CPU帶來的異構計算和OpenGL都會帶來延遲。

2.2.3 編解碼

音視頻通訊延遲的編碼部分主要是指信源編碼，信源編碼須要作到減小傳輸所需字節數，壓縮數據量，壓縮也要權衡音/ 畫質、碼率、延遲和吞吐四個方面，所以選擇合適的編碼方案就顯得尤其重要。在同等碼率下編碼方案所用的延遲越高，壓縮質量也會越高，二者不可兼得。好比HE AAC在配置時不論CPU運行速度有多快，都會引入129ms的固有延時，而OPUS能夠把延時控制在10ms內，在同等低碼率條件下HE AAC的壓縮效果會比OPUS好，但咱們會將碼率提升到必定程度使得音質不會受損，在低延遲的狀況下仍是會選擇OPUS編碼方案。

H.264有多種編碼的類別，包括Baseline Profile和Main Profile，這兩種編碼方案的區別是Baseline Profile只產生I幀和P幀，而Main Profile除了I幀和P幀還產生雙向參考幀（B幀），假如編碼幀率是20幀每秒，一個B幀將會引入50ms的延遲，所以雖然Main Profile編碼方案的壓縮率更高，但在直播場景和實時通信場景都採用BaselineProfile編碼方案。關於計算延遲更多涉及到的是視頻部分，其中編碼分爲軟件編碼和硬件編碼兩部分，因爲軟件編碼能夠作的很是複雜，硬編的吞吐量大，當分辨率很大、碼流很大的時候，軟編是hold不住的，因此仍是要依賴硬編。

2.2.4 流媒體數據傳輸

傳輸在音視頻通訊中是很是複雜的過程，其中涉及到運營商、物理距離、接入方式和節點部署。光纖中光速可達到20萬km/s，從北京到深圳靠光纖傳遞信息大概須要10ms，但實際上數據每通過網絡中一個節點都會引入延遲，並可能出現丟包現象。使用traceroute能夠探測一個IP包送到目的地所通過的節點，經過發送 icmp 包，並指定 ip 包裏的 TTL字段的值。TTL 指的是 Time To Live，IP 協議爲了防止一個 IP 在網絡中無限遊蕩，每一個 IP 包都有這麼一個字段，一個 IP 每通過一個節點，都會把這個值減1，若是這個值變成 0，就會丟掉。將TTL從小設置到大，直到足夠送達目標地址。

但僅僅靠這兩個簡單的工具還不可以掌握網絡的複雜性，這是因爲有些服務器不響應 ICMP，致使沒有響應，或者網絡中某些節點，不會去修改 TTL，致使看到的節點數比真實的少，但這也不妨礙traceroute對網絡狀況和鏈路問題的判斷。網絡鏈路狀況是很是複雜的，可是咱們能夠針對應用場景和興趣給網絡建模，建模主要的參數有 RTT、丟包率和帶寬預測。

想要打造一個低延遲的通訊網絡，須要從如下各個層面入手：

首先須要有更好的網絡設施，好比光纖到戶（FTTH），5G，這些基礎建設是作低延遲優化的基礎。其次須要合理的服務器部署，作到就近接入，並作好全鏈路最優化路由。最後，現實的網絡情況丟包不可避免，所以須要針對實時流媒體傳輸優化的傳輸控制協議，好比作好重傳策略、帶寬估計以及根據網絡狀況加入編碼冗餘等。

2.3 5G對傳輸的影響

5G的到來意味着更好的網絡設施，而基礎建設也是低延遲的基礎。同時5G有三個應用場景， 第一個應用場景是加強型移動寬帶，能夠實時傳輸4K/8K的視頻；第二個應用場景是高可靠低延遲通訊，能夠實現自動駕駛和遠程操做等技術；第三個應用場景是大規模機器通訊（IoT），即構會更加關注5G在前兩個方面的應用。

5G自己有邊緣雲計算的需求，因此機房須要儘可能靠近基站，把核心網不少功能移到邊緣雲。另外設備也區域小型化，會有更多的機房空間騰出來，能夠用於邊緣雲建設；同時運營商也面臨提速降費的壓力，會有動力創造更多類型的營收。即構的網絡架構自己就是按轉控分離設計，邊緣雲用於數據轉發是很是合適的，因此咱們很是期待邊緣雲鋪開能夠進一步下降延時。

2.4 渲染對音視頻通訊延遲的影響

渲染主要是和系統接口打交道，重點是選擇合適的接口以及參數配置。
對於 Android來講，使用 OpenSL ES 接口才能達到低延遲的最佳效果。還有一些手機廠商的私有接口，好比華爲、OPPO、VIVO……例如耳返功能就有很多廠家提供了私有接口，能夠更低延遲的實現耳返。上圖列舉了廠家私有 API 的耳返優化效果，例如VIVO x9在沒有耳返優化的狀態下延遲達到279ms，而在開啓耳返優化後延遲降到了14ms，目前即構SDK已經能夠支持主流手機廠商的耳返優化。

2.5 下降延遲是系統性工程

總之，下降延遲是一個系統性工程，任何單個節點出現異常，都會引起總體的異常。而主要的優化思路（客戶端）也分爲採用更低延遲的算法和更合理的任務分割兩種。其實無論是在前處理仍是在編碼部分，都須要仔細考慮是否使用了更低延遲的算法，而更細粒度的任務分割可讓流水線更繁忙，壓榨設備的性能，減小延遲。

上圖所描述的任務分割粒度很粗，採集、前處理、編碼都一塊兒作完以後再交給傳輸，端解碼、後處理、渲染也一口氣作完。這種作法在設備性能好的狀況下，延遲能夠比下面流水線的延遲低。而使每個環節都有本身的隊列會引入額外的延遲，同時系統的吞吐量也會增長，能夠作更多的事情，這其中須要在設備算力和任務分割之間權衡。

1. 音視頻低延遲應用的技術實踐

3.1 低延遲應用的強互動性

低延遲應用的特色是強互動性，任何須要互動的場景都會對延遲有要求。互動的形式包括雙向流媒體、單向流媒體+獨立消息通道和單向流媒體。而這些形式的優化思路主要包括從架構設計與工程實現上逼近物理極限和從業務設計上下降用戶對真實延遲敏感度兩個方面。

好比視頻聊天場景，若是單向延遲達到了1秒，除去對方思考的時間，聽到對方的迴應就是2秒後的事情了，這樣的用戶體驗是很是糟糕的，將單向延遲控制在150ms之內用戶是能夠接受的。

3.1.1 直播應用場景舉例

直播場景最初採用CDN來作分發，但CDN延遲很高，這與直播場景需求很是不匹配，打賞反饋延遲過高將影響營收。可是低延遲同時也意味着高成本，而即構的產品策略是區分人羣，對部分VIP觀衆和少許參與「打賞」的觀衆採起低延時應用，而普通觀衆則採用低成本應用，由此達到節省成本的目的。

3.1.2 娃娃機應用場景舉例

在線抓娃娃是曾經很火的應用場景，而且我相信，隨着虛擬與現實、線上線下互動探索的更加深刻，後續還有會相似的應用場景出現。

娃娃機在不少商場都能見到，很是簡單也很受歡迎。爲了突破場地的限制讓你們隨時隨地抓娃娃，咱們推出了線上版本。

這個方案的架構很簡單，分爲娃娃機、傳輸網絡、玩家三部分。首先是娃娃機端，經過攝像頭拍攝娃娃機，推流出去，玩家從實時網絡把娃娃機的流拉回來觀看到娃娃機的視頻。這其中玩家的每個指令都須要及時響應並及時反饋給玩家。

針對在線抓娃娃的應用場景，咱們對延遲作了優化。首先以實時傳輸方案爲基礎定製採集設備、去掉視頻濾鏡以及去掉音頻。

首先是數據的採集，娃娃機的採集端是能夠控制的，所以能夠定製設備讓攝像頭穩定以60fps採集。其次，額外的前處理是沒有必要的，娃娃機不須要視頻濾鏡，另外的一個關鍵優化是去掉音頻，娃娃機抓手移動的聲音並無什麼吸引力，而去掉音頻所帶來對延遲的優化效果倒是很是明顯的，由於去掉音頻就至關於去除了音頻採集、音頻前處理、音頻編碼、音頻的傳輸、音畫對齊、音頻渲染等等環節所帶來的延遲，相似可優化的應用場景還有遠程挖掘機、遠程醫療和串流遊戲等。

3.1.3 AI教學

即構在去年年末推出了一套AI教學的方案，老師能夠根據教研設計，參考學生可能出現的反應，錄製好各類可能的視頻。在上課時根據學生答題的的結果播放對應的視頻。這個場景對延遲要求也很高，學生回答後須要及時的響應，不然學生會認爲在作點播，缺乏趣味性，即構的實時方案已經能夠知足以上場景對延遲的要求。從某種意義上看，這就是一個點播系統，只是經過優化把延遲下降，使得點播看起來像是實時視頻而已，在此基礎上加上AI就變成了AI教學。

在AI教學場景中還存在的問題是，不一樣的視頻片斷之間須要作好銜接，傳統的處理方法對拍攝的要求很高。爲了緩解這個問題，即構提供了視頻銜接過渡的優化方案，能夠根據機器學習自動生成過渡內容。

3.1.4 KTV合唱雙向流媒體互動舉例

雙向流媒體互動應用的場景之一是線上KTV合唱，如何把線下的 KTV 體驗帶到線上，讓人們突破空間約束一塊兒 KTV，即構提出瞭如下兩個方案。

方案一又能夠稱之爲「串行」方案。首先，歌手A隨着伴奏唱歌，並把伴奏和本身的歌聲一塊兒發送給歌手B；歌手B聽到A的歌聲以及伴奏後加入唱歌，同時，歌手B把混入從A收到的聲音推流給聽衆，爲了讓歌手A可以聽到B的聲音，B把本身的聲音推流給A。

方案一的優勢是即便網絡延遲較大，聽衆聽到的合唱老是合拍的，但缺點是A聽到B的聲音延遲是環回延遲，延遲沒法控制在100ms內，一般不能被用戶接受。

方案二又稱之爲「並行」方案。讓歌手A和B在本地播放伴奏，各自隨本地播放伴奏唱歌，單向的經過實時網絡推拉流，使得延遲只有原來的一半，聽到對方聲音的延遲只包括單向延遲。

但要讓這個方案徹底可行，就必須讓A和B兩我的同時開始唱歌，若是啓動不一致就會出現時間差的問題。第二個問題是聽衆獨立播放兩路流，也可能出現步調不一致的狀況，須要對兩路音頻流進行同步。

爲了讓合唱場景的用戶能夠同時開始唱歌，咱們須要一個可比較的時鐘信號。實際上咱們可讓雙方共同參考伴奏音樂的進度來做爲時鐘，將伴奏播放進度時間戳發送給對方，讓對方判斷本身是否超前了。啓動時間差能夠經過估算啓動時間差和加入合適的播放拉伸來進行消除。一方面咱們須要讓本身的方案儘可能作到各個角度都低延遲，另外一方面也須要從業務的設計上規避延遲所帶來的影響，這兩方面都是咱們在將來須要思考的方向。

1. 總結與展望

總結以上內容，低延遲的實現離不開各個環節的努力，包括客戶端、服務端和業務端，低延遲須要更優的Codec、更好的網絡設施、更好的傳輸協議（更底層的優化）和更深刻具體應用場景打磨細節，產學研緊密結合，在將來低延遲更加可靠以後，將會對音視頻應用帶來變革。