隨著直播業務的發展，在線教育，連麥直播、賽事直播等高實時性直播場景的出現，用戶對于直播流暢度、低延遲等性能的要求愈加嚴苛。騰訊云直播技術高級工程師陳華成 從5G時代未來直播產品的發展趨勢、直播行業業務新需求出發，分享騰訊云快直播（超低延遲直播）的建設方案、應用以及技術優勢與優化實踐。

大家好，我是騰訊云直播技術高級工程師陳華成，這次和大家分享的主題是騰訊云快直播——超低延遲直播技術方案及應用。主要涵蓋以下四個方面：直播行業的背景；直播行業的現狀；快直播（超低延遲直播）方案；快直播——延遲、秒開、抗性、畫質提升。

01 PART 直播行業的背景 1.1 直播行業新變化

首先我們來看一下整個直播行業在近期有哪些新的變化。5G的到來將使得邊緣帶寬由Mb增長至Gb、帶寬容量增加、延遲由30ms減小至1ms左右；此外應用場景也將得到豐富，調研發現與5G最相關的10大場景均是低延遲音視頻應用，比如電商類、在線教育、云游戲、VR、AR、物聯網、自動駕駛等等。 1.2 快直播（超低延遲直播）應用場景 本次分享主要介紹兩個快直播（超低延遲直播）應用場景。

直播帶貨興起——要求延遲小于500ms

首先是直播帶貨。相信大家近一年對直播帶貨應用場景感受很深。據統計，今年五一期間整個直播帶貨量增長了五倍左右。那帶貨場景有哪些呢？其實就是把線下的促銷變成了線上，上圖中列舉了兩個典型場景。第一個是低價秒殺促銷，主播為了活躍氣氛帶動更多的人參與進來，她會給一些低價商品讓大家搶購，秒殺的過程要求延遲很低。第二個是主播為了活躍氣氛發紅包，這兩個場景對延遲的要求都很高。現在標準直播的延遲一般在三到幾十秒，是無法滿足帶貨需求的。延遲高也限制了帶貨新玩法的出現，導致現在的直播帶貨幾乎沒有互動。

教育類

第二類場景是教育類客戶大班課，大班課比較火的主要原因是名師價值最大化。在線教育類企業最主要就是把名師價值最大化，同時保證教學效果。在線教育大班課這種模式，老師面向的可能是上百萬學生在聽講，課程講解結束后老師一般會出一個題目讓學生練手，比如數學中配圖的解答題、英語的選擇題。如果延遲比較高達到幾十秒，那老師與學生的互動體驗就非常差，老師與學生之間收、發題目的過程會因為延遲較高，導致老師認為已經把題目發給學生，學生實際上還沒看到題目，而在老師收題時，學生可能剛看到題目或根本沒看到題目，從而導致收題率不高，學生投訴比較多，這是對低延遲剛性的需求。 02 PART 直播行業現狀 2.1 標準直播現狀

現在直播行業大多數用的是標準直播，它的直播協議主要是FLV、HLS、RTMP。FLV延遲一般在2-10秒左右，它的延遲因素主要是GOP大小和TCP弱網傳輸積壓。HLS的延遲更大，一般是幾秒到幾十秒，它的延遲因素主要是GOP大小和TS大小，HLS是以文件索引和下載的方式，它每個文件的的大小限制了它的延遲，很多播放器要等3個TS才播放，而3個TS可能就有幾十秒了，所以HLS在標準直播中延遲最高。此外RTMP的延遲因素主要是GOP大小和TCP弱網傳輸積壓。以上介紹的集中標準直播都是基于TCP的，當前QUIC的引入對弱網帶來的延遲有一定的改善，但QUC沒有流媒體特性，在這里不是一個最佳方案。 2.2 TCP不適合低延遲直播的原因

延遲確認+捎帶應答 帶來感知延遲

TCP有延遲確認和捎帶應答，比如數據發過來不是立即對每個數據響應ACK，攢一定的數據量才會響應，這就會帶來感知延遲，超低延遲整體只有幾百毫秒，這一部分帶來的延遲是不可忍受的。

弱網場景，可靠傳輸導致數據積壓

弱網場景下，像TCP機制會導致數據積壓。舉個例子，主播在推流，然后發送緩存，因為TCP有一個可靠緩存的對列，而網絡條件比較差的時候，發送窗口發送完了卻一直沒有ACK，窗口一直沒有往前滑動，就會導致直播這種實時傳播的數據積壓，甚至會導致幾秒鐘或幾十秒鐘的延遲。

ACK機制導致通道利用率低

ACK機制會導致通道利用率低，在ACK之后不是立馬就返回的，還有ACK的等待時間。在這段時間通道未被利用就會導致通道利用率變低。

無流媒體特性、可靠傳輸導致無效重傳

直播是有時效性的，上圖1、2、3、4、5、6，可以看到5、6數據已經過期了，但無效的重傳會一直重傳，直到傳輸成功，所以無效重傳進一步加劇擁塞。 綜合以上四點可以得出TCP不適合低延遲直播。 03 PART 快直播（超低延遲直播）方案 3.1 UDP是低延遲直播的必由之路

調研顯示，低延遲直播在業界的協議有QUIC、SRT、WebRTC、ORTC，比較而言QUIC的延時還是比較大的，因為他沒有流媒體功能；SRT、WebRTC、ORTC延遲都是毫秒級別的，都有流媒體特性，其中SRT、ORTC用的比較少，WebRTC生態繁榮，因此我們選擇了WebRTC做超低延遲。 3.2 延遲關鍵問題在哪里？

我們要做超低延遲，首先就要知道它們的超低延遲出現在哪里？整個直播過程從數據的采集、編碼都經過哪些過程？ 首先是視頻輸入攝像頭采集的數據，由YUV編碼成264、265數據，采集t0，編碼t1，推流傳輸t2，轉碼t3，再由CDN傳輸，經過視頻解碼，最終通過視頻顯示出來。在這個過程中攝像頭采集耗時很小，一般在十幾毫秒左右；編碼耗時通過調整編碼參數也能達到幾十毫秒；推流傳輸是和rtp相關的，基本耗時在十幾毫秒到幾十毫秒；如果采取高速轉碼，耗時也不高；最關鍵的是CDN傳輸和視頻解碼，用戶的網絡現在千奇百怪，對于網絡條件好的用戶，傳輸延遲可能不高，但對于網絡條件不好的用戶，傳輸延遲可能就要達到幾秒甚至幾十秒，所以TCP傳輸延遲是一個不可控的因素。在t5視頻播放和解碼階段，目前像Flash播放器、hls、rtmp播放器緩存需要6-10秒，播放器的緩存是產生延遲的關鍵原因。那為什么不在當前直播條件下把緩存調到0呢？這是由于調到0之后延遲雖然小了，但卡頓會很高。由此可以看到，延遲高的關鍵在于CDN的傳輸和播放解碼沒有很好地配合和互動。所以我們主要要解決這個問題。 3.3 快直播方案

快直播方案改造的就是從CDN分發節點到SDK、再到觀眾端播放這部分，這樣的好處在于主播推流中間的錄制、截圖、轉碼等都可以復用，接入簡單，可以同時出flv、rtmp、hls、WebRTC的數據流。 3.4 快直播對標準WebRTC進行了升級

此外快直播對標準WebRTC進行了升級。標準WebRTC存在很多限制，音頻只支持OPUS、視頻不支持H265（H265因為專利的一些問題，因為VP9和H265有競爭關系，谷歌更希望推VP9）、視頻不支持B幀、信令交互耗時長、無法透傳metadata，這些問題對于在線教育和主播帶貨是沒必要的，可以跳過。而有些客戶希望用metadata帶一些同步信息，顯然標準WebRTC是不支持的。 我們從五個方面對標準WebRTC進行升級，包括支持aac（同時支持adts、latm兩種封裝）、視頻支持H265和B幀、通過STP協商精簡了信令交互、可以關閉gtrs以及支持透傳metadata。上圖就是騰訊云快直播的Demo，從圖中可以看到支持H264、H265，Audio格式、加密開關。 3.5 快直播如何接入

快直播的接入其實非常簡單，只需要一步就可以從標準直播升級為快直播——升級播放端、其余全部復用。Web/H5端調用瀏覽器WebRTC接入快直播，App接入需要集成SDK。 3.6 快直播優勢

快直播有五大優勢： 1.全球分布、覆蓋廣泛（支持1100+節點，支持25個國家） 2.超大帶寬容量（我們的部門擁有了騰訊90%的流量，支持100T+帶寬） 3.質量好、成本低（抗30%丟包） 4.接入簡單（只要下行SDK做改造就可以了、功能完善、平滑兼容） 5.已大規模使用（內部已接入騰訊課堂、企鵝電競，外部已接入教育類、電商類的客戶） 04 PART 快直播——延遲、秒開、抗性、畫質提升 4.1 快直播延遲

我們現在能做到的延遲一般是300ms左右，極限延遲可以做到43ms，這個極限方案主要是給云游戲提供的，硬件編碼通過邊緣編碼處理的方式得以實現。 4.2 快直播首幀耗時秒開

標準WebRTC要經過sdp交互、ice、dtls握手、rtp/rtcp，這里第二步和第三步基本是可以跳過的，ice可以用簡單的storm來代替，dtls握手對于不需要加解密的也可以跳過，所以我們做了一個可以通過SRTP協商來關閉dtls握手，所以第二、第三步可以根據需求選擇性的開或者關，從而通過精簡信令優化首幀耗時。 第二點就是邊緣覆蓋，我們不同的地方是信令和流媒體sever都部署在邊緣節點，這就會保證用戶與我們信令和流媒體交互的時候RTT多數會很小，從而就會保證整個信令耗時很短。 另外還有一個影響首幀的是流媒體的回源，如果命中率不高，流媒體需要回源，也是一個首幀耗時的點，所以我們做了個調度按房間來收斂，提高命中率，也就是說在同一個省份看同一個房間的話都讓他走到同一個機房。通過以上三點優化首幀耗時基本達到100多ms。 4.3 快直播WebRTC抗性優化

WebRTC抗性怎么優化？這里抗性優化的本質是不斷 “感知 + 調整 ”來適配變化的網絡，這里的感知主要是RTT、丟包率、瓶頸帶寬，通過感知到的網絡的變化來調整發包策略、重傳策略、FEC冗余策略等等。上圖把網絡分為兩類，有丟包未擁塞的網絡（基站的信號弱，WiFi的信號弱），這種情況通過根據丟包率計算重傳次數，提高重傳成功率，也可以通過FEC冗余發包，在弱丟包或者少丟包的情況下不需要重傳。有丟包且擁塞的網絡，它的表現主要是是丟包且RTT變大，這種情況又分為兩種：一種是我們的碼率超過了瓶頸帶寬，第二個是碼率沒有超過瓶頸帶寬。上圖可以看出I幀與P幀的關系，在視頻會中比較特殊的是I幀一般比P幀大8-10倍左右，所以很多時候發包策略不受控制的時候，每次發一幀的時候就是很大的毛刺。

這里我們采取的是場景的識別和動態的適配。 第一種是碼率不是瓶頸，我們采用的是自適應的Pacing、根據I幀的播放時間以及buff將它平化掉，就會使得整個發包帶寬在瓶頸帶寬以下，從而兼顧幀率、幀大小、瓶頸帶寬、播放器緩存，整個丟包就會少很多。 第二種是碼率是瓶頸，也就是它的碼率在瓶頸帶寬以下，如果不降低發送的數據量就一定會導致擁塞。我們有兩種策略：一種是時域分層，在編碼的時候，將視頻幀分三到四個級別，比如I幀、P幀、B幀，因為有一些B幀是沒有依賴的，我們可以通過丟失一部分的幀直到碼率小于瓶頸帶寬，也就是通過降幀率達到降卡頓的效果。另一種方式是空域分層，比如說編碼的時候，我們會編高分辨率和低分辨率，對于弱網（碼率是瓶頸）的情況下，我們通過只發低分辨率的幀使碼率小于瓶頸帶寬。

以上是我們抗性優化的效果。從左上的圖片中可以看到我們在做pacing前I幀的毛刺是很大，通過pacing發包可以減少80%突發毛刺，通過這張圖可以看到在我們自己的應用上體現，WebRTC的質量是和flv相當的，而延遲從10秒降低到300ms，并且可以抗30%+丟包。 4.4 快直播畫質優化

畫質優化主要通過“云+端”來做協同優化，就是源流在編碼的時候做修復增強，再通過一定的算法把視頻進行壓縮輸出低碼率的流，同時在云端進行云上的預分析，檢測出視頻的紋理區域以及邊緣區域，然后把數據寫到SEI中去讀出紋理和邊緣區域，如果是上采樣就提高采樣率進行超分，這樣通過云端壓到低碼率、再由終端恢復到高碼率的策略從而達到畫質最強的效果。

上圖是我們云端的優化效果，通過邊緣區域的網格增強，平坦區域直接上采樣、紋理區域網絡增強。

540p的視頻優化前效果

優化后的效果，它的邊緣和細節清晰了很多

責任編輯：lq