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

什么是低延遲？

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

什么是低延遲視頻流？

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

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

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

UDP

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

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

圖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將數據流分割成片段，其大小可以動態變化。在通道內，與音頻和視頻有關的數據包可以交錯和復用。

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。這種擴展假定廣播方和接收方都支持兩種方法：

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

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

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

LL-HLS

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

它由以下部分組成：

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

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

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

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

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

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

在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。

使用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，用戶自己決定使用這兩種技術中的哪一種（或同時使用兩種），以平衡最低延遲和最高傳輸可靠性。

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

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

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

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

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

總結

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

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

在瀏覽器中不支持

Safari中不支持

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

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

原文標題 | Low Latency Streaming Protocols SRT， WebRTC， LL-HLS， UDP， TCP， RTMP Explained原文鏈接 | https://ottverse.com/low-latency-streaming-srt-webrtc-ll-hls-udp-tcp-rtmp/0

翻譯整理：徐鋆

責任編輯：haq