4.1. 參數名稱解析
這一節，我將逐個向大家介紹會影響SRT傳輸性能的參數名稱，他們包括：Round Trip Time（RTT，往返延時）、RTT Multiplier（RTT倍數）、Packet Loss Rate（丟包率）、Bandwidth Overhead（帶寬開銷）以及Latency（延時），SRT加密等。
4.1.1. Round Trip Time (RTT)
RTT（往返延時）表示從發送端發送數據開始，到發送端收到來自接收端的確認（接收端收到數據後便立即發送確認），總共經歷的時延。我們可以通過RTT知道兩臺設備（在我們的應用中，即爲SRT源設備和SRT目標設備）在網絡中的距離。在配置SRT傳輸時，我們就能以這個值爲參考，設置帶寬開銷以及傳輸延時。
當兩臺設備連接在局域網的同一臺交換機上時，RTT值幾乎爲0（小於1 ms），而隨着基礎設施建設越來越完善，即使跨越大洋，也可能得到很低的RTT值。
要想得到兩臺設備間的RTT值，我們可以使用ping命令。例如，如果我想知道我的電腦和Google在美國的免費DNS服務器8.8.8.8之間的RTT值，就可以使用電腦ping這個IP地址，從而得到他們之間的RTT值，如下圖，我們從中可以知道，此時該網絡鏈路RTT值平均約爲51 ms。
4.1.2. RTT Multiplier
RTT Multiplier是一個用於計算SRT延時的數值，它可以反應出網絡擁塞程度和RTT之間的關係，隨着網絡擁塞的增加，SRT控制信息數據包的交換量以及丟包的重傳量也會隨之增加，這些額外傳輸的數據包的傳輸時間都會受限於RTT，所以爲了抵消掉這些數據包的傳輸延時，就必須要增加SRT延時，而調整SRT延時的依據就是RTT Multiplier了，他們的關係如下：
SRT Latency = RTT Multiplier * RTT
我們也可以換一個RTT Multiplier的理解方式：它表示了在SRT傳輸中，對一個數據包的最大重傳次數。當然，這個值不會直接出現在SRT的配置參數中，而是用於計算最理想的理論SRT延時。
4.1.3. Packet Loss Rate
Packet Loss Rate（丟包率）這個參數大家就再熟悉不過了，它通常表示丟掉的數據包占總髮送數據包的百分比。在SRT傳輸中，我們可以把出現丟包的情況大致分爲兩種，在不同的情況下，分別會對我們設置Bandwidth Overhead有不同的影響：
✦ Constant loss（穩定的丟包）
即鏈路的丟包率不會出現太大波動，基本處於一個恆定的數值。在這種情況下，要想穩定傳輸，就要求SRT開銷應不小於此時的理論最小值（如下公式）：
Minimum Bandwidth Overhead = 1.65 * Packet Loss Rate
✦ Burst loss（爆發式丟包）
即鏈路會出現大量連續的丟包，並且丟包量達到或超過SRT latency buffer（緩存區）內緩存的數據包量。在這種情況下，要想穩定傳輸，要求SRT開銷應不小於此時的理論最小值（如下公式）：
Minimum Bandwidth Overhead = 100 ÷ RTT Multiplier
這種爆發式丟包一旦持續時間超過了設置的SRT延時，將會導致接收端收到的流中斷，所以，SRT傳輸延時應該保證永遠大於最差網絡環境下的網絡持續丟包時間。.
4.1.4. Bandwidth Overhead
Bandwidth Overhead（帶寬開銷）是一個根據網絡鏈路質量設置的百分比值，用這個百分比值乘以編碼器編碼的視音頻總碼率，就可以得到Bandwidth Overhead允許的最大開銷，這個值與視音頻碼率的總和就是當前SRT傳輸帶寬的最大值了，也就是這個SRT通道可以使用的最大帶寬。
它的作用首先是傳輸伴隨SRT流的控制信息數據包，另外還包括所有媒體數據包的重傳，所使用的網絡鏈路條件越差，就需要越多的控制信息數據包的交互以及媒體數據包的重傳，也就需要設置越大的Bandwidth Overhead值。
如果從“開銷”的角度理解，它就是在傳輸所需的媒體內容（可以理解爲載荷payload）外，額外要佔用的“無效”帶寬，但它與我們常見的協議開銷、TCP首部開銷、UDP首部開銷有所區別，這裏的帶寬開銷並不是固定的20~60字節TCP首部開銷或8字節UDP首部開銷，而是根據網絡情況實時變化的，網絡鏈路條件越差，正常傳輸所需的開銷就越多。
在高駿SRT設備中，Bandwidth Overhead的設置範圍是5%~100%，默認大小爲25%。
爲了讓大家對Bandwidth Overhead這個概念理解得更清晰，下面我們舉個例子來說明。
假如需要使用HDE-650S實時傳輸視頻，設置視頻編碼碼率爲2000 kbps，音頻碼率爲128 kbps（只使用一對立體聲），所以視音頻的總碼率爲2128 kbps，我們可以算上一些元數據和其他附加數據，向上取整爲2200 kbps，如果我們設置Bandwidth Overhead爲默認值25%，那麼爲傳輸這段視頻所保留的總帶寬則爲：
2200 + (25% * 2200) = 2750 kbps (2.75 Mbps)
這個值表示的是SRT傳輸可以使用的最大帶寬，如果在網絡傳輸的過程中沒有產生丟包，那麼就只會使用很少量的開銷來進行控制。通常只要能保證SRT總帶寬不超過在兩臺SRT設備間的的可用帶寬，數據流就能夠保證順利地傳輸。
4.1.5. Latency
Latency（延時）對大家也是一個很熟悉的概念了，具體來說，它在這裏用來表示通過網絡傳輸數據包的時間延遲。在高駿SRT設備中，Latency的設置範圍是20 ms至8000 ms，而我們設置的這個延時大小，則代表了可用於管理SRT數據包的最大buffer（緩存區）的大小。
在SRT傳輸中，SRT源設備需要將它發出的數據包在buffer內排序，用於進行傳輸和重傳，在SRT源設備的buffer內會保存那些還沒有被SRT目標設備確認收到的數據包。
而SRT目標設備則需要將它收到的數據包（在收到時可能是亂序的）存儲在buffer內，並以正確的順序排列，確保之後的解碼正常，在SRT目標設備的buffer內會保存那些已經收到並等待解碼的數據包（包的順序按16進制1到f）。
圖4-4 SRT傳輸中的buffer
在傳輸過程中，我們應該確保SRT源設備緩存在buffer中的內容（換算成以毫秒爲單位）始終低於設置的Latency值，同時保證SRT目標設備緩存在buffer中的內容不要減少到0，這樣才能保證SRT目標設備正確的收到所有數據包。
SRT Latency是基於當前網絡鏈路的性能來設置的（如我們前面說到的RTT與網絡丟包率等），例如在一個較好的網絡環境中，丟包率爲0.1%-0.2%，那麼根據經驗可能將RTT Multiplier選爲4就可以了，也就是：
SRT Latency = 4 * RTT
在使用時，我們在SRT源設備和SRT目標設備兩端都可以設置Latency的大小，最終將取兩個值中較大的一個爲SRT傳輸延時。
圖4-5 在HDD-461中SRT Statistics顯示的Latency-Buffer-RTT圖表
4.1.6. SRT加密
在使用SRT傳輸時，高駿SRT設備可以使用AES加密算法進行128位或256位的內容加密，並在SRT目標設備中解密，確保傳輸內容的安全。
要想打開加密功能，首先要在SRT源設備中選擇“Encryption”項的加密類型（AES-128或AES-256），並在SRT源設備和SRT目標設備中的“Passphrase”欄內填寫相同的加密口令。
4.1.7. 傳輸過程中的Latency、Buffer和BW Overhead
了讓前面介紹的幾個參數更好理解，下面我們通過一張圖表來將它們形象的表現出來，下圖描述了在一次SRT傳輸過程中，傳輸數據量隨着時間的變化圖，期間由於一次網絡問題，傳輸數據量降爲零，短暫的鏈路斷開後，又恢復了數據傳輸，具體如下：
圖4-7 SRT傳輸過程中的傳輸數據量變化圖
（圖片來自SRT Alliance的指導文檔《SRT Deployment Guide, v1.1, Issue 01》）
＊注：
- 綠色直線：表示該鏈路可用的最大帶寬；
- 紅色虛線（偏上）：表示根據流量帶寬和BW Overhead計算得到的SRT最大帶寬；
- 紅色虛線（偏下）：表示正常情況下的流量帶寬，即視頻、音頻、元數據等；
- 藍色曲線：表示傳輸數據量隨時間變化的曲線；
- 灰色區域：表示接收端buffer緩存的數據總量。
我們首先來解釋一下接收端buffer，它是SRT目標設備緩存的數據包，我們在前面說過，它可以換算成以毫秒爲單位的時間值，具體是如何做的呢，中間有這樣一個簡單的數學公式：
時間 = 緩存數據量大小 ÷ 流量帶寬
而在上圖中，灰色區域的面積就表示buffer內緩存的數據量，由於在鏈路故障點之前始終保證了穩定的傳輸碼率，將buffer緩存一直維持在“滿”的狀態，所以灰色區域對應的時間軸長度與SRT延時基本相同。
在鏈路出現故障後，傳輸碼率降爲零，隨後又重新建立起連接，再次開始傳輸，也就是說SRT目標設備在一段時間內沒有收到任何數據包。
當SRT傳輸出現這樣的情況時，SRT目標設備將用buffer中緩存的數據來保證輸出給解碼部分的數據流，設置的SRT延時越長，buffer中就能緩存的數據就越多。
隨後，一旦鏈路恢復，SRT源設備就會重新開始傳輸數據，其中將包括重傳在鏈路故障期間丟失的數據包，爲了這部分重傳數據，SRT就會使用到在正常流量帶寬之外的“開銷”部分。一般情況下，帶寬開銷的大小應該保證在可能出現的最壞的網絡狀態下，SRT源設備能夠在爆發期（burst time，圖中區域B）內傳輸鏈路故障期間傳輸失敗的所有數據（圖中區域A），也就是區域B的面積應與區域A的面積相等。
在保證輸出圖像連貫的條件下，SRT連接能夠承受的鏈路故障（完全沒有數據傳輸）的最長時間爲：
SRT Latency (ms) * Bandwidth Overhead (%) ÷ 100
4.2. 基本設置方法
在我們設置SRT傳輸參數時，所使用的網絡鏈路狀態通常是千變萬化，即便是相同的網絡鏈路，不同時間也可能會有不同的網絡狀態，但是，不論何時，我們都要總結出一套通用的技巧，來有理有據地提供一系列初始設置參數，然後再根據實際的效果做出相應的調整，下面就讓我來給大家介紹一些SRT的基本設置方法。
設置過程可以分爲以下七步：
4.2.1. 檢測網絡鏈路的Round Trip Time（RTT）值
✦ 使用ping命令檢測所使用的網絡鏈路的RTT值；
✦ 如果已經建立起SRT連接，可以在SRT設備的Statistics統計頁面中查詢RTT值；
✦ 當RTT ≤ 20 ms時，應認爲RTT值爲20 ms，因爲SRT不對時間單位低於20 ms的數據做出響應。
4.2.2. 檢測網絡鏈路的Packet Loss Rate（丟包率）
✦ 網絡鏈路的丟包率將直接影響SRT延時和BW Overhead的計算，我們通常可以使用iperf來檢測網絡丟包率。
✦ 如果已經建立起SRT連接，可以在SRT設備的Statistics統計頁面中獲取網絡鏈路的丟包率， Resent Bytes和Sent Bytes兩個統計數據的比值即爲網絡丟包率，爲了保證準確性，應該至少保證數據的統計時間超過60秒，網絡鏈路丟包率計算公式如下：
Packet Loss Rate = Resent Bytes ÷ Sent Bytes * 100
4.2.3. 根據測得的網絡丟包率，從下表中查找相應的RTT Multiplier和BW Overhead值
表4-1 不同丟包率時RTT Multiplier和BW Overhead的取值
（表格來自SRT Alliance的指導文檔《SRT Deployment Guide, v1.1, Issue 01》）
＊注：
1. 表格中的BW Overhead取值同時考慮了前文提到的Constant Loss和Burst Loss兩種情況，取兩種情況下計算得到的較大值（較大值全部爲100 ÷ RTT Multiplier）；
2. 表格中計算的最小SRT Latency爲RTT ≤ 20 ms時（即RTT取值爲20 ms），在實際使用時應代入實際測得的RTT值；
3. 表格中所列的數值，基本代表了一般情況下最高效的SRT設置，如果網絡環境變得更差，或者希望系統容錯率更高，也可以取更大的RTT倍數和BW Overhead值。
從表格中我們可以看到，隨着網絡丟包率的增高，RTT Multiplier順理成章地逐漸變大，BW Overhead卻在逐漸變小，爲什麼它會給出這樣的建議呢？下面給大家分享一些我個人的想法。
我們前面已經介紹過，RTT Multiplier表示了SRT連接中一個數據包的最大重傳次數，也就是說，在網絡丟包率不超過1%時，表格建議設置最大3次重傳就可以基本保證數據包能夠傳輸到接收端了，而經過3次重傳數據包都沒能到達接收端的概率就是 (1/100)^3×100%=0.0001%（一百萬分之一）；以此類推，我們可以得到數據包最終丟失的概率公式爲：
將上述函數畫在二象限圖表中，可得下圖：
從上圖中可知，如果按照表格中的RTT Multiplier值和BW Overhead值設置SRT傳輸參數，那麼在傳輸過程中一個數據包最終沒能到達接收端的概率將始終小於0.0002%（一百萬分之二）。
我們不妨主觀地判斷，這個表格建議我們能夠認爲概率爲0.0002%的事件是幾乎不可能發生的事件（即數據包幾乎不可能無法到達接收端），從而認定此時的SRT傳輸是安全的。
但是，爲什麼隨着網絡丟包率的增加，設置的BW Overhead值是在逐漸減小的呢？我們可以嘗試按照表格中的規律，將網絡丟包率、RTT Multiplier、BW Overhead的值繼續推演下去，即以1%爲單位逐漸增加網絡丟包率，同時不斷地增大RTT Multiplier值，來確保：
p^(RTT Multiplier)≤0.0002%,p爲網絡最高丟包率
並根據得到地網絡丟包率和RTT Multiplier值，分別計算Constant Loss和Burst Loss兩種情況下的BW Overhead的值，並將其繪製成圖標如下（具體推演數據不在這裏列出）：
爲了保證表格中的參數設置能夠同時兼容Constant Loss和Burst Loss兩種網絡丟包情況下的SRT傳輸，BW Overhead應該取上圖中較大的數值，而在網絡丟包率不超過10%時，始終是Burst Loss狀態下的BW Overhead的值更大，並且不斷減小（上圖中橙色線），所以我們纔會看到表格中的BW Overhead值不斷減小；而當網絡丟包率超過10%後，就變成了Constant Loss狀態下的BW Overhead的值更大，所以就應該選擇數值較大的藍色線，這之後BW Overhead將逐漸增大。
以上這些內容完全是我根據《SRT Deployment Guide, v1.1, Issue 01》中的參數表格所做的猜想，無論正確與否，希望能夠給大家一點啓發。
4.2.4. 通過以下公式確定SRT Latency
SRT Latency = RTT Multiplier * RTT
✦ 當RTT ≤ 20 ms時，RTT取值統一爲20 ms。
4.2.5. 測試可用鏈路帶寬
✦ 使用iperf測試；
✦ 如果已經建立起SRT連接，可以通過SRT設備Statistics統計頁面中的Max Bandwidth和Path Max Bandwidth兩個參數獲取鏈路帶寬信息。
4.2.6. 確定傳輸碼率
✦ SRT傳輸碼率將會包括視頻、音頻、元數據等有效數據，再加上SRT協議開銷，我們可以得到如下關係式：
Channel Capacity＞SRT Stream Bandwidth * (100 + Bandwidth Overhead) ÷ 100
✦ 如果不滿足上述關係式，應減小視音頻碼率，直到滿足；
✦ 通常情況下，建議保留出更多的空餘帶寬來抵抗不斷變化的鏈路帶寬，所以下面這個關係式會具有更強的安全性：
0.75 * Channel Capacity＞SRT Stream Bandwidth * (100 + Bandwidth Overhead) ÷ 100
4.2.7. 檢查SRT傳輸參數設置是否正確
✦ 檢查SRT傳輸參數最好的方法，就是在開始進行SRT傳輸後，查看SRT源設備的Statistics統計頁面圖表， Send Buffer數值應該保持始終不超過SRT Latency的值，如果兩條線十分接近，應當適當增加SRT延時。
4.2.8. 關於iPerf
iPerf是一個網絡性能測試工具，通過它我們能夠得到網絡鏈路的帶寬、延遲、抖動以及丟包等信息，從而判斷一個網絡鏈路的性能狀態。
在常用的Windows平臺中，我們可以在網上下載到iPerf應用程序，並放在系統目錄 %systemroot% 中，通過命令行窗口來運行，需要注意，iPerf3（如iPerf 3.1.3）與iPerf（如iPerf 2.0.9）之間不兼容；除此之外，也可以選擇帶有用戶界面的應用程序，這樣就不需要牢記複雜的操作命令了，如下圖：
圖4-10 iPerf軟件
這裏，我只向大家介紹測試傳輸帶寬所用的命令（使用iPerf 2.0.9），如果大家感興趣，可以去研究iPerf更多的使用方式。
在開始測試前，應該先確保打開防火牆相應的端口，同時停止其他數據流的傳輸，保證測試結果的準確性。
在SRT傳輸的接收端，輸入如下命令：
iperf -s -u -i 1 -p “port#”
-s：表示iperf爲server模式；
-u：表示使用UDP協議；
-i 1：表示反饋信息的時間間隔爲1秒；
-p “port#”：表示通過某一個端口號進行測試。
在SRT傳輸的發送端，輸入如下命令：
iperf -c “IP ADDRESS OF DESTINATION” -u -b “BW” -i 1 -p “port#”
-c “IP ADDRESS OF DESTINATION”：表示iperf爲client模式，訪問server端的公網IP並進行測試；
-u：表示使用UDP協議；
-b “BW”：表示測試的帶寬值；
-i 1：表示反饋信息的時間間隔爲1秒；
-p “port#”：表示通過某一個端口號進行測試。
然後我們就可以在窗口中看到測試結果了。例如，我在一臺電腦上同時運行iperf server和iperf client，將得到下圖中的結果：
圖4-11接收端的iPerf命令和測試結果
圖4-12 發送端的iPerf命令和測試結果
從上圖中可知，測試得到網絡帶寬能夠滿足5.5 Mbps（由命令中寫的帶寬值而來），網絡抖動爲0.000 ms，丟包率爲0%。在真正的互聯網環境下，我們就能夠以此來判斷網絡鏈路的性能了。
4.3. SRT統計信息和優化傳輸設置
在進行SRT傳輸時，兩端的設備會交互大量的網絡條件信息和數據包傳輸信息，而正是這些重要的信息內容讓SRT在傳輸視音頻信息時能夠使用最佳的傳輸策略，SRT設備會將其中一些重要的信息參數以曲線圖的方式表現出來，讓他們變得簡單直觀，而對於操作人員來說，能夠理解這些參數所代表的意義對優化SRT傳輸設置至關重要。
4.3.1. HDE-650S中的鏈路統計信息（Link Statistics）
在HDE-650S的Statistics統計信息中，包含了SRT狀態、傳輸和丟失的數據包數，碼率、啓動時長、網絡狀態信息等等參數，如下圖：
圖4-13 HDE-650S的Link Statistics統計信息
其中，可選擇查看SRT協議或簡單UDP協議的輸出統計信息，簡單UDP協議的輸出統計信息只包含狀態和碼率，這裏就不介紹了。另外可以選擇曲線圖的取樣時間範圍，可選擇最近5分鐘、最近60分鐘或最近24小時內的統計數據信息。
Link Statistics中呈現的參數項包括：
注意事項：
✦ 首先應注意Status保持Connected狀態，即保持SRT連接正常；
✦ 當發現Reconnections值不斷變大時，表明兩臺設備間的網絡通訊異常；
✦ 當Received NAKs值保持穩定上升時，證明在傳輸鏈路中存在某些網絡問題，導致始終有一定量的數據包無法正常到達接收端；
✦ 如果發現Skipped Packets值緩慢增加，通常可以增加一些SRT Latency來解決；但是如果發現Skipped Packets的值會快速變大，那麼就應該降低一些視頻碼率，如果有足夠的可用帶寬，也可以適當的增加Bandwidth Overhead。
在編碼器HDE-650S的Link Statistics中，還可以看到兩個曲線圖，分別表現帶寬和延時隨時間變化的曲線，如下圖：
圖4-14 HDE-650S中的統計數據曲線
在上方的Bandwidth Used圖中，我們可以看到傳輸碼率曲線，以及設備預測的最大鏈路帶寬（僅供參考）。
在Delays圖中，則會體現在SRT傳輸過程中，buffer是如何來改善傳輸效果的，途中我們可以看到buffer和RTT隨時間變化的曲線，而延時則作爲基準線保持不動。
注意事項：
✦ 在編碼器中，buffer的數值（綠色曲線）通常不會超過SRT延時的值（黑色直線），如果編碼器的發送buffer曲線越過了Latency線，那麼就需要增加SRT Latency的值。
✦ 如果編碼器的發送buffer曲線經常會到達或越過Latency線，那麼基本可以證明當前的網絡帶寬不足以支撐所要求的視頻碼率，此時就應該降低視頻碼率；如果編碼器的發送buffer曲線只是偶爾會超過Latency線，這時就應該增加SRT延時。
4.3.2. HDD-461中的鏈路統計信息（Link Statistics）
在HDD-461的Statist城市統計信息中，可以看到SRT狀態、重傳、丟包數、帶寬信息、網絡狀態信息等等參數，如下圖：
其中，可以選擇曲線圖的取樣時間範圍，可選擇最近5分鐘、最近60分鐘或最近24小時內的統計數據信息。
Link Statistics中呈現的參數項包括：
注意事項：
✦ 首先應注意Status保持Connected狀態，即保持SRT連接正常；
✦ 當發現Reconnections值不斷變大時，表明兩臺設備間的網絡通訊異常；
✦ 傳輸時出現少量的Lost Packets屬於正常現象；
✦ 如果發現Skipped Packets值緩慢增加，通常可以增加一些SRT Latency來解決；但是如果發現Skipped Packets的值會快速變大，那麼就應該降低一些視頻碼率，如果有足夠的可用帶寬，也可以適當的增加Bandwidth Overhead百分比。
在解碼器HDD-461的Link Statistics中，也有兩個曲線圖，同樣表現帶寬和延時隨時間變化的曲線，如下圖：
圖4-16 HDD -461中的統計數據曲線
在上方的Bandwidth Used圖中，我們可以看到傳輸碼率曲線，丟包率曲線以及接收數據流傳輸所使用的帶寬。
注意事項：
✦ 如果在解碼器輸出畫面中出現太多的跳幀或丟幀，那麼應該增加SRT延時，降低視頻碼率，和/或增加Bandwidth Overhead百分比
在Delays圖中，同樣會體現Buffer曲線與Latency線的關係。
注意事項：
✦ 理想狀態下，解碼器的buffer值應該十分接近Latency值，如果解碼器的接收buffer經常降到0，通常是因爲鏈路帶寬不足以支撐所要求的傳輸碼率，此時應該調低傳輸碼率；如果解碼器的buffer只是偶爾下降到0，則可以通過增加SRT延時來解決。
原文鏈接：https://blog.csdn.net/weixin_42228920/article/details/90946259