文 / 陳華成

整理 / LiveVideoStack

視頻回放：https://www.livevideostack.cn/video/online-huacheng/

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

直播行業(yè)的背景

1.1 直播行業(yè)新變化

首先我們來(lái)看一下整個(gè)直播行業(yè)在近期有哪些新的變化。5G的到來(lái)將使得邊緣帶寬由Mb增長(zhǎng)至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è)直播帶貨量增長(zhǎng)了五倍左右。那帶貨場(chǎng)景有哪些呢？其實(shí)就是把線下的促銷變成了線上，上圖中列舉了兩個(gè)典型場(chǎng)景。第一個(gè)是低價(jià)秒殺促銷，主播為了活躍氣氛帶動(dòng)更多的人參與進(jìn)來(lái)，她會(huì)給一些低價(jià)商品讓大家搶購(gòu)，秒殺的過(guò)程要求延遲很低。第二個(gè)是主播為了活躍氣氛發(fā)紅包，這兩個(gè)場(chǎng)景對(duì)延遲的要求都很高。現(xiàn)在標(biāo)準(zhǔn)直播的延遲一般在三到幾十秒，是無(wú)法滿足帶貨需求的。延遲高也限制了帶貨新玩法的出現(xiàn)，導(dǎo)致現(xiàn)在的直播帶貨幾乎沒有互動(dòng)。

教育類

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

直播行業(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)帶來(lái)的延遲有一定的改善，但QUC沒有流媒體特性，在這里不是一個(gè)最佳方案。

2.2 TCP不適合低延遲直播的原因

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

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

弱網(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)致通道利用率變低。

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

直播是有時(shí)效性的，上圖1、2、3、4、5、6，可以看到5、6數(shù)據(jù)已經(jīng)過(guò)期了，但無(wú)效的重傳會(huì)一直重傳，直到傳輸成功，所以無(wú)效重傳進(jìn)一步加劇擁塞。

綜合以上四點(diǎn)可以得出TCP不適合低延遲直播。

快直播（超低延遲直播）方案

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)鍵問(wèn)題在哪里？

我們要做超低延遲，首先就要知道它們的超低延遲出現(xiàn)在哪里？整個(gè)直播過(guò)程從數(shù)據(jù)的采集、編碼都經(jīng)過(guò)哪些過(guò)程？

首先是視頻輸入攝像頭采集的數(shù)據(jù)，由YUV編碼成264、265數(shù)據(jù)，采集t0，編碼t1，推流傳輸t2，轉(zhuǎn)碼t3，再由CDN傳輸，經(jīng)過(guò)視頻解碼，最終通過(guò)視頻顯示出來(lái)。在這個(gè)過(guò)程中攝像頭采集耗時(shí)很小，一般在十幾毫秒左右；編碼耗時(shí)通過(guò)調(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è)問(wèn)題。

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)閷＠囊恍﹩?wèn)題，因?yàn)閂P9和H265有競(jìng)爭(zhēng)關(guān)系，谷歌更希望推VP9）、視頻不支持B幀、信令交互耗時(shí)長(zhǎng)、無(wú)法透?jìng)鱩etadata，這些問(wèn)題對(duì)于在線教育和主播帶貨是沒必要的，可以跳過(guò)。而有些客戶希望用metadata帶一些同步信息，顯然標(biāo)準(zhǔn)WebRTC是不支持的。

我們從五個(gè)方面對(duì)標(biāo)準(zhǔn)WebRTC進(jìn)行升級(jí)，包括支持aac（同時(shí)支持adts、latm兩種封裝）、視頻支持H265和B幀、通過(guò)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è)國(guó)家）

2.超大帶寬容量（我們的部門擁有了騰訊90%的流量，支持100T+帶寬）

3.質(zhì)量好、成本低（抗30%丟包）

4.接入簡(jiǎn)單（只要下行SDK做改造就可以了、功能完善、平滑兼容）

5.已大規(guī)模使用（內(nèi)部已接入騰訊課堂、企鵝電競(jìng)，外部已接入教育類、電商類的客戶）

快直播——延遲、秒開、抗性、畫質(zhì)提升

4.1 快直播延遲

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

4.2 快直播首幀耗時(shí)秒開

標(biāo)準(zhǔn)WebRTC要經(jīng)過(guò)sdp交互、ice、dtls握手、rtp/rtcp，這里第二步和第三步基本是可以跳過(guò)的，ice可以用簡(jiǎn)單的storm來(lái)代替，dtls握手對(duì)于不需要加解密的也可以跳過(guò)，所以我們做了一個(gè)可以通過(guò)SRTP協(xié)商來(lái)關(guān)閉dtls握手，所以第二、第三步可以根據(jù)需求選擇性的開或者關(guān)，從而通過(guò)精簡(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)度按房間來(lái)收斂，提高命中率，也就是說(shuō)在同一個(gè)省份看同一個(gè)房間的話都讓他走到同一個(gè)機(jī)房。通過(guò)以上三點(diǎn)優(yōu)化首幀耗時(shí)基本達(dá)到100多ms。

4.3 快直播WebRTC抗性優(yōu)化

WebRTC抗性怎么優(yōu)化？這里抗性優(yōu)化的本質(zhì)是不斷 “感知 + 調(diào)整 ”來(lái)適配變化的網(wǎng)絡(luò)，這里的感知主要是RTT、丟包率、瓶頸帶寬，通過(guò)感知到的網(wǎng)絡(luò)的變化來(lái)調(diào)整發(fā)包策略、重傳策略、FEC冗余策略等等。上圖把網(wǎng)絡(luò)分為兩類，有丟包未擁塞的網(wǎng)絡(luò)（基站的信號(hào)弱，WiFi的信號(hào)弱），這種情況通過(guò)根據(jù)丟包率計(jì)算重傳次數(shù)，提高重傳成功率，也可以通過(guò)FEC冗余發(fā)包，在弱丟包或者少丟包的情況下不需要重傳。有丟包且擁塞的網(wǎng)絡(luò)，它的表現(xiàn)主要是是丟包且RTT變大，這種情況又分為兩種：一種是我們的碼率超過(guò)了瓶頸帶寬，第二個(gè)是碼率沒有超過(guò)瓶頸帶寬。上圖可以看出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)砣Ｎ覀冇袃煞N策略：一種是時(shí)域分層，在編碼的時(shí)候，將視頻幀分三到四個(gè)級(jí)別，比如I幀、P幀、B幀，因?yàn)橛幸恍〣幀是沒有依賴的，我們可以通過(guò)丟失一部分的幀直到碼率小于瓶頸帶寬，也就是通過(guò)降幀率達(dá)到降卡頓的效果。另一種方式是空域分層，比如說(shuō)編碼的時(shí)候，我們會(huì)編高分辨率和低分辨率，對(duì)于弱網(wǎng)（碼率是瓶頸）的情況下，我們通過(guò)只發(fā)低分辨率的幀使碼率小于瓶頸帶寬。

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

4.4 快直播畫質(zhì)優(yōu)化

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