超低延遲直播技術(shù)方案及應(yīng)用

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

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

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

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

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

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

教育類

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

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

延遲確認(rèn)+捎帶應(yīng)答 帶來感知延遲

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

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

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

ACK機(jī)制導(dǎo)致通道利用率低

ACK機(jī)制會(huì)導(dǎo)致通道利用率低，在ACK之后不是立馬就返回的，還有ACK的等待時(shí)間。在這段時(shí)間通道未被利用就會(huì)導(dǎo)致通道利用率變低。

無流媒體特性、可靠傳輸導(dǎo)致無效重傳

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

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

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

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

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

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

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

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

標(biāo)準(zhǔn)WebRTC要經(jīng)過sdp交互、ice、dtls握手、rtp/rtcp，這里第二步和第三步基本是可以跳過的，ice可以用簡(jiǎn)單的storm來代替，dtls握手對(duì)于不需要加解密的也可以跳過，所以我們做了一個(gè)可以通過SRTP協(xié)商來關(guān)閉dtls握手，所以第二、第三步可以根據(jù)需求選擇性的開或者關(guān)，從而通過精簡(jiǎn)信令優(yōu)化首幀耗時(shí)。 第二點(diǎn)就是邊緣覆蓋，我們不同的地方是信令和流媒體sever都部署在邊緣節(jié)點(diǎn)，這就會(huì)保證用戶與我們信令和流媒體交互的時(shí)候RTT多數(shù)會(huì)很小，從而就會(huì)保證整個(gè)信令耗時(shí)很短。 另外還有一個(gè)影響首幀的是流媒體的回源，如果命中率不高，流媒體需要回源，也是一個(gè)首幀耗時(shí)的點(diǎn)，所以我們做了個(gè)調(diào)度按房間來收斂，提高命中率，也就是說在同一個(gè)省份看同一個(gè)房間的話都讓他走到同一個(gè)機(jī)房。通過以上三點(diǎn)優(yōu)化首幀耗時(shí)基本達(dá)到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ò)（基站的信號(hào)弱，WiFi的信號(hào)弱），這種情況通過根據(jù)丟包率計(jì)算重傳次數(shù)，提高重傳成功率，也可以通過FEC冗余發(fā)包，在弱丟包或者少丟包的情況下不需要重傳。有丟包且擁塞的網(wǎng)絡(luò)，它的表現(xiàn)主要是是丟包且RTT變大，這種情況又分為兩種：一種是我們的碼率超過了瓶頸帶寬，第二個(gè)是碼率沒有超過瓶頸帶寬。上圖可以看出I幀與P幀的關(guān)系，在視頻會(huì)中比較特殊的是I幀一般比P幀大8-10倍左右，所以很多時(shí)候發(fā)包策略不受控制的時(shí)候，每次發(fā)一幀的時(shí)候就是很大的毛刺。

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

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

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

上圖是我們?cè)贫说膬?yōu)化效果，通過邊緣區(qū)域的網(wǎng)格增強(qiáng)，平坦區(qū)域直接上采樣、紋理區(qū)域網(wǎng)絡(luò)增強(qiáng)。

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

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

責(zé)任編輯：lq