騰訊雲快直播——超低延遲直播技術方案及應用
正文字數：4361 閱讀時長：7分鐘
隨着直播業務的發展，在線教育，連麥直播、賽事直播等高實時性直播場景的出現，用戶對於直播流暢度、低延遲等性能的要求愈加嚴苛。騰訊雲直播技術高級工程師陳華成 從5G時代未來直播產品的發展趨勢、直播行業業務新需求出發，分享騰訊雲快直播（超低延遲直播）的建設方案、應用以及技術優勢與優化實踐。
文 / 陳華成
整理 / LiveVideoStack
視頻回放：https://www.livevideostack.cn/video/online-huacheng/
大家好，我是騰訊雲直播技術高級工程師陳華成，這次和大家分享的主題是騰訊雲快直播——超低延遲直播技術方案及應用。主要涵蓋以下四個方面：直播行業的背景；直播行業的現狀；快直播（超低延遲直播）方案；快直播——延遲、秒開、抗性、畫質提升。
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的視頻優化前效果
優化後的效果，它的邊緣和細節清晰了很多
LiveVideoStackCon 2020 北京
2020年10月31日-11月1日
點擊【閱讀原文】瞭解更多詳細信息