基于當下直播技術對下一代低延遲的直播CDN場景的思考和展望

◎賴材棟 張小強 劉 斌

(中國移動通信集團陜西有限公司，陜西 西安 710077)

隨著家庭寬帶業(yè)務的高速發(fā)展，陜西移動互聯(lián)網(wǎng)電視用戶規(guī)模已經(jīng)突破600 萬，成為傳播紅色能量、弘揚主旋律、傳遞疫情防控政策、豐富市民精神文化生活的一支重要力量。移動互聯(lián)網(wǎng)電視業(yè)務隨著規(guī)模和影響力的不斷擴大，已經(jīng)成為省內(nèi)乃至全國主流的宣傳渠道。如何構建全新的互聯(lián)網(wǎng)電視視頻直播業(yè)務發(fā)展模式，保障互聯(lián)網(wǎng)電視視頻直播業(yè)務低延遲、高品質(zhì)、優(yōu)體驗，成為互聯(lián)網(wǎng)電視從業(yè)人員需要關注的重大課題。

在多媒體領域技術盛會——LiveVideoStackCon 音視頻技術大會上，阿里云的高級技術專家進行了下一代低延時的直播CDN 技術分享[1]，從當下直播技術回顧、低延時直播技術思考、低延時直播技術實現(xiàn)、直播業(yè)務未來展望四個部分展開，對直播CDN 相關從業(yè)者有一定的幫助和啟發(fā)。

陜西移動結合互聯(lián)網(wǎng)電視系統(tǒng)業(yè)務構架及CDN 直播業(yè)務發(fā)展需求，提出了OTTx 直播業(yè)務模式改造方案。OTTx業(yè)務是一種新的互聯(lián)網(wǎng)電視形態(tài)，直播采用組播技術，在節(jié)省項目投資預算和提升用戶體驗方面具有非常明顯的競爭優(yōu)勢。為保障OTTx 業(yè)務的安全平穩(wěn)發(fā)展，互聯(lián)網(wǎng)電視系統(tǒng)優(yōu)化包括MRF、FCC、FEC、探針等各邊緣節(jié)點網(wǎng)絡設備及用戶側的直播頻道音視頻質(zhì)量監(jiān)測，針對接入網(wǎng)絡、傳輸網(wǎng)絡進行整體質(zhì)量提升等，旨在提升移動互聯(lián)網(wǎng)整體傳輸網(wǎng)絡質(zhì)量，保障互聯(lián)網(wǎng)電視視頻內(nèi)容的流暢性、穩(wěn)定性、安全性，為推動互聯(lián)網(wǎng)電視業(yè)務發(fā)展提供可靠基礎，為提升和優(yōu)化互聯(lián)網(wǎng)電視CDN 終端用戶體驗滿意度提供堅強后盾。

一、直播業(yè)務發(fā)展歷程

直播業(yè)務包括多種場景[2]。秀場直播是國內(nèi)最早出現(xiàn)的直播形式，在各個直播平臺比較常見。游戲直播，例如斗魚、虎牙、戰(zhàn)旗等直播平臺都是比較典型的游戲直播平臺，游戲直播對編碼的要求高，同時在線觀看人數(shù)多，所以它是流量貢獻最大的直播形式。賽事直播，如F1、奧運會、世界杯等對即時交互要求不高，所以一般都是HLS 形式，延遲相對其他場景會稍微高一點，賽事直播最重要的指標是穩(wěn)定性，熱點事件帶來的帶寬快速增長、高收視并發(fā)需要CDN 具備足夠的儲備帶寬應對突發(fā)情況，直播全程不能出現(xiàn)任何中斷故障，否則會影響用戶體驗。移動直播、短視頻是近兩年井噴式發(fā)展和全民參與的直播形式，其特點是推流和播放比較便捷, 通過手機APP 就可以進行直播，所以手機直播也是推流數(shù)最多的直播形式，這種直播用戶通過隨機的封面選擇，對于不感興趣的直播內(nèi)容，用戶點進去觀看不超過幾分鐘就可能退出觀看下一個，在這樣頻繁地接入和退出操作下，首屏體驗感知就變成最重要的指標，用戶難以忍受切換慢或起播慢的體驗，對延遲要求高，視頻秒開是客戶非常關注并評價很高的技術。還有近幾年興起的VR 直播，VR 直播視頻碼率很大，一般在10M/bits，VR 直播主打的就是用戶的視覺沖擊體驗，在畫質(zhì)上要保證優(yōu)質(zhì)，在控制清晰度不變的情況下需要降低使用的帶寬，這就涉及到視頻編碼格式。比如h265 編碼格式的視頻帶寬比同清晰度的要低2—3 倍，也就意味著帶寬最少會降低一半，直播用戶并發(fā)峰值期間對CDN 出流負載要求很高，所以對網(wǎng)絡質(zhì)量及內(nèi)容源流暢度要求極高，如果觀看流暢度不能保證連續(xù)性，就不能帶來用戶體驗滿意度提升，無法增強互聯(lián)網(wǎng)電視品牌競爭力。

二、低延遲直播需求

國內(nèi)主要使用HTTP-FLV 和RTMP 這種傳輸形式，這兩種傳輸形式一般延遲在3—5 秒，當然延遲時長也會受視頻本身GOP 影響，移動直播一般在1—2 秒間隔。游戲直播關鍵幀延遲一般在8—10 秒，所以游戲直播的延遲更大一些，而賽事活動一般不會強調(diào)互動性，對流暢度要求比較高，所以一般會選擇HLS，延遲在10 秒左右。

直播業(yè)務場景下3—5 秒延遲對于大多數(shù)常見直播形式一般影響不大，但是在某些特定場景下效果不能滿足業(yè)務需求。如直播連麥場景下延遲造成的影響是最明顯的，連麥延遲超過1 秒，對話可能就會出現(xiàn)卡頓甚至掉線；在答題直播場景下，需要參與者在固定時間內(nèi)完成答題后提交答案，如果出現(xiàn)個別用戶延遲比較大而不能在固定時間內(nèi)完成答題并提交，就對其他用戶不公平。雖然現(xiàn)在大多數(shù)直播平臺仍然使用FLV 的傳輸形式進行答題類直播，但是基本都會采用SEI 插幀等方法來解決時間同步問題，需要平臺的客戶端和直播CDN 做一些配合來完成。除了直播連麥場景之外，像在線課堂、在線拍賣等直播場景因為涉及到實時互動，對延時的要求也比較高。從對業(yè)務的支持層面來看，僅僅有RTMP、FLV 這種3—5 秒延時以上的直播形式已經(jīng)不能滿足客戶對流暢度的需求, 需要對更低延遲的直播業(yè)務場景進行支持。

三、技術選型的思考

技術選型首先必須要兼容已有直播業(yè)務和技術棧，因為直播CDN 系統(tǒng)已經(jīng)承載了很多用戶，短延時直播需要從現(xiàn)有直播的業(yè)務基礎上逐步衍生, 可以讓客戶在短延時和常規(guī)直播手段間進行切換，這也是基于現(xiàn)網(wǎng)業(yè)務穩(wěn)定性的考慮。對于直播業(yè)務來講，視頻秒開和卡頓率是非常重要的業(yè)務指標。

傳統(tǒng)CDN 業(yè)務場景，無論是圖片、大小文件、點播、直播等業(yè)務，都是在TCP 協(xié)議通信基礎上實現(xiàn)的，所以短延時直播在研究初期就思考使用TCP 協(xié)議的可能性。我們對于短延時的目標定義為從端到端延遲在800 毫秒以內(nèi)，例如一場直播的延遲主要包括推流端延遲、CDN 延遲、播放端延遲這三個方面，很多客戶會關注CDN 延遲，通過實際收集相關延遲數(shù)據(jù)分析，CDN 從入流到出流整個業(yè)務流程所產(chǎn)生的總延時全網(wǎng)平均不超過100 毫秒，晚高峰期間平均也不超過200 毫秒。而從業(yè)務系統(tǒng)維護經(jīng)驗角度來分析，播放端的延遲會比較嚴重，主要包括兩方面，一方面是開播時卡前一個關鍵幀所帶來的延遲，另一方面如果CDN 服務器到播放端之間網(wǎng)絡有抖動，累積的延遲會越來越多。所以我們就可以得出這樣的結論，在網(wǎng)絡正常的情況下使用現(xiàn)有的RTMP、HTTP-FLV 進行分發(fā)，延遲也基本可以做到控制在1 秒以內(nèi)。但是現(xiàn)實情況是網(wǎng)絡不可能出現(xiàn)不丟包的情況。當網(wǎng)絡抖動丟包導致卡頓等質(zhì)差時，TCP 協(xié)議能提供可靠的數(shù)據(jù)傳輸服務。為保證數(shù)據(jù)傳輸?shù)恼_性，TCP 會重傳其認為已丟失的報文，TCP 協(xié)議通過ACK 確認機制，也就是說發(fā)送方發(fā)送一個數(shù)據(jù)包報文之后，一定要收到對方應答才會繼續(xù)發(fā)送。如果傳輸網(wǎng)絡由于質(zhì)差出現(xiàn)丟包，就會在一個RTO 之后重傳，RTO 的值和RTT 有關，并且RTO 的最小值是200ms。如果想保證流暢性，播放端一定要至少能容忍200ms 以上的抖動，但播放端的jitbuffer 太多又無法滿足低延時的要求。

使用TCP 傳輸時無效傳輸無法避免。TCP 是采用socket buffer 進行通信，數(shù)據(jù)也是從應用層先進入socket buffer 再分發(fā)。對于RTMP 或FLV 的分發(fā)來說，假如某一幀數(shù)據(jù)的一部分已經(jīng)進入了socket 緩沖區(qū)，那么就必須將這一幀剩余的數(shù)據(jù)發(fā)送出去，如果剩余的數(shù)據(jù)傳輸時出現(xiàn)擁塞等無法發(fā)送，播放端會解析錯誤斷開連接造成用戶體驗會非常差。而網(wǎng)絡在出現(xiàn)波動的時候，有可能socket buffer 里面的數(shù)據(jù)需要多次重傳才能傳送到播放端, 而在短延時直播的場景下，這些socket buffer 里面和應用層過期的數(shù)據(jù)再發(fā)送給播放端已經(jīng)沒有意義，也就是說會產(chǎn)生很多無效的傳輸。

近些年發(fā)展起來的WebRTC 協(xié)議，能夠?qū)崿F(xiàn)亞秒級的延遲，它并不是通過分塊傳輸降低延遲，使用的是UDP/IP協(xié)議傳輸，提供了在Web、iOS、Android、Mac、Windows、Linux 等所有平臺的API，保證了API 在所有平臺的一致性，而且大多數(shù)的瀏覽器均支持，不需要額外的插件，支持自適應比特流的傳輸來適應復雜的網(wǎng)絡狀況。

因為WebRTC 在移動端擁塞控制和重傳方面有部分技術優(yōu)化，卡頓率方面不會比TCP 差，所以技術選型對齊到WebRTC 會是最終的結果, 畢竟用戶能夠使用H5 就可以直接推流或者觀看直播, 能夠提高用戶的接受度和使用率。完整地支持WebRTC 要解決加解密、打洞、音頻格式等問題，所以前期考慮只使用WebRTC 中的一部分技術，完整支持WebRTC 會是后期的長遠工作規(guī)劃。

這里對比一下WebRTC 中RTP 傳輸使用的NACK 機制，NACK 的丟包反饋更加及時，如果網(wǎng)絡偶然性抖動較多時，NACK 機制效果會更好。通過統(tǒng)計網(wǎng)絡數(shù)據(jù)分析，全網(wǎng)平均RTT 小于15ms，如果CDN 節(jié)點覆蓋足夠好的情況下，延遲理論上會非常低。以1.5Mbps 碼率的音視頻流舉例，每秒鐘100 個數(shù)據(jù)包，包和包之間就是10ms 的間隔。如果第二個丟包出現(xiàn)的時候，第三個包對方接收到了，就可以立即知道第二個包是丟掉了，然后立刻返回一個NACK 進行重傳。在這種極限場景下重傳間隔就是25ms，相比之前TCP 的200ms 重傳延遲是一個質(zhì)的提升，不再需要通過服務器進行路由，減少了延遲和帶寬消耗，實現(xiàn)直接通信可提高數(shù)據(jù)傳輸和文件共享的速度。

四、應用實踐

(一)解決端口問題

標準WebRTC 的建連流程，最簡單的服務器端端口方案是我們可以為每個客戶端分配一個端口，服務器端上使用這個端口區(qū)分每個用戶。那么多端口有什么不足呢？很多的網(wǎng)絡出口防火墻對能夠通過的UDP 端口是有限制的；對于服務器端來說開辟這么多端口，安全性也有一定的問題；開辟這么多的端口在Server 端上，端口的開銷和性能均有一定的影響。那能否用單端口？首先要解決的一個問題是：如何區(qū)分每一個RTP/RTCP 包是屬于哪一個WebRTC 客戶端。WebRTC 在服務器SDP Answer 中設置 ice-ufrag 為roomid/userid，其中RoomID 和UserID 是通話業(yè)務層分配的內(nèi)容，用于區(qū)分會話連接以及客戶端。接著做Ice candidate 協(xié)商，客戶端開始做連通性檢測，也就是stun binding request 里的USERNAME 為SDP local 和remote 的ice-ufrag 指定內(nèi)容。服務器收到stun binding request 的客戶端ip 和端口，并正?；豷tun binding response。記錄客戶端地址與用戶信息的映射關系。服務器收到一個rtp/rtcp 媒體數(shù)據(jù)包，通過包的源ip 和端口，查詢映射表就可以識別這個包屬于哪個用戶。

(二)視頻秒開

秒開是指用戶點擊播放到看到畫面的時間非常短，在1秒之內(nèi)。實現(xiàn)視頻秒開是基于GOP 的視頻緩存策略實現(xiàn)的。例如RTC 交流場景下，可直接通過PLI 交流，向發(fā)布端索要關鍵幀，對于接收端立即完成視頻渲染。但是對于直播CDN 場景，海量的客戶端向服務器端索要PLI 是不現(xiàn)實的。為了解決這個問題，服務器端需要加入Gop Cache 數(shù)據(jù)結構，構建基于Gop 的緩存結構。在低延遲直播的情況下，需要考慮在Gop 下發(fā)后客戶端能夠快速追上服務端的發(fā)流，所以在客戶端感知不明顯的情況下會對P 禎和B 禎采用1.1 或1.2倍速下發(fā)，直到所有包能夠追上服務端下推包的進程，后續(xù)在合流完成后的整體時間即可同步，延遲會降到最低。

(三)RTP 報文

RTP 數(shù)據(jù)包中，PT 字段是載荷類型，sequence number是包序列號，發(fā)送端切片的時候?qū)懞眯蛄刑?，接收端依?jù)這個序列號進行數(shù)據(jù)的還原。而且在數(shù)據(jù)報文發(fā)生重傳的時候，還依靠這個序列號進行NACK 的返回。同時，時間戳對流媒體傳輸非常重要，播放器依賴它進行解碼和同步。SSRC 用來識別不同的身份，同一個IP 和端口被NAT 重新分配的時候，SSRC 能夠識別出這是一個不同的連接。

以H264 為例[3]，RTP 在封裝的時候，如果NAL 單元小于MTU，那么我們認為一個RTP 包可以完整封裝一個NAL單元，如果出現(xiàn)丟幀，那么我們認為缺少的是一個完整的NAL 單元，對后面NAL 單元的解析不會出現(xiàn)數(shù)據(jù)錯亂。如果一個NAL 單元大于一個MTU 的時候，假設一個NAL 單元需要三個RTP 包封裝，不管丟掉部分還是全部丟掉，接收端都可以標識出這個NAL 單元，不會影響其他NAL 單元的解析。所以采用RPT 報文是可以滿足設想需求的。

(四)平滑發(fā)送機制

現(xiàn)在通常采用的混合擁塞算法，基于丟包率和延遲進行碼率控制。標準的方案是當播放端卡頓時，發(fā)送端碼率會降低。當推流端上行網(wǎng)絡出現(xiàn)抖動的時候，CDN 服務器返回數(shù)據(jù)包通知推流端把碼率降下來。當播放端下行網(wǎng)絡出現(xiàn)抖動的時候，一種是輸出轉(zhuǎn)碼視頻流，另一種是讓推流端推兩路視頻流，提醒播放卡頓的用戶切換到低碼率。

陜西移動互聯(lián)網(wǎng)電視系統(tǒng)結合當前業(yè)務平臺系統(tǒng)現(xiàn)狀，分析CDN 服務器使用的擁塞控制算法取決于sysctl 接口的net.ipv4.tcp_congestion_control。缺省的擁塞控制算法是最后注冊的算法(LIFO),如果全部編譯成模塊，則將使用reno 算法，如果使用缺省的Kconfig 配置，CUBIC 算法將編譯進內(nèi)核，并且內(nèi)核將使用CUBIC 作為默認的擁塞控制算法，CUBIC 擁塞控制基礎[4]提升優(yōu)化TCP 快速重傳算法net.ipv4.tcp_congestion_control = cubic，在快速重傳丟失的數(shù)據(jù)包后啟用擁塞避免算法，而不是慢啟動算法被調(diào)用，這就是快速恢復的意義。這一方法使得在中度擁塞的情況下CDN 服務器能有較高的吞吐率，達到優(yōu)化出流效率的目的，最終提升終端用戶的體驗感和滿意度。

(五)FEC 冗余傳輸

FEC 是通過數(shù)據(jù)報文冗余傳輸來提高容錯率。關鍵幀10%冗余率，非關鍵幀5%，根據(jù)丟包率判斷網(wǎng)絡狀況，動態(tài)調(diào)整冗余度?，F(xiàn)在H264 和AAC 數(shù)據(jù)會在內(nèi)部先進行切片，放到平滑發(fā)送隊列再發(fā)送給播放端，同時重傳包也會進入平滑發(fā)送隊列，并且會放到平滑發(fā)送隊列的隊首位置，完成數(shù)據(jù)報文冗余傳輸。

陜西移動互聯(lián)網(wǎng)電視系統(tǒng)OTTx 業(yè)務是使用華為MRF 編碼[5]，在中轉(zhuǎn)過程中采用RTP 協(xié)議封裝組播流，生成FEC冗余流，使用戶在終端獲得更流暢的播放體驗。FEC 采用帶外承載方式，與組播組使用同一個IP 地址，以UDP 端口區(qū)分原始組播流和FEC 冗余流，默認端口為組播端口減1，播放端獲取的頻道列表信息中有指定的FEC 端口，則必須采用指定端口。FEC 算法采用移動集團規(guī)范，能夠適配組播流任意位置隨機丟包恢復業(yè)務場景，F(xiàn)EC 冗余度不超過5%，對于1%的隨機丟包至少要達到99%以上的恢復成功率，對于2%的隨機丟包至少要達到95%以上的恢復成功率。

(六)探測活動

采用RTCP 報文的方式實現(xiàn)對播放和推流連接的斷開進行控制。采用TCP 方式傳輸?shù)臅r候也有類似的問題，推流端發(fā)送了FIN 結束報文，但是CDN 服務器未必收到，所以要有超時的機制來進行管理。我們采用數(shù)據(jù)及時反饋機制，下行播放端要求周期性返回，上行推流端必須在8—10 秒內(nèi)完成真實視頻流數(shù)據(jù)傳輸，否則連接就會斷開。

五、結語

對于CDN 低延遲優(yōu)化要做的另一個關鍵點就是優(yōu)化傳輸，其實無論對于文件加速還是流媒體加速，傳輸永遠都是最重要的環(huán)節(jié)，CDN 這個分發(fā)網(wǎng)絡質(zhì)量提升本身就是為了優(yōu)化傳輸而存在的。

完整地支持WebRTC 一定是下一階段實現(xiàn)的目標, 畢竟直接通過瀏覽器就可以完成推流和播放，對于用戶端的接入便捷性有質(zhì)的提升，對于CDN 來說，控制接入一定是最重要且必須做的事情。