?點擊上方“LiveVideoStack”關注我們

作者：張博力

編輯：Alex

▼掃描下圖二維碼或點擊閱讀原文▼

了解音視頻技術大會更多信息

”

摘? 要：SRT協議（即安全可靠傳輸協議）是一個新興的網絡傳輸協議，適用于實時音視頻傳輸。本文將從SRT協議的原理分析入手，嘗試定義出一個衡量SRT鏈路可靠性高低的指標：鏈路安全冗余量(Secure-Margin)，并詳細介紹如何依照這個指標來部署一個可靠的SRT傳輸鏈路，并分析在不同的直播場景中的參數調整策略。

? 引? 言??

音視頻的信號傳輸技術作為廣電領域的重點技術之一，保障了傳輸的安全和質量。傳統的信號傳輸手段也許可以用三句話來概括：天上一顆星，地下一根纜，中間面對面的微波。

“天上一顆星”指的是衛星傳輸，優點是靈活安全可靠并且對于直播現場的條件沒有特殊要求，但其設備投資和費用非常昂貴。“地下一根纜”指的是光纖傳輸，優點是安全可靠并且延時極低，但它很依賴光纜鏈路的基礎建設，靈活性較差。“中間面對面的微波”最初指的是通視條件下的定向微波，后來又發展出長距離的U波段“大微波”和短距離的2G波段“小微波”。隨著5G和互聯網技術的飛速發展，通過公共互聯網安全可靠的傳輸音視頻信號已經成為一種可能，實際上我們的傳輸手段又多了一種：無需面對面的公網傳輸。

然而公共互聯網中普遍存在著不同程度的丟包、抖動、延時和帶寬波動，這就需要一種可靠的傳輸協議來保證傳輸鏈路的可靠性。SRT（Secure Reliable Transport）協議，即安全可靠傳輸協議，是一種新興的音視頻傳輸協議，在音視頻的點對點實時傳輸方面有著非常好的應用效果。

廣電的技術人員習慣通過鏈路的冗余量來估算鏈路的可靠程度，衛星鏈路中的類似指標是載噪比冗余量(C/N Margin),光纖鏈路可以通過光功率衰減和接收端靈敏度來估算光功率冗余量。類比這些概念，本文將從SRT協議的理論基礎談起，嘗試定義一個衡量SRT鏈路可靠性的指標——安全冗余量(Secure-Margin)。接著根據這個指標，討論SRT協議中相關參數的設置步驟和策略。

1

SRT協議原理分析

SRT協議能夠在不可預測的互聯網環境下提供安全、可靠的數據傳輸，目前廣泛應用在流媒體傳輸領域。理論上SRT可以傳輸任意類型的數據，但由于其特別針對實時音視頻傳輸做了優化，目前的主要應用場景是跨越公共互聯網點對點傳輸實時音視頻數據。

SRT協議最初是一個私有協議，在2017年4月由SRT聯盟將其開源，由于該協議良好的性能以及開源、應用靈活等特性，越來越多的廠商和設備開始支持SRT協議。在實際工作中，搭配使用不同廠商的SRT設備也能夠實現高可靠、低延時的音視頻傳輸，這對于用戶來說非常方便和靈活。

1.1

SRT協議和UDP協議

追述SRT的開發歷程我們會發現，它是由UDT(UDP-based Data Transfer)協議改進而來，SRT協議保留了UDT協議大多數的核心概念和機制，同時引進了一些改進和增強功能，其中主要包括針對實時音視頻的流量控制、增強的擁塞控制、控制數據的修改、加密機制的改進。UDT協議由Grossman提出，該協議在UDP協議的基礎上添加了可靠性控制和擁塞控制機制來保證可靠性，可以有效地利用高速廣域網絡的高帶寬，實現文件的高效、可靠傳輸。由于UDT協議主要適用于高吞吐的文件傳輸，SRT主要適用于流媒體傳輸，所以從應用層面來說，SRT協議和UDT協議之間的差別其實是不可跨越的。

拋開SRT協議的歷史，我們可以把它理解成一個基于UDP協議的流媒體傳輸協議。眾所周知，UDP協議是一種基于數據報的不可靠傳輸協議，它以提高數據的傳輸速率作為主要設計原則，只能提供不可靠的數據傳輸服務，盡最大努力交付。

圖1展示了裸露的UDP協議在有損網絡上的傳輸效果，測試中利用軟件Netem模擬了具有丟包、抖動、延遲的有損網絡，在源端將音視頻信號進行信源編碼，編碼后輸出的TS流具有可變比特率(VBR)和固定的幀間隔，但是在跨越網絡后輸出的碼流特性已經完全改變，固定的幀間隔也因為網絡的抖動發生了改變，實際上解碼器很難從這樣的碼流中恢復出正常的音視頻信號。

圖1? UDP協議在有損網絡下的傳輸性能

由圖2可以看到，SRT協議很好地克服了有損網絡環境中的丟包和抖動，在輸出端很好地還原了輸入的碼流，它通過有效的差錯控制、精確的時間戳、反饋信號、根據延時量定義緩沖區等一系列機制，實現了在有損網絡下的流媒體傳輸，其中差錯控制使用了自動重傳請求機制(ARQ)。

圖2? SRT協議在有損網絡下的傳輸性能

1.2

自動重傳請求：ARQ

數字通信中的差錯控制方法大致可分為兩類：前向糾錯(FEC，Forward Error Correction)和自動重傳請求(ARQ，Automatic Repeat reQuest)。從七十年代開始，ARQ思想就被廣泛應用在各類通信技術和傳輸協議中，發展至今經歷了多次進化，SRT協議發明者聲稱其對ARQ技術的改進可以稱得上ARQ技術的第三次飛躍。

圖3表示了ARQ技術的基本思想，接收端成功收到數據包后通過反饋信道向發送端傳送一個指示接收成功的信號(ACK)，若超時未收到, 則通過反饋信道向發送端傳送一個要求重傳的信號(NAK)，發送端收到此NAK信號后就重新傳送相應的未被接收的數據包。因此這種機制除了要求發送端需要一個重傳緩沖區之外，接收端也需要一個能依次存放數據包的緩沖區。?

圖3? 自動重傳請求技術(ARQ)基本思想

圖4表示了ARQ和FEC之間的區別，一般情況下，我們要根據實用場景的特點和需求來選擇ARQ或FEC。以衛星通信為例，通信鏈路的單次往返時延即RTT約為540ms，并且噪聲都為高斯白噪聲，這種情況下使用ARQ效率就很低，也會造成非常大的延時，FEC就成為了最合適的選擇。互聯網環境中的丟包和抖動有很多都是突發的，這種環境就比較適合ARQ技術來工作，因此SRT最初選擇了ARQ作為糾錯方式。隨著SRT應用領域的發展和擴大，最新版的SRT也加入了對FEC的支持，從而更好地適應各類場景下的應用。

圖4 FEC和ARQ鏈路對比圖

2

定義鏈路的安全冗余量

(Secure-Margin)

在廣電領域的直播工作中，工作人員都會習慣通過鏈路的冗余量來估算鏈路的可靠程度，衛星鏈路中的類似指標是載噪比冗余量(C/N Margin),光纖鏈路可以通過光功率衰減和接收端靈敏度來估算光功率冗余量。類比這些概念，本文從應用層面出發，嘗試定義出SRT鏈路的安全冗余量(Secure-Margin)，并給出定性和定量的分析。

在討論安全冗余量之前，我們首先來了解單次往返時延(RTT，Round-Trip Time)的概念：它表示了數據在發送端和接收端之間進行一次往返所需要花費的時間，也可以理解為兩點之間一來一回所需要的時間。RTT的值與兩點之間物理距離有關，同時也受到網絡接入方式和路由選擇的影響。

也許可以用一句話表示如何配置一個可靠的SRT傳輸鏈路：我們要保證發送緩沖區的使用量（使用單位毫秒來衡量）低于延時量，并且保證接收緩沖區的使用量永遠不會接近零。這句話的原理將在下文詳述，它實際上指出了SRT鏈路中的兩個臨界崩潰點，而SRT鏈路安全冗余量表示了鏈路離臨界崩潰點還有多少余量。

2.1

發送端緩沖區冗余量

參考圖3，ARQ的工作機制決定了發送端需要一個重傳緩沖區，接收端也需要一個能依次存放數據包的緩沖區。另一方面，SRT協議通過設定延時量(Latency)統一規定了發送緩沖區和接收緩沖區的最大可使用量。

發送緩沖區的作用是來保存有可能需要重傳的數據包，即那些還沒有收到肯定應答(ACK)的數據包，如果發送端收到了關于某個數據包的肯定應答，該數據包將被從發送端緩沖區踢出。如果一直沒接收到回復的ACK信號，該數據也不能永遠保存在發送端緩沖區中，SRT協議規定了保存的最長時間為延時量。

參考圖5，并結合SRT的工作原理，我們把延時量的長度想象成一個同時在發送端和接收端從左向右滑動的窗口，圖中的1號至6號數據包都已收到肯定應答(ACK)，已從發送端緩沖區踢出，7號數據包還保存在緩沖區等待接收方的回復。這是一種較好的傳輸狀態，發送端緩沖區的使用比例很小，大部分數據都已經被及時接收并且收到肯定應答。

參考圖6，接收方沒有收到3號數據包，并向發送端回復了否定應答(NAK)，由于種種原因這一過程被延誤，導致3號數據包已經處在窗口最左側，隨著窗口的滑動下一步它將被從發送端緩沖區踢出。這種情況下如果3號數據包的重新傳輸再出現丟失或者延誤，該數據包就會丟包，解碼端的圖像可能也會出現問題。同時我們也注意到圖中發送端緩沖區已經被填滿，這也表示了一種處于丟包臨界點的傳輸狀態。

圖5 發送端和接收端緩沖區(較好狀態)

圖6 發送端和接收端緩沖區(較差狀態)

根據分析可以得出結論：發送端緩沖區被占用的比例越少，鏈路越安全，若發送端緩沖區被占滿，鏈路則很有可能發生丟包。

根據SRT的工作機制可知：數據保存在發送端緩沖區的最長時間為延時量(Latency)，相反保存在發送端緩沖區的最短時間為鏈路的單次往返時延(RTT)。如果把發送端緩沖區被填滿定為臨界崩潰點，則發送端緩沖區冗余量SendBuffer-Margin的定義為：一段時間內緩沖區的最大空余量除以發送端緩沖區的最大值，則公式如下：

需要注意的是，我們通過狀態圖觀察發送端緩沖區最大占用量的使用可以忽略那些偶爾出現的短時間峰值。

圖7是某次直播當天的發送端緩沖區監測圖，圖中延時量為125ms，RTT為10ms，這段時間內的發送端緩沖區冗余量約為40%。由于通過測試選擇了合適的參數，即使圖中后半段網絡出現了波動，我們仍然保證了較為充足的發送端緩沖區冗余量。

圖7 發送端緩沖區監測圖

2.2

接收緩沖區冗余量

接收緩沖區的作用是將收到的數據包排序(SRT協議在SRT包頭記錄了精確的時間戳)，排序一方面是解碼的需要，另一方面是為了找出未及時到達的數據包，向發送端返回否定應答(NAK)，并等待重傳。

參考圖5，接收端的1號數據包已經被送至解碼器，2號數據包隨著延時量窗口的滑動也即將送至解碼器，同時2號至6號數據包都已保存在接收緩存區中，接收緩沖區幾乎被數據包填滿，這是一種較好的鏈路狀態。

參考圖6，這是一種較差的鏈路狀態，接收端未收到3號數據包，并且3號數據包在接收端窗口最左側，意味著3號數據包很可能被跳過，解碼出的圖像會出現問題。在這種情況下接收緩沖區數據包較少，原因有可能是丟包或者網絡帶寬和視頻碼率不匹配。

由此可以得出結論：接收緩沖區的理想狀態應該是其使用量應該略低于延時量，若接收緩沖區占用量變為零，解碼圖像很可能會出現問題。

根據SRT的工作機制可知：數據存放在接收端緩沖區的最長時間應略低于延時量的數值(Latency)。如果把接收端緩沖區使用量變為零看作臨界崩潰點，則接收端緩沖區冗余量ReceiveBuffer-Margin的定義為：一段時間之內接收端緩沖區的最小占用量除以接收端緩沖區的最大值，公式如下：

圖8是某次直播當天的接收端緩沖區監測圖，圖中延時量為125ms，RTT為10ms，在圖中這一段時間內的接收緩沖區冗余量約為40%。

圖8 接收端緩沖區監測圖

2.3

鏈路的安全冗余量

根據SRT的工作機制，發送端和接收端的緩沖區狀態是相互影響的，并且狀態較差一端的緩沖區冗余量實際上決定了鏈路的安全冗余量，那么定義鏈路的安全冗余量(Secure-Margin)等于發送端緩沖區冗余量(SendBuffer-Margin)和接收端緩沖區冗余量(ReceiveBuffer-Margin)兩者的最小值。

根據SRT的機制和延時量的含義，實際上延時量和RTT一起定義了數據包能夠被重傳的次數，這個次數等于延時量除以RTT，我們可以依此進一步定義重傳次數冗余量的概念：

至此我們分別用百分比和重傳次數兩種形式定義了鏈路的安全冗余量(Secure-Margin)，該指標表示了SRT鏈路差錯控制能力的冗余量，同時也是從應用的層面出發，給SRT協議的鏈路測試以及參數調整設立了一個目標。理解安全冗余量的含義能夠幫助工作人員更好地讀懂緩沖區狀態圖，并且以此為參考更有針對性地調整參數，我們也強烈推薦結合該指標和緩沖區狀態圖來一起評估鏈路的安全狀態。

參照圖7和圖8，可以觀察到RTT一直比較平穩，有時候我們的直播任務往往沒有這么好的網絡條件，如果遇到RTT突增的情況，鏈路安全冗余量在下降，而重傳次數冗余量在成倍的下降，這時以百分比計算的安全冗余量就不能真實反映鏈路安全的變化情況，需要同時計算鏈路的重傳次數冗余量。

3

配置SRT流的策略

3.1

測量網絡鏈路的基礎參數

在配置SRT流之前我們必須測量自身鏈路的可用帶寬、丟包率、單次往返時延RTT，并注意觀察這些指標是否在變動以及變動的范圍。

• 可用帶寬：可以使用Iperf軟件測量SRT流的鏈路可用帶寬。

• 丟包率：丟包率是衡量網絡堵塞程度的一種方法，使用丟失數據包與發送數據包的百分比表示。信道的丟包率會驅動SRT延遲和帶寬開銷計算，并可從Iperf統計信息中提取。

• RTT：要確定兩臺設備之間的RTT，可以使用ping命令，如果RTT<=20ms，則使用20ms作為RTT值。這是因為SRT無法對時間尺度小于20ms的事件進行響應。

3.2

設定延時量

延時量(Latency)可以說是SRT協議中最重要的參數，它是一個固定值，可設置范圍是80ms-8000ms。延時量越大，SRT鏈路的差錯控制能力就越高，但鏈路總延時會增加。通過前期測試選擇合適的延時量，能夠幫助我們在鏈路的可靠性和低延時之間取得平衡。表1給出了不同丟包率和RTT下延時量的建議值。

最大丟包率（%）	RTT乘數	帶寬開銷（%）	最小延時量 (當RTT<=20ms)
<=1	3	33	60ms
<=3	4	25	80ms
<=7	5	20	100ms
<=10	6	17	120ms

表1 SRT參數設置表

參考表1，延時量的計算公式如下，其中如果RTT小于20ms，按20ms來計算：

延時量Latency=RTT*RTT乘數

上式中RTT乘數的實際含義是SRT鏈路能夠完成的重傳次數，也代表了鏈路的差錯控制能力，這也是為什么丟包率越高,所需要的RTT乘數越高，所需要的延時量也越高，而之前定義的鏈路重傳次數冗余量可以理解成目前還未使用的重傳次數。

最初我們完全按照這張表來配置SRT鏈路，但經過多次直播工作之后我們發現按照推薦值配置的鏈路安全冗余量并不一定充足，一個好的習慣是提前進行鏈路測試，并結合安全冗余量和緩沖區狀態圖來選擇合適的延時量。

關于延時量還有其他幾個需要注意的點：

• 在鏈路其他參數固定的情況下，提高延時量，安全冗余量(Secure-Margin)會隨之增大。

• 延時量(Latency)可以在編碼器和解碼器上分別設置，若數值不一樣，以較高的數值為準，這也就意味著我們僅在某一端把延時量參數降低是無法生效的。

• 延時量參數并不能代表傳輸鏈路的端到端延時，計算鏈路總延時還需要考慮編碼器延時、解碼器延時以及RTT。

• 體育比賽這類直播的傳輸鏈路需要很低的延時，因為觀眾肯定不希望從鄰居的歡呼聲或者朋友圈得知進球，我們需要非常謹慎地權衡延時量和安全冗余量，從而找到一個折衷的參數。以上圖的直播為例，在保證充足安全冗余量的情況下，端到端延時只有0.8秒左右，遠小于衛星鏈路的延時。

3.3

設定帶寬開銷比例

帶寬開銷(Bandwidth Overhead)是一個百分比參數，其計算基數為音視頻碼流比特率，默認值為25%，最高不建議超過50%。這部分由用戶分配的額外帶寬是用來重傳丟失的數據包、傳輸反向控制數據以及處理擁塞，也就是說帶寬開銷比例與鏈路的差錯控制能力也是息息相關的，實際上SRT協議中每丟失一個數據包就需要在接收端消耗大約400bps的可用帶寬。

圖9是一種SRT鏈路發生崩潰的極端情況，可以用該圖來理解帶寬開銷的功用。在鏈路崩潰發生后，首先緩沖區數據會暫時填補解碼器對數據的持續需求，緊接著鏈路恢復后，額外劃定的帶寬開銷會彌補之前對緩沖區數據的消耗，在處理完這次突發事件后，整個SRT鏈路會恢復正常。

圖9 帶寬開銷示意圖

關于帶寬開銷有幾點需要注意：

• 參考表1，可以找到在不同丟包率下的帶寬開銷比例的最小值，根據鏈路狀態可稍作上浮。

• 帶寬開銷的計算基數是視頻+音頻+元數據+其他輔助數據的總比特率，在估算時要加以注意。

• 在確定了編碼的流帶寬之后，可以通過流帶寬*(1+帶寬開銷)來計算所需要的鏈路可用帶寬，實際應用中建議在此基礎上再增加一些鏈路可用帶寬來對抗波動，建議值為流帶寬*(1+帶寬開銷)*1.33。以HEVC方式編碼4K信號為例，如果編碼后的TS流為40Mbits，帶寬開銷為25%，建議的鏈路可用帶寬應該在67Mbits以上。

• 參考圖9，區域A和區域B必須相等，實際上SRT鏈路能夠容忍的網絡中斷時間為延時量*帶寬開銷。綜藝晚會或者政府會議這樣的直播工作，其對延時并不敏感，可以考慮充分利用延時量和帶寬開銷這兩個參數來極大增強鏈路的可靠性。假設我們在這種情況下設置延時為8000ms，帶寬開銷為50%，那么網絡即使中斷4秒鐘也不會影響SRT鏈路的正常工作，SRT鏈路這一特性甚至是衛星和光纖鏈路都不具備的。

? 結 束 語??

近年來，SRT協議在廣電領域的發展呈現多點開花的趨勢，在現場直播、遠程制作、上行推流、國際間遠距離傳輸多方面都有著廣泛的應用。在實際部署SRT鏈路的過程中，前期大量的測試工作是必不可少的，在測試時可以通過觀察安全冗余量和緩沖區狀態圖來判斷鏈路的安全性。

《公網傳輸技術之SRT協議解析》的下篇將從SRT數據包的角度來分析SRT協議的運行機制和原理，并演示如何通過Wireshark來進行抓包和故障診斷，敬請期待。

參考文獻:

1. Haivision.SRT Protocol Technical Overview［M/OL］.(2018-10) [2022-02].www3.haivision.com/srt-protocol-technical-overview.

2. Yunhong Gu,Robert L.Grossman.UDT:UDP-based data transfer for high-sspeed wide area networks[J].Computer Networks,2006,51(7):1777-1799.

3. Haivision.SRT Open Source White Paper［M/OL］.(2019-1) [2022-02].www3.haivision.com/srt-open-source-wp.

4. SRT Alliance. SRT Deployment Guide,v1.1,Issue 01［M/OL］.(2018-10) [2022-02].www3.haivision.com/srt-alliance-guide.

作者簡介：

張博力，安徽廣播電視臺工程師。

---

喜歡我們的內容就點個“在看”吧！

總結

以上是生活随笔為你收集整理的公网传输技术之SRT协议解析（上）的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。