編者按： 賽事直播場景與普通直播場景有一定差異，賽事直播場景對碼率、畫質、延時等性能要求更高。LiveVideoStackCon 2022 音視頻技術大會上海站邀請到了騰訊專家工程師，媒體直播負責人 —— 吳昊老師，為我們分享《騰訊視頻云流媒體技術探索 —— 賽事直播場景的技術優化》，他將介紹如何利用多路徑傳輸、QoS 控制，以及跨區調度和加速的能力，優化端到端的傳輸質量。在媒體處理和封裝上，他將介紹通過多碼率自適應、低延遲、多音軌、廣告插入等技術，提升終端的播放體驗，同時滿足國內及海外不同場景的需求。

文 / 吳昊

整理 / LiveVideoStack

大家好，我是騰訊專家工程師吳昊，很高興來到 LiveVideoStackCon 2022 音視頻技術大會 上海站，為大家做這次的線下技術分享。今天我的主題是：在賽事直播場景下，視頻云流媒體技術的優化探索。

1、Introduction

首先介紹背景，自從 2020 年以來，疫情改變了人們工作和生活的方式，越來越多的線下活動開始以線上的形式舉行。與此同時，人們對體育賽事、電競賽事等娛樂活動的關注度逐年提高。線上制作和賽事直播成為了人們的核心訴求。

通常一個完整的賽事直播流程如下：賽事現場可能是遍布全球的，比如電競賽事、世界杯足球賽等，首先通過遠程低延時傳輸的方式，將遠程采集到的音視頻信號傳輸到制作中心，由于制作中心的成本較高，無法按照賽事場地的要求進行適配，因此需要一個全球化的媒體傳輸方案。然后，經過二次制作后，通過媒體源站，進行媒體處理、編碼、封裝。最后，通過 CDN 分發到觀眾的播放端上。因此，保證整個流程的穩定性和質量成為了一個關鍵。

接下來，將從 3 個點分別進行介紹。首先，如何通過優化媒體傳輸來提高源站的可用性。其次，針對播放端的體驗，在協議和架構上的優化方面可以做些什么。最后，針對賽事場景，我們有哪些技術上的創新點。

2、媒體傳輸與高可用源站

在媒體行業里，有很多流媒體的傳輸協議，這里列舉一些常用的協議。首先是最常用的基于 TCP 的 RTMP，它的歷史較為悠久，目前也是國內、海外最常用的流媒體協議。但是它本身存在一些不足的地方，如因為版本維護等其他原因，它支持的編碼格式不夠完善，在傳輸 H.265，AV1 時可能需要一些私有化的改造。其次，基于 TCP 的 RTMP 在傳輸抗抖動性和延遲上相對其他協議做得并不太好。第二個介紹的是 RTP，它是廣電媒體行業里常用的流媒體傳輸協議，它的容器格式：MPEG-TS 支持的編碼格式比較完善，同時，基于 UDP 的 RTP 在延遲上做的比較好，但它本身存在最大的問題是不支持可靠傳輸的，所以通常采取 FEC 或 SMPTE2022-07 的標準，通過冗余發送和聚合去重的方式來提高穩定性。SRT 是一個近年逐漸得到推廣應用的協議，它具有低延遲，高抗抖動性的特性，同時有多路復用以及多路徑的特點，目前逐漸成為一些大型賽事的首選流媒體傳輸協議，已逐漸替代 RTMP 成為主流。第四個介紹的是 QUIC，嚴格來說它不是太適合，它更適合互聯網場景，如在 web 生態等做得較好，目前成為 HTTP3 的傳輸標準。RIST 與 SRT 有競爭關系，是近年逐漸得到應用的一個流媒體傳輸協議，它在延遲、高抗抖動性方面做得較好，但在標準化、多版本間的兼容性方面存在一些問題，這限制了它們在目前市場的占有率，但相信在未來更多場景會使用 RIST。以上是公網的一些傳輸協議，但也有一些針對專業視頻制作領域的局域網的傳輸協議，如 NDI、ST 2110 等，它們的主要特點是極低的延遲，傳輸的主要是未壓縮或淺壓縮的一些音視頻信號，如 ST 2110 傳輸的 JPEG-XS，只做了幀內預測，沒有做幀間的運動估計，這樣的好處是可將延遲降到一個幀的級別，但會有壓縮效率低的問題。因此這些局域網的協議對傳輸網絡條件要求較高，限制了它們在公網傳輸中的應用。

簡單來說，針對直播流媒體在傳輸機制上需要做哪些優化？如在連接機制上面，通過優化信令來減少首幀的延遲，通過多路復用解決隊頭阻塞的問題。然后，在糾錯和重傳機制上面，我們基于更精確的 RTT 測量去動態調整重傳間隔以減少不必要的重傳，其次，除了 NACK、超時重傳以外，我們還通過 FEC、RLNC 等信道編碼技術，通過冗余發送的方式來降低傳輸延遲。還有一個大家比較容易忽視的地方，就是亂序的處理問題，在傳輸過程中，要自適應地調整亂序容忍度，來減少不必要的重傳帶來的網絡擁塞。在擁塞算法上，像 bbr、cubic、以及 WebRTC 中的 Transport-cc 等，它們的思路不太一樣，我們一方面基于延遲梯度的帶寬估計，去做碼率自適應的控制，但要注意在一些場景，如低 RTT 的場景，可能類似于基于 RTT 延遲或延遲變化的擁塞控制算法，反而沒有基于丟包的算法更準確，所以需要根據實時的網絡 QoS 去做自適應的調整擁塞控制算法。最后一個針對的是直播場景，特別是媒體新聞的場景，需嚴格控制整體的端到端延遲，因此需要傳輸協議能支持可選擇性的丟包，即通過控制一段固定的 Buffer 來維持一個恒定的延遲。

我們主要基于 SRT，也結合了 QUIC、WebRTC 中的一些優勢，同時做了剛才提到的一系列優化，最終形成了一個針對流媒體遠程傳輸的產品，同時，也提供了 SDK 的接入方式。通過與常規的 RTMP，甚至 QUIC 的對比，發現它在卡頓和延遲上都得到很大的提升。

多路徑傳輸是一個重點。現場可能有 4G、5G、WIFI 等多種網絡并行，通過多路徑傳輸的算法，可以很好地規避單一網絡波動所帶來的影響，如當 4G、5G 的使用人較多，現場可能出現信號中斷，這時通過多條鏈路進行實時地補償，可以做到下行的平滑切換。但這種方案有一些限制，如它要求現場必須有多種網絡類型，但很多情況下不具備這樣的條件。又比如，新聞外采等處于戶外場景時，可能是在偏遠地區，上行接入節點可能無法做到本地覆蓋，這時通常可以采用多個上行節點備選的方式，在推流前進行探速，選擇質量最好的節點進行推流，但當新聞或賽事持續時間長（如有些媒體領域需 7×24h 不間斷直播），這樣的方式無法適應網絡的變化帶來的影響。因此，提出多接入點的方案，允許接入端同時鏈接多個接入節點，在傳輸過程中，根據每條鏈路的 QoS 對比情況進行動態切換或調整發送的比例，來達到下行無感知的效果。

多路徑傳輸的方案較多，最悠久的是 MPTCP，目前已經形成了標準，它的原理是根據已創建的鏈接，通過子 flow 的方式定義一個新的子鏈接，同時借助 token、隨機數、HMAC 等安全算法來確保建立子鏈接的安全和準確性。但它也有一些局限，如因為 TCP 與內核相關，在部署時有阻礙和瓶頸，并且 MPTCP 存在兼容性問題，如多路徑版本的 TCP 與普通 TCP 存在兼容性問題。

MPQUIC 沿襲了 TCP 的思路，包括通過遷移、協商的方式來建立新的鏈接。同時，它改進了一些機制，如在重傳機制上，它允許一個鏈接的重傳包在另一個鏈接上重傳，這時因為兩個鏈接的 RTT 可能不一樣，因此若仍用 RTT 較大的鏈接進行重傳，可能延遲會增加，而用 RTT 較小的鏈接進行重傳，來補齊這個延遲。此外，相對 TCP，QUIC 的兼容性更好，因為沒有在 QUIC 的包頭額外新加字段。

SRT 中的多路徑方案為 SRT-BONDING，它的大致原理是在 handshake 階段，每個子鏈接會有一個 group id，服務端根據 group id 將不同的 srt_socket “綁定” 到一起。我認為 bonding 這個詞用得比 multipath 要好一些。其實原本的 SRT 支持的是廣播和 Backup 模式，在此基礎上，我們新增支持聚合模式。聚合模式使用起來相對更復雜，需要根據實時的 QoS 的狀態，如 RTT、重傳率等來調整發送比例。

這個視頻演示的內容是：在網絡發生切換時，它能有一個很平滑的切換過程。

將現場的音視頻信號傳輸到云端后，還要將音視頻信號低延遲地遠程傳輸到可能位于地球另一端的制作中心，因此需要一個云端的低延遲遠程傳輸方案。我們的 StreamLink 能提供全球化的高速、穩定、低延遲的視頻流媒體的傳輸服務和平臺，解決現場到制作中心的低延遲遠程傳輸的問題。同時支持協議間的轉換，如由于設備的原因，上行只支持 RTP，或只支持 RTMP，甚至只支持 UDP、TS 這種，那么我們通過中間的傳輸環節，在制作中心轉送適配的音視頻傳輸協議。

除了媒體傳輸方面，我們還可在源站方面提高穩定性。比如在媒體層面，采用 SMPTE2022-07 等標準，該標準通過冗余發送的方式做到幀級別的冗余糾錯。但這個標準存在一些局限，如它要求這個源是來自于相同編碼器推兩路流上來。那有可能現場有兩個機位，它們編碼器設置方面或者參數方面可能有些不一致，那么在這種場景下，我們還需要進行基于時間戳的 GOP 粒度的平滑切換，并對時間戳進行一些修改，而不能按照幀級別進行切換。在分發階段，需要結合每條鏈路量化的 QoS，去動態決策每個路由需發多少比例的數據，來達到整體的穩定性。

3、流媒體播放體驗優化

接下來，針對這些播放協議，介紹我們有哪些優化手段。

除了卡頓、首幀和成功率等指標，直播場景下，我們對直播的播放延遲和畫面質量也有很高的要求。

在媒體源站上，除了通過輸入雙通道提升穩定性，通過自動補幀等功能做到平滑效果外，我們還基于騰訊云智能極速高清編碼技術，達到在相同畫質的場景下碼率更低的效果。

其次，在輸出方面，首先通過獨立的 output group 輸出設置來滿足不同場景的需求，并且隔離相互間的影響，比如設置不同的分辨率、碼率組合等。還需注意的是，若要采用自適應多碼率，要確保多碼率間的切片邊緣達到幀級別的對齊，這樣切換碼率時才能保證畫面不前進或后退。另外，由于 4K、8K 視頻流對 CPU 的消耗較高，當前的容器或云主機無法做到所有的碼率組合，因此需要提供分布式轉碼任務和切片封裝的能力，并在提升可擴展能力的同時，保障多碼率間達到幀級別的對齊。

媒體行業里常用的一個平滑手段是 continue，即在斷流期間可以自動補齊靜音、黑屏幀，但這樣的效果不佳。另外，還可以自動補齊一張圖片（如 PPT 右圖所展示的圖片）或提前準備好的一段廣告。

在封裝階段，我們支持 HLS、DASH、CMAF 等自適應多碼率的輸出，也支持一些低延遲的輸出，還支持 DRM、多音軌等輸出。同時，源站支持多 CDN 的接入，包括轉存、回源、分發，這更適合多 CDN 場景的架構。

流媒體里的一個關鍵因素是延遲。相對其他協議，國內最常用的 FLV 的特點是較簡單、

消耗較少、延遲較好（2、3 秒級別），因此它是目前國內主流的播放側的協議。但它最大的問題是由于版本維護等歷史原因，支持的編碼格式不多，比如對 HEVC、AV1 等格式支持得不太好，或需要一些私有化的改造，且在多碼率、多音軌等方面做得不太好。

HLS、DASH 很好地解決了上述問題，但同時它們的延遲較高，這是因為切片的粒度至少是一個 GOP，因此帶來的延遲是 n 個 GOP，這樣延遲相對于 FLV，不能達到在一個 GOP 內也能夠開始播放的效果。

因此，在這種場景下，低延遲流媒體應運而生。LL-DASH 和 LHLS，或者基于 CMAF 這種低延遲 DASH 和 HLS，它利用 chunked 傳輸機制，能將延遲控制在和 FLV 的延遲同一個級別的場景。蘋果官方的 LLHLS 可做到相對更低的延遲。若要達到 1 秒以內的延遲，需要借助實時音視頻的王者，即 WebRTC，它通過一些傳輸機制，如分級重傳等機制，可將延遲控制在 500 毫秒，甚至更低。但它本身也存在一些不足：它的協議比較復雜，涉及到私有化的改造，需要更復雜的信令來實現多碼率、多音軌，對于 CDN 的架構，改造的成本和挑戰也較多。

低延遲切片的基礎是分塊傳輸編碼，HTTP 1.1 的版本已經對其進行了支持，但 LL-DASH 還做了容器化的改造，如支持 Chunked CMAF，更重要的是在 CDN 的分發系統里支持 Chunked 傳輸，這是 CDN、媒體源要做的事情。

與此同時，LLDASH、社區版的 LHLS（不是蘋果官方的 LHLS）也有各自的優化思路。LLDASH 提供 Manifest 文件來告知播放器，在什么樣的延遲下以什么樣的播放速率去播放，這樣在延遲較大時，可以按照比如 1.1 倍的速度進行播放，將延遲 “追上來”。LHLS 采用預加載的方式，通過 manifest 告訴播放器下一個分片是什么。

而蘋果官方的 LLHLS 會成為低延遲 LHLS 的標準，社區版的 LHLS 會逐漸被廢棄。LLHLS 的改進點更多，它摒棄了 chunk transcoding encoding，即分塊傳輸編碼，采用粒度更小的切片，直接在 Manifest 文件中展示出來，同時也提供預加載方式。此外，提供阻塞式更新和增量升級，它允許播放器在請求 LLHLS 時，帶上當前已下載的 menu sequence 序列號，即已下載的分片，以及子分片的序列號，服務端會根據這個參數判斷有無更新的切片產生，若沒有新切片產生，通常的 HLS 直接返回舊的 m3u8 文件，而這種低延遲的 HLS 會阻塞住，一直等到有新的切片產生再返回，這樣的好處是它能第一時間把信息推送給播放器，而不是等到輪詢的方式再去獲取信息，其次可以減少播放器的請求次數。還有一些其他手段，如更快的碼率切換，它允許一個子碼率的 m3u8 可以攜帶其他碼率信息，這樣播放器可以復用一個連接去快速請求其他碼率的數據，還有一個是 server push，但是我看它已經在最新的常案中被廢棄了，因為它需要 HTTP/2 的支持。這些特性 LLHLS 也提供更靈活的播放端的控制，允許播放端帶上一些參數來選擇性地開啟這些開關。

如果要想達到 1s 內的延遲，需要借助基于 WebRTC 的超低延遲直播，目前 WebRTC 更多地應用在實時音視頻的場景，但我們也將其用在低延遲的直播場景，如電商、課堂互動場景。除了在傳輸上簡化信令以外，也結合了直播流媒體的特點進行了深度優化，包括分級重傳、選擇性地丟幀等，這里不再贅述，總體上能夠在弱網條件下，也能保證低延遲。

4、賽事場景探索與創新

最后，簡單介紹針對賽事場景，我們一些比較有意思的創新。

比如直播時移。在直播過程中，將切片實時地存儲起來，這樣可以統一直播和時移的分片格式和分片內容。一方面，簡化播放器請求的邏輯和參數，實現拖拽即時移的效果。另一方面，在直播過程中，動態地智能生成精彩點位的信息，具體做法是，在媒體處理階段，進行視頻幀分析，通過深度學習和智能分類技術，把畫面中出現的熱點事件（如英雄聯盟中的五殺事件）捕捉出來，通過接口回調的方式推送給業務平臺方的接口，業務平臺方接收到信息后，可在其播放頁面或播放器上展示出相應的效果。

另一個是廣告插入，這個技術比較悠久，根據插入位置，可分為視頻前廣告、視頻中廣告和視頻后廣告，直播領域主要是前兩種。從技術手段來講我們主要分為 3 類。第一類，可達到千人一面的效果，即將提前準備好的視頻廣告在編碼環節加入視頻流里，這樣大家看到的廣告都是一樣的。第二類，借助廣電行業的標準：SCTE-35，SCTE-35 是 MPEG-TS 里的事件信息標識的標準，將其應用在廣告插入里能達到動態插入的效果，在最終的 HLS、DASH、CMAF 的 Manifest 文件里會打上相應的標簽，播放器讀到標簽后，可以在它所指示的時間點做相應的行為，如開始一段廣告、暫停或停止播放等。第三類，是個性化廣告，讓大家看到的廣告都不一樣，這包含了智能化技術，如通過視頻幀的智能識別，識別到轉場畫面或特殊事件時，打上一個標記，播放器得到這個標記后，可遵循 VAST 等標準，去請求這個標記和源信息里包含的廣告投放方的接口，廣告投放方可根據歷史畫像，如 IP 信息、國家地區信息，去下發不同的廣告內容，這樣就實現了千人千面的廣告效果。

最后是云導播。云導播是制作中心的一種低成本云端替代方案，在一些低成本的應用場景，更加適合采用云導播方式，實現在云端一鍵切流、混流、字幕、水印等一系列強大的音視頻處理能力。

以上是本次的分享，感謝大家！