本文來自安徽廣播電視臺(tái) 直播技術(shù)工程師 張博力在LiveVideoStackCon 2020 線上峰會(huì)的演講，詳細(xì)介紹了SRT協(xié)議在信號傳輸、遠(yuǎn)程制作等方面的應(yīng)用，以及實(shí)際工作中遇到的相關(guān)技術(shù)問題。

文?/?張博力

整理?/?LiveVideoStack

非常高興能和大家在首屆音視頻線上峰會(huì)上和大家進(jìn)行分享和討論。我是來自安徽廣播電視臺(tái)的張博力。本次分享的主題是SRT協(xié)議在電視直播中的應(yīng)用。

首先我會(huì)介紹一下行業(yè)背景，也就是今天討論的SRT應(yīng)用到底是在一個(gè)什么樣的行業(yè)之中進(jìn)行的。

第二，我會(huì)和大家分享一下SRT協(xié)議的流程、原理，其中將會(huì)重點(diǎn)介紹的是SRT數(shù)據(jù)包結(jié)構(gòu)以及怎么運(yùn)用數(shù)據(jù)包結(jié)構(gòu)的知識(shí)來排除鏈路故障。

第三，我會(huì)分析一下安徽廣播電視臺(tái)首次5G直播中SRT協(xié)議的應(yīng)用，并嘗試提出SRT鏈路安全冗余量(Secure-Margin)的概念，接著討論如何調(diào)整參數(shù)來實(shí)現(xiàn)足夠的安全冗余量，以及不同直播場景下的調(diào)整策略。

第四，我會(huì)和大家簡單介紹一下電視節(jié)目遠(yuǎn)程制作中SRT技術(shù)的應(yīng)用。

1

行業(yè)背景

廣電行業(yè)可以說是一個(gè)比較傳統(tǒng)的行業(yè)，按照傳統(tǒng)的劃分，一般只要擁有五項(xiàng)功能，就可以稱為是一個(gè)類似電視臺(tái)的機(jī)構(gòu)或組織。這5項(xiàng)功能是信號的采集、編輯、節(jié)目的播出、素材的存儲(chǔ)以及最后節(jié)目的傳輸。以上只是電視臺(tái)技術(shù)領(lǐng)域的基礎(chǔ)劃分，并沒有涵蓋電視臺(tái)下游的分發(fā)端。

如果按照更現(xiàn)代一些或者說更宏觀一些的劃分，廣電領(lǐng)域的工作流程可以分為三項(xiàng)。第一項(xiàng)叫節(jié)目的制作(Contribution)，第二項(xiàng)是節(jié)目的分發(fā)(Distribution)，最后就是面向客戶的交付(Delivery)。本次分享的內(nèi)容主要與前兩項(xiàng)相關(guān)，也就是在節(jié)目的制作和分發(fā)領(lǐng)域中，應(yīng)該怎么樣使用SRT技術(shù)。另外隨著廣電領(lǐng)域的擴(kuò)大化，泛廣電領(lǐng)域的工作流程也是類似的。

SRT在泛廣電領(lǐng)域內(nèi)的應(yīng)用較早，大概在2015/2016年就已經(jīng)開始。在很多技術(shù)區(qū)域，我們已經(jīng)在使用SRT技術(shù)。首先從拍攝機(jī)位的信號來說，傳輸?shù)街辈ボ嚮蜓莶ブ行?#xff0c;都可以使用SRT。另外制作好的節(jié)目傳輸?shù)诫娨暸_(tái)，以前都是使用衛(wèi)星或者光纖之類比較昂貴的傳輸方式，現(xiàn)在也可以通過公共互聯(lián)網(wǎng)使用SRT技術(shù)來實(shí)現(xiàn)。在電視臺(tái)播出之后傳給各個(gè)分發(fā)商，這些分發(fā)商包括傳統(tǒng)的有線網(wǎng)、上星站、無線覆蓋或者直接對接CDN。對于CDN或者直播平臺(tái)，我們之前是使用RTMP，但現(xiàn)在也有一些流媒體服務(wù)器的解決方案使用SRT作為上傳推流的方式。

2

SRT協(xié)議

2.1 SRT協(xié)議簡介

實(shí)話實(shí)說，我第一次接觸到SRT協(xié)議時(shí)的反應(yīng)是：這不是我們之前看劇的時(shí)候下載的字幕格式srt嗎？其實(shí)不是的。

SRT是Secure、Reliable、Transport三個(gè)單詞的縮寫，分別代表了安全，可靠和傳輸。安全是指它可以對傳輸內(nèi)容進(jìn)行加密。可靠是指它能對抗有損網(wǎng)絡(luò)中的丟包和抖動(dòng)，傳輸就是針對點(diǎn)對點(diǎn)的傳輸。

SRT于2017年開源，其發(fā)展勢頭一直不錯(cuò)。上圖是一個(gè)來自Broadcast IP Transformation Report的傳輸協(xié)議使用調(diào)查，盡管這個(gè)調(diào)查是全球范圍內(nèi)沒有細(xì)分領(lǐng)域的調(diào)查，但是我們可以看到SRT是處在第一梯隊(duì)的。

SRT是一個(gè)開源協(xié)議，它在github有一個(gè)非常活躍的社區(qū)。從2017年到2020年的Issues和Pull Requests的數(shù)據(jù)可以看出這個(gè)社區(qū)有多活躍。

我們大概從2018年開始接觸SRT，也經(jīng)過了很長時(shí)間的學(xué)習(xí)，有一些覺得不錯(cuò)的學(xué)習(xí)資料想和大家分享一下。

圖左是SRT的技術(shù)綜述（89頁），它更像一個(gè)規(guī)范，這是學(xué)習(xí)SRT的朋友都繞不過去的一本書。第二本圖書是SRT聯(lián)盟推出的部署指南，這本書更針對實(shí)際使用者，告訴我們怎么應(yīng)用SRT，怎么部署，怎么穿越防火墻，怎么調(diào)整，出錯(cuò)了怎么辦等等，這也是一本大概四五十頁，內(nèi)容非常詳細(xì)的指南。當(dāng)然咱們可以通過github去學(xué)習(xí)。SRT在今年三月份提交了一個(gè)RFC的草案，第二個(gè)網(wǎng)址是草案的全部內(nèi)容，內(nèi)容是對最新版SRT非常詳盡的概述，此外Haivison和SRT聯(lián)盟官網(wǎng)也有非常多的資料和白皮書可供下載。當(dāng)然，學(xué)習(xí)SRT最主要的是實(shí)踐，無論是從應(yīng)用還是開發(fā)的角度，實(shí)踐都是最好的學(xué)習(xí)方式。

我們嘗試總結(jié)一下SRT到底是一個(gè)什么樣的協(xié)議。

當(dāng)然SRT在不斷的發(fā)展，它的野心也是很大的，SRT現(xiàn)在開發(fā)了許多新功能，包括傳輸大文件、小的對話數(shù)據(jù)等等。但是SRT的“傳統(tǒng)優(yōu)勢領(lǐng)域“還是實(shí)時(shí)的視音頻傳輸，SRT本質(zhì)上是一個(gè)點(diǎn)對點(diǎn)的傳輸協(xié)議（單播而不是組播）。SRT的亮點(diǎn)在于能夠克服有損網(wǎng)絡(luò)中的抖動(dòng)和丟包。SRT目前還是專注于節(jié)目的制作和分發(fā)，而不是交付。最后兩個(gè)也是SRT獨(dú)有的特點(diǎn)，SRT擁有一個(gè)強(qiáng)制的延時(shí)量，并且這個(gè)延時(shí)量是固定不變的，但是這個(gè)延時(shí)在網(wǎng)絡(luò)搭建之前可以由用戶進(jìn)行調(diào)整，另外SRT可以對內(nèi)容進(jìn)行加密。

SRT是如何實(shí)現(xiàn)這些功能的呢：

• 首先，SRT協(xié)議以UDP協(xié)議為基礎(chǔ)，傳統(tǒng)觀念認(rèn)為UDP協(xié)議不可靠，但實(shí)際它的效率很高，具備穩(wěn)定、可重復(fù)并具有連續(xù)吞吐量的數(shù)據(jù)包投遞機(jī)制。

• 第二，SRT采用握手機(jī)制建立連接。這個(gè)握手機(jī)制非常高效，只需使用兩個(gè)往返就可以完成握手、信息交互、參數(shù)交互。

• 第三，SRT使用了改進(jìn)后的ARQ自動(dòng)重發(fā)請求技術(shù)，也逐步開始支持FEC前向糾錯(cuò)。

• 第四，封裝協(xié)議中帶有精準(zhǔn)的時(shí)間戳。

• 最后SRT通過設(shè)定延時(shí)量，統(tǒng)一規(guī)定了發(fā)送端和接收端緩沖區(qū)的大小。實(shí)際上延時(shí)量也決定了緩沖區(qū)可以使用的大小。

2.2 UDP協(xié)議

在有損網(wǎng)絡(luò)中不用SRT協(xié)議，使用裸露的UDP協(xié)議行不行呢？這是一個(gè)編碼后的TS流信號（VBR），固定幀間隔40毫秒，經(jīng)過了有損網(wǎng)絡(luò)傳輸之后，碼流特性改變，幀間隔也變得不固定。實(shí)際上，這樣的信號是幾乎無法解碼出來的。

2.3 SRT協(xié)議

上圖是SRT協(xié)議的效果圖，可以看到SRT在解碼端重新恢復(fù)了原有的碼率特性和幀間隔。如圖所示，SRT有一個(gè)發(fā)送端緩沖區(qū)、接收端緩沖區(qū)，在發(fā)送信號的同時(shí)會(huì)有一些控制信息或者說反饋信息來實(shí)現(xiàn)ARQ糾錯(cuò)，并且SRT包頭中有精確的時(shí)間戳。

另外在發(fā)送端接收端之間有一個(gè)強(qiáng)制的固定延時(shí)量。這個(gè)延時(shí)實(shí)際上是在接收端緩沖區(qū)產(chǎn)生的，所有數(shù)據(jù)放到接收端緩沖區(qū)，必須要等待一個(gè)延時(shí)量才會(huì)被送給解碼器，這是SRT的一個(gè)重要的特點(diǎn)。

2.4 ARQ機(jī)制原理

這是關(guān)于一個(gè)自動(dòng)重發(fā)請求的簡圖。數(shù)據(jù)包如果被正確接收，會(huì)返回一個(gè)肯定應(yīng)答ACK給發(fā)送端，如果沒有被正確接收，會(huì)返回一個(gè)否定應(yīng)答NAK，發(fā)送端接收到NAK后會(huì)重發(fā)相應(yīng)數(shù)據(jù)包。

值得注意的一點(diǎn)是有的傳輸協(xié)議雖然也是使用ARQ機(jī)制，但是它可能只使用ACK或者NAK，而SRT既是用ACK也使用NAK。

2.5 ARQ和FEC的對比

上圖是ARQ機(jī)制和FEC機(jī)制的對比。

l假設(shè)發(fā)生了數(shù)據(jù)包丟失，我們不做糾錯(cuò)和控制，那丟包就是無法挽回的了。

l但如果使用FEC機(jī)制，那么接收端就會(huì)通過一定的算法來恢復(fù)，當(dāng)然FEC對于丟包的恢復(fù)有一定的上限，并且占用一定的額外帶寬。

l如果是ARQ機(jī)制，就會(huì)返回一個(gè)重發(fā)請求，發(fā)送端接收到請求之后便會(huì)重發(fā)該數(shù)據(jù)包。

2.6 SRT協(xié)議流程圖

經(jīng)常使用SRT的朋友一定對SRT中常用的“呼叫監(jiān)聽”模式很熟悉。一方是呼叫方(Caller)，另一方是監(jiān)聽方(Listener)，雙方在連接成功之后，這兩個(gè)角色便失效了，雙方又恢復(fù)到發(fā)送端和接收端的角色。

如圖所示，SRT在第一次握手往返時(shí)只是簡單地交換一下cookie。第二個(gè)往返就會(huì)交換很多參數(shù)，比如版本、加密方式、雙向延時(shí)量、StreamID等參數(shù)。開始傳輸之后，數(shù)據(jù)包首部就帶有時(shí)間戳，另外還會(huì)交換很多控制數(shù)據(jù)，例如ACK、NCK、ACKACK（針對肯定應(yīng)答的肯定應(yīng)答）、Keepalive，Shutdown。

通過這個(gè)簡略的流程圖，我們可以知道SRT是如何工作的，另外我們也可以看到數(shù)據(jù)包結(jié)構(gòu)的雛形，首先它有一個(gè)傳輸有效數(shù)據(jù)的信息數(shù)據(jù)包，當(dāng)然還有控制數(shù)據(jù)包，例如握手、ACK、NAK、ACKACK、Keepalive和Shutdown包。

2.7 SRT協(xié)議數(shù)據(jù)包

SRT中有四個(gè)比較重要的數(shù)據(jù)包類型，咱們從數(shù)據(jù)包結(jié)構(gòu)來學(xué)習(xí)SRT協(xié)議有助于在實(shí)際工作中檢測鏈路狀態(tài)，或者是進(jìn)行故障排除。

2.7.1 SRT協(xié)議數(shù)據(jù)包結(jié)構(gòu)

首先SRT的首部是緊跟在UDP首部之后的，SRT首部第一個(gè)標(biāo)志位為0代表該數(shù)據(jù)包是信息數(shù)據(jù)包。

數(shù)據(jù)包序列號字段：每發(fā)送一個(gè)數(shù)據(jù)包，數(shù)據(jù)包序列號的字段便會(huì)加1。序列號起始數(shù)值是隨機(jī)生成，并不是從零開始計(jì)數(shù)。

報(bào)文序號字段：從零開始獨(dú)立計(jì)數(shù)，在Live模式中用處不大。前面的四個(gè)標(biāo)志位分別有其含義，具體如圖所示。

時(shí)間戳字段：以連接建立時(shí)間(StartTime)為基準(zhǔn)的相對時(shí)間戳（精確到微秒）。

2.7.2 握手包

上圖簡略展示了SRT握手包的結(jié)構(gòu)，它省略了加密擴(kuò)展模塊和配置擴(kuò)展模塊。

第一行標(biāo)志位為1表示控制數(shù)據(jù)包，控制類型為0表示握手包。

版本字段：SRT的握手分為兩個(gè)版本：HSv4和HSv5。SRT1.3版本之后都是HSv5，之前都是HSv4，并且HSv5向前兼容HSv4。

加密標(biāo)志位EncrFld：表示了加密的類型。

擴(kuò)展標(biāo)志位ExtFld：表示了有哪些擴(kuò)展模塊。

數(shù)據(jù)包序列號初始值字段：該初始值是隨機(jī)生成的，這樣握手的時(shí)候，雙方就知道從哪里開始計(jì)數(shù)。

MTU字段：最大數(shù)據(jù)包長度。

FC字段：滑動(dòng)窗口的大小。

握手類型字段：在連接成功的時(shí)候意義不大，但是在連接失敗的時(shí)候會(huì)給出錯(cuò)誤碼，告訴我們?yōu)槭裁词?#xff0c;圖左下角是錯(cuò)誤碼對照表。

同步cookie字段：由listener的主機(jī)、端口和當(dāng)前時(shí)間生成，精度1分鐘。

握手請求和握手響應(yīng)拓展模塊是比較重要的擴(kuò)展模塊，其字段含義如下：

SRT版本：可以是1.3、1.4或者更老的版本。

SRT標(biāo)志位：8個(gè)標(biāo)志位實(shí)現(xiàn)了SRT的不同模式和功能。

發(fā)送方向延時(shí)和接收方向延時(shí)：SRT協(xié)議1.3版本實(shí)現(xiàn)了雙向傳輸功能，雙向傳輸可以分別設(shè)定不同方向的延時(shí)量。對于常規(guī)的單向傳輸，假設(shè)A向B發(fā)送數(shù)據(jù)，該方向的延時(shí)量Latency應(yīng)該是A的發(fā)送方向延時(shí)(PeerLatency)和B的接收方向延時(shí)(RecLatency)的最大值，該延時(shí)量在握手階段就已由雙方協(xié)商確定。

2.7.3 ACK包

ACK數(shù)據(jù)包最初是為了返回肯定應(yīng)答，但SRT中添加了許多鏈路信息和對鏈路的預(yù)測。這里控制類型為2便表示ACK包。

附加信息字段：包含有單獨(dú)的ACK序列號，用于讓ACK包和ACKACK包一一對應(yīng)，從而計(jì)算出RTT（鏈路往返時(shí)延）。

最近一個(gè)已接收數(shù)據(jù)包的序列號+1：如該字段為6，便表示前5個(gè)包都已收到。

RTT估值字段：SRT會(huì)估算RTT。

RTT變化量：SRT會(huì)對一段RTT進(jìn)行統(tǒng)計(jì)，估算出RTT估值的變化量，這個(gè)變化量也顯示了RTT的波動(dòng)程度，一個(gè)良好鏈路的RTT一般相對穩(wěn)定。

接收端的可用緩沖數(shù)據(jù)：接收端緩沖區(qū)中可用的數(shù)據(jù)越大越好。

ACK數(shù)據(jù)包還會(huì)對鏈路帶寬和接收端的下行帶寬進(jìn)行估算。

ACK里的鏈路數(shù)據(jù)非常豐富，對于使用者和開發(fā)者來說都是非常好的。使用者可以通過此獲得很多有用的信息，開發(fā)者可以依此做一些擁塞控制。

2.7.4 NAK包

控制類型為3代表NAK數(shù)據(jù)包。NAK包中的丟失列表有兩種信息：單個(gè)丟包序列號和連續(xù)丟包序列號，如果是連續(xù)丟包，就需要列出起始序列號和截至序列號。

值得注意的一點(diǎn)是，SRT協(xié)議中的NAK都是發(fā)兩次的，一般情況是在丟包時(shí)就發(fā)送NAK，但是還會(huì)定期重發(fā)NAK隊(duì)列，這樣做主要是為了防止在反向傳輸中NAK包丟包的概率。

2.7.5 實(shí)際運(yùn)用

以上說了那么多枯燥的數(shù)據(jù)包結(jié)構(gòu)知識(shí)，主要是為了能在實(shí)際工作中運(yùn)用。下面我們使用一個(gè)視頻來說明怎樣判斷一個(gè)鏈路的故障。當(dāng)出現(xiàn)鏈路沒聯(lián)通的情況，我們可以使用Wireshark進(jìn)行抓包分析。當(dāng)發(fā)現(xiàn)里面全是握手包之后，說明握手沒有成功，但另外一個(gè)方面也說明了IP和端口號設(shè)置是正確的。

在握手中出了問題，我們首先要找到第一個(gè)握手包。在SRT中所有的第一個(gè)握手包，出于兼容性問題的考慮都是HSv4版本的握手包。在找到第一個(gè)握手包之后，由于是兩次往返，所以需要往下數(shù)第四個(gè)握手包，可以看到錯(cuò)誤類型是1002，1002表示對端拒絕。當(dāng)然這個(gè)錯(cuò)誤碼給的是比較含糊的，我們還要繼續(xù)分析。

在第二個(gè)監(jiān)聽方發(fā)給呼叫方的握手包里面看到了要求。可以看到這里它的加密標(biāo)志位是02，02表示AES-128，即要求對方以AES-128方式來加密。

接下來我們在下一個(gè)握手包里看有沒有響應(yīng)，也就是看握手包里有沒有加密的擴(kuò)展模塊。擴(kuò)展標(biāo)志位是01，01表示只有響應(yīng)擴(kuò)展模塊，沒有加密擴(kuò)展模塊，也沒有配置擴(kuò)展模塊。

這里其實(shí)就破案了，Listener要求加密，但Caller并沒有以加密的形式做響應(yīng)。之后我們要做的Caller以AES-128的模式進(jìn)行加密，并且需要知道對方的密碼。以上是一個(gè)非常簡單的例子，演示了了我們在實(shí)際工作中怎樣運(yùn)用數(shù)據(jù)包結(jié)構(gòu)的知識(shí)進(jìn)行故障分析。

3

SRT在5G直播中的運(yùn)用

3.1 安徽省首次5G直播

接下來我們來看看SRT在5G直播中的應(yīng)用。去年年初安徽廣播電視臺(tái)完成了安徽省首次5G直播，電視臺(tái)以前的直播形式都是以衛(wèi)星和光纖為主，特點(diǎn)是價(jià)格昂貴，但是非常可靠。隨著現(xiàn)在網(wǎng)絡(luò)條件越來越好，也有5G網(wǎng)絡(luò)做為支撐，我們使用SRT來作為主路傳輸，備路為衛(wèi)星和其他協(xié)議來實(shí)現(xiàn)直播，另外還使用SRT構(gòu)建了一個(gè)回傳鏈路，方便節(jié)目的制作。

這是5G直播的設(shè)備示意圖。這里需要說的是由于SRT的開源特性，它在工作中使用起來是非常方便的，和其他的單位或公司對接也相當(dāng)便捷。因?yàn)樗粫?huì)區(qū)分品牌、軟件/硬件編碼器等等。比如我們安徽廣播電視臺(tái)的這次5G直播，使用了三個(gè)品牌的SRT的設(shè)備。

3.2 鏈路安全冗余量

第一次在大型的直播中使用SRT鏈路我們內(nèi)心也是很忐忑的，衛(wèi)星和光纖我們可以通過一些指標(biāo)去判斷鏈路是否安全可靠，但SRT鏈路并沒有相應(yīng)的指標(biāo)。我們通過一些學(xué)習(xí)和測試，提出了安全冗余量(Secure-Margin)的概念，可以用來衡量SRT鏈路的安全可靠程度。

3.2.1 延時(shí)量

在此之前還是要聊一聊延時(shí)量，從而引入鏈路安全冗余量的概念。咱們之前說過延時(shí)量實(shí)際上決定了緩存區(qū)的大小，而且雙方都需要知曉延時(shí)量。

延時(shí)量是在接收端產(chǎn)生的，但是發(fā)送端也需要知曉。舉個(gè)不恰當(dāng)?shù)睦?#xff0c;隔壁老王對你說：“兄弟，江湖救急，禮拜五24:00之前我需要一筆錢。”那么你就知道了，他需要這筆錢的時(shí)限是在禮拜五24:00之前（相當(dāng)于雙方都知曉了延時(shí)量）。如果你恰巧在禮拜五24:00的時(shí)候才剛剛湊到了錢，那么你已經(jīng)知道，即使現(xiàn)在你把錢送給老王也來不及了（因?yàn)樗湾X也需要RTT/2的時(shí)間）。那么你會(huì)怎么做呢，就是默默的把錢收好不給隔壁老王了：）

這種情況在SRT里面有一個(gè)對應(yīng)機(jī)制叫做：過遲丟棄TLPD(Too Late Packet Drop)，指在發(fā)送端會(huì)主動(dòng)丟棄一些數(shù)據(jù)包。雙方都知道延時(shí)量，發(fā)送方知道即使數(shù)據(jù)包發(fā)過去也過期了，就直接將其丟棄。本質(zhì)原因是：我們是在進(jìn)行實(shí)時(shí)視音頻傳輸，而不是傳文件。

另外雙方都知曉延時(shí)量還有一個(gè)用處。比如說我是老王，我在禮拜五24:00之前還沒有收到錢，那么我也明白即使24:00之后你再給我錢也沒有用了。但是做人留一線，日后好相見：）那么我會(huì)給你回個(gè)信息，告訴你錢已經(jīng)湊夠了不用擔(dān)心了（實(shí)際上沒湊夠）。

對應(yīng)到SRT協(xié)議，接收端會(huì)在估算到這個(gè)包已經(jīng)來不及重傳的情況下，返回一個(gè)肯定應(yīng)答ACK給發(fā)送端，而不是否定應(yīng)答NAK。

3.2.2 緩沖區(qū)狀態(tài)圖

上圖是緩沖區(qū)狀態(tài)圖，包括了發(fā)送端緩沖區(qū)和接收端緩沖區(qū)。延時(shí)量就像窗口一樣在向前滑動(dòng)。隨著延時(shí)量窗口的滑動(dòng)，發(fā)送端過期的包就會(huì)被丟棄，就也是剛剛所說的過遲丟棄TLPD。另外隨著窗口的滑動(dòng)，接收端滑出窗口的包就會(huì)被送給解碼器。

接收端接收到第6號包之后會(huì)返回一個(gè)ACK，發(fā)送端接收到ACK之后會(huì)將2-6號數(shù)據(jù)包都從緩沖區(qū)踢走。這張圖是一個(gè)非常好的鏈路狀態(tài)，發(fā)送端緩沖區(qū)里面只有很少的數(shù)據(jù)，說明數(shù)據(jù)發(fā)出去之后經(jīng)過了很短的時(shí)間就收到了肯定應(yīng)答，鏈路狀況良好。另外接收端緩沖區(qū)里面充滿了數(shù)據(jù)，也說明鏈路狀態(tài)很好。

這張圖是不太理想的鏈路狀態(tài)。如圖在收到第4號包的時(shí)候，接收端便意識(shí)到3號包沒有收到，并返回了一個(gè)NAK。比較幸運(yùn)的是3號包還在發(fā)送端窗口的邊沿，還沒有被丟棄，這時(shí)候重傳或許還來得及。但是這個(gè)時(shí)候。鏈路已經(jīng)處在出錯(cuò)邊緣的狀態(tài)，這不是一個(gè)好的鏈路狀態(tài)。

同時(shí)可以看到發(fā)送端緩沖區(qū)里充滿了數(shù)據(jù)，說明這些數(shù)據(jù)都沒有收到肯定應(yīng)答，而接收端緩沖區(qū)里又幾乎沒有什么數(shù)據(jù)。

我再來解釋一下為什么說接收端緩沖區(qū)里面的數(shù)據(jù)要越多越好。例如，有一位叫解碼器的朋友去吃自助餐，他的胃口時(shí)大時(shí)小，是動(dòng)態(tài)碼率VBR。同時(shí)網(wǎng)絡(luò)帶寬有波動(dòng)，上菜時(shí)快時(shí)慢。那么接收端緩沖區(qū)里的數(shù)據(jù)（餐盤里的食物）當(dāng)然是越多越好，如果數(shù)據(jù)很少的話，很可能沒有辦法應(yīng)對相應(yīng)的波動(dòng)。

3.2.3 發(fā)送端鏈路狀態(tài)圖

至此我們嘗試總結(jié)出安全冗余量(Secure-Margin)的概念。首先我們看一下發(fā)端緩沖區(qū)冗余量(SendBuffer-Margin)，圖中橙紅色的線是延時(shí)量Latency，同時(shí)也是緩沖區(qū)的最大值。如果發(fā)送緩沖區(qū)用量超過這個(gè)值就表示鏈路可能出錯(cuò)。

這是我們5G直播中的鏈路狀態(tài)截圖，在前一段時(shí)間鏈路狀態(tài)還是不錯(cuò)的，后半段發(fā)生了一些波動(dòng)，但是距離鏈路出錯(cuò)還有一些距離，這一段距離就是發(fā)送端緩沖區(qū)冗余量。圖下方是發(fā)送端緩沖區(qū)冗余量的公式，實(shí)際工作中我們更多是依靠鏈路狀態(tài)圖來做監(jiān)測。

3.2.4 接收端鏈路狀態(tài)圖

下面咱們來看接收緩沖區(qū)冗余量(ReceiveBuffer-Margin)，接收端緩沖區(qū)比較好的狀態(tài)應(yīng)該是緩沖區(qū)用量沿著Latency這條黑色的線波動(dòng)，說明咱們家里的存糧很多。圖中可以看到某些時(shí)間點(diǎn)緩沖區(qū)數(shù)據(jù)被消耗很多，但還是有余量的，這些余量就是接收端緩沖區(qū)冗余量。

圖下方是接收端緩沖區(qū)冗余量的公式，接收端緩沖區(qū)的冗余量和發(fā)送端緩沖區(qū)的冗余量是相互影響的，兩者我們都需要參考，并且選擇一個(gè)比較差的作為鏈路的安全冗余量，這樣就可以判斷出我們鏈路是否安全以及安全程度，也就是距離鏈路出錯(cuò)還有多少距離。

在了解如何判斷SRT鏈路是否安全后，咱們還要學(xué)會(huì)怎么把它調(diào)整到安全的狀態(tài)。架設(shè)SRT鏈路之前，首先要通過相應(yīng)工具獲知網(wǎng)絡(luò)帶寬、丟包率和RTT。

3.3 Lantency

在知道RTT之后就可以根據(jù)鏈路參數(shù)計(jì)算出Latency。Latency是SRT協(xié)議的核心參數(shù)，具體計(jì)算參見圖片，圖中的“RTT乘數(shù)”實(shí)際上代表鏈路可以完成多少次重傳。

通過圖中的公式就可以得到延時(shí)量的建議值，但我們建議還是要進(jìn)行長時(shí)間的測試，觀看鏈路的安全冗余量以及狀態(tài)圖來找出一個(gè)最終合適的延時(shí)量。當(dāng)然，也需要根據(jù)直播的場景對延時(shí)的敏感度，也就是直播場景的需求做具體的判斷。

3.3.1 SRT鏈路丟棄的數(shù)據(jù)包和RTT乘數(shù)的關(guān)系

上圖能幫助我們更好的了解SRT鏈路丟棄的數(shù)據(jù)包和RTT乘數(shù)的關(guān)系。兩條鏈路初始丟包率分別是4%和8%。可以看到在RTT乘數(shù)為1的時(shí)候沒有恢復(fù)的數(shù)據(jù)非常多，實(shí)際上鏈路的丟包率越高就需要越大的RTT乘數(shù)。

這主要是針對RTT沒有波動(dòng)的鏈路來設(shè)計(jì)的一個(gè)RTT乘數(shù)，如果鏈路有波動(dòng)，實(shí)際的RTT會(huì)更復(fù)雜。在考慮鏈路波動(dòng)的情況下，應(yīng)該以波動(dòng)上限進(jìn)行參數(shù)計(jì)算，實(shí)際工作中我們架設(shè)的SRT鏈路都是經(jīng)過了很多輪的測試和調(diào)整的。

3.3.2 延時(shí)量總結(jié)

我們針對SRT的延時(shí)量進(jìn)行了一些總結(jié)：

在鏈路其他參數(shù)固定的情況下，提高延時(shí)量，安全冗余量會(huì)隨之增大，當(dāng)然我們也需要關(guān)注直播場景對延時(shí)的敏感程度。

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

延時(shí)量參數(shù)并不是傳輸鏈路的端到端延時(shí)，估算端到端延時(shí)還需要考慮編碼延時(shí)、解碼延時(shí)以及RTT。

體育比賽這類直播需要很低的端到端延時(shí)，因?yàn)橛^眾一定不希望從鄰居的歡呼聲或者朋友圈得知進(jìn)球，這種情況需要我們非常仔細(xì)的權(quán)衡延時(shí)量和安全冗余量，從而找到一個(gè)折衷的參數(shù)。以這次5G直播為例，在保證充足安全冗余量的情況下，端到端延時(shí)只有0.5s左右，遠(yuǎn)小于衛(wèi)星鏈路的延時(shí)。

3.4 帶寬開銷

前面說了SRT的很多優(yōu)點(diǎn)，但其實(shí)沒有一種協(xié)議是完美無缺的。某種程度上來說，SRT是用帶寬來換取對丟包和抖動(dòng)的恢復(fù)能力，那么就會(huì)有一些額外的帶寬開銷，帶寬開銷(BW Overhead)參數(shù)就是用來設(shè)置這部分額外開銷。

帶寬開銷是一個(gè)百分比參數(shù)，計(jì)算基數(shù)為TS流比特率，默認(rèn)值為25%，實(shí)際可設(shè)置為5%-50%，這部分額外帶寬被用作重傳數(shù)據(jù)包、傳輸反向控制數(shù)據(jù)。據(jù)SRT大聯(lián)盟測算每丟失一個(gè)數(shù)據(jù)包都會(huì)在消耗400b的反向傳輸帶寬。

3.4.1 帶寬開銷示意圖

這張圖可以幫我們更好地理解帶寬開銷的功用。鏈路崩潰時(shí)，我們需要使用緩沖區(qū)的數(shù)據(jù)，當(dāng)鏈路恢復(fù)后，就需要利用帶寬開銷來彌補(bǔ)對于緩沖區(qū)數(shù)據(jù)的消耗，彌補(bǔ)的過程被稱為突發(fā)期(BurstTime)。經(jīng)過突發(fā)期之后，鏈路又恢復(fù)了正常傳輸。需要注意的是圖中A和B的面積是相等的，這會(huì)導(dǎo)出一個(gè)關(guān)于帶寬開銷的公式（下文會(huì)給出）。

鏈路可用帶寬=流比特率*(1+帶寬開銷)。但實(shí)際上，SRT聯(lián)盟還是建議留一些余量，其建議的鏈路可用帶寬=流比特率*(1+帶寬開銷)*1.33。假設(shè)使用HEVC方式編碼超高清視頻，TS流比特率為40Mbps，帶寬開銷為25%，鏈路可用帶寬應(yīng)高于建議值為66.5Mbps。

可能會(huì)有人覺得這個(gè)帶寬還是很大，但對于需要使用SRT協(xié)議的傳輸工作來說，這個(gè)帶寬還是可以接受的，因?yàn)椴⒉皇且笫謾C(jī)端具備這個(gè)帶寬，更多還是在節(jié)目制作和節(jié)目傳輸中使用的帶寬（BtoB）。

區(qū)域A和區(qū)域B的面積必須相等，因此SRT鏈路能夠容忍的網(wǎng)絡(luò)中斷時(shí)間為延時(shí)量*帶寬開銷。實(shí)際上綜藝晚會(huì)或者政府會(huì)議這類對延時(shí)并不敏感的直播工作，就可以考慮充分利用延時(shí)量和帶寬開銷這兩個(gè)參數(shù)來大幅度增強(qiáng)鏈路的可靠性。假設(shè)我們在這種情況下設(shè)置延時(shí)為8000ms，帶寬開銷為50%，那么網(wǎng)絡(luò)中斷低于四秒鐘都不會(huì)影響SRT鏈路的正常工作，這一特性甚至是衛(wèi)星和光纖鏈路都不具備的。

3.5 MTU最大傳輸單元

有時(shí)候我們在5G直播中MTU也會(huì)出現(xiàn)問題。正常來說MTU默認(rèn)值是1500，考慮VLAN包頭可設(shè)置為1496。一般情況MTU最小值：188*7+20+8+16=1360。但在5G直播中與中興工程師對接時(shí)遇到的問題是，5G核心網(wǎng)的MTU要求為1320，MTU設(shè)置不一致會(huì)發(fā)生問題。我們的解決方法是級聯(lián)了一臺(tái)路由器，當(dāng)然也可以在編/解碼器端設(shè)置，SRT實(shí)際在握手階段就已經(jīng)同步MTU信息了。

總結(jié)一下，這一節(jié)我們提出了SRT鏈路安全冗余量(Secure-Margin)的概念，并介紹了在不同應(yīng)用場景下如何調(diào)整延時(shí)量參數(shù)和帶寬開銷參數(shù)。

4

遠(yuǎn)程制作

4.1 遠(yuǎn)程制作介紹

遠(yuǎn)程制作現(xiàn)在在廣電領(lǐng)域很火，那到底什么是遠(yuǎn)程制作呢？我們傳統(tǒng)領(lǐng)域的節(jié)目制作，所有的攝像師、現(xiàn)場人員、導(dǎo)播、切換設(shè)備都需要遷移至現(xiàn)場，這樣會(huì)導(dǎo)致人力資源和資金的浪費(fèi)。

遠(yuǎn)程制作的機(jī)位和切換中心可以通過廣域網(wǎng)甚至光纖來連接，第一可以節(jié)省一部分費(fèi)用，第二可以節(jié)省人力資源，第三同樣的工作人員可以完成多場制作，提升了效率，而且可以完成以前完不成的任務(wù)。

4.2 遠(yuǎn)程制作實(shí)例

接下來看一個(gè)超級鐵人三項(xiàng)的視頻，這個(gè)賽事在中國大陸的首次直播是由安徽廣播電視臺(tái)承擔(dān)的，該賽事全程是226公里，所以我們以SRT技術(shù)為基礎(chǔ)完成了遠(yuǎn)程制作。

這些短視頻的是在現(xiàn)場實(shí)時(shí)剪輯的，正是得益于遠(yuǎn)程制作的模式，我們可以把所有的信號匯集在一起，才有可能完成這些短視頻的實(shí)時(shí)剪輯。首先SRT傳輸?shù)男盘栠M(jìn)入慢動(dòng)作系統(tǒng)，得到高光時(shí)刻的粗剪后，立刻就送到了短視頻制作團(tuán)隊(duì)-ASVS團(tuán)隊(duì)，之后會(huì)制作出一個(gè)短視頻的集錦，在賽事進(jìn)行的過程中就已經(jīng)發(fā)布了出去。

這次直播給我們帶來的體驗(yàn)是，如果使用對的技術(shù)或者說有一個(gè)好的技術(shù)基礎(chǔ)，會(huì)給你帶來許多意想不到的效果。

接下來具體介紹一下這個(gè)超級鐵人三項(xiàng)賽事。全程226公里，賽道涉及山地、公路和公開水域。如果采用傳統(tǒng)的轉(zhuǎn)播方式可能需要兩到三臺(tái)轉(zhuǎn)播車，信號無法匯集到一起，還需要海量的人員和設(shè)備。

而實(shí)際上我們只采用一臺(tái)轉(zhuǎn)播車和兩個(gè)信號匯聚點(diǎn)，實(shí)現(xiàn)了13個(gè)機(jī)位。我們把轉(zhuǎn)播車和媒體中心放在一起，另外設(shè)置了換項(xiàng)區(qū)和入水點(diǎn)的信號中轉(zhuǎn)點(diǎn)，使用SRT技術(shù)把所有信號匯總至轉(zhuǎn)播車，并設(shè)置統(tǒng)一的固定延時(shí)量(Latency)。

上圖是入水點(diǎn)的工作圖。我們設(shè)置了很多機(jī)位，包括水上機(jī)位、空中機(jī)位、移動(dòng)跟拍機(jī)位和固定機(jī)位，由該信號匯聚點(diǎn)統(tǒng)一收集這些機(jī)位，并利用SRT技術(shù)將其傳輸至轉(zhuǎn)播車。

換項(xiàng)區(qū)也是非常精彩的，選手出水后能夠以非常快的速度將泳裝換成自行車服，然后騎上自行車進(jìn)行下一項(xiàng)賽事，整個(gè)過程一氣呵成，行云流水，是超級鐵三賽事的亮點(diǎn)之一。所以這個(gè)區(qū)的信號采集也是非常重要的，我們使用了SRT技術(shù)與轉(zhuǎn)播車聯(lián)通。

4.3 感想

良好的技術(shù)基礎(chǔ)像一粒種子，除了完成既定任務(wù)之外，它還會(huì)帶給你一些意想不到的驚喜。比如這次我們同步進(jìn)行短視頻的制作，在節(jié)目直播的時(shí)候?qū)崟r(shí)短視頻就已經(jīng)發(fā)布出去，同時(shí)炒熱了整個(gè)直播活動(dòng)，形成了一個(gè)線上線下的互動(dòng)。

這些都得益于我們能夠把所有信號都匯聚到一起，以前想實(shí)現(xiàn)這樣的信號匯聚是非常困難的，所以良好的技術(shù)基礎(chǔ)是非常重要的。

5

總結(jié)

最后來做一個(gè)總結(jié)：

• 電視直播其實(shí)是要求低延時(shí)、高質(zhì)量、高可靠的視音頻傳輸。

• SRT通過ARQ糾錯(cuò)和基于時(shí)間戳的數(shù)據(jù)包傳送(TSBPD)，實(shí)現(xiàn)了點(diǎn)對點(diǎn)的實(shí)時(shí)視音頻傳送，并保證了低延時(shí)和高質(zhì)量。

• SRT協(xié)議的數(shù)據(jù)包結(jié)構(gòu)分析和應(yīng)用，這一點(diǎn)也是非常重要的。

• 我們嘗試提出SRT協(xié)議安全冗余量(Secure-Margin)的概念，可以依此判斷一個(gè)SRT鏈路安全可靠的程度。

• 另外還需要學(xué)會(huì)調(diào)整延時(shí)量Latency，保證安全冗余量的同時(shí)滿足不同的直播場景對延遲的需求，不同直播場景有不同的設(shè)置策略，

• 當(dāng)然在遠(yuǎn)程制作中SRT也有著豐富的應(yīng)用前景。

SRT學(xué)習(xí)資料鏈接：

https://pan.baidu.com/s/13elUntfkeQ0qj66UabJt1g 提取碼：vvrw

編解碼的新挑戰(zhàn)與新機(jī)會(huì)

人生總會(huì)面對諸多選擇，若要實(shí)現(xiàn)超高清的畫面，全景或沉浸式的視頻體驗(yàn)，就需要對編碼效率、時(shí)延和畫質(zhì)提出更高的要求，因此，編碼器的選擇也變得尤為重要。本次LiveVideoStackCon 2020 北京站我們也將邀請講師討論編解碼方面的挑戰(zhàn)與機(jī)遇，點(diǎn)擊【閱讀原文】可了解更多講師及話題信息。

---

LiveVideoStackCon 2020?北京

2020年10月31日-11月1日

點(diǎn)擊【閱讀原文】了解更多講師及話題信息

總結(jié)

以上是生活随笔為你收集整理的SRT协议在电视直播中的应用的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。