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

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

01 PART 直播行業(yè)的背景 1.1 直播行業(yè)新變化

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

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

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

教育類

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

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

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

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

弱網(wǎng)場景，可靠傳輸導致數(shù)據(jù)積壓

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

ACK機制導致通道利用率低

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

上圖是我們云端的優(yōu)化效果，通過邊緣區(qū)域的網(wǎng)格增強，平坦區(qū)域直接上采樣、紋理區(qū)域網(wǎng)絡(luò)增強。

540p的視頻優(yōu)化前效果

優(yōu)化后的效果，它的邊緣和細節(jié)清晰了很多

責任編輯：lq