音影片低延遲應用的四個技術實踐

• 2019 年 10 月 5 日
• 筆記

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

文 / 邱國欽

整理 / LiveVideoStack

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

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

1. 目錄

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

2. 影響音影片通訊延遲的關鍵構成

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 降低延遲是系統性工程

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

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

3. 音影片低延遲應用的技術實踐

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兩個人同時開始唱歌，如果啟動不一致就會出現時間差的問題。第二個問題是聽眾獨立播放兩路流，也可能出現步調不一致的情況，需要對兩路音頻流進行同步。

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

4. 總結與展望

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