1 背景

直播(bo)延遲(chi)(chi)是指(zhi)從推流端(duan)到播(bo)放端(duan)的端(duan)到端(duan)延遲(chi)(chi)，目前業界的直播(bo)延遲(chi)(chi)普(pu)遍在3秒以(yi)上，這主要有兩方面原(yuan)因：

• 提供直播加速的各大云廠商為實現“秒開”功能，普遍在服務端緩存了一個GOP(兩個I幀之間的數據)，一個GOP大小普遍在3秒以上，播放器拿到GOP以后如果沒有倍速播放等追趕功能，會保持3秒以上的播放延遲；
• 傳統直播主要使用RTMP或者HTTP協議，都是基于TCP的協議，一旦出現弱網擁塞，將轉變為延遲。

2 目標

本方(fang)案的(de)目(mu)的(de)是在支持(chi)傳(chuan)統直播(bo)(bo)“秒開”功(gong)能的(de)前提下，通過(guo)(guo)在拉(la)流端(duan)引入WebRTC技術，將播(bo)(bo)放延遲降(jiang)(jiang)低(di)到200ms以內(nei)。通過(guo)(guo)播(bo)(bo)放器客戶端(duan)內(nei)部的(de)“追趕”機制(zhi)來降(jiang)(jiang)低(di)延遲，通過(guo)(guo)服(fu)務(wu)端(duan)的(de)“丟幀”策略來降(jiang)(jiang)低(di)客戶端(duan)的(de)追趕時間來實現用(yong)戶對倍(bei)速播(bo)(bo)放的(de)無感知，通過(guo)(guo)優化擁(yong)塞控制(zhi)算(suan)法來提升弱網(wang)下的(de)QOS以達(da)到甚至超過(guo)(guo)傳(chuan)統RTMP直播(bo)(bo)的(de)體驗(yan)。

3 技術方案

3.1 RTMP到WebRTC的轉封裝

為了實現無(wu)侵入地對接當(dang)前(qian)的(de)直播(bo)CDN系(xi)統(tong)，最(zui)(zui)大(da)程(cheng)度(du)地復用當(dang)前(qian)直播(bo)系(xi)統(tong)上的(de)轉碼、鑒(jian)權、鑒(jian)黃等業務(wu)，需(xu)要(yao)在直播(bo)CDN系(xi)統(tong)的(de)中(zhong)心節(jie)點(dian)(dian)或者邊緣(yuan)節(jie)點(dian)(dian)部署轉封裝服務(wu)，該服務(wu)負責從當(dang)前(qian)節(jie)點(dian)(dian)拉取RTMP流，并通(tong)過(guo)FFmpeg將RTMP協議(yi)轉換(huan)成RTP協議(yi)，通(tong)過(guo)RTC分發(fa)系(xi)統(tong)發(fa)送(song)給RTC媒(mei)體服務(wu)，以(yi)對接最(zui)(zui)終用戶。也(ye)就是說推流端為RTMP協議(yi)，經過(guo)轉封裝、分發(fa)等服務(wu)后(hou)，最(zui)(zui)終用戶通(tong)過(guo)WebRTC協議(yi)拉流播(bo)放。

如(ru)圖3.1.1，轉(zhuan)封裝服(fu)務作(zuo)為直播CDN系(xi)統到RTC系(xi)統的(de)網關，負(fu)責RTMP協議到RTP協議的(de)轉(zhuan)換。

圖3.1.1

3.2 客戶端倍速播放追趕

客戶端使用WebRTC協議拉取直播流，服務端接收到拉流請求后會立刻發送緩存的1個GOP數據，這些數據在客戶端的接收時間間隔比在以正常碼率傳輸數據時的接收時間間隔要小，基于這個特性可以通過WebRTC的音頻NetEQ模塊和視頻JitterBuffer模塊的配合進行延遲追趕，以快速消費客戶端接收緩沖中的數據。
對音(yin)(yin)頻來說，NetEQ會通(tong)過音(yin)(yin)頻接收時間間隔以直方圖算法和峰值(zhi)檢測算法估算音(yin)(yin)頻目標延遲(chi)(chi)，在音(yin)(yin)視頻同步后的(de)音(yin)(yin)頻當(dang)前延遲(chi)(chi)比(bi)音(yin)(yin)頻目標延遲(chi)(chi)大的(de)情況(kuang)下(xia)，通(tong)過一定(ding)的(de)壓(ya)縮算法壓(ya)縮解(jie)碼后的(de)音(yin)(yin)頻同步緩沖(chong)中的(de)波形，達到加(jia)速播(bo)放的(de)效(xiao)果。

對視頻(pin)來說，JitterBuffer計(ji)算(suan)出的(de)視頻(pin)幀的(de)視頻(pin)渲(xuan)(xuan)(xuan)染(ran)(ran)時(shi)(shi)間(jian)的(de)間(jian)隔比正(zheng)常(chang)速率(lv)(lv)要小，這段時(shi)(shi)間(jian)的(de)渲(xuan)(xuan)(xuan)染(ran)(ran)幀率(lv)(lv)要提(ti)高，直(zhi)到接收幀率(lv)(lv)和推流幀率(lv)(lv)持平后視頻(pin)渲(xuan)(xuan)(xuan)染(ran)(ran)時(shi)(shi)間(jian)間(jian)隔會趨于(yu)正(zheng)常(chang)。

如(ru)圖(tu)3.2.1、圖(tu)3.2.2、圖(tu)3.2.3，首GOP瞬間(jian)發送，數(shu)據(ju)到(dao)達(da)間(jian)隔(ge)小(xiao)，音(yin)頻(pin)NetEQ、視頻(pin)JitterBuffer模塊分(fen)別根據(ju)音(yin)、視頻(pin)到(dao)達(da)間(jian)隔(ge)對音(yin)、視頻(pin)數(shu)據(ju)做延(yan)遲追趕并進行同步(bu)。

圖3.2.1 首GOP數據間隔(ge)

圖3.2.2 音(yin)頻延遲追趕

圖3.2.3 視頻延遲(chi)追趕

3.3 服務端首GOP內丟幀和時間戳重寫

如上述，客戶端(duan)追(zhui)(zhui)趕算法是實現低延遲的(de)根本算法，但是如果推流端(duan)設置的(de)GOP過(guo)大，或(huo)者用(yong)戶側下載速度不足，會導(dao)致追(zhui)(zhui)趕過(guo)程持續較長(chang)時間，而(er)追(zhui)(zhui)趕過(guo)程中(zhong)可能會出現快進、跳(tiao)幀(zhen)、卡頓等較差的(de)用(yong)戶體驗，為了降低用(yong)戶對(dui)這個過(guo)程的(de)感知，需要通過(guo)在(zai)首(shou)GOP內丟幀(zhen)的(de)方式減少第一次發送給客戶端(duan)的(de)數(shu)據(ju)量。

基(ji)于(yu)I幀(zhen)(zhen)(zhen)(zhen)、P幀(zhen)(zhen)(zhen)(zhen)之間(jian)的(de)(de)(de)(de)(de)參考關系，首GOP內(nei)(nei)(nei)丟(diu)(diu)幀(zhen)(zhen)(zhen)(zhen)的(de)(de)(de)(de)(de)基(ji)本原則是不能從GOP前面開始(shi)丟(diu)(diu)幀(zhen)(zhen)(zhen)(zhen)，不能從中間(jian)跳躍丟(diu)(diu)幀(zhen)(zhen)(zhen)(zhen)，只能丟(diu)(diu)GOP末尾(wei)(wei)的(de)(de)(de)(de)(de)連續幀(zhen)(zhen)(zhen)(zhen)。同時(shi)(shi)還必(bi)須保證(zheng)(zheng)丟(diu)(diu)幀(zhen)(zhen)(zhen)(zhen)以后(hou)發(fa)(fa)送的(de)(de)(de)(de)(de)視(shi)(shi)頻(pin)幀(zhen)(zhen)(zhen)(zhen)時(shi)(shi)間(jian)戳的(de)(de)(de)(de)(de)連續，具體做(zuo)法(fa)為：設(she)置(zhi)一個(ge)時(shi)(shi)間(jian)窗口(kou)TW(TW<GOP)，該時(shi)(shi)間(jian)窗口(kou)為首GOP內(nei)(nei)(nei)需(xu)要(yao)(yao)發(fa)(fa)送的(de)(de)(de)(de)(de)視(shi)(shi)頻(pin)幀(zhen)(zhen)(zhen)(zhen)時(shi)(shi)間(jian)總(zong)長度，將GOP末尾(wei)(wei)TW時(shi)(shi)間(jian)長度內(nei)(nei)(nei)的(de)(de)(de)(de)(de)視(shi)(shi)頻(pin)幀(zhen)(zhen)(zhen)(zhen)的(de)(de)(de)(de)(de)時(shi)(shi)間(jian)戳按順序設(she)置(zhi)為GOP頭部TW時(shi)(shi)間(jian)長度內(nei)(nei)(nei)的(de)(de)(de)(de)(de)視(shi)(shi)頻(pin)幀(zhen)(zhen)(zhen)(zhen)的(de)(de)(de)(de)(de)時(shi)(shi)間(jian)戳，在發(fa)(fa)完(wan)首GOP內(nei)(nei)(nei)TW時(shi)(shi)間(jian)長度的(de)(de)(de)(de)(de)視(shi)(shi)頻(pin)幀(zhen)(zhen)(zhen)(zhen)后(hou)，立刻開始(shi)發(fa)(fa)送下一個(ge)GOP，以保證(zheng)(zheng)發(fa)(fa)送視(shi)(shi)頻(pin)幀(zhen)(zhen)(zhen)(zhen)時(shi)(shi)間(jian)戳的(de)(de)(de)(de)(de)連續。而在首GOP還未完(wan)整的(de)(de)(de)(de)(de)情況下，則需(xu)要(yao)(yao)通(tong)過收幀(zhen)(zhen)(zhen)(zhen)來驅動時(shi)(shi)間(jian)戳的(de)(de)(de)(de)(de)設(she)置(zhi)。

如圖3.3.1，服務端只發送首GOP開(kai)頭TW時間(jian)窗口內的視(shi)頻幀，并將GOP末尾TW時間(jian)窗口內的視(shi)頻幀的時間(jian)戳(chuo)設(she)置到GOP開(kai)頭TW時間(jian)窗口內的視(shi)頻幀，保證發送視(shi)頻幀時間(jian)戳(chuo)的連續。

圖3.3.1 首GOP丟幀(zhen)和時間戳重寫

3.4 WebRTC NetEQ對AAC的兼容

如(ru)上述(shu)，客(ke)戶端(duan)的(de)(de)(de)(de)NetEQ模塊需要(yao)解碼(ma)(ma)音頻(pin)數據并(bing)壓縮(suo)波形以實現對音頻(pin)的(de)(de)(de)(de)快進播放，傳統(tong)直(zhi)播的(de)(de)(de)(de)音頻(pin)編(bian)碼(ma)(ma)一般為(wei)AAC，而WebRTC系統(tong)的(de)(de)(de)(de)音頻(pin)編(bian)碼(ma)(ma)一般為(wei)OPUS，不(bu)支(zhi)持(chi)AAC，并(bing)且NetEQ支(zhi)持(chi)的(de)(de)(de)(de)音頻(pin)采樣率必須為(wei)8K的(de)(de)(de)(de)倍數，不(bu)支(zhi)持(chi)AAC的(de)(de)(de)(de)44.1K采樣率。針對這些兼(jian)容性(xing)問(wen)題有兩個(ge)解決(jue)方案(an)，一是(shi)服務端(duan)將AAC轉碼(ma)(ma)成(cheng)OPUS，并(bing)重(zhong)采樣成(cheng)48K，但是(shi)會增(zeng)大服務端(duan)的(de)(de)(de)(de)壓力；二是(shi)本(ben)方案(an)采取(qu)的(de)(de)(de)(de)辦(ban)法，修改客(ke)戶端(duan)NetEQ模塊以支(zhi)持(chi)AAC的(de)(de)(de)(de)解碼(ma)(ma)并(bing)重(zhong)采樣到8K的(de)(de)(de)(de)倍數，優點(dian)為(wei)服務端(duan)只需要(yao)轉發不(bu)影響性(xing)能，但是(shi)提高了客(ke)戶端(duan)復雜(za)度。

如圖(tu)3.4.1，RTP包(bao)進入NetEQ之前需要經過44.1K采樣率到48K采樣率的時間戳映射，然后(hou)經過AAC解碼、重采樣，得到48K的PCM數據由NetEQ進行處理。

圖(tu)3.4.1 NetEQ支持AAC

3.5 優化擁塞控制算法

WebRTC協(xie)議(yi)(yi)使用基(ji)于(yu)UDP的(de)(de)(de)RTP協(xie)議(yi)(yi)傳輸媒體(ti)數據(ju)，在(zai)弱(ruo)網下需要對擁(yong)塞控制算法做(zuo)一定(ding)的(de)(de)(de)優化(hua)以達到(dao)甚至超過RTMP的(de)(de)(de)指標。這里(li)主(zhu)要分成兩部分，一個(ge)是NACK、FEC等(deng)冗余(yu)數據(ju)的(de)(de)(de)發(fa)(fa)送，在(zai)低延遲(chi)丟包(bao)場(chang)景下基(ji)于(yu)評估(gu)的(de)(de)(de)RTT和丟包(bao)率(lv)按(an)照一定(ding)比例(li)增大NACK的(de)(de)(de)發(fa)(fa)送量，在(zai)高延遲(chi)丟包(bao)場(chang)景下按(an)照一定(ding)比例(li)提高FEC的(de)(de)(de)發(fa)(fa)送量；二是在(zai)帶寬受限等(deng)擁(yong)塞場(chang)景下，對碼率(lv)進(jin)行波(bo)形(xing)的(de)(de)(de)整形(xing)，對以GOP為周期的(de)(de)(de)I幀位置的(de)(de)(de)碼率(lv)峰值(zhi)進(jin)行削(xue)峰，平滑發(fa)(fa)送碼率(lv)，以達到(dao)擁(yong)塞避(bi)免的(de)(de)(de)目標。

如圖3.5.1，通(tong)過NACK、FEC發送(song)冗余數據對抗(kang)(kang)丟(diu)包(bao)，通(tong)過Pacer Sender平滑發送(song)對抗(kang)(kang)擁塞(sai)。

圖3.5.1 擁塞控制

4 架構

如下圖4所(suo)示，轉(zhuan)(zhuan)封(feng)裝服(fu)務采用SRS，提供(gong)回源拉流、轉(zhuan)(zhuan)封(feng)裝、GOP緩(huan)存等(deng)功能，RTC媒體服(fu)務采用基于Janus的(de)SFU，實現WebRTC接(jie)入(ru)，提供(gong)NACK、FEC、Pacer Sender等(deng)擁(yong)塞控制能力(li)，低(di)延(yan)遲直(zhi)播客戶端的(de)功能封(feng)裝在libctrts.so動態(tai)庫中，以播放(fang)器插件的(de)形式接(jie)入(ru)播放(fang)器，可(ke)以達到業務的(de)無(wu)侵(qin)入(ru)對接(jie)。

圖4

5 技術要點

• 客戶端通過WebRTC的音頻NetEQ、視頻JitterBuffer對直播流進行倍速播放以實現播放延遲追趕；
• 服務端通過首GOP丟幀、重寫時間戳以壓縮客戶端追趕過程；
• 客戶端WebRTC NetEQ對傳統直播AAC編碼以及1K采樣率的兼容；
• 在擁塞控制優化中使用NACK、FEC等算法，在參數調整、閾值設置，以及平滑碼率發送中采用一系列自動控制算法;
• 實現服務端回源拉流、客戶端通過播放器插件無侵入對接現有直播系統。

6 優勢

通(tong)過(guo)使用本方案(an)，在傳統(tong)直(zhi)播業務(wu)系(xi)統(tong)的基礎上(shang)疊加(jia)了(le)穩定可靠的超低延(yan)遲直(zhi)播的能力：

• 超低播放延遲

可以達(da)到(dao)200ms的播放(fang)延遲，極限環(huan)境可以達(da)到(dao)120ms，基本做到(dao)實時。

• 用戶無感知

通過首GOP丟(diu)幀壓縮了快進(jin)追趕的時(shi)間，基(ji)本做(zuo)到了用戶無(wu)感知。

• 無侵入接入

服務端(duan)通(tong)過拉(la)流轉封裝服務接入(ru)(ru)現有(you)直播(bo)系(xi)統，客(ke)戶端(duan)通(tong)過播(bo)放器插件化的SDK接入(ru)(ru)，可以做到無侵(qin)入(ru)(ru)的業務對(dui)接。

• 不降低QOS性能

通過(guo)優化的(de)擁塞(sai)控制算法，QOS性能可(ke)以達(da)到(dao)甚至(zhi)超過(guo)傳統RTMP直(zhi)播的(de)性能指(zhi)標(biao)。