低廣播延遲已經成為任何關于建設源端站和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
-
多媒體
+關注
關注
0文章
496瀏覽量
36975 -
廣播
+關注
關注
1文章
305瀏覽量
23048 -
延遲
+關注
關注
1文章
70瀏覽量
13520
原文標題:低延遲流媒體協議SRT、WebRTC、LL-HLS、UDP、TCP、RTMP詳解
文章出處:【微信號:xunwei201508,微信公眾號:訊維官方公眾號】歡迎添加關注!文章轉載請注明出處。
發布評論請先 登錄
相關推薦
評論