低廣播延遲成為建設(shè)源端站和CDN的必要特性

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

什么是低延遲？

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

什么是低延遲視頻流？

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

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

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

UDP

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

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

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

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

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

TCP

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

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

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

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

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

RTMP

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

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

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

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

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

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

CMAF

CMAF（Common Media Application Format，通用媒體應(yīng)用格式）是由蘋果和微軟邀請(qǐng)MPEG開發(fā)的協(xié)議，用于在HTTP上進(jìn)行自適應(yīng)廣播（具有根據(jù)整個(gè)網(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)容有兩個(gè)不同的播放列表，用于特定的播放器：iOS（HLS）或Android/Microsoft（MPEG DASH）。

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

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

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

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

LL-HLS

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

它由以下部分組成：

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

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

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

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

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

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

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

WebRTC

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

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

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

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

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

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

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

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

SRT

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

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

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

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

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

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

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

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

總結(jié)

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

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

在瀏覽器中不支持

Safari中不支持

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

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

原文標(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