close

。【業界術語】SRT 串流方式
。2021業界術語 SRT (Secure Reliable Transport 安全可靠傳輸)
●  SRT (Secure Reliable Transport ) 代表【安全可靠傳輸】,是一種開源 影音串流傳輸協議 和 技術堆疊碼。 SRT 使用安全串流和輕鬆穿越未知的防火牆來優化串流性能,並通過最不可靠的公共網絡,提供高質量的影音串流,常用於 遠程製作。
◎ 圖片資料來源:https://youtu.be/Hf5KzZNyxiM
◎ 參考資料來源:https://www.haivision.com/resources/streaming-video-definitions/srt/

◎ 參考資料來源:https://www.haivision.com/products/srt-secure-reliable-transport/

image

SRT_01cht

SRT的成長歷程
● 2012 Haivision 發明了 SRT
● 2013 Haivision 首次發表 SRT
● 2014 Makito X 支援 SRT
● 2017 Haivision 成立 SRT 聯盟
● 2018 VLC, FFMPEG, Microsoft 加入聯盟
● 2019 SRT 獲頒 艾美獎 EmmyR Award
● 2020 Avid, Grass Valley 加入聯盟
● 2021 Sony,  Lumen Technology 加入聯盟
● 2021 SRT 聯盟成員超過 500 家
===========================
===========================
●  SRT 開源項目主要由 Haivision 創立的 SRT 聯盟推動。 它允許使用在公共互聯網上提供高品質、低延遲的影音串流,並在不可預測的網絡上優化影音串流性能。


什麼是SRT?
image
●  SRT 等於【低延遲 的 UDP】+【ARQ 丟包立刻補發】。
Hivision_09

SRT的得力助手ARQ
image
● ARQ(Automatic Repeat reQuest 丟包立刻補發)是一種數據的【傳輸錯誤控制】和【數據封包還原】的方法,如果數據封包丟失,接收方會向發送方發出警報,以便發送方可以重新發送丟失的數據封包。ARQ 使用小量的頻寬來糾錯,非常適合在具有不可預測性的 IP 網絡上,以串流方式來傳輸影音,例如:公共互聯網上。 ARQ 為傳輸安全使用了小程度的延遲,由於適用於不可預測的網絡,而且不會增加大量延遲,開源 SRT (Secure Reliable Transport) 串流協議利用 ARQ 作為其主要的糾錯方法。這與 FEC (Forward Error Correction 前向糾錯) 有些差異,後面有說明。

image

可穿越未知的防火牆
image
●  SRT (Secure Reliable Transport ) 代表【安全可靠傳輸】,是一種開源 影音串流傳輸協議 和 技術堆疊碼。 SRT 使用安全串流和輕鬆穿越未知的防火牆來優化串流性能,並通過最不可靠的公共網絡,提供高質量的影音串流。
Hivision_08

一手傳 一手接
image
●  SRT 傳輸是利用【Encoder】編碼 SRT 格式,再經由【Internet】傳輸,目的地使用【Decoder】解碼 SRT 的成像。
Hivision_01


SRT 會聆聽 有丟包嗎? 
image
●  SRT Encoder 除了【輸出影音內容】外,還會【聆聽】SRT Decoder 的【回饋】,如果 Decoder 回饋的內容是【某內容影音未送達】,那 Encoder 就會【補上】。
Hivision_02


SRT 以換代修
image
●  SRT Encoder【補上的輸出影音內容】,會從【Buffer】中,重新【再傳送一次】,當然這會關係到【Buffer 長短】,Buffer 愈長,那 Encoder 就【愈有機會 補上】。
Hivision_03


SRT快速一來一往
image
●  SRT 的【Buffer 愈短】,代表【Latency 愈短,影音愈快抵達目的地】;【Buffer 愈長】,代表【Latency 愈長,影音延遲抵達目的地的時間愈慢】。一般會根據【Encoder】與【Decoder】二端的網路頻寬品質與距離,來進行設置【Buffer 長短】。
Hivision_05

SRT 您要的我還有
image
●  SRT Buffer 的 另一層意義是【Buffer 愈短】,代表【安全畫面 愈短】;【Buffer 愈長】,代表【安全畫面 愈長】。例如:下圖中,Decoder 回饋的內容是【送達的 第5格畫面有誤】,因為 Encoder【第5格畫面影音 還在Buffer 中】,因此可以重新發送【第5格畫面】,讓目的地得到的影音更臻完美。
Hivision_04


●  SRT 協議使用【end-to-end 的 128/256 位 AES 內容加密】來確保內容不受發佈的影響。 它還提供配置特定控件的功能,允許用戶糾正特定網絡挑戰,以提供低延遲影音串流並防止抖動、數據封包遺失和頻寬波動。
Hivision_07

=========================
=========================

SM_005_小常識.png
https://www.haivision.com/blog/broadcast-video/low-latency-video-packet-loss-arq-fec/
● ARQ 與 FEC 
https://www.haivision.com/resources/streaming-video-definitions/arq/
● ARQ 與 FEC 經常被拿來比較,其中 ARQ 為 SRT(Secure Reliable Transport 安全可靠傳輸)中 的“可靠”提供了基礎。

● 這篇文章將說明【丟包還原】的兩種基本方法:ARQ(Automatic Repeat reQuest 丟包立刻補發)和 FEC(Forward Error Correction 前向糾錯)。這兩種技術都是在【檢測】和【糾正】數據在傳輸中的錯誤。
◎ 一個簡單的背景:
◎ FEC (前向糾錯):常使用 Pro-MPEG FEC 的標準中,以通過非原始網絡傳輸數據。
◎ ARQ (自動反覆偵測):TCP 中使用的技術(在下面討論),但更常與 R-UDP、SRT、Zixi、QVidium 相關聯使用。
◎ TCP/IP 為什麼不能針對低延遲影音串流進行擴展。
◆目前幾乎所有的網絡流量都受到 TCP/IP (Transmission Control Protocol over Internet Protocol 基於 Internet 的傳輸控制協議) 的保護,不會讓數據丟包,TCP/IP 規定透過互聯網傳輸數據的規則、TCP/IP 規定計算機之間的傳送和接收關係 和 握手方式。

◆這些規則要求接收方確認所有收到的數據封包內容,以便發送方可以重新發送丟失的任何數據封包。然而,對於即時的影音串流,TCP/IP 會讓人崩潰,因為通信效率非常低,尤其是在長距離上。太多的【接收確認】淹沒了連接,大大降低了頻寬效率。在工作流程中的每個發送方和接收方(例如每個路由器)之間建立的緩衝也引入了巨大的傳輸延遲。這就是基於 TCP 的協議(例如 RTMP、HLS 和 MPEG-DASH)並不是最適合【低延遲即時的影音串流】的原因。

◎ 什麼是 FEC?
◆FEC(Forward Error Correction 前向糾錯)是一種在傳輸之前就向影音串流添加 Redundant data (備用數據) 的技術。類似 RAID 存儲技術,在多個儲存硬碟上傳輸和複製原始數據,當任何一個儲存硬碟故障時,所有原始數據都可以恢復。

◆在影音串流開始之前,如果丟失任何數據,將會執行恢復創建所需的數據。 FEC 在丟失一些輕微數據時,表現非常出色,但如果丟失大量數據,則效果則不佳。在上述的 RAID 範例中,如果兩個儲存硬碟同時故障,那就倒霉了。因此,FEC 與公共互聯網傳輸的突發性、由於電路異常、SLA 過度配置,導致擁塞致使數據封包丟失,起使用類型不太匹配。
◆FEC 通常在丟包率低於 3%-5% 且發送方/接收方關係不可能時有效,例如單向衛星或多播。
◆FEC 適用於丟包率低且一致的網絡。
◆FEC 確實會增加頻寬費用(對於備用數據),通常在 30% 的範圍內,以防止網絡具有“已知”損失。 FEC 還增加了執行初始計算和提供恢復計算的延遲。通常,這種增加的延遲可以是 100 到 500 毫秒的數量級。 FEC 的真正問題之一是為了避免過度配置 FEC 開銷(這會轉化為使用額外的延遲和不必要的頻寬),運營商需要了解數據封包丟失模式,這實際上是不可能做到的用於互聯網連接。

◎ ARQ – 丟失數據封包的發現者。
◆ARQ(Automatic Repeat reQuest 丟包立刻補發)是一種數據封包重傳方法,更適合即時的影音串流或資料量非常大的文件。 ARQ 並不是去確認收到每個數據封包內容,而是簡單地確認數據包是否丟失,因此,也避免了使用 TCP 高度潛伏的大量通信時間與頻寬效率的浪費。
◆ARQ 所需的頻寬,只是與所經歷的數據封包丟失相關聯,並且沒有像 FEC 那樣固定的“可破壞”級別,使其更適合公共互聯網的不可預測性。 如果數據封包丟失最小,則頻寬也最小。
◆當然,ARQ 確實會增加一些延遲,這取決於發送方/接收方的重傳或往返時間。 節點相距越遠,您需要透過更大的緩衝區來適應更多的延遲。 例如:從紐約到洛杉磯的往返時間約為 100 毫秒,額外的延遲並不是很明顯。 此外,由於最高效的網絡設計有幾個非常短的傳輸段,因此可以最大限度地減少整個工作流程的延遲。



小吳老師 整理

arrow
arrow
    全站熱搜

    小吳老師 發表在 痞客邦 留言(0) 人氣()