低延遲流媒體協議 SRT、WebRTC、LL-HLS、UDP、TCP、RTMP 詳解

本文爲媒礦工廠翻譯的技術文章

原標題：Low Latency Streaming Protocols SRT, WebRTC, LL-HLS, UDP, TCP, RTMP Explained

原作者：Vitaly Suturikhin

原文鏈接：https://ottverse.com/low-latency-streaming-srt-webrtc-ll-hls-udp-tcp-rtmp/0

翻譯整理：徐鋆

低廣播延遲已經成爲任何關於建設源端站和 CDN 的招標和競爭中的必要特性。以前這種標準只適用於體育廣播，但現在運營商要求每個領域的廣播設備供應商提供低延遲，比如：廣播新聞、音樂會、表演、採訪、談話節目、辯論、電子競技等等。

什麼是低延遲？

一般來說，延遲是指某一特定視頻幀被設備（攝像機、播放機、編碼器等）捕獲的時間與該幀在終端用戶顯示器上播放的時間之間的時間差。

什麼是低延遲視頻流？

低延遲不應降低信號傳輸的質量，這意味着在編碼和複用時使用最小的緩衝，同時在任何設備的屏幕上需要保持流暢和清晰的畫面。另一個先決條件是保證傳輸：所有丟失的數據包都應該被恢復，以及在開放網絡上的傳輸不應該引起任何問題。

越來越多的服務正在遷移到雲端，以節省租用的場地、電力和硬件成本。這增加了對高 RTT（Round Trip Time, 往返時間）下低延遲的要求。在播放高清和超清視頻時，傳輸高比特率的情況尤其如此。比如如果雲服務器位於美國，而內容消費者在歐洲的情況。

在這篇文章中，我們將分析目前市場上在低延遲廣播方面提供的方案。

UDP

在現代電視廣播中被廣泛使用並與 "低延遲" 一詞相關的第一項技術可能是通過 UDP 的 MPEG TS 流內容進行的組播。通常情況下，這種格式適合封閉的無負載網絡，在這種情況下，丟包率是最小的。例如，從編碼器到源端站調製器的廣播（通常在同一個服務器機架內），或通過帶有放大器和中繼器的專用銅線或光纖線路的 IPTV 廣播。

這種技術被普遍使用，並表現出良好的延遲特性。市場上的公司使用以太網實現的與編碼、數據傳輸和解碼相關的延遲，在每秒 25 幀的情況下不超過 80ms。在更高的幀率下，這一延遲特性甚至更低。

圖 1. UDP 廣播延遲測量

圖 1 上半部分顯示了來自 SDI 採集卡的信號，下半部分展示經過編碼、多路複用、廣播、接收和解碼階段的信號。如圖所示，第二個信號晚一幀到達（在這種情況下，因爲信號是 25fps，1 幀是 40 毫秒）。在 Confederations Cup 2017 和 FIFA World Cup 2018 上使用了類似的解決方案，只有一個調製器、一個分佈式 DVB-C 網絡和一個作爲終端設備的電視加入到架構鏈中，最終總延遲爲 220-240 毫秒。

如果信號通過一個外部網絡怎麼辦？有各種問題需要克服：干擾、整形、流量阻塞通道、硬件錯誤、電纜損壞和軟件層面的問題。在這種情況下，不僅需要低延遲，還需要對丟失的數據包進行重傳。

在 UDP 的情況下，帶有冗餘的前向糾錯技術 FEC（有額外的測試流量或開銷）做得很好。同時，對網絡吞吐率的要求隨之增加，因此，延遲和冗餘也會增加，這取決於預期丟失數據包的百分比。由於 FEC 能恢復的數據包的百分比總是有限的，而且在開放網絡的傳輸過程中可能有很大的變化。因此，爲了在長距離上可靠地傳輸大量數據，有必要在其中增加較多的多餘流量。

TCP

接下來讓我們看看基於 TCP 協議的技術（可靠交付）。如果收到的數據包的校驗和不符合預期值（在 TCP 數據包頭中設置），那麼這個數據包就會被重新發送。而如果客戶端和服務器端不支持選擇性確認（SACK）規範，那麼整個 TCP 數據包鏈（從丟失的數據包到最後一個以較低速率接收的數據包）就會被重新發送。

以前，當涉及到直播的低延遲時，通常會避免使用 TCP 協議，因爲錯誤檢查、數據包重發、三次握手、"慢啓動" 和防止信道擁塞（TCP 慢啓動和擁塞避免階段），延遲會增加。同時，即使信道很寬，傳輸開始前的延遲也可能達到 RTT 的五倍，而吞吐量的增加對延遲的影響非常小。

另外，使用 TCP 廣播的應用程序對協議本身沒有任何控制（它的超時、重新廣播的窗口大小），因爲 TCP 傳輸是作爲一個單一的連續流實現的，在錯誤發生之前，應用程序可能會無限期地 "凍結"。而且高層協議沒有靈活配置 TCP，以儘量減少廣播問題的能力。

同時，有些協議即使在開放的網絡和長距離的情況下也能通過 UDP 有效工作。

下面讓我們來考慮和比較各種協議的實現。在基於 TCP 的協議和數據傳輸格式中，將會涉及 RTMP、HLS 和 CMAF，而在基於 UDP 的協議和數據傳輸格式中，將會涉及 WebRTC 和 SRT。

RTMP

RTMP 是 Macromedia 公司的專有協議（現在歸 Adobe 公司所有），在基於 Flash 的應用程序流行時非常流行。它有幾個品種，支持 TLS/SSL 加密，甚至還有基於 UDP 的變種，即 RTFMP（實時媒體流協議，用於點對點連接）。RTMP 將數據流分割成片段，其大小可以動態變化。在通道內，與音頻和視頻有關的數據包可以交錯和複用。

圖 2. RTMP 廣播實現用例

RTMP 會構建幾個虛擬通道，在這些通道上傳輸音頻、視頻、元數據等。大多數 CDN 不再支持 RTMP 作爲向終端客戶分配流量的協議。然而，Nginx 有自己的 RTMP 模塊，支持普通的 RTMP 協議，它運行在 TCP 之上，使用默認的 1935 端口。Nginx 可以作爲一個 RTMP 服務器，分發它從 RTMP 流媒體接收的內容。另外，RTMP 仍然是向 CDN 交付流量的流行協議，但在未來，流量將使用其他協議進行傳輸。

目前，Flash 技術已經過時，且不受支持：瀏覽器或是減少對它的支持，或是完全禁止使用。RTMP 不支持 HTML5，在瀏覽器中也難以使用（播放需要通過 Adobe Flash 插件）。爲了繞過防火牆，他們使用 RTMPT（封裝到 HTTP 請求中，並使用標準的 80/443 而不是 1935 端口），但這大大影響了延遲和冗餘（根據各種估計，RTT 和整體延遲增加 30%）。儘管如此，RTMP 仍然很流行，例如，在 YouTube 上的廣播或在社交媒體上（Facebook 的 RTMPS）。

RTMP 的主要缺點是缺乏對 HEVC/VP9/AV1 編碼器的支持，以及只允許兩個音軌的限制。此外，RTMP 在數據包頭中不包含時間戳。RTMP 只包含根據幀率計算的標籤，因此解碼器並不確切知道何時解碼這個流。這就需要一個接收組件均勻地生成用於解碼的樣本，因此緩衝區必須按數據包抖動的大小來增加。

RTMP 的另一個問題是重新發送丟失的 TCP 數據包，這在前文已經描述過。爲了保持較低的回傳流量，確認收到（ACK）並不直接到發件端。只有在收到數據包鏈後，纔會向廣播方發送 ACKs 或 NACKs 的確認信息。

根據各種估計，使用 RTMP 進行廣播，通過完整的編碼路徑（RTMP 編碼器→RTMP 服務器→RTMP 客戶端）的延遲至少是兩秒。

CMAF

CMAF（Common Media Application Format，通用媒體應用格式）是由蘋果和微軟邀請 MPEG 開發的協議，用於在 HTTP 上進行自適應廣播（具有根據整個網絡帶寬速率變化而變化的自適應比特率）。通常情況下，蘋果公司的 HTTP 直播（HLS）使用 MPEG TS 流，而 MPEG DASH 使用片段式的 MP4。2017 年 7 月，CMAF 標準被髮布。在 CMAF 中，片段式的 MP4 片段（ISOBMFF）通過 HTTP 傳輸，同一內容有兩個不同的播放列表，用於特定的播放器：iOS（HLS）或 Android/Microsoft（MPEG DASH）。

默認情況下，CMAF（像 HLS 和 MPEG DASH）不是爲低延遲廣播設計的。但行業對低延遲的關注和興趣在不斷增加，所以一些廠商提供了標準的擴展，例如低延遲 CMAF。這種擴展假定廣播方和接收方都支持兩種方法：

  1. 分塊編碼：將片段分成子片段（帶有 moof+mdat mp4 框的小片段，最終構成適合播放的整個片段），並在整個片段拼合之前發送。

  2. 分塊傳輸編碼：使用 HTTP 1.1 發送子片段到 CDN（源）：每 4 秒只發送 1 次整個片段的 HTTP POST 請求（每秒 25 幀），此後在同一會話中可以發送 100 個小片段（每個片段有一幀）。播放器也可以嘗試下載不完整的片段，而 CDN 則使用分塊傳輸編碼提供完成的部分，然後保持連接，直到新的片段被添加到正在下載的片段中。一旦整個片段在 CDN 一側形成，向播放器傳輸的片段就會完成。

圖 3. 標準的分塊 CMAF

如果要在配置文件之間切換，則需要緩衝（至少 2 秒）。鑑於這一點以及有可能的分發問題，該標準的開發者聲稱延遲小於 3 秒。同時，諸如通過 CDN 與成千上萬的同時客戶端進行擴展、加密（連同通用加密支持）、HEVC 和 WebVTT（字幕）支持、保證交付和與不同播放器（蘋果 / 微軟）的兼容性等重要特徵都得到了保留。在缺點方面，人們可能會注意到播放器方面強制性的 LL CMAF 支持（支持碎片化的片段和內部緩衝區的高級操作）。然而，在不兼容的情況下，播放器仍然可以使用 CMAF 規範內的內容，具有 HLS 或 DASH 的標準延遲。

LL-HLS

2019 年 6 月，蘋果發佈了低延遲 HLS 的規範。

它由以下部分組成：

  1. 生成部分片段（片段式的 MP4 或 TS），最小持續時間爲 200 毫秒，甚至在由這些部分組成的整個片段完成之前就可以使用。過時的部分片段會定期從播放列表中刪除；

  2. 服務器端可以使用 HTTP/2 推送模式，將更新的播放列表與新的片段一起發送。然而，在 2020 年 1 月的最後一次規範修訂中，這一建議被排除；

  3. 服務器的責任是保留請求（阻塞），直到包含新片段的播放列表版本可用。阻斷播放列表的重新加載消除了輪詢；

  4. 不發送完整的播放列表，而是發送播放列表的增量（默認的播放列表被保存，然後只在出現時發送增量，而不是發送完整的播放列表）；

  5. 服務器宣佈即將出現的新的部分片段（預加載提示）；

  6. 關於播放列表的信息在相鄰的配置文件中被同時加載，以加快切換。

圖 4. LL HLS 的運行原理

在 CDN 和播放器完全支持該規範的情況下，預計延遲時間小於 3 秒。HLS 由於其出色的可擴展性、加密和自適應比特率支持跨平臺功能以及向後兼容，非常廣泛地用於開放網絡的廣播，如果播放器不支持 LL HLS，這一點很有用。

WebRTC

WebRTC（網絡實時通信）是由谷歌在 2011 年開發的一個開源協議。它被用於 Google Hangout、Slack、BigClueButton 和 YouTube Live。WebRTC 是一套標準、協議和 JavaScript 編程接口，並且使用 DTLS-SRTP 在點對點連接中實現了端到端的加密。此外，該技術不使用第三方插件或軟件，可以在不損失質量和延遲的情況下通過防火牆（例如，在瀏覽器的視頻會議期間）。在播放視頻時，通常使用基於 UDP 的 WebRTC 實現。

該協議的工作原理如下：一臺主機向要連接的對等客戶發送一個連接請求。在對等客戶之間的連接建立之前，它們通過第三方信號服務器相互通信。然後，每個對等客戶都向 STUN 服務器詢問 "我是誰？" (如何從外面找到我？)。

同時，有公共的谷歌 STUN 服務器（例如 stun.l.google.com:19302）。STUN 服務器提供一個 IP 和端口的列表，通過這個列表可以到達當前的主機。ICE 候選者是由這個列表形成的。第二個客戶也進行相同的操作。ICE 候選者通過信號服務器進行交換，正是在這個階段建立了點對點的連接，即形成了一個點對點的網絡。

如果不能建立直接連接，那麼一個所謂的 TURN 服務器就充當中繼 / 代理服務器，它也被列入 ICE 候選名單。

SCTP（應用數據）和 SRTP（音頻和視頻數據）協議負責多路複用、發送、擁塞控制和可靠交付。對於 “握手” 交換和進一步的流量加密，使用了 DTLS。

圖 5. WebRTC 協議棧

使用 Opus 和 VP8 作爲編解碼器。最大支持的分辨率爲 720p，30fps，比特率最高到 2Mbps。

WebRTC 技術在安全方面的一個缺點是，即使在 NAT 後面和使用 Tor 網絡或代理服務器時，也要定義一個真實的 IP。由於連接結構的原因，WebRTC 不適合大量同時觀看的對等客戶（難以擴展），而且目前 CDN 也很少支持它。最後，WebRTC 在編碼質量和最大傳輸數據量方面不如其他協議。

WebRTC 在 Safari 中不可用，在 Bowser 和 Edge 中部分不可用。谷歌聲稱其延遲不到一秒。同時，該協議不僅可用於視頻會議，也可用於文件傳輸等應用。

SRT

SRT（Secure Reliable Transport，安全可靠傳輸）是由 Haivision 在 2012 年開發的一個協議。該協議在 UDT（基於 UDP 的數據傳輸協議）和 ARQ 數據包恢復技術的基礎上運行。它支持 AES-128 和 AES-256 加密。除了監聽（服務器）模式，它還支持呼叫（客戶端）和會合（當雙方啓動連接時）模式，這使得連接可以通過防火牆和 NAT 建立。SRT 的 “握手” 過程是在現有的安全策略中進行的，因此允許外部連接，而不需要在防火牆中打開永久的外部端口。

SRT 在每個數據包內都包含時間戳，這就允許以與流編碼速率相等的速度播放，而不需要大量的緩衝，同時使抖動（不斷變化的數據包到達率）和傳入的比特率保持一致。與 TCP 中一個數據包的丟失可能會導致重新發送整個數據包鏈不同，從丟失的數據包開始，SRT 通過其編號識別一個特定的數據包，並只重新發送這個數據包。這對延遲和冗餘有積極作用。

重發的數據包比標準廣播的優先級更高。與標準的 UDT 不同，SRT 完全重新設計了重發數據包的架構，一旦數據包丟失，就立即做出反應。這項技術是選擇性重複 / 拒絕 ARQ 的一個變種。值得注意的是，一個特定的丟失的數據包可能只被重新發送固定的次數。當數據包上的時間超過總時延的 125% 時，發送方會跳過該數據包。SRT 支持 FEC，用戶自己決定使用這兩種技術中的哪一種（或同時使用兩種），以平衡最低延遲和最高傳輸可靠性。

圖 6. SRT 在開放網絡上的運行原理

SRT 中的數據傳輸可以是雙向的：兩點都可以同時發送數據，也可以同時作爲監聽和發起連接的一方。當雙方都需要建立連接時，可以使用會合模式。該協議有一個內部複用機制，允許將一個會話的幾個流複用到使用一個 UDP 端口的一個連接中。SRT 也適用於快速文件傳輸，這個應用在 UDT 中首次引入。

SRT 有一個網絡擁堵控制機制。每隔 10 毫秒，發送方就會收到關於 RTT 及其變化的最新數據、可用的緩衝區大小、數據包接收率和當前鏈接的大致大小。SRT 對連續發送的兩個數據包之間的最小延時有限制。如果它們不能及時送達，就會從隊列中刪除。

開發者聲稱，在封閉網絡中短距離傳輸中設置緩衝區爲最小，使用 SRT 可能實現的最小延遲是 120 毫秒。建議穩定廣播的總延遲是 3-4 個 RTT。此外，SRT 在長距離（幾千公里）和高比特率（10Mbps 及以上）的傳輸方面比其競爭對手 RTMP 處理得更好。

圖 7. SRT 廣播延遲測試

在上面的例子中，實驗室測量的 SRT 廣播的延遲在 25fps 的條件下是 3 幀。也就是 40ms*3=120ms。由此我們可以得出結論，在 UDP 廣播中可以達到的 0.1 秒的超低延遲，在 SRT 廣播中也是可以實現的。SRT 的可擴展性與 HLS 或 DASH/CMAF 不在同一水平上，但 SRT 得到 CDN 和轉發者 (restreamer) 的大力支持，也支持通過媒體服務器以監聽模式直接廣播給終端客戶。

2017 年，Haivision 披露了 SRT 庫的源代碼，並創建了 SRT 聯盟，該聯盟包括 350 多個成員。

總結

作爲總結，下表展示了各個協議的對比：

  1. 不支持由 CDN 向終端用戶傳輸。支持內容流向最後一英里，例如，流向 CDN 或 restreamer。

  2. 在瀏覽器中不支持

  3. Safari 中不支持

目前，所有開源的、文檔全面的東西都在迅速流行起來。可以認爲，像 WebRTC 和 SRT 這樣的格式在各自的應用範圍內有一個長遠的未來。在最低延遲方面，這些協議已經超過了 HTTP 上的自適應廣播，同時保持可靠的傳輸，具有低冗餘度，並支持加密（SRT 的 AES 和 WebRTC 的 DTLS/SRTP）。

另外，最近 SRT 的 “小兄弟”（根據協議的產生時間，而不是在功能和能力方面）RIST 協議，正在獲得普及，但這是另一個話題了。同時，RTMP 正在積極地被新的競爭者擠出市場，而且由於瀏覽器缺乏原生支持，它難以很快被廣泛使用。

本文由 Readfog 進行 AMP 轉碼，版權歸原作者所有。
來源：https://mp.weixin.qq.com/s/GbKZoJCK82bGh5hWDBWM2Q

猜你喜歡