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

◎賴材棟 張小強 劉 斌

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

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

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

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

一、直播業務發展歷程

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

二、低延遲直播需求

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

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

三、技術選型的思考

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

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

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

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

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

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

四、應用實踐

(一)解決端口問題

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

(二)視頻秒開

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

(三)RTP 報文

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

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

(四)平滑發送機制

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

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

(五)FEC 冗余傳輸

FEC 是通過數據報文冗余傳輸來提高容錯率。關鍵幀10%冗余率，非關鍵幀5%，根據丟包率判斷網絡狀況，動態調整冗余度。現在H264 和AAC 數據會在內部先進行切片，放到平滑發送隊列再發送給播放端，同時重傳包也會進入平滑發送隊列，并且會放到平滑發送隊列的隊首位置，完成數據報文冗余傳輸。

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

(六)探測活動

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

五、結語

對于CDN 低延遲優化要做的另一個關鍵點就是優化傳輸，其實無論對于文件加速還是流媒體加速，傳輸永遠都是最重要的環節，CDN 這個分發網絡質量提升本身就是為了優化傳輸而存在的。

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