低廣播延遲已經(jīng)成為任何關(guān)于建設(shè)源端站和CDN的招標(biāo)和競爭中的必要特性。以前這種標(biāo)準(zhǔn)只適用于體育廣播，但現(xiàn)在運營商要求每個領(lǐng)域的廣播設(shè)備供應(yīng)商提供低延遲，比如：廣播新聞、音樂會、表演、采訪、談話節(jié)目、辯論、電子競技等等。

什么是低延遲？

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

什么是低延遲視頻流？

低延遲不應(yīng)降低信號傳輸?shù)馁|(zhì)量，這意味著在編碼和復(fù)用時使用最小的緩沖，同時在任何設(shè)備的屏幕上需要保持流暢和清晰的畫面。另一個先決條件是保證傳輸：所有丟失的數(shù)據(jù)包都應(yīng)該被恢復(fù)，以及在開放網(wǎng)絡(luò)上的傳輸不應(yīng)該引起任何問題。

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

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

UDP

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

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

圖1上半部分顯示了來自SDI采集卡的信號，下半部分展示經(jīng)過編碼、多路復(fù)用、廣播、接收和解碼階段的信號。如圖所示，第二個信號晚一幀到達（在這種情況下，因為信號是25fps，1幀是40毫秒）。在Confederations Cup 2017和FIFA World Cup 2018上使用了類似的解決方案，只有一個調(diào)制器、一個分布式DVB-C網(wǎng)絡(luò)和一個作為終端設(shè)備的電視加入到架構(gòu)鏈中，最終總延遲為220-240毫秒。

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

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

TCP

接下來讓我們看看基于TCP協(xié)議的技術(shù)（可靠交付）。如果收到的數(shù)據(jù)包的校驗和不符合預(yù)期值（在TCP數(shù)據(jù)包頭中設(shè)置），那么這個數(shù)據(jù)包就會被重新發(fā)送。而如果客戶端和服務(wù)器端不支持選擇性確認（SACK）規(guī)范，那么整個TCP數(shù)據(jù)包鏈（從丟失的數(shù)據(jù)包到最后一個以較低速率接收的數(shù)據(jù)包）就會被重新發(fā)送。

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

另外，使用TCP廣播的應(yīng)用程序?qū)f(xié)議本身沒有任何控制（它的超時、重新廣播的窗口大小），因為TCP傳輸是作為一個單一的連續(xù)流實現(xiàn)的，在錯誤發(fā)生之前，應(yīng)用程序可能會無限期地 “凍結(jié)”。而且高層協(xié)議沒有靈活配置TCP，以盡量減少廣播問題的能力。

同時，有些協(xié)議即使在開放的網(wǎng)絡(luò)和長距離的情況下也能通過UDP有效工作。

下面讓我們來考慮和比較各種協(xié)議的實現(xiàn)。在基于TCP的協(xié)議和數(shù)據(jù)傳輸格式中，將會涉及RTMP、HLS和CMAF，而在基于UDP的協(xié)議和數(shù)據(jù)傳輸格式中，將會涉及WebRTC和SRT。

RTMP

RTMP是Macromedia公司的專有協(xié)議（現(xiàn)在歸Adobe公司所有），在基于Flash的應(yīng)用程序流行時非常流行。它有幾個品種，支持TLS/SSL加密，甚至還有基于UDP的變種，即RTFMP（實時媒體流協(xié)議，用于點對點連接）。RTMP將數(shù)據(jù)流分割成片段，其大小可以動態(tài)變化。在通道內(nèi)，與音頻和視頻有關(guān)的數(shù)據(jù)包可以交錯和復(fù)用。

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

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

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

RTMP的另一個問題是重新發(fā)送丟失的TCP數(shù)據(jù)包，這在前文已經(jīng)描述過。為了保持較低的回傳流量，確認收到（ACK）并不直接到發(fā)件端。只有在收到數(shù)據(jù)包鏈后，才會向廣播方發(fā)送ACKs或NACKs的確認信息。

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

CMAF

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

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

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

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

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

LL-HLS

2019年6月，蘋果發(fā)布了低延遲HLS的規(guī)范。

它由以下部分組成：

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

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

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

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

服務(wù)器宣布即將出現(xiàn)的新的部分片段（預(yù)加載提示）；

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

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

WebRTC

WebRTC（網(wǎng)絡(luò)實時通信）是由谷歌在2011年開發(fā)的一個開源協(xié)議。它被用于Google Hangout、Slack、BigClueButton和YouTube Live。WebRTC是一套標(biāo)準(zhǔn)、協(xié)議和JavaScript編程接口，并且使用DTLS-SRTP在點對點連接中實現(xiàn)了端到端的加密。此外，該技術(shù)不使用第三方插件或軟件，可以在不損失質(zhì)量和延遲的情況下通過防火墻（例如，在瀏覽器的視頻會議期間）。在播放視頻時，通常使用基于UDP的WebRTC實現(xiàn)。

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

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

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

SCTP（應(yīng)用數(shù)據(jù)）和SRTP（音頻和視頻數(shù)據(jù)）協(xié)議負責(zé)多路復(fù)用、發(fā)送、擁塞控制和可靠交付。對于“握手”交換和進一步的流量加密，使用了DTLS。

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

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

WebRTC在Safari中不可用，在Bowser和Edge中部分不可用。谷歌聲稱其延遲不到一秒。同時，該協(xié)議不僅可用于視頻會議，也可用于文件傳輸?shù)葢?yīng)用。

SRT

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

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

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

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

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

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

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

2017年，Haivision披露了SRT庫的源代碼，并創(chuàng)建了SRT聯(lián)盟，該聯(lián)盟包括350多個成員。

總結(jié)

作為總結(jié)，下表展示了各個協(xié)議的對比：

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

在瀏覽器中不支持

Safari中不支持

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

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

原文標(biāo)題 | 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

翻譯整理：徐鋆

責(zé)任編輯：haq